4 ms·
Actually a few weeks ago there was a big movement in the React community about that. The problem is that the JS community is too big and people use different bu
by sotojuan 11y ago
Actually a few weeks ago there was a big movement in the React community about that. The problem is that the JS community is too big and people use different build systems and tests frameworks, let alone coding styles or project/files layout.
I think only Ember has been able to have a strong set of conventions, mostly thanks to ember-cli[1]. I consider it the Rails of JS.
That said, I am looking into nwb[2]. Looks fine for personal projects.
[1] http://ember-cli.com http://ember-cli.com
[2] https://github.com/insin/nwb https://github.com/insin/nwb
- joshuahornby 11y agolet alone coding styles or project/files layout Agreed, the lack of project structure is in my opinion the biggest issues when building React apps. An interesting discussion on project structure can be found here: https://github.com/mxstbr/react-boilerplate/issues/27 https://github.com/mxstbr/react-boilerplate/issues/27
- sotojuan 11y agoYeah I think it's one of the least talked about conventions, and unfortunately there's a lot of debate because of how React is (CSS next to component or in its own place?, etc).
- EvanPlaice 11y agoCoding styles is a solved problem. Use the feross/Standard tool or SemiStandard equivalent (ie if you prefer semicolons). Structure arguments will continue until the past decade of brain damage caused by trying to shoehorn MVC into front-end frameworks wears off. The future is self-contained, reusable web components. Organize the structure by feature. Provide a root file that acts as an exports facade that maps the internals to an easy-to-understand public API.
- EvanPlaice 11y agoCorrection: I'm not implying that separating of concerns is bad. I'm saying that arbitrarily separating them into folders by-type at the base level is not a useful pattern when it comes to reusability.