@capensisma glad to see you’re thinking about this! You are correct, some of this isn’t that hard to solve (we just need to get it into core somehow). What you are talking about is “memoization.” Autorun memoization can solve a lot of the re-run issues. @veered actually provided code that does exactly this:
And that will go a long way, even though it will inevitably require more memory. But CPU and blocking is a bigger problem for UI-based apps than memory.
If we can automatically populate fields (probably using what I’m calling a “property level cursor”) then we’d be on our way, and I’d be motivated to start working on the dependency visualizations. But I think “property level cursors” are a more time-consuming problem to address. Here’s the solution I’ve envisioned:
accessing keys on a model object is really accessing getters, which when are accessed, notify a stored reference to the cursor to stop and start its mongo observer and re-specify the fields option. In essence, propagate the names of model keys used back to the cursor and re-apply the request made.
in addition, if we can figure out how to make this run without an initial test (i.e. without an initial request and initial set of rendered data), we win! The idea is it will have to at least run once without the fields option specified to determine what fields are actually used. This may or may not be possible and therefore result in multiple round trips to the server by the database observer as new fields are utilized in new code paths taken within the view. It would be a lot better if we could do this statically at compile time. That would prevent multiple round trips, but would disallow dynamic cursors. This is precisely where a lot more thought and work must be done–because those round-trips must be avoided; it’s what Relay goes to great lengths to avoid through requiring the static specification of data requirements.
lastly, of course we intersect used fields with any manually specified fields.
I think this is extremely important because this is the expected behavior of Meteor. People don’t expect their template helpers to be re-running each time an unused field is updated.
Yes, I had this code around, but sadly Proxy objects are not yet completely standardized. You can go about this with getters and custom transform, but it is a bit meh. And event getters are not supported on all browsers Meteor is targeting. Maybe it is time to limit those browsers.
@mitar@faceyspacey, do you know of an article/post somewhere that will clear up the confusion on how to properly use and best practices around Tracker? Maybe we can even get something into the Meteor guide on this?
@faceyspacey@mitar
Well I think this issue doesn’t need to be fixed just a BIG TEXT in the guide saying use/add the option to only restrict it to the fields you need to be reactive! or you will have some bad performance issues!
It’s like people select all field when they just need some of them!
So how about the second issue? Re-Runs when no changes occurs ?
exactly, i think we are on the same page. And I know Computed Field has much of this. I’m just saying that I think MDG could upgrade Tracker, and our apps just run better without having to change a single line of application code. And if we do have to change application code, it’s removing of code we wrote to prevent unnecessary re-runs. See what I’m saying. If it can be done without a new interface/API, it should be done.
On another note, an even rootier “primitive” is Meteor should allow you to swap out a core package with 3rd party one that takes its place. E.g. in .meteor/packages you should be able to write:
tracker refer: peerlibrary:tracker
Likely not all core packages are perfectly unbundled/decoupled in such a way, but many like Blaze for example are. I know this isn’t a “language primitive” or “framework primitive,” but it’s “primitive” nevertheless–maybe we can call it a “platform primitive.” Whatever. Either way, until we have something like this, we can’t really work on or contribute to core packages. Monkey patching can only go so far, and in terms of marketability falls far short.
I’ve written about this elsewhere, but basically this is a big deal if any of MDG’s code has any competition competing with what’s going out of NPM. In addition, there is another very important aspect: packages like tracker get their own Github repo rather than live in github.com/meteor/meteor. The combination of these 2 things will inevitably lead to much more contribution.
So until we have the ability to delegate/refer another package in place of a core package, or MDG declares they want to work with us on these issues, we have very little inspiration to do this stuff. That’s the hard part, @mitar. Our work on packages can get a lot more love on plain NPM. Things are just too messy for the time being in the Meteor world.
Agree 100%. It’s why I’m not building these things–I am hoping somebody does though ;). I think there are people who need Tracker more than me (I’m out of the Blaze game), and that’s why i’m writing this, so they can see there is an improved path forward if they really need it.
…but yea, one of the major tradeoffs is Haskell is a lot more complex for newcomers to code than OOP. The same isn’t true with ClojureScript. There is a path forward of purity. A picture of the best development setup yet is emerging. With concepts like “observables all the way down the stack” and functional programming, and using typing to facilitate WYSIWYG IDE tools (a la Bret Victor stuff), a very clear picture of how we should be coding, and how we will inevitably be coding in a short number of years is emerging. If there was any a time for intermediate-advanced programmers to learn Haskell, the time is now. It’s not like past years where functional programming was just hype–it’s reached the tipping point. And me personally, my mind is blown how pertinent to “live” “visual coding” functional programming is. As it is, you could basically use a GUI like this flow-based one: http://noflojs.org to write a Cycle app.
So what I’m saying is, there will always be trade-offs, but a future with far less trade-offs is emerging. Like, right now! Many of the trade-offs of today are evaporating. I don’t even wanna waste my time on anything unless it’s being a part of making this future.
At the core of everything is essentially functional programming. And I’m talkin more than view rendering frameworks, but rather visual tools to build applications. I and many of us have known about these Bret Victor-inspired tools for some time now. I just didn’t realize how deeply inspired by functional programming they are. Rather, how they wouldn’t even be possible without functional programming. Without the composability that comes from strict side-effects control. Not even considering opportunities like React Native, it’s for these reasons that the trade-offs for picking the Tracker/Blaze route vs. React aren’t worth it. If we can improve tracker and provide better observability about what’s going on, then I’d recommend using Tracker within React. You can then use my Tracker React package:
I mean we’ve all successfully developed with Blaze/Tracker for years. “Need” as we are clearly seeing by this conversation is subjective. Everything can be solved through several packages mentioned by @mitar etc. The point is I personally don’t want to have to do all that, not when everything I’m saying is so doable.
Now that said, I care much more about being able to visualize reactive dependencies and the corresponding flow of data. That to me is where the most gain will come from. It’s also a lot more time consuming to do right. And if we’re gonna do that, Tracker really should be on point to begin with. Like, I wouldn’t set out to build developer tools for a language or libraries that themselves aren’t solid.
And before all this, the real challenge is getting this into core. None of these conversations would have to concern MDG if we could use the refer: syntax I described above to provide replacements to core packages.
The most productive thing that could be gained from this conversation is the motivation to request from MDG at every chance we get that they give us this capability. I’m no longer interested in building monkey-patched solutions. I want to know that if I invest my time into building a library I can control my own destiny. Meteor too long has been a land of hacks. It’s done a lot of harm to its perception. Expert developers are choosing not to join Meteor. The best javascript developers are on “bare metal” NPM. I’ve only realized all of this in recent months. Until then I was too busy building things to realize the quality of developer tools available underneath us was shifting again–I think that’s an experience so many of us Meteor developers are currently going through! A while back @SkinnyGeek1010 explained a lot to get me thinking about how Meteor has prevented us from growing up. It’s like we got stuck on “training wheels” and never learned to ride a real bike.
So in conclusion, my big realization is: before we even bother fixing Tracker or make any more Meteor-specific packages that do things like patch Tracker, we need a professional Meteor-sanctioned way to replace core packages. Then we fix Tracker. Then we build Tracker visualizations, which is SO NEEDED since TRP is not based on a pure unidirectional flow.
…As for a suggestion, the only hard one I can make is: stop building anything new for a while and analyze all the stuff coming out of functional programming and wait until Meteor builds its own response to Relay. If you can’t do that, use React + Redux or React + Tracker React or React + Both. But whatever you do, no more Blaze. Why would you wanna do that anyway when you’ll inevitably wanna use React Native for mobile. If you’re a newb developer, fine use Blaze as a way to learn coding.
