cybrown / web-decorators Goto Github PK

Find something to "mount" other controllers to a current controller, so the app would be a tree of Controller linking each other.

A PropertyDecorator might be used for that purpose.

• Add cookie attribute in ResponseMetadata
• Make the express adapter to send the cookies

• Use next if a thunk returns an error
• Use next if a promise returns an error

Use bluebird's when to detect a promise

Add error handler in controllers ?

Maybe something like spring's controller advice ?

• send a file
• send a file as an attachement
• do a permenant / temporary redirection
• Access denied
• Not authorized
• 500 Error
  ...

Use https://www.npmjs.com/package/route-parser for route matching, implement the concept of routes and middlewares.

• Create the main handler function to give to http#createServer()
• Create the structure that takes the methods and patterns
• Create the api to add routes to the route container
• On request, dispatch the request to the right handler, from the pattern and method
• Extract path params from the request
• Extract query string params from the request
• Provide an API to read the request body
• Add response related tasks
• Add middleware related tasks

For the moment, the result is sent as is, it should be possible to force a return type.

How to provide the typing information through an npm package ?

• Create .npmignore file
• Create a dist .d.ts type definition file
• Normalize the public interface
• Add express adapter in the public interface

A controller is bootstrapped (configured with the backend) when it is first encountered by the runtime.
It would be better if the @controller decorator did not contain the backend adapter, and use directly the adapter to add classes that must be parsed.

Moreover, with es6 or commonjs modules, all classes are not loaded at startup, so only adding a @controller alone would not have much effect.

@controller might be merged with @route.

Nice work, Cy 👍

We must inject the response with @ResParam to send content to the client, it would be better to return a result with a return statement, even an asynchronous result via Promise or thunk.

Request handler parameters are not well unit tested

Middlewares are not as integrated into the API as normal routes, for example, parameters are not injected.