I totally agree with your opinion @abhiaiyer. Redux is only a way to build a modern app. Meteor (with Tracker) is another, valid as well.
Code is simpler when using Tracker (transparent reactivity), that’s for sure. The only thing it lacks, is some organisation so when your app grows it doesn’t end up being a mess. I think that’s the problem of many people. Not Tracker itself.
Again, I agree with you. I think Flux is a good way to separate concerns, keep your flow easy to debug and your code organised. That’s the reason MeteorFlux uses Flux for code organisation but still embraces Tracker and it doesn’t try to replace it with Redux or any other external tool.
By the way, I think it’s worth to mention there the last article of @faceyspacey about this topic:
It’s a really good read and I totally agree with him as well.
@abhiaiyer I don’t want to come across as nit-picky but I think these are great points to discuss. Here’s my take:
I think that if you compare flux/Redux with Meteor for non-persistent data you’ll find that things fall apart really quickly. You can no longer try to map ‘actions’ to Meteor methods, and mini-mongo is not really applicable (you could use null collections but Session and template var are more applicable).
Redux/flux is the easiest when not dealing with AJAX/Database data but gets a little more complex if you do, as you have to invalidate the cache (store) manually.
Meteor does not have a DB on the client… it’s just a cache, like a Redux store. Minimongo is specifically a write-though cache from what I understand which Redux does not have (you have to manually handle IO). Minimongo also stores data in arrays, it just uses Tracker to update them.
Using Tracker in React has been the root of all of my React performance problems and much prefer the events used in Redux. It takes a choppy laggy UI with Tracker and makes it silky smooth using connect in Redux.
Elm though is indeed far out, and if I had a lack of client side reactivity in tracker I’d jump on the Redux/Elm bandwagon.
Elm does look pretty cool! I’m still not sure how they do SPAs with a router but someday i’ll have enough time to check this out fully
You can map actions to methods if you implement logging. Which is extra effort but worth it for local collection state. I think people forget that users can hit save buttons and things don’t have to be reactive with the server.
To your point on minimongo. Now you’re talking semantics. Minimongo may not be “db” but you can approach your apps with the mentality that it is.
Its certainly an opinion. But I have my reasons: I say “should” because when your entire application is composed of pure functions, then your program is literally a mathematical proof-by-induction. And if you were programming in Haskell, you get amazing things like “deterministic parallelism”. Now that sounds like just a bunch of worthless fancy words and you’re sort of right – you can build software however you want! But I really suggest diving deep into functional programming. It took me a while before it really clicked in my head and I though, “man, this is the way you’re supposed be doing it!”.
To your other points:
Tracker is amazing and really cool, but it inherently causes side-effects which is why Meteor feels so magical. But you can easily find yourself getting entangled with Tracker.autorun. I prefer the explicitness of pure functions. What’s so great about pure functions is you never have to open up another file – everything this function is concerned with is given as an argument.
Minimongo is full of side-effects that are out of your control. Flux isn’t as much about dispatching and updating as it is about a functional programming pattern for reactivity involving pure functions. So creating a thin layer on top of Meteor to incorporate Flux is pretty much worthless so long as you’re imperatively calling Meteor.subscribe and Meteor.unsubscribe within the lifecycle of your views. Now this probably sounds vague, but consider something like time-travel. Flux sets you up really nice for time-travel. To do time-travel properly, you need your entire application to be a pure function. With minimongo sending side-effects that are out of our control, you’ll never be able to create a slider that can show you the state of your entire application (including the minimongo cache).
I’ve been working on a little project of mine called elmish and I’m building some tutorials right now. You should check them out and let me know what you think. And let me know in an issue ticket if theres anything I should clarify. @SkinnyGeek1010, I’d love to hear your thoughts as well.
Hey @SkinnyGeek1010 and @ccorcos I wrote an entire medium article response to your comments here:
HERE IT IS:
The summary is the problem is one thing:
tracker re-runs functions many times more than they need to be re-run (which is the sole cause of Blaze rendering jankiness).
and a fair fight would be “Tracker 2.0” vs. Redux, and what Tracker 2.0 would have fixed is:
re-runs only occur if the precise dependent data utilized changes, not just because dependency.changed() was called
“property-level cursors” that automatically populate the fields option, eg: post.title within Spacebars automatically makes your fields option become: Posts.find(selector, {fields: {title: 1}})
an options param to Tracker.autorun(func, options) to further constrain what triggers re-runs
once re-runs don’t run more than they have to, snapshotting Minimongo and ReactiveDict become a real option, and we can time travel (even if Minimongo is made of mutable state)
we need a Chrome devtools extension to visualize tracker dependencies between functions (graph diagram) as well as a 2nd visualization that depicts the stack frame of dependent autoruns sequentially. Picture “branches” of the graph highlighting as they update similar to the React devtools for components. Now you would know exactly what your autoruns are doing!
A combination of a controlled/optimised Tracker (like @faceyspacey suggests) and the React virtual-dom (or BlazeReact) would give us the best of both worlds: control invalidations in the logic and in the DOM.
…Regarding Michel Weststrate, the creator of Mobservable, here’s a talk he just gave 2 weeks ago along guys like @staltz (creator of Cycle.js) at Reactive conference:
My point in sharing that and Mobservable in general is to indicate that there is a model and a path forward for “Transparent Reactive Programming,” which is the model of reactivity autoruns was always a part of (not sure why I never heard that term until recently). It’s always felt like Meteor’s been the only one to implement reactivity like “autoruns,” but the reality is there are other examples, and it’s looking like even better examples.
Here’s one more article from Michel Weststrate worth checking out:
Nice article! Just wanted to add that I agree with your last point:
Redux is for “UI STATE” and Relay is for “DOMAIN STATE”. In Meteor, Minimongo is also for “domain state” but we have no good “ui state” pattern. Conversely, people using Redux for “domain state” are doing it wrong and will likely change to Relay as it evolves (that’s my prediction).
Redux works very very well for ‘transient’ UI State but it’s not ideal for database state or ‘Domain State’ as you referred to it. I’ve primarily used Redux for domain state in React Native where neither Relay nor Minimongo exist and it’s ok in a simple app but it cant be complicated to invalidate your cache on complex apps.
I’ve experimented using Redux for domain state in Meteor and the only advantage to doing that is to work around Tracker inefficiency, as getMeteorData is much easier to use than Redux. I do love the approach of Relay though, the UI just says what data shape it wants and Relay gets it.
Nobody doubts the functional approach that Elm et al are promoting works, and may very well be the way of the future. Kudos for being an early adopter–the Meteor community definitely needs to become more adventurous like yourself.
That said, you’re missing the point of my article: to honor what functional programming gets right and start a conversation about how to bring the best parts of it to imperative object oriented programming.
…Just stating that “explicitness” is the way to go–not to be rude, but that’s basically like what everyone in 2015 with access to a blog and a little React experience has been doing–is not adding anything to the conversation. Though, in your favor, I do agree us Meteor developers have been blind way too long (me included), especially in comparison to the greater NPM community. 2015 was especially fast, so let it serve as a wakeup call to us.
But let’s move to the next step and start thinking how we can improve Meteor. What you–as in you specifically, Chet–want is a functional stack top to bottom based on observables (imagine cycle.js on the client all the way down to the database). Very similar to what the Datomic database is bringing to the Clojurescript world (which I know you’re aware of, as its integration is a to do item in your “elmish” package):
I.e. similar to what’s described in “Turning the Database inside out”, popularized by Redux creator, Dan Abramov:
…That’s a different framework altogether–and if Meteor was ever to become that there wouldn’t be a single line of code from their current platform. I’m speaking hyperbolically but you get the idea. My point is either way: I agree with you–this would be awesome! Let’s go start a company and build that. Until then, while we’re still using Meteor, let’s figure out what we can fix in a fraction of the time and get it done. Multiple approaches work–so rather than trash one, let’s realize the precise strengths and weaknesses and get to work where we can add value. The main strength being that Meteor is built already and the main weakness of the impending functional stack is that it’s currently just hypothetical. Parts of it are done, particularly the client side, but everything below that HAS NOT ARRIVED YET. I’m considering going being part of that future myself, i.e. its arrival, i.e. helping it to arrive sooner, i.e. building it! That said, I think an incremental approach improving our current tools needs to happen regardless. If you watched @staltz’s video at Reactive Conference:
you will see that we are making improvements to our imperative “horse” while the new functional stack is, what seems to be, a “BMW” lol. …But one hidden takeaway I got from that video is that people will have a hard time migrating from the OOP imperative approach to functional for years to come. The more we can make the OOP imperative approach like the functional approach (like React has done with hybrid functional class-based components), the more we can bridge that gap, the easier we can make it for people to transition to our brighter functional future. I’m not even saying I’m going to be the one to do it and carry the imperative flag for much longer–I’m this close to jumping ship completely like @staltz did with Cycle.js. Either way I have compassion for the struggles with predictability that imperative OOP programmers have and will continue to have, and understand–that for business reasons, the time it takes to learn or other, even plain old stubbornness–it’s not an option for everyone to just jump ship to functional programming. I would also argue it’s not the right time either. The industry is in the midst of so much upheavel. I wouldn’t even build an app right now, if I had the choice. I’d just be part of creating the foundation of the future, and that’s basically what I’m doing with these Medium articles and things like TrackerReact.
The problem explicit fanboys have with implicit abstractions is that so many implicit abstractions are leaky and not complete. If they were rock solid, we wouldn’t be having this conversation. Would you write 100 lines instead of 20 lines if 20 lines was 100% guaranteed to achieve what you want without problems?? No, you wouldn’t. What I’m saying today is Tracker has been far from “rock solid,” but if it was rock solid you wouldn’t even have the trace errors you’re talking about.
In short, we aren’t talking about “magically changing the meaning of [our] code”–we are talking about getting right what Tracker got wrong all along. Tracker never should re-run your code if you don’t even use the fields in your find call! That’s not the expected behavior. It’s nonsense we have put up with because the ease of Meteor application development has lulled so many of us into thinking we could never build the internals of what Meteor is doing ourselves–meanwhile the greater NPM community and sharp individuals like yourself are discovering every day that’s not true and there is a life outside of Meteor [patented @SkinnyGeek1010 concept :)].
You are correct about potentially missing state, but for the wrong reasons. Minimongo is a subset of what’s in Mongo–by caching/snapshotting all of Mongo on your local machine, you guarantee not only that you capture minimongo, but also subscriptions and everything behaves as normally; you guarantee that stale server side data doesn’t come back, which is most important. …and I’m actually incorrect as well–there are local collections too–so we have to snapshot both minimongo and all of mongo, but it’s still not that big of a deal since you only need one extra snapshot, and then a log of all mutations to bring it up to speed when necessary.
But I’m not done disproving your hypothesis that we “[cannot] guarantee [we’ll] reproduce” state well enough to be useable :
…Now, if in Redux you used any immutable data, any global state, within your reducers, you would f#*! it up. right. So similarly in Meteor, any state outside of Minimongo–because of the fact that it’s not tracked–would break things. It doesn’t have to do with the state being held outside the [client] application in Mongo on the server as you’re pin-pointing the problem to be. It has to do with making sure ReactiveDict, Session (which is ReactiveDict), and all the most common reactive datasources are snapshotted/cached in the same way. AND THEN on top of that, like reducers in Redux, relies on you not using global variables or properties on global variables to store some extra state. Again, Redux has the same problem; you’re just instructed not to do do that–we can provide similar instructions.
The fact of the matter is most Meteor apps do a good job of relying on reactive datasources rather than plain old global state anyway–so we are most of the way there. They need them to do the reactive stuff Meteor is all about. So it’s not that big of an “ask” to ask developers to just use reactive data sources if they count on time traveling working. If they want to add a new reactive data source, e.g. @luisherranz 's ReactiveState, well then there’s a simple API he can use to partake in the snapshotting goodness.
But I agree, there are holes. But I would say easy holes to keep plugged if you want to partake in Time Traveling and [accurate] hot module reload. I think a “more than good enough” solution for facilitating time traveling and HMR is completely possible, and in fact easy to build. The more challenging part in fact is traversing the dependency graph and providing dispose, accept etc handlers like Webpack so that HMR occurs properly–so for the purpose of this conversation, let’s limit it to Time Traveling.
Time traveling [yes, in a mutable environment] is easily achievable by snapshotting et al as discussed.
I’ll check out Elmish. That’s dope that you used Ramda to make it.
I agree @ccorcos, I never liked Tracker for the reason that is magical and (is non-deterministic the correct term?).
However, I still haven’t found a SIMPLE way to build a meteor app aside from using getMeteorData (I’m using react, not blaze). I like Meteor for its simplicity, and I feel like Redux and Flux requires me to drink some kool-aid that I’m not really interested, until I see a good reason for it!
I’m still waiting to to see a GOOD, NON-DOGMATIC example of how I can use Flux/Redux with Meteor and React, when it is actually is needed.
With meteor, a hot code push is a new version of the application that is sent to the client.
You have various ways to persist session data (not commited in db) so that the connected client doesn’t loose the data he is creating/editing.
The usual way is to use “Session” (not recommended) or a ReactiveDict, which both achieve the same thing.
But then you have to consolidate three sources of data in a typical CRUD application: data from the db, session data, and (previous) session data before the last hot code push.
I guess that most meteor dev just drop hot code push persisted data, because that make it easier to develop your app, but i find it more elegant to allow your users data to persist between hcp, but that is not easy to code.
Hm, that’s an interesting problem I didn’t think much about. It seems like if you’re pushing a new version of client in a production app it would be safest to prompt the user, make sure all data is saved, and then refresh the page, don’t you think?
I never thought of hot code push as a good feature in a production app, I saw it as a convenience during development.
Not necessarily, but I hear you, it’s nice to preserve state if possible. I guess I don’t think about it much, I usually treat my app as stateless, I realize I hardly ever store anything in the session, I rarely put things into React state, mostly I write everything to DB asap (since Meteor makes it so easy)… or I try to encode state in the URL for example if I have a page with many sections.
What about an Meteor app architecture with the following rules:
All app state must be stored in in MongoDB (Like the single store with Redux)
All state mutations are triggered through Meteor Method calls (Like actions in Flux / Redux)
Views get their data from Minimongo Collections (by subscribing to data and then using cursors) or the parent view.
I would like to know examples where this wouldn’t work for you or other thoughts you have on this.
More in detail thoughts on the points:
All app state must be stored in in MongoDB
Only one place to store state
We get the full benefits of Meteor: Data synchronisation between server and clients and persistence of data.
All state mutations are triggered through Meteor Method calls
A Meteor Method call is the same as using an action creator.
We get action/event transfer to the server + simultaneous handling on the client for latency compensation
The current design of the API let you think that you can only have one handler for a Method call, but you can have multiple by just imperatively calling multiple functions or introducing a dispatcher that works on the client and server. The support for multiple Meteor method implementations could be something that can be built in in a future version of Meteor core.
Changing your MongoDB state in Meteor method handlers will synchronize the state between server and client automatically the right way (= built in latency compensation feature of Meteor).
Views get their data from Minimongo Collections or the parent view.
In Flux / Redux views also get their data from the store(s). In this architecture the Minimongo Collections are the stores.
You can also think of the set of all Minimongo Collections as the one store, where each collection manages a specific part of the store. As plain object this looks like this: {docs: [...], comments: [...], attachments: [...]} where docs, comments and attachments are Minimongo collections.
But I really suggest diving deep into functional programming. It took me a while before it really clicked in my head and I though, “man, this is the way you’re supposed be doing it!”.
