I’m working on a hybrid system where I need some content in the builder.io page to be updated on-demand on the server side. This is done with a simple string replacement for content received from the HTML API on the server.
The problem is that this content is then replaced with the original when the content is re-hydrated on the client. How can I prevent the client from re-hydrating the content?
Even without my current technical issue, our content is such that the client-side re-hydration is simply a waste of both bandwidth and cycles. Nothing changes.
Completely bypassing the entire client process is easy enough… but then I lose any interactivity I would have had on the client.
I’m doing this using the html rest Api and the web components integration.
Could you tell us more about the tech stack you’re using the HTML API and Web Components in? It’s helpful to understand the full picture of what you’re trying to handle.
It may be possible to alter the structure of your app to check if Builder has already loaded by selecting the webcomponent HTML on the page and checking to see if there’s content. If you’re able to make that check, you can conditionally render some of your app’s structure so that Builder doesn’t get replaced on hydration.
Overall, you will need to handle this on your tech stack. Builder is subject to whatever hydration processes occur on the page, and there’s unfortunately not a way to influence the loading process of the app via Builder.
Server is essentially just an html server. Pages are generated using a non-jamstack ssg. The generated pages are vanilla html/js and use the webcomponent builder tag.
I could technically make the stack anything I want. Although the complexity and overhead of the stack would quickly overwhelm the absolute simplicity of what is actually necessary. The returns diminish rapidly.
Here’s what I’m trying to accomplish… maybe there’s a better way:
In builder I want to build simple template pages. Technically, I could make them dynamic pages with an API connection… but, again, that’s heavy for what is actually needed.
Those template pages are then pulled and merged via the ssg (statiq) with a dataset of static content that grows regularly (more pages), but rarely changes (effectively immutable). Conceptually very simple, but functionally challenging because of the rehydration.
It’s possible/probable builder is overkill for this, but it’s already in our stack for other reasons. And we happen to like and prefer it. But if I needed to move for this particular function, I could.
Hey @Matt , just wanted to follow up here to see if you were still interested in Builder and solving this re-hydration problem. It sounds like you are building a net-new app?
If that is the case, Builder might actually have a perfect solution in our QWIK API and our QWIK framework
This is open source technology developed by Builder that basically eliminates the need for hydration on the client, instead hydrating individual components on demand at the moment of interactivity or need. Do either of these look like they would work for you?
Just one last thing I want to note… The API is still in beta, and framework is currently in active development, but we are happy tow work with you to see if these would be good candidates for your application and Builder setup!
