Component doesn't reliably respond to a signal after hydration about solid

[katywings]

@fasiha Maybe instead of onMount you could use https://primitives.solidjs.community/package/lifecycle#ishydrated as a way to check if you are safe to change the signal 🤔

Edit: I guess isHydrated does only make a difference if your app is hydrated only once. If you do something like below the user is correctly rendered in the indirect case.

function bootstrap(el: any, indirect: boolean, renderId: string) {
  (indirect ? render : hydrate)(
    () => (
      <Suspense>
        <Avatar indirect={indirect} />
      </Suspense>
    ),
    el,
    {
      renderId,
    }
  );
}

[ryansolid]

I see the issue it is just a bit tricky. The we are pretty lax when it comes to hydration in that we assume the server is correct and we don't correct text mismatches. If someone interacts with the page then we cancel hydration/streaming and apply the new state. However, if things are still hydrating we continue to assume the server is correct. What is happening in the example here is that since the one place is hydrating it assumes it doesn't need to do work but the signal under it has changed. So while the signal is being tracked and would update on another change it doesn't try to write the DOM initially.

That being said in general lazy hydrating + shared state is just not a good idea. Because the client state can change and if it is shared hydration will break. Like consider a global counter that can be incremented and the lazy hydrated component shows/hides stuff based on whether the count is above 5. If anything changed the counter before it hydrated you'd have serious hydration errors. This error was less serious and wasn't detected, but it would cause hydration issues just the same in other solutions that were stricter.

[fasiha]

@ryansolid ahh, understood, thanks for that cogent explanation! Adding a onMount(() => console.log("Mounting …", new Date().toISOString())) to both components reveals that the incorrect behavior happens only when the signal-reader component (AvatarSolid in the example) is hydrated after the signal-setter component (User): the newly-hydrated component never "heard" the signal being set.

If I can burden your generosity some more. Should I just abandon the hydration + shared state model? Is that just a Bad Idea™️?

Or does one just have to be careful about this pitfall by making the signal-writer (User) write the signal only after it's confirmed that all readers have been hydrated? A terrible workaround might be to just wait 100 ms after page load to write to the signal. Are there better ways to work around this or should I just give up?

Edit: another terrible approach is to use an object as the signal's contents, and then in every hydrated reader component's onMount, check if the signal's contents have been updated client-side and if so, reassign the signal. In the context of my example:

// in signals.tsx
export const [user, setUser] = createSignal<{
  user: string | undefined;
}>({ user: undefined }); // undefined = server-side

// in User.tsx, the signal writer component
export const User: Component = () => {
  onMount(() => {
    const savedUser = localStorage.getItem("user") ?? ""; // string = client-side
    if (savedUser) setUser({ user: savedUser });
  });
  // ...
}

// in AvatarSolid.tsx, the signal reader component
export const AvatarSolid: Component = () => {
  onMount(() => {
    if (user().user !== undefined) setUser((x) => ({ ...x })); // cause a rerender if this component is hydrating late
  });
  // ...
}