search

shama / on-load

On load/unload events for DOM elements using a MutationObserver
113 stars 19 forks source link

server rendering #4

Closed yoshuawuyts closed 8 years ago

yoshuawuyts commented 8 years ago

What happens when we run this code on the server? I don't reckon the hooks will be called. I'm not sure how this works; happy to hear answers or acknowledge we should start thinking about it. Thanks!

yoshuawuyts commented 8 years ago

I know virtual-dom had a render clause for server side rendering of widgets; not sure there is one we could rely on for the client.

Don't reckon using the init / load hook on the widget itself would be viable, since it might kick off all sorts of xhr / browser specific APIs that aren't available in Node. Hmmmmm.

shama commented 8 years ago

atm, nothing happens because the mutation observer is ignored on the server. We could implement a polling polyfill for older browsers and the server though.

I'd think this would ultimately be handled by the serializer though. The cool thing about native DOM elements is we don't need to provide special handling for server rendering. For instance, let's say I fire up a D3 chart on load, the serializer would just read the SVG like any other native element.

Disabling or mocking (service worker ftw) xhr or browser specific APIs would be options provided by the serializer. I'm using electron atm for serializing which isn't as efficient as .toString() but gives us a lot more options here. Especially if a headless mode comes down the road, it will be a lot more practical.

yoshuawuyts commented 8 years ago

Yeah to be fair tho: I'm mostly interested in getting the right DOM representation in Node, very much less about doing XHR or the like since that would have a massive perf impact. But like you say: the mutation observers don't do anything; so at worst we'd be missing a few Nodes when coming back from the server. Sounds good to me.

If we really wanted custom placeholders on the server render, we could pass in a special env var / piece of state that would trigger a different render from elements; e.g. a lil placholder or something similar. I reckon that's reasonable enough.

The serializer stuff makes sense too; when targeting a custom platform we'd just serialize nodes using a custom serializer and it's good. I like it :sparkles:

Thanks for sharing your thoughts! Given that it's a non-issue right now I think I can safely close this.