To chime into the react/blaze discussions… I have had a very bad experience porting an admin theme I bought from themeforest to Meteor+React. I had initially tried the same with Blaze and to be honest. That integration was a breeze. I spent hours learning React then once I was comfortable enough, I spent more hours getting the menu’s to work with transition.
I have actually paused to get clarity on the way forward with Meteor. It’s quite frustrating to say the least. I believe I speak for many developers when I say “We just need it to work… it doesn’t have to be cutting edge”
Maybe you could post some specific issues you’ve had/currently have, so others could learn and help. I myself started with React not long ago, and I’ve found it almost just as easy to learn as Blaze was, and I’m actually enjoying it far more than Blaze. As far as jQuery related stuff goes, it should be just as easy in React as it is in Blaze. You should use refs to select the DOM elements and do you jQuery plugin calls inside of the componentDidMount lifecycle method.
I tried a few different approaches. Most React apps use the flux architecture. So I tried using Alt and then later switched to Redux (they are both libraries for building apps using the flux architecture). After a while I realised I didn’t get that much benefit out of using either of those, as minimongo acted as a store (which is basically the core of the flux architecture), and in combination with Meteor’s ReactMeteorData mixin, I basically had a simpler, more native version of flux. So I’m still using flux, just not any flux libraries.
I’m working on a large app, so I wanted my code to be modular. At first I was using an all packages approach. It worked pretty well, but as it grows, it still become a bit of a pain to manage. Then I discovered Webpack, and more specifically this Meteor Webpack boilerplate. Using webpack is definitively the way I would recommend. It has a lot of advantages (see the boilerplate readme), my favourites of which are code splitting (you can split your code into asynchronously loaded modules to make your initial page load way smaller), and hot module replacement (or whatever it’s called), which basically replaces Meteor’s hot re-load when React code changes to only reload the React components that have actually changed (while preserving their state). This means I see the changes in under a second, rather than the 20 - 25 seconds Meteor takes to rebuild the entire app every time I make a change.
Using Webpack is quite different from writing a traditional Meteor app, but it my opinion it’s the best fit for using React in Meteor (at least for medium to large apps). You’ll lose things like Meteor’s way of automatically including files (you have to require the files where needed yourself). On the other hand, your code becomes much more predictable, safer from a development perspective (no more relying on globals everywhere), and much easier to understand (you can see what external code is used in a file just by checking what it requires). Also, coming from an all packages approach, I had already lost Meteor’s auto including of files, and the traditional ES6 modules way of including files is much better than the way it is done with Meteor packages. The boilerplate I linked to uses ReactRouter (which I actually prefer over Flow Router/Iron Router), but there is another boilerplate by the same author that uses Flow Router (although that one doesn’t support code splitting).
Oh and another benefit of using Webpack is that you can easily add NPM packages to your app, so you don’t just rely on Meteor packages.
So to sum up, I recommend using Webpack with ReactRouter. Definitively use the flux architecture, but whether you want to implement it using a library or simply with minimongo and the ReactMeteorData mixin is up to you (see here for a discussion on that topic)
I was just starting out on this when you responded. I have to unlearn my package only approach. If React could work with JQuery plugins without too much hustle I would not have any reservations.
Very cool answer thanks! Really from a production view which makes it so interesting.
The web pack structure seems to make a lot of sense and seems quite future proof. Do you still use lots of parts from the Meteor stack itself? Since you moved out loading, building, packages, tempting etcetera. Where is the real-world advantage for you to add Meteor to the stack in this project?
I got to watch @ryanswapp’s very well structured video and tinkered with it a bit.
Actually, I still use quite a few Meteor packages, just not the ones that are wrappers for NPM packages. I still use things like Simple Schema, collection2, accounts packages and all sorts of other stuff.
Meteor basically just handles the data and authentication now, which I think is it’s best part. The database everywhere and reactive nature of it is great in combination with React.
The one thing I miss from Blase is Autoform. Some people are using a React + Blaze combination to achieve that, but I want to stay in pure React, so I started developing a package that helps build forms in React and does from validation using Simple Schema: https://github.com/coniel/meteor-react-form-handler/. It’s still very basic and definitively not production ready, but it does the job for now (I’m actively working on it, will be adding documentation today). The form components are in separate packages (pretty much like Autoform templates). So far I’ve started one for Material UI and one for Semantic UI. I’ll be documenting those today as well.
This is where this trend is leading to. Where you strip it down and only use it for a particular purpose and not as a full stack anymore. @SkinnyGeek1010 and @ryanswapp have discussions on how to use it with Phoenix. All this is quite confusing and demanding for a newbie who simply wants to pick on the ‘good and run with it’ so to speak.
Sometimes opening a thread on discussions leads one to 10+ tabs on various techs one needs to learn and dependencies with a whole bunch of libs
It can be rather overwhelming. To be honest, the only thing I feel I’ve replaced is Blaze. The other stuff is just add ons to Meteor I would use regardless of React/Blaze. As a Meteor app grows, the Meteor way of doing things becomes a mess, which is why people start including other techs.
You can make an app with nothing but Meteor + React, in the same way you would with Meteor + Blaze. Blaze is a little easier to get started with, but in the long term you will run into issues that React solves much more elegantly than Blaze. People tend to be afraid to mix HTML and javascript as you do in React, but in the end that’s basically what you are doing with Blaze when using helpers. Except in React you aren’t limited to the just if, unless and each as you are in Blaze. React is basically what Blaze would have become if they continued to develop it, but why re-invent the wheel?
Blaze is really the only part of Meteor that I no longer use. I still use minimongo, collections, Meteor methods, shared client and server code, packages, reactivity… Webpack helped me replace my all packages structure (which, as my app grew ever larger started feeling like a poor structure), but it’s definitively not required to use Meteor and React together.
When you’re starting out it’s definitely overwhelming. I would just keep using whatever make you productive. If you’d like to learn the extra libs, just pick one and dive into, ignoring the rest. Focusing on one things makes it easier to learn.
