2 ms·

The project is still 0.5 and it has a lot of cool ideas that most other NodeJS frameworks lack. That being said, here are the things I feel would be worth impro

by voidr 11y ago

The project is still 0.5 and it has a lot of cool ideas that most other NodeJS frameworks lack. That being said, here are the things I feel would be worth improving, based on the first video: Writing tests for the Controllers would be a real pain, because you would have to do a lot of ad hoc mocking, it would be better if the controllers would return something instead of calling the this.render. You might be able to make the the controllers into POJO's. The file naming conventions are weird, mixing camel case coding with underscore filenames is just unnatural. Having a custom 'require' function in the framework, means that any code I write, is dependent on the framework itself. The automatic migration generation is pretty sweet. Coupling the data models with DB configuration is a bad habit. The use of static methods to define aspects doesn't feel natural. Having one big routing file doesn't scale, the routings should be expressed in the controllers. Overall I would recommend adding in TypeScript, it would allow a lot more cleaner code.

keithwhor 11y ago
Thanks for the suggestions, but a lot of the things you dislike were choices made very purposefully. 1. POJOs are ugly and you must revert back to using Object.create() for inheritance, breaking the design pattern of using ES6's class syntax. 2. PascalCase class <-> camelCase instance <-> underscore_filename <-> underscore_tablename is a standard borrowed from Rails and easily managed through the npm inflect module (i). 3. It's just a shortcut. You can use normal CommonJS require(), you'll just have to resolve the relative path yourself. 4. Thanks! :) 5. Models can exist without database connections and with manually defined schemas. If you check through the commit history, I used to keep database and model completely separate but there was way too much code reuse / smell (passing in a db as a parameter on every function call). 6. The alternative is setting properties with ClassName.prototype.value = 'xyz'; or ClassName.value = 'abc'; Static methods provide an easy to read + concise way to do this for you (and take care of additional functionality). Also borrowed from Rails. 7. Chose that pattern because it is very explicit / ordered. How do I determine what order the routes are hit when I specify them per Controller? And if I define them on the Controller, that means I need to load all Controllers globally on Application start. 8. I'm happy with how clean the code is now. :)

by voidr 11y ago

keithwhor 11y ago

Thanks for the suggestions, but a lot of the things you dislike were choices made very purposefully. 1. POJOs are ugly and you must revert back to using Object.create() for inheritance, breaking the design pattern of using ES6's class syntax. 2. PascalCase class <-> camelCase instance <-> underscore_filename <-> underscore_tablename is a standard borrowed from Rails and easily managed through the npm inflect module (i). 3. It's just a shortcut. You can use normal CommonJS require(), you'll just have to resolve the relative path yourself. 4. Thanks! :) 5. Models can exist without database connections and with manually defined schemas. If you check through the commit history, I used to keep database and model completely separate but there was way too much code reuse / smell (passing in a db as a parameter on every function call). 6. The alternative is setting properties with ClassName.prototype.value = 'xyz'; or ClassName.value = 'abc'; Static methods provide an easy to read + concise way to do this for you (and take care of additional functionality). Also borrowed from Rails. 7. Chose that pattern because it is very explicit / ordered. How do I determine what order the routes are hit when I specify them per Controller? And if I define them on the Controller, that means I need to load all Controllers globally on Application start. 8. I'm happy with how clean the code is now. :)