Preact-hot-loader

[theKashey]

Original issue - preactjs/preact#1007

[theKashey]

Ok. So here is the plan. I'll describe the problems, and a few ways to solve them.

How RHL v3 works?

It uses babel to "register" all top level variables (including Components), and then replace "real" ones by "fake" on createElement call.

The problems here - HOCs and decorators. They are not a "single" top level variable, usually they are top level+internal. And that internal is invisible for v3.

What did v4 changed

Exactly this moment. It first "hydrates" the tree, and then starts traversing the old and the new tree simultaneously. But with preact we don't have the old tree to traverse, as long is it "VDOM-free".

How to solve?!

I have 2 ideas, both are great, both will work.

Idea 1. Put everything inside.

Completely disable RHL "hot-renderer"
Make "compare" function configurable in preact (in "debug" mode).
Append this logic from RHL to a new comparator.
Then, on element comparison, it will not dom._componentConstructor===vnode.nodeName, but will isSwappable(dom._componentConstructor, vnode.nodeName) and next proxy got updated, original class will be hacked, and magic happened.

Actually - this is hot react-hot-loader should work from the scratch. Could be easy implemented both in React and Preact. As result it could compare existing component with a potential one, and diside - should it be hot-replaced or not.

But it will require changes in base libraries.

####Idea 2. Don't rely on the internals.

Remove all "getStack" related code. We will not need it anymore.
On "hot-render" render the old tree, then render the new tree, as usual.
As long we render everything by ourself - we could remove 50% of "hacks" from hot renderer and comparison will be super easy.
Result is React/Preact version agnostic, and does not rely on any internals.
The problem here - how render the old tree. It's doable, as long we control createElement and all "entry points" are registered via babel plugin.

So - on some component render, we can detect that hot-replacement-render should be run, and then "roll back" the proxy registrations, thus being able to render the old tree.
Could be easily made if actual "componentSwap" will not occur on registration, but on createElement call, it will remove requirement of "unrolling" as long nothing will be applied yet.

SO?

Both ways could reduce technical debt and greatly simplify how RHL works.
But which way to follow?

[theKashey]

fixed in v4.3.0