[Bug?]: Hydration mismatch -- ContextProvider inside Show inside Suspense

[iacore]

Duplicates

• [x] I have searched the existing issues

Latest version

• [x] I have tested the latest version

Current behavior 😯

"hydration mismatch" "hydration key not found"

Expected behavior 🤔

it should work

Steps to reproduce 🕹

Steps:

1. git clone https://codeberg.org/iacore/kanban.git -b solidstart-debug
2. Follow README.md

Now you will see that it is broken.

To make it work, remove !data.loading && inside app.tsx.

Alternatively, move <ContextProvider> outside <Show>.

Context 🔦

See the comments in app.tsx.

[dennev]

There are several compounding issues with createResource. In your case, the following applies and can make this reproduction usable.

1. Multiple export functions

• Need to wait for a merge, see #1936.

2. Promise.resolve return value not available in synchronous functions

• I've created a PR for this.

[iacore]

@dennev I think you are trolling. You don't understand what's going on.

[dennev]

Can you tell me why you think so? I'm organizing the issues with createResource that I know of. Could you please be patient?

[iacore]

You said

There are several compounding issues with createResource. In your case, the following applies and can make this reproduction usable.

1. Multiple export functions

This is not the case.

Also, you used setTimeout and setInterval in https://github.com/solidjs/solid/pull/2533, which should never be used inside server rendering.

[dennev]

The export issue is a pre-existing one. I realized it may not apply in your example, maybe app.tsx imports everything? This is interesting, but it will be fixed to use export in general, not in specific situations.

Your concern about delayed initialization is valid, albeit for the limited use of returning a promise that just wraps an object in a sync function. Nevertheless, my attempt to submit this PR at this point is based on the following considerations.

1. People expect to be able to call isLoading, loading, etc, to determine availability by accessing them first. As summarized in that issue, - This needs to be fixed in the solid side repo rather than solid start, so I've cleaned up the issue in that repo. - calling the entire data(), which is unknown how large and massive it might be, is a concern.

2. Direct access to the component being hydrated is currently unstable and may require extensive modifications or usage changes to fix, and may not be resolved in a short amount of time, as it may be an operational policy decision rather than a bug.

3. Your case is a specialized use case compared to a typical component call. It resolves a promise wrapped around a simple object, even though a synchronous function could simply return the object as it is. However, promises are often used as synchronous functions in JS, and many users will try them out. Therefore, it deserves prioritized support for compatibility and stability, and I've submitted a commit to resolve the preemptive access to loading variables issue with minimal modifications to ensure usability without impacting your usage or other components. - It's going to be a bit of a delay, but I figured it's better than users trying to do this and getting stuck with an error screen. They might also get the wrong idea about the component or its usage. - It's not just a bug; it's a question of using promises in synchronous functions in this way in this framework. but in your case, it's how it used to work, so I wanted to provide support for this usage.

4. And unlike other cases where the length of the latency allows you to get away with it, a promise that merely wraps an object will unconditionally fail on the preceding access of loading.

In short, making further changes here may require more changes than I think, and more decisions to be made - That's just my opinion! Of course, someone could come up with a great idea out of the blue. - And people can get the wrong idea that it's an unusable usage. This could take longer than a small fix like this, so I've submitted a PR with the focus on supporting usability and stability for now. This could be part of the maintainer's options, or it could buy time until a policy decision or enhancement is made. It's up to the maintainers to decide if this is reasonable under the current circumstances.

Thanks for reading!

[dennev]

I resolved it by overriding loading.