This is a really good explanation of the advantage of a “Pure UI”. I’m starting a new project right now, and since React isn’t really officially supported yet I feel very torn. I am forced to pick Blaze because of this, but then again I guess it’s not so bad since it’s only supposed to be an MVP.
@adrianmcli Why not use both? If you roll with FlowRouter you can use FlowLayout to render blaze on a particular route and ReactLayout to render a React component on a particular route. In addition, you could use the react-template-helper package to throw a React component right into Blaze if you need to.
I’ve become accustomed to working with Blaze, but only recently started investigating React. However, from what I’ve experienced so far, I think it may become my go-to view library.
3 Likes
Interesting! I’ll have a look at some of those packages!
1 Like
@adrianmcli I’ve also done this as well… React works incredibly well when you have an existing app and you just change out bits and pieces until you get to the point of having everything converted over.
Actually… here’s a great video on doing just that:
3 Likes
@ryanswapp 
I’m about to try this approach as I’m becoming increasingly frustrated with react-router. From my initial impression, it seems like a sort-of-hybrid approach you mentioned could be the way to go… although i’ll have to figure out a good way to implement a flux uni-directional pattern
1 Like
You may want to checkout this post for a flux inspired architecture:
Flux for Meteor using Blaze or React
Also you can just use regular Flux. I haven’t tried this yet but want to this week. Keep an eye out for the React-ive Meteor repo, i’m going to port that to using Reflux and Alt.
Basically you can start the subscription in the store and have an action trigger it. The subscription has a callback when data changes, you can use this to trigger a store update event. This would cause the subscribed components to re-render of course.
Those components can either pull in their data directly from Minimongo, or if you wanted the store could manage the data and pass it back via the update call.
Additionally if you want your store to survive a hot-reload, you can store the store state in a reactive dict or Session variable.
This would eliminate the MeteorData mixin and would be normal flux.
This is all theory of course 
I can’t wait to try it out soon.
FWIW FlowRouter has been working great. react-router takes some time to get used to and I think the nested UI feature is better suited for a certain type of app layout.
What’s your developer HR strategy going to be? React is the more performant solution, as per the points described above, and being pure JS; but Blaze is the more ubiquitous architecture, being HTML/JS/CSS. Are you building to make you and a few others rich? Or are you building to change the world? If you want to onramp teams of people, Blaze has some organizational and training advantages over React that will make themselves known once you’re trying to hire developer #5 and developer #16, etc. If you simply want to maximize developer:user ratio, however, and are willing to pay premium for experienced talent and skip or train the junior devs, go with React.
Can you share the video link. It seems to not be linked. Thanks for the thoughtful feedback.
Hey no problem! Here’s the link: Ryan Florence - Don't Rewrite, React! at react-europe 2015 - YouTube
[quote="jxm262, post:11, topic:6921"] . although i'll have to figure out a good way to implement a flux uni-directional pattern [/quote]
Update! Just released an example repo of using flux and Meteor. The gist is that you can use Tracker to watch collections and trigger actions like “PLAYERS_CHANGED” and then the players store can re-fetch, causing it’s views to re-render 
The rewind/replay functionality with the chrome debugging extension is killer!
@SkinnyGeek1010 thanks a bunch, haven’t seen this repo yet.
For others who may be interested, I think this is a really thoughtful thread as well - MeteorFlux Flow
@awatson1978 I can agree with this to a point. The Big thing that I initially liked with Blaze was that it was very friendly to pure html/js syntax. In a way, it reminded me a bit of how easy it was to get started with angular, you just need to know html and input chunk of code wherever you want to run js. But once you start building anything with any decent amount of complexity, it becomes kind of difficult managing the state of the app. I had no problems picking up React very very quickly (much faster than angular). Learning different flux architectures become somewhat difficult however. At this point, I can’t actually think of any reasons why I’d not use React/Flux (given the tradeoffs) since managing state has become soo much easier. That said I also have many issues with React - jsx transpiling, test frameworks/code coverage, etc. all become more difficult especially when trying to integrate with different tools/other frameworks.
Anyway, I’m open to changing my mind 
but for the moment, I think I’ll go with React with minimal Blaze+FlowRouter. Would love to see some nice code examples comparing all the different architectures, or better yet for Meteor to have a really good example of using React+Some popular Flux architecture.
Yep, agreed. For me the Alt tutorial is what made it click for me. However perhaps it was trying to grok 20 others before lol. Also actually doing it helps 10x more. Once you see the console.logs flowing it starts to make more sense.
[quote="jxm262, post:16, topic:6921"] But once you start building anything with any decent amount of complexity, it becomes kind of difficult managing the state of the app. [/quote]
Also i’ve noticed that having separate JS/HTML files makes me want to use less of them… and I end up with html files with > 100 lines of Blaze templates, where React encourages you to have many small components (sometimes several in the same file if it makes sense).
Another perk that’s not 100% obvious up front… composition. Suddenly those verbose bootstrap classes don’t matter when you have row, column, etc… components:
example of composing components with HTML:
<Row>
<Column size='L' width='3'>
<Button text='Click Me' color='red' />
</Column>
<Column size='L' width='7'>
<YesNoRadio label='Do you like React?' />
</Column>
</Row>
I’m starting to buildup a ‘toolbox’ repo of these things because they’re so easy to re-use
1 Like
@SkinnyGeek1010 I checked out your flux leaderboard example and was a little bit confused… In the action files you have functions that just return whatever is inputted to them without doing anything. What is the point of that?
1 Like
Ah yea i’ll change that and add a note. You can also call this.dispatch() instead of returning. Both will create an action and send it to the dispatcher.
Sometimes apps will do things with the data before dispatching it, or even just use an action without a store (perhaps routing with FlowRouter.go or something).
Actions can also can cause several stores to update (otherwise you may think why not just call PlayerStore directly?).
Also if the action is just passing through and not manipulating data, then you can save some keystrokes and call this helper instead:
var LocationActions = alt.generateActions(
'updateLocation',
'updateCity',
'updateCountry'
);
This will do the same thing and just dispatch the action. Thanks for bringing this up! I’ll fix this in the example soon. 
I also use Flux. I additionally allow views to get data directly from collections. Changing data happens still in the stores via Meteor method calls.
1 Like
@sanjo are you using Flux with Blaze? I assume Flux can be implemented in any framework right? (Still wrapping my head around it)
1 Like
Yes, I use it with Blaze templates. I use a fork of https://github.com/CodeAdventure/space-ui.
2 Likes
Interesting! With React the views won’t update when the data does so I don’t that would work well for a full React app? At any rate how is it working out, do you find it to be easier to reason about the data flow?
This is totally normal! Checkout these articles, I have found them helpful 
http://tylermcginnis.com/reactjs-tutorial-pt-3-architecting-react-js-apps-with-flux/
http://blog.mgechev.com/2015/05/15/flux-in-depth-overview-components
http://blog.andrewray.me/flux-for-stupid-people/ (not implying anything here of course 
)
@SkinnyGeek1010 Thanks! I’ll check them out. I have only really been developing since Fall of 2014 so I’m looking at Flux and thinking, “This seems like a lot of unnecessary complexity.” haha. I’m sure it will make more sense to me as I build bigger projects.
Yep I think that’s a fair point! It also doesn’t help that the app is so small so it looks like overkill.
If you think about an app being over 30k lines of code, hundreds of components, and lots of components needing to share/know about the same state, it seems like a dream come true. The perk is that you can reason about what’s happening with data, even though there are hundreds of components. Something like the Spotify app or the Squarespace website editor would be prime candidates.
Also I didn’t really think flux was necessary until I was wallowing in the tangle of code of a large React Native app
For small apps it’s prob. best to keep it simple and do something like this instead. Separate the view from mutating (easier to test), but still keep it organized in a domain (area of the app).
``` Template.leaderboard.events({ 'click .inc'() { var playerId = Session.get("selectedPlayer"); PlayersDomain.incrementScore(playerId, 5); } }); ```
PlayersDomain = {
// returns cursor of players
getAll: function() {
return Players.find({}, { sort: { score: -1, name: 1 } });
},
getSelectedName: function() {
var selectedId = Session.get("selectedPlayer");
var player = Players.findOne({_id: selectedId});
return player && player.name;
},
// returns number of docs updated
incrementScore: function(docId, amount) {
return Players.update({_id: docId}, {$inc: {score: amount}});
}
};
For community adoption Blaze will never have the same footprint as React