TODOs

[OKNoah]

Shorter-term

• One of the biggest features is left out at the moment, which is the simple data modelling right in the component. Now we're using flow-runtime's somewhat odd validation API. I have taken to storing the schema in another file (importing from examples/data-model.js for some other examples/tests). The API for this should be so simple that there's no need for this. The holdup is that flow-runtime does not work with Babel@7 yet, so when it does I'll revisit this.

• At the moment there's a bug in the gamer-server.js example that updates with the previous props, not the newest, for some reason.

• Routes should probably resolve on the first match. This way we can have 404 pages like createServer({ components: [User, Error404] }) where Error404 is just a component that returns a 404 page/error.

• Determine what to do with "middleware" (if anything). One use case is letting the user replace co-body (the POST body-parser we use) with a multi-part compatible one. Or perhaps some sort of authentication that would be tedious to apply to all routes. Or redux middleware.

• Create a this.props.send action that sends either the WebSockets response of HTTP response depending on which is active.

• The lifecycle management (currently in updater.js) is not very elegant. I had spent a lot of time trying to make this more interesting. I looked at React a bit too. For now it's basically spaghetti code. There are some remnants of my earlier "elegant" solution in Component.lifecycle and Component.lifcycleIncrement and .tick(), which should either be brought back or removed.

• There isn't currently a way to add a unique constraint on a model. Normally this would be done when you define a schema. But since we're going to (try) use flow-type to define our schema, I don't think this is possible. There may need to be a uniques = ['myFieldName', 'email'] type property on the class.

• In-component tests. Having something like a tests (t) function that runs tape or another test utility when run. Then providing a command to automatically run tests from within that function. This may require a CLI tool (added below).

Longer-term

• Go dependency-free. For security we should be dependency-free in production.

• Separate Arango decorator from package. Perhaps use the lerna method.

• Foxx-compatability/Foxx version. I would like to try use this library in ArangoDB's Foxx platform. It was one of the reasons for starting the project.

• Command-line tool. This would be necessary for the tests idea above. But it could also be used to run the server from a folder of components without the createServer method needing to be in the code. It could also be used to create projects from the examples, e.g. final new or final new game-server. This satisfies my goal of Final being a toolset.