May I ask React guys what’s wrong with parallel controller tree and (virtual) view tree which React tries to avoid (and, in my opinion, creates a bunch of in-club issues on a way that didn’t exist outside of its paradigm)?
I’m talking about this desktop mvc adapted to hyperscript approach:
class AppCR extends CR {
ctor() {
this.db = new RemoteDB
this.sidebar = new SidebarCR
this.content = new ContentCR(db)
this.val = {a:42, b:3.14, c:this.db.fetchC()}
}
render() {
let {h, val} = this
return h.div.wrapper(null, [
this.sidebar.render(),
this.content.render(),
h(AuxViewType1),
h(AuxViewType2.model(this.val, "c")),
h.div(val.b),
])
}
}
class AuxViewType1 extends View {
render() {
let {h, cr} = this
return h.span(cr.val.a)
}
}
class AuxViewType2 extends View {
render() {
let {h, model} = this
return h.model_input({model})
// model == {object, key} (for "input")
}
}
You also may have a global read-only (mostly) store of reference data, but that’s more for caching large datasets, not for state sharing.
Btw, model_input could wait on a val.c promise and rerender appropriately without your intervention (something React folks were to deliver last year, supposedly with help from async setstate process, which was a requirement for that (why?)).
All of this React thing honestly feels like Haskell sneaked into an enterprise for the sake of “so cool we did it” giggles. Dan’s comments on this did not help much when I read ‘em.