Mutation watchers in as far as checking for changes on the vdom, though my current dev iteration of bs-tea uses kind of ‘pipes’ to mark areas instead. But currently I’m not sure you mean by ‘general render function’? Do you mean calling something else to return a vdom from inside the vdom? If so then the lazy construct can do that. Do you mean rendering, say, a javascript owned element? Then not yet but that’s planned as the CustomNode, however I find webcomponents better for that anyway and should be used and work fine in the current system (as does bucklescript-tea work perfectly inside a web component, I find the whole concept of chaning javascript calls to build the DOM tree a horrible misdesign that a lot of people do for who knows what reasons, webcomponents are superior).
OvermindDL1
tmbb
I’m yalking about having something like:
inner_vdom_fragment = f(state)
Is this what you consider a bad design decision?
tmbb
Chatiness as in “sends data over the network” is a problem, of course. Because of network latency. I thought you were referring to the amount of data trabsmitted over the network, which is not a very important variable (as long as it’s greater than zero!)… We are actually saying the same thing in different ways.
OvermindDL1
In my Tea library parlance would that be something like where f is a function call typed like model -> 'msg vdom or what is it all?
Which is why I love that the BEAM builds timeouts into everything. ^.^
grych
OvermindDL1
Yeah I’m curious about that as well, mutation watchers in javascript was turned down by the spec so they don’t exist anymore (and hard to emulate reliably, look at all the pain that polymer had to emulate it).
grych
I’ve never heard about mutation watchers before, this is why I doubt I am using it in Drab. But it always may be an issue with a terminology.
I am afraid Drab is not so sophisticated. It uses something I may call “naive direct updaters” than “mutation watchers” 