Async Support? about incremental-dom HOT 5 CLOSED

This is typically only desirable for server side rendering. Since our initial goal is to support existing templating languages those could just use their existing string generation instead.

from incremental-dom.

Dust.js is a pretty popular templating engine with asynchronous support. I'm sure there are other engines out there that support async rendering as well.

from incremental-dom.

@kesne Oh, I've implemented a few of those myself. Just saying it is typically a very bad idea on the client because it leads to uncontrollable re-layouts.

If this comes up as something people want we can make something like this work

elementOpen('div', '', null);
var context = saveContext();
setTimeout(function() {
  restoreContext(context);
  text('hi');
  elementClose('div');
}, 1000);

But I don't see very high priority.

from incremental-dom.

I would also be concerned about people potentially kicking off a second render while the first is in progress, which could lead to strange behavior.

One reason why I think async rendering generally isn't handled by virtual DOM implementations is that invoking a render again when you have more data usually isn't too bad.

from incremental-dom.

@cramforce I see your concern with it now. I think it's only dangerous if you don't have some sort of control between when re-layouts occur. Though I understand it being low-priority or generally out of scope for the project.

@sparhami That's true, I guess that's the alternative approach to this. Though if you have a cascading async layout it might get less-than-ideal. Although I guess if your site is structured like that you probably have bigger problems...

from incremental-dom.