refresh the ui from outside dom event handlers?

[joshski]

Not sure this is a good idea, perhaps I am missing a trick. I was trying to render a loading screen until an async operation completes:

function render(model) {
  if (model.stuff)
    return h('div.stuff', model.stuff);
  else
    return h('div.loading', 'Loading...');
}

var model = { stuff: null };

loadSomeStuff(function(error, stuff) {
   model.stuff = stuff;
   // tell plastiq the model has changed...
});

I also tried attaching an onload handler in render, which seems more consistent but didn't work and I'm not sure that's a good idea either. Am I missing an alternative?

[joshski]

onload would be nicer in the respect that you don't need a reference to the return value from plastiq.attach, which will be awkward to pass around. Shall I have a go with onload instead?

[joshski]

Oops, did I just ask for a component model?

[refractalize]

Yeah, I thought this would be a good idea. Onload is interesting too but sounds a little contrived since it's only going to be called once, but it does allow components deep inside the view to participate in a kind of "initial loading" behaviour without having to be aware of attach.

The other interesting thing about this particular example is that you can check for the existence of stuff in the model, and if not present then load it - inside a render function.. Although you'd still need to call refresh. This doesn't seem quite as good as the other two though.

I'm thinking that onload would be a good one since it's pretty obvious what it means. onattach?

[refractalize]

Oh!

I've been thinking about other things like routing, and how routing would have to refresh() when there's a popstate event. Of course you need to add routing to the render() so you render different things, so it would be nice for the routing engine to be able to gain access to the refresh() function while it's being rendered - using an onload event.

[refractalize]

The other thing I was thinking about was being able to subscribe to beforeRender and afterRender events, e.g. if you want to attach jQuery to anything. How does that fit in?

[joshski]

onattach onbeforerender onafterrender 😄

[refractalize]

And the other other thing I was thinking about was firebase, and couchdb, and other model synchronisers. They would need to refresh() the view when they make changes to the model too. They're not quite in the view so they probably need some other way of getting access to refresh().

[refractalize]

onattach onbeforerender onafterrender 😄

like it!

[joshski]

Had a play with the "onattach" idea (n.b. this test doesn't pass yet):
featurist/plastiq@0b4bd43

virtual-dom supports "hook" attributes, but hooks will fire on every render or patch, which is not what we want.

In order to fire a once-off event, something needs to know whether it's the first render, or a patch. Of course, plastiq knows this, but it would need to descend the tree and remove the onattach hooks before a patch, which doesn't seem right.

Another option is that the render function takes an h argument which behaves differently between render and patch. I don't like that either.

I'll keep digging...

[joshski]

I found a way to implement onattach but for the reasons you mentioned above (couchdb and firebase) we might still need this one.

[joshski]

@adiel mentioned another example of where he might need this, or something like it...

If you have an existing HTML page, and you want to attach plastiq to two different elements in that DOM, with a shared model. You are not ready or willing to let plastiq render the entire DOM -- so you'd need a way of refreshing both elements when the model changes.

[refractalize]

Yeah I was thinking about this too. Would solve the original React use-case on FaceBook: message count on top, messages at bottom.

API:

var model = {}
var page = plastiq.page();
page.attach(document.querySelector('#one'), renderOne, model);
page.attach(document.querySelector('#two'), renderTwo, model);

[joshski]

Not needed now...