Prevent re-hydration client-side

I’m working on a hybrid system where I need some content in the 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.

Hey @Matt, welcome to the forum!

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.

You can also handle this by re-evaluating the integration strategy you’ve chosen. Is it possible to install Builder directly in this project, such as using Builder for React or Next.JS, or by including the webcomponent directly in your project files?

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.

~Logan from

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.

Maybe forcing client-side rendering ONLY could be an approach worth exploring, check out the response from Tim here: Builder page is missing pictures and interactivity - #10 by TimG

Give it a try and let me know if this works for your tech stack :v:

You’re missing the point of why I’m doing it the way that I am. Client-side rendering is exactly what I don’t want.

I’ll look somewhere else to solve this. Builder is probably over-engineered and under-configurable for what I need here… which is too bad.