Reduce lifecycle for Server Side Rendering

[pragmaticivan]

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]

cc @Robert-Frampton

[robframpton]

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.

[zenorocha]

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

[pragmaticivan]

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