Meteor, React, NPM, and packages

[preinders]

React is still not even 1.0.0, therefore is still in development and can be difficult to keep up to date on Meteor’s react’s package. Undocumented features such as context’s are interesting, and I can’t wait till I see where they take this. The last release had the “ref” concept change a bit which is a highly useful construct. I wanted to get a head start on the change and brought the package in with NPM using meteorhacks:npm. Note: the latest Meteor 1.2.1 has this change, but I was impatient.

I also brought in the velocity.js, react-velocity, and material-ui, and flex (which is how I make my components reactive without using the Meteor react-meteor-data package) NPM packages. All works great as long as I bring them in together.

When I try and package them up separately (using cosmos:browserify) I could not figure out a way to share the common react and react-dom NPM dependency between my packages causing multiple react’s to run which does not work.

Some questions:

• What does the Meteor react package provide, beside the react-meteor-data package? Am I wrong just using the react, react-dom, and react-addon… NPM packages directly?

• I looked into the Universe:modules utilizing ES6’s modules and import’s (my editor webstorm really hates this), does this look like a viable direction? Looks also the direction rocket:module seems promising but not much has changed on the project in a while?

• Atmosphere looks a mess to me, anyone else? Updating packages which seem only to repackage NPM’s looks to be a nightmare to maintain.

• Am I the only one frustrated with Meteor’s packaging system? Not to complain but a package using “hacks” in it’s name does not inspire confidence in the framework.

I am pretty much a beginner at the web stuff, having developed software using C/C++ and Java for many years before. I might add the transition to JS has certainly been a bit of a challenge, as the nuances of the language are many. I have a new respect for JS guru’s.

I believe Meteor was a great starting point. But how far can it go into building larger and larger websites without a reasonable way of reusing software components? I will not get into SQL vs. Mongo issues here, but that does not bother me as much as the ability to re-use packages which are solving my issues.

[dell]

I am in a similar boat to you from the sound of it,
you might want to check out this:

Webpack compiler inside Meteor (ES6 modules, hot reload and code splitting!)

While the Meteor community was hacking projects this weekend, I was also hacking but the Meteor build system . You can now seamlessly integrate Webpack within your Meteor application. Why should you do this? Hot-reload with React (probably doable with others): The amazingly fast hot-reload with no page refresh. This is a killer feature. Works with Cordova! ES6 modules: this will be introduced in Meteor in the future but with Webpack, you can be in the future! Bundle your assets for you…

Basically replaces (not completely I don’t believe) meteor’s isobuild with webpack.
I’m currently migrating over to it so I can use externally developed react components e.g. react-bootstrap.
From the forum and even checking issues on github it seems there’s a pretty contentious debate over the topic of build system/blaze vs. react right now and how best to proceed.
Personally I like the direction of the aformentioned thread, from a newcomers perspective. From what I’ve read it doesn’t seem like MDG will take this implementation and merge it into the core directly, but they will probably resolve being able to include react components/being more open to code developed outside the current meteor community, in the coming months, in some fashion.
(edit: you may also want to check out GitHub - optilude/meteor-react-example: Skeletal example app showing how to integrate Meteor and React with some basic user management)

[preinders]

Awsome, works great!

I wish I found this earlier, being on the cutting edge is a bit ambitious I suppose.