Hyperapp: Hydration using a HOA or plugin / remove from core! 🥤

Created on 14 Dec 2017 · 12Comments · Source: jorgebucaran/hyperapp

From the docs:

Hyperapp works transparently with SSR and pre-rendered HTML, enabling SEO optimization and improving your sites time-to-interactive.

The process consists of serving a fully pre-rendered page together with your application. Then instead of throwing away the server-rendered markdown, we'll turn your DOM nodes into an interactive application.

Sounds great! But does it have to be built-in? Currently there is no way to opt-out or customize this process.

I'll also admit that I am not even close to an expert on this subject. By making this solution external (by allowing you to solve this problem externally, that is), we'd get the chance to figure out exactly what we want and what works best for Hyperapp.

Is anyone already enjoying the benefits of our current "self-hydration" solution? Have you had the need to customize this process or found that it didn't meet your needs so you avoided it instead? Do you have a position on this issue?

Discussion Wontfix

Source

jorgebucaran

All 12 comments

@JorgeBucaran I'm not using hydration myself, but is there anything preventing supporting this as an HOA? Do you have some sample code of what that might look like?

okwolf on 14 Dec 2017

Maybe @andyrj can share his opinion with us?

jorgebucaran on 14 Dec 2017

So I'm guessing we would save some bytes, but playing Devil's advocate for a moment - Hyperapp is already doing really well on startup time. Do we actually think this is hurting performance, or just not needed for a majority of use cases and should be out of core?

okwolf on 14 Dec 2017

@okwolf I don't think this is hurting performance, but...

I'll also admit that I am not even close to an expert on this subject...
...no way to opt-out or customize this process.

I am not sure if the current solution is "good enough". I haven't collected much feedback of it and while we are (my company) actually using it at work to pre-render a few parts of the app (e.g., the global header), the current solution could exist externally just as well.

There is also no way to customize this process. I don't even know if this is something you'd want to do or how often you'd want to.

One of the engineers in my company had to come up with a slightly different hydration solution than the current one when we were using >=0.9.1 because of an issue with what the server was giving them, and now that hydration is built-in to core since ~0.10.0, that is no longer possible. Not a deal breaker, but still, what good use cases are there for customizing the hydration process?

jorgebucaran on 14 Dec 2017

Never mattered to me when I pushed for this feature whether it was baked in or external. That said what I last saw of hydration, other than working around things like the whitespace cleanup you had with the trim in the external hydrate, not really sure why anyone would want a different hydrate.

Sorry I haven't been super active in here recently.

andyrj on 14 Dec 2017

Thanks for your feedback @andyrj.

...not really sure why anyone would want a different hydrate.

Me neither, but I'd like to know.

jorgebucaran on 14 Dec 2017

I'm actually using the feature in a login screen where we render serverside a part and hydrate it afterwards with hyperapp. It'd be cool to have it in the core and since it's not slowing anyone who doesn't use it and it's not adding too much bytes, I'd say, leave it where it is ;)

alber70g on 14 Dec 2017

👍1

I'm not using it yet, but when I do, it will be nice to have it seamless and work out of the box.

SkaterDad on 14 Dec 2017

👍1

I'm not using it at the moment but wouldn't mind seeing it abstracted to @hyperapp/ssr when it could be worked on in its own domain without restraint and imported where/when required. Disclaimer, I'm no expert either.