@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
@SkinnyGeek1010 I’ve been building a huge app that is in the 30k lines of code range (maybe more) and I’ve started to hit all kinds of maintainability issues. I’m excited about learning Flux! Hopefully it’ll solve my problems when I figure it out. I was furiously working on another react app last night so that I could try to learn it. I’ll start implementing the domain example you recommended. Thanks for sharing!
1 Like
Personally I find it faster to hack something up in blaze than in react.
For a large team though, it might be easier to work in react.
Overall, discarding the reality distortion field around react, I find react to be sluggish compared to blaze.
Also, looking at the virtual-dom benchmarks here, it ins’t the topmost in terms of speed. http://vdom-benchmark.github.io/vdom-benchmark/
What do I know though. If Facebook created it, it must be holy and thy must not question.
2 Likes
I am currently in the Blaze hell you are referring to. A single page displays a TON of information, and all the underlying information changes independently of each other - like a user profile. My following count will go up, but my location will not change, nor will my follower count, etc.
So, I wrap many different segments of the single visible page into very many templates. Templates within templates within templates, separated by logic. If X, then render this sub-template, which in turn renders several of its sub-templates, etc., which have their own Blaze control flow. End up having order 10^2 files for a single route. This is what I am working with atm.
If I’m not mistaken everything in React by default is already broken up into individual independent pieces. So I feel like my usage of templates is telling me I should switch to react, because that structure is what I am converging to by nature. Seriously consider using React once official-official support is out.
Yea it sounds like your app might be a prime candidate. Also, if you feel like you would like more structure regarding to ‘control flow’ of the app, i’ve found that flux helped me dig myself out. It helps eliminate the problem of ‘ok a user clicks this button and now what else is happening from this chain reaction’. Meteor doesn’t give you any architecture out of the box and I find that, with React at least, flux helps solve that and gives me an easy ‘mental model’ of what’s happening.
If you wanted to dip your toes in the water, this boilerplate repo will help you test it out, add some stuff, and experiment. I also have other complex examples up too. This video explains how to refactor an existing app really well.
You’re right, it’s going to be faster to hack on with Blaze. It’s very light and terse (as much as HTML can be). However I have a long list of ‘tab triggers’ that helps get me out of this… reactm scaffolds out a base component setup for Meteor, etc…
[quote="bhoot, post:28, topic:6921"] For a large team though, it might be easier to work in react. [/quote] Again I think this is a really valid point. The larger the team the more benefits. Things like propTypes, and the 'pure function' methodology of the view help you reason about the view that you might not have built. I think these are also helpful for 1 person teams where you're going back to your codebase months later.
[quote="bhoot, post:28, topic:6921"] Overall, discarding the reality distortion field around react, I find react to be sluggish compared to blaze. [/quote] I think this is going to happen with any new framework. Everything is slower when you're bumbling around and skimming docs. I had this experience with Angular even though experienced Angular devs proclaimed it was so easy.
[quote="bhoot, post:28, topic:6921"] Also, looking at the virtual-dom benchmarks here, it ins't the topmost in terms of speed. [/quote] To me speed is one of the least appealing things about React. Blaze is very fast too. However this virtual diffing allows you to do things like 'when a query param changes, re-render the entire app'. With this philosophy you don't have an issue of parts of the app not updating.
The perks for me are:
- thinking of views as ‘pure functions’
- virtually re-rendering the entire app on any change
- re-usability
- composability (like the column, row ex. above)
Just my $0.02! I think Blaze is really cool too. For my needs React solves a lot pain points.
1 Like