-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Convert module to v3 format #4
Conversation
instance.prototype.destroy = function() { | ||
var self = this; | ||
incomingData(data) { | ||
this.log('debug', data) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we now have log rotation, but nevertheless logging every piece of incoming data will pollute the log
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm assuming/I don't believe there is much returned data (aside from possibly the version command which I've currently not implemented). I don't currently have a running older release with Telnet, but I was migrating the module to v3 before trying to add the current (beta) OSC support.
index.js
Outdated
|
||
if (self.socket !== undefined) { | ||
self.socket.destroy(); | ||
this.updateStatus(InstanceStatus.Ok, 'Received data') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should not update the status on every incoming data, only when the status has to change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't see a way to get the current status, do I have to double track it locally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it depends on how the module makes use of the status and how it depends on the device or communication. We just want to make sure there is no flooding of status updates (possible DoS).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added some basic functionality, but it seems very backwards to me that companion-module-base couldn't deal with this under the hood using effectively the same code, to save each module author having to reinvent the wheel.
index.js
Outdated
case 'pause': | ||
cmd = 'pause'; | ||
break; | ||
if (self.config.host) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should check for existance and validiy of host and port
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What exactly do you mean, won't the Regex handle that? Do you just mean not undefined, or do we need to check it's not an empty string too? I've added the port at least.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes and no. In actions or feedbacks the regex is just a visual hint, in the configuration you can't hit save if the regex doesn't match. This check in the config has not been there from the start so there may be configurations with illegal data. Also some users edit the configuration database by hand. It is always a good idea to do some extra checks. Minimum goal is that the module doesn't crash if it gets invalid data. You can go as complicated as you want. Best would be to do the regex again and do a status update and error logging if it fails.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So it turns out I'd not changed from this.REGEX_IP
to Regex.IP
and it was silently dropping all regex checks in the config, without throwing any errors during build, so that was a good fix at least.
Can you point me at another module that does this I could learn from, I've got something that actually works (but haven't committed it), after the obvious thing didn't work because a regex string needs foo
whereas a regex literal needs /foo/
in JS!
Again it feels like we want to nick a chunk of:
https://github.com/bitfocus/companion/blob/master/webui/src/Components/TextInputField.jsx#L56-L66
Into companion-module-base if we're going to do this, and fetch the config from getConfigFields, so I just pass in the field name, and maybe the variable, and it gives me a boolean result, again rather than everyone reinventing the wheel badly/with different edge cases.
Thanks @dnmeid . As you can probably tell I'm not a JS expert (or at least not anything as modern as this) so thanks for the pointers. This is also my first time working on a companion module. As a general thought, given there's a fairly finite number of common comms methods (e.g. TCP, UDP, Telnet, HTTP, OSC), are there, or would there be benefit in, some basic starter/template modules people could work from, without all the complexity of say the generic ones, and that might have less bad habits than working from other existing modules? |
Don't worry if it is not perfect from the start. It will never be. After each release you will find things to improve.
That would be nice, but we need somebody to do it. It is allready a lot of work to code new features, find bugs, review PRs, update modules, give support to developers and users, write documentation... |
Yeah fair point, in which case to turn that slightly on its head, as a developer of a new module I want to find a good HTTP example to work from say, without lots of trawling through code, its hard to know which modules talk via HTTP, so could there be a list of the top few HTTP based modules for me to go and look at? Obviously likewise for other high level protocols. Which is fairly minimal extra effort and might remove some of the developer support required. Plus then at least someone will be starting from a good base rather than the first one they come across which might have lots of issues... |
Create dependabot.yml
Revert "Create dependabot.yml"
Revert "Revert "Create dependabot.yml""
Try and check dev dependencies too
Bumps [@companion-module/tools](https://github.com/bitfocus/companion-module-tools) from 0.5.2 to 1.2.1. - [Release notes](https://github.com/bitfocus/companion-module-tools/releases) - [Changelog](https://github.com/bitfocus/companion-module-tools/blob/main/CHANGELOG.md) - [Commits](bitfocus/companion-module-tools@v0.5.2...v1.2.1) --- updated-dependencies: - dependency-name: "@companion-module/tools" dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [@companion-module/base](https://github.com/bitfocus/companion-module-base) from 1.0.2 to 1.4.1. - [Release notes](https://github.com/bitfocus/companion-module-base/releases) - [Changelog](https://github.com/bitfocus/companion-module-base/blob/main/CHANGELOG.md) - [Commits](bitfocus/companion-module-base@v1.0.2...v1.4.1) --- updated-dependencies: - dependency-name: "@companion-module/base" dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
…ion-module/base-1.4.1 Bump @companion-module/base from 1.0.2 to 1.4.1
…ion-module/tools-1.2.1 Bump @companion-module/tools from 0.5.2 to 1.2.1
Merge my master changes back into v3
My first time doing this, and I've not tested against the software, but the expected commands appear in a Telnet window.
I figured this was a good way to start before looking at #2 / #3