metal.js icon indicating copy to clipboard operation
metal.js copied to clipboard

Reduce lifecycle for Server Side Rendering

Open pragmaticivan opened this issue 8 years ago • 4 comments

Currently, the whole lifecycle is triggered on server side rendering causing a bunch of unexpected behaviors and sometimes requiring a lot of validations verifying if it's a client rendering.

For instance, React only triggers componentWillMount on SSR (https://reactjs.org/docs/react-component.html#componentwillmount)

If a sub-component tries to change something on rendered and attached it would cause unexpected behaviors.

The function getCurrentData also gets a call on SSR, and looks like it should not. https://github.com/metal/metal.js/blob/master/packages/metal-incremental-dom/src/render/render.js#L114

On SSR comp.element doesn't exist, and the current code assumes it exists on that conditional.

I suggest having the same behavior, just only lifecycle to be triggered before rendering. Maybe willAttach.

pragmaticivan avatar Dec 01 '17 17:12 pragmaticivan

cc @Robert-Frampton

pragmaticivan avatar Dec 01 '17 17:12 pragmaticivan

Makes sense to me.

One question I have, is what do we allow for people who want to use JSDom with their SSR? If we use metal's isServerSide method, it will prevent those lifecycle methods from firing even though the document technically exists.

I think instead of checking with isServerSide, we should just check to see if the global document exists before invoking the lifecycle methods. That way SSR works out of the box, but also works with more advanced implementations with JSDom.

robframpton avatar Dec 01 '17 18:12 robframpton

Having SSR to work out of the box would be great! I'm not a big fan of adding isServerSide all over the place ;)

zenorocha avatar Dec 04 '17 19:12 zenorocha

I agree with your suggestion @Robert-Frampton that seems to be reasonable to still support those lifecycles for projects that want to maintain that with JSDom

pragmaticivan avatar Dec 04 '17 23:12 pragmaticivan