I’ve read a few places that larger meteor apps should be package-oriented instead of one giant codebase. How does this go along with React components?
One of the reasons for package-oriented development is testing. However React strikes me as far easier to test with than Blaze, so I feel this argument becomes invalid. Packages does split up the app in to smaller pieces more than react already does.
I’ve done monolithic apps and never had much of an issue with load order. Once or twice, but nothing that’s not easy to fix. This was often due to bad prototyping-design.
So is splitting your app in to multiple packages redundant? Are there still benefits from doing this?
With the new 1.3 release it will be very redundant. Every module should have one purpose so that kind of takes the place and also fixes load order.
React itself is very modular so you end up having a components dir for reusable bits. Here’s how to test in 1.2 and less
5 Likes
I haven’t looked that much into 1.3 as of yet. I will upon release, barely started perusing 1.2 due to stability requirements and breaking changes.
Still not quite sure why 1.3 makes it redundant in terms of modules. A feature I’ve missed in 1.3?
Reading up on react these days and about to try it out on a new project with 1.2. The modularity and unidirectional data flow seems promising for a few things that annoyed me with Blaze. I do feel it may on occasion be too verbose for smaller components/templates, but for enterprise or long-term-projects it seems very resonable to use!
The testinglink is most certainly bookmarked!
In larger and distributed apps and development, MVPs, and some cases of prototyping where package modularity is convenient, I still see natural use cases of separation in packages/repos, whether they be Meteor or NPM based. But yes, the 1.3+ module system does make a lot of things easier and possible.
Why would React change anything when it comes to package-oriented development? It’s not like the vast complexity of an app reside in UI components anyway?
I’m more excited for the app testing improvements in 1.3. Splitting up in packages was/is a way to easier separate an app into scoped domains and do testing on those, since IMO package testing is easier than app testing at the moment in Meteor <=1.2.