rename `cache` to `query`, action `onComplete`

[ryansolid]

Proposed updates to Router APIs...

Mainly rename cache to query

Also add the onComplete API to submissions. That I brainstormed here: https://hackmd.io/@0u1u3zEAQAO0iYWVAStEvw/ry9vVctJkg

[changeset-bot[bot]]

🦋 Changeset detected

Latest commit: 663b3c16a211d9803920fda5b2da4bcb31cb042a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@solidjs/router	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[atilafassina]

Instead of completely replacing on this release, how about we add a deprecation warning so the minor doesn't break existing apps?

/**
 * @deprecated Use `query()` instead..
 * This method will be removed on v0.15.0+
 */
export const cache = query

This will allow TS codebases at least to have a clear distinct warning on their code:

[davedbase]

I agree with @atilafassina here. Let's keep cache available with a deprecation notice and provide query as the new option. In a few releases we can officially deprecate it, just give users some warning before we do.

Docs need to be aligned to notify users of the change as well.

[brenelz]

If i'm not mistaken I think he did this already here? https://github.com/solidjs/solid-router/pull/490/files#diff-ec90fda2df5f2c5fb4fdc9858fdece2ed80173595f5443fd20720df0a6623b12R233

[devagrawal09]

I really like the new action api to allow for those advanced optimizations for people that are willing to put effort into manual cache management.

My only slight disappointment is that if I'm writing manual cache mutations anyways, I would like it to optimize all the way and prevent any reconciliation by making the cache update fine grained. This is still a good optimization over the default since it saves server resources and latency, but it feels like there is potential to save on data reconciliation as well without adding any more work for the developer.

What if query could be configured to use a store under the hood, and createAsyncStore can check if the thing I returned was a store and just let it through? createAsync could either unwrap it or just let it through as well.

Typescript can also potentially tell you whether the resolved object is a store based on the query configuration.

You could even get rid of createAsyncStore entirely. If I want the async data to be fine grained, I define that at the query level, not the component level. If I want to access data fine grained, I probably also want to update it fine grained.

[ryansolid]

@devagrawal09 I've thought about this before. As you can imagine I moved stuff all around originally. The Store on the inside is awkward for hydration and serialization. It needs to upgrade to a store without running the store code on the client. There may be solutions there but finding a good solution for this with the constraints of how createResource works is pretty tough.

[devagrawal09]

Aww hydration PITA strikes again

So am I hearing that this idea could be revisited in 2.0 once createAsync is the building block?

[ryansolid]

Aww hydration PITA strikes again

So am I hearing that this idea could be revisited in 2.0 once createAsync is the building block?

Maybe but it also brings with it the question of if createAsync should automatically serialize for hydration. That's more of the challenge here. We could make a change where it doesn't. Which would make these sort of things easier but we'd need to still find ways for people not using this stuff to find success.

[atilafassina]

Docs are ready:

https://github.com/solidjs/solid-docs/pull/937

[ryansolid]

Aww hydration PITA strikes again

So am I hearing that this idea could be revisited in 2.0 once createAsync is the building block?

I was thinking maybe createAsync shouldn't serialize by default. It is a big change but that way systems like cache etc could manage it themselves rather than have the generic async primitive worry about it. It could be an option but not the default. Big departure but it frees us up.