daftfox / rev-service Goto Github PK

You can create a env.dev.ts and a env.prod.ts. On a higher level you can then include these libs. Check the way angular does this. might send you of on a better path.

Instances of Board class should allow the pins to be configured during constructing or after. This would allow the boards that don't have a specific class instance (like Major Tom) to be more flexible.

Could also just pass an arrow func to avoid using the bind keyword

Clients should be able to create, read, update and delete programs through the ProgramService

The service contains an executeProgram method allowing consecutive actions to be executed on a board. Such a program would consist of an array of Command class instances with the following structure:

{ action: "BLINKOFF", duration: 3000, parameter: <optional> }

action should correspond with any of the available actions in an instance of the Board class, or any of the extending classes.
duration is the delay (in ms) after which the next command is executed. Therefore being the duration for which a command is valid.
parameter is optional and only required for actions that require a parameter to execute.

The executeProgram method should consume an instance of Board and an array of Command instances.

Can also structure your domain model a bit better if you include models and their allotted mime-types in a different file. Following the single responsibility principle. The http service should just make the request. You would have another entity which just checks allotted mime-types. In the end it makes everything easier to test and also removes added complexity in a specific class.

After refactoring a few times and neglecting to update the SerialService, it needs to be fixed.

A user should be able to create, update and remove programs. For this, I wish to implement the corresponding methods in the ProgramService and a DatabaseService that is able to interface with (at least) an sqlite database. Use Sequelize to create an ORM.

feel free to destructure

({id}) => ...

No need for annotations as they are describing what TS is already doing.

Loving this class name and description. Might want to add a model file to extract state from the class. An enum for this would be perfect.

Try to form consistency between promises and async keywords. This could easily work with async await as well.

Consider treating options as an class argument. It will give you run-time flexibility.

All methods describing non specific behavior should be moved to the default Board class.

Although you are just using this once, makes it a bit more legible to have an interface.

Swap the EtherPort dependency in favor of a custom integration that allows for multiplexing. This would greatly decrease the complexity of the EthernetService and remove the need for an extra dependency.

The database is now included inside of the code repo. Would be best to make a demo folder and include a instance there for reviewing purposes. A simple hello world would be fine. Then include Rev as a node_module (external dep)

This way you can keep the core clean.

The user should be able to execute programs on a board using the WebSocket interface. The user should be able to choose one from a list of programs that are shared with the user as soon as a WebSocket connection is made.

object lookups are fast, but considering you do not have a blazing fast device (IoT) would be best to shorten the lookup by saving the object into a reference

const blabla = this.options
or
const {prop, prop2, prop3} = this.options

Feel free to use destructing

{id, type}

In this file, the annotations add absolutely no value.

Clients connected through the WebSocket interface (and any other) should be able to see the current state of device pins. Update these values and share with connected clients as soon as anything is changed.

Any artifact created from develop should be predictable and not include state. This is why it's beneficial to have anything generated in the public folder (including the folder itself) to be in the build step.

After a board has disconnected it is not automatically cleared from the list of available devices. This is only done after a TCP packet is sent to the (disconnected) device, resulting in an error on the exposed socket. Devices can get disconnected through loss of power, network errors or hardware failure.

Look into creating release cycles with app versioning. It might help with cleaning up merged feature branches.

Consider adding this to a model file as an enum