I cannot speak for React, but we’ve invested quite a bit of effort to combine the “one direction data flow” with Tracker capabilities of Blaze.
In a nutshell what we call a “component” is:
- a template augmented by an interpreter.
- on creation it sends a message asking parent template to bind its free reactive variables to the client app state.
- on desctruction in sends a message asking parent template to unbind its free reactive variables.
- During its living time, it may send a finit set of messages for the parent template to interpret.
- super late bindings that is crucial for complex app (> 40 templates)
- fine grained tracks of what is happening by logging messages
- very neat separation between the “source of truth” that comes from the DB and local states (ex: text in an input element in the DOM)
- full exploitation of Tracker:
a = new ReactiveVar(...)
b = new ReactiveVar(...)
c = new ReactiveVar(...)
Tracker.autorun(() => c.set(a.get() + b.get()))
a, b, c could be
It’s quite easy to split a component into sub-components and assembling them using the binding mechanism described above: this aspect is crucial when the app is expected to “grow” vs being planned.
Hope Blaze 2 will let us keep this pattern or give us a better one…
Anyway, loved the Meteor experience so far (apart the DB part so +1000 for GraphQL and the direction it takes with DB)