new major challenge to overcome: Sideways-loading Data

[faceyspacey]

essentially we gotta generate getMeteorData methods that return the data the template reactively depends on. The this.data context Meteor uses is called "Sideways-loading" data. Meteor isn't the first to do it. A few other complimentary React tools use the data property, and React is working on making an official implementation for sideways loading data:

facebook/react#3398

So that's basically what Meteor is already doing, and what we need to automatically generate so that components get triggered to update themselves, similar to how they do when you call this.setState(). The ReactMeteorData mixin essentially triggers the template to update itself when Tracker indicates the subscribed data has changed.

I wonder if we can dynamically add/modify that method during execution. We won't know what cursors are being created until runtime. We could guess a lot statically, but I think this is one we gotta sit out trying to figure out statically, unlike events where it's worth it. This one we gotta do completely dynamically or not at all. But I actually think we can do it easily dynamically. Cursors serve the perfect vehicle. They describe precisely the data dependent on. What we do is wrap all find/findOne calls, etc, and analyze the cursor as it passes through our code, and then in the cursor dynamically change the getMeteorMethod and trigger it to return again, notifying the rest of the system to reactively use it instead of the old one. The latter part is the unknown we gotta figure out, but something tells me the answer will be affirmative and the harder part will be writing the wrapper functions--like you did over the weekend with writeFile.

The main thing is we gotta know what component our find calls are executing in. We could do what meteor does with tracker and put into the global scope a variable that tells u the currently being executed component. We override all the componentWillMount/Unmount calls to tell us this. It basically is gonna do exactly what Tracker does--cuz check it: tracker only can reactively depend on "live" code that is called within a function, that is not code that was never triggered in an else block; so similarly we must rewrite the getMeteorData method every time methods of its component are called since new cursors might be used and old ones not used. Hell, we may find it easier to rewrite what getMeteorData itself does. Cuz it's basically doing something like this--it's triggering an update based on cursors used in it. Well, we gotta trigger an update based on cursors used in any damn helper method. Performance wise, I dont see it as being that much bigger--I don't see why Meteor didn't do it this way to begin with. But even if performance does suffer, it's not a big deal as long as it works. We have to keep in mind this is more about the transition from Blaze to React. That's what production apps will end up doing anyway--rewriting performance-intensive areas, but using the "lead" we gave them by generating React components that aren't far off from their manual more performance-optimized versions. What I'm saying is React clearly allows for side-ways loading data. It likely leads to entire branches of the tree re-rendering, unlike the props-based mechanism they advocate for which which does not (i.e. "dumb components"). Nevertheless, it will work! And that's all that matters. Especially when we get it to work with React Native. At the end of the day Clojurescript's Om performs way faster than standard React because it insures all the data is truly immutable. React does not. So in Om React object comparisons by reference are all that's needed all the way down the tree, which is a lot faster than standard React's shallow object comparisons, i.e. whether to determine to just re-render the component as it was the last re-render.

So anyway, getting this to work is priority. Not performance. Performance can easily be optimized by those willing to permanently transpile our code and start using the lovely React components we generated for them--i.e. rather than continue to transpile blaze code as a build step. ..We need to do whatever it takes to intercept the reactive cursors + sessions in helper methods, and then force updates on the component whenever our interceptor gets notified from tracker. We'll likely drop the ReactMeteorData mixin altogether and incorporate this completer reactivity in our mixin. ..that said, my components system has basically a subscription Relay-style ORM built into any component you want to add it to, and that's the recommended way of subscribing to data. So once again, the Components-based version of Blaze will come to the rescue if we can't solve this in plain Blaze.