Proxy classes/attrs to the stub element in SSR scenarios

[brophdawg11]

Fixes #34

[maoberlehner]

Hey @brophdawg11 just letting you know that I've not forgotten about that pull request. I will try to shift my priorities so I can take a closer look at the weekend. Thx!

[maoberlehner]

After taking a closer look I'm not sure if this is going in the right direction.

<LazyHydrate :triggerHydration="hydrated" class="lazy-class-outer">
  <div class="lazy-class">
    <button @click="onClick">
      Click me
    </button>
  </div>
</LazyHydrate>

I agree that the renderless nature of <LazyHydrate> makes this example confusing for somebody who expects <LazyHydrate> to render a wrapper <div>. But I think, because <LazyHydrate> is renderless it makes no sense to apply lazy-class-outer onto <LazyHydrate>.

In my opinion there are two ways how to deal with it:

1. Ignoring lazy-class-outer class.
2. Proxying lazy-class-outer to <div class="lazy-class">.

Both ways are wrong in my opinion. I think there is no right way how to handle this gracefully.

Why do I think both ways are wrong: as I see it, the only reason why to put a class on <LazyHydrate> is because the developer who does it thinks that <LazyHydrate> does render a <div>. The expected output in such case is the following:

<div class="lazy-class-outer">
  <div class="lazy-class">
    <button>
      Click me
    </button>
  </div>
</div>

But this is not what <LazyHydrate> is actually rendering. But a developer who applies lazy-class-outer onto the outer element most likely does this because they want to apply CSS styles which may rely on a HTML structure like you see above. Otherwise, again, it makes no sense to apply lazy-class-outer onto <LazyHydrate> in the first place.

• I think applying a class on <LazyHydrate> is an error and should not be encouraged.
• I think there is no right way how to handle this so everybody would get the outcome they'd expect.

Possible solutions for this project:

• Log a console warning when attributes or classes are applied onto <LazyHydrate>.
• Add a chapter in the README explaining that attributes and classes do not work on <LazyHydrate>.

Possible solutions for your use case:

If the renderless nature is confusing to your team, you can use https://github.com/znck/lazy-hydration It works pretty much the same as this package (in fact most of my code is based on the work of @znck) with the exception that this lazy-hydration is not renderless and renders a wrapper <div> which means applying classes on it should work as expected (although I've not tested it).

Thanks for your contribution!

[brophdawg11]

Thank you for the thorough response. I see your point and it makes sense when viewing LazyHydrate as a true renderless component that effectively disappears upon hydration. So I agree that both of the solutions, when viewing it this way do feel wrong.

I think both of your solutions make sense, logging a console warning when LazyHydrate is being used incorrectly, and adding a small section to the README. I can update this PR with those 👍

[brophdawg11]

@maoberlehner Updated with a console warning and a new section in the README 👍