Handling hydration state of buttons and input fields
Hi all, Input fields and buttons are non interactive when hydrating and I was wondering how most people handle this state to improve the UX as well as fix flakiness for end to end tests.
I've seen a few suggestions on disabling them until hydrated. For this I would have to add logic by enabling them onMounted(). Another solution would be to show skeleton loaders instead.
However I don't really notice these patterns when looking at other production websites with SSR. How do you guys handle this?
5 Replies
Hi @Donitron. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Nuxt provides several strategies for handling hydration and improving the user experience (UX) for interactive elements like buttons and input fields during the hydration phase. Here are some approaches, based on the knowledge sources:
1. Lazy/Delayed Hydration
Nuxt supports lazy (or delayed) hydration, allowing you to defer the hydration of components until certain conditions are met (e.g., when the component is visible, when the browser is idle, after a user interaction, or after a delay). This can help avoid non-interactive states for critical UI elements by prioritizing their hydration, or conversely, by deferring less important components to improve performance.
For example, you can hydrate a component only when it becomes visible:
Or after a user interaction:
Or after a specific delay:
These strategies can help you control when buttons and input fields become interactive, potentially reducing flakiness in end-to-end tests and improving perceived performance for users. All delayed hydration components emit a @hydrated event, which you can use to trigger additional logic if needed feat(nuxt): delayed/lazy hydration support.
2. Disabling Inputs Until Hydrated
Another common pattern is to disable interactive elements until hydration is complete, then enable them in the onMounted() lifecycle hook. This ensures users cannot interact with elements before they are ready, but it does require some manual logic in your components. This approach is mentioned as a practical solution, though it may not be as seamless as lazy hydration for all use cases.
3. Skeleton Loaders
Showing skeleton loaders or placeholders until hydration is complete is another UX pattern. This visually indicates to users that content is loading and not yet interactive. While this is a valid approach, it is not specifically detailed in the provided knowledge sources for Nuxt, but it is a common web development practice.
4. Real-World Usage
The knowledge sources do not provide a survey of production websites, but they do note that lazy hydration and disabling elements until hydration are both supported and recommended strategies in Nuxt. The choice depends on your UX priorities and the criticality of the interactive elements.
Summary
- Use Nuxt's built-in lazy hydration strategies to control when components become interactive.
- Optionally, disable inputs/buttons until hydration is complete, enabling them in onMounted().
- Skeleton loaders are a valid pattern, though not specifically documented in the sources.
- All strategies aim to improve UX and reduce test flakiness during hydration.
For more details and code examples, see the official documentation on lazy hydration feat(nuxt): delayed/lazy hydration support.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
<@148451702310305792> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
I see lazy hydration more of an optimization reducing the chances of flakiness but not a complete solution @kapa.ai
Let me check the knowledge base for you again. One moment! :books:
----------------------
You're correct—lazy hydration in Nuxt is primarily an optimization technique. It allows you to defer the hydration (and thus interactivity) of components until certain conditions are met, such as visibility, user interaction, or a specific delay. This can reduce the likelihood of flakiness in end-to-end tests and improve performance by not hydrating all components immediately. However, it does not fully eliminate the underlying issue of non-interactive elements during the hydration window.
For truly critical interactive elements (like primary buttons or input fields), lazy hydration may not be sufficient as a standalone solution. In such cases, additional patterns—like disabling elements until hydration is complete (e.g., enabling them in the onMounted() hook) or using skeleton loaders—are often necessary to ensure a robust and user-friendly experience. These approaches are mentioned as practical solutions in the community, but the knowledge sources do not provide a single, definitive pattern that is universally adopted in production SSR sites feat(nuxt): delayed/lazy hydration support.
In summary, lazy hydration is a valuable tool for optimization and reducing flakiness, but for critical interactivity, you may need to combine it with other UX strategies.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
<@148451702310305792> Kapa.ai is still learning and improving, please let me know how I did by reacting below.