@sanjo are you using Flux with Blaze? I assume Flux can be implemented in any framework right? (Still wrapping my head around it)
Yes, I use it with Blaze templates. I use a fork of https://github.com/CodeAdventure/space-ui.
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!
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.
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.