Ability to invalidate a custom identifier on goto()

[gterras]

Describe the problem

I know there is an issue discussing this here but this seems a wider issue.

To extend on the discussion here it could be very useful to invalidate an identifier on goto(). A common use case is as follow:

in a simple CRUD with the following pages :

/list
/list/[id]

Say you have a delete button on the [id] page that calls a DELETE action at the same level, if you plan to invalidate then goto(parent_page) the [id] load function will get in-between a not found error (obviously).

goto(invalidateAll) won't really work if you have unrelated parametrized load functions in previous segments of the URL (ie if you're using depends anywhere).

You can solve this by redirecting to the parent page on error in the load function but this doesn't feel right (one extra -and failed- request per deletion).

Describe the proposed solution

goto( { invalidate: ['myidentifier'] } )

Alternatives considered

I could redirect to some dummy invalidation page or add a query parameter that would trigger an invalidation in the list page but it feels complicated.

Importance

would make my life easier

Additional Information

No response

[dummdidumm]

Related #10359

[paulcalcraft]

I'm new to SvelteKit and had the same issue with CRUD delete. I currently work around it with:

await goto(parentLocation)
invalidateAll() // presumably will work also for specific invalidations

(I didn't know about the goto invalidateAll param so I can try that now obviously.)

This seems to correctly cause the invalidation after the goto, so it doesn't hit the 404 between the delete and goto parent. The GET/read then doesn't need to have a default redirect to parent on not found (I'd prefer we get proper 404 when an ID doesn't exist).

Not sure if this is idiomatic and feels potentially brittle? But working. If relevant, it's currently executing in an onResult callback in superforms, I'm unsure exactly how that might affect the page lifecycle so YMMV.

Also wasn't exactly sure what you meant by:

goto(invalidateAll) won't really work if you have unrelated parametrized load functions in previous segments of the URL (ie if you're using depends anywhere).

So apologies if that makes this workaround not applicable.

[gterras]

Also wasn't exactly sure what you meant by

goto already has an invalidateAll arg as seen on the docs so doing goto(url, { invalidateAll: true })) will entirely solve your problem.

This issue is about having the same kind of option when using depends where invalidateAll does too much.

[paulcalcraft]

Right, I realised that, but I'm wondering if this approach works for you for specific invalidations. That is, await the goto (or use .then) and perform invalidate after goto has resolved?

[gterras]

Right, I realised that, but I'm wondering if this approach works for you for specific invalidations. That is, await the goto (or use .then) and perform invalidate after goto has resolved?

In my experience this can (randomly) trigger weird behaviors on non-basic apps through race conditions. But if I recall correctly this technique was officially documented in Sapper (SvelteKit ancester). I don't have much knowledge of SK internals so I prefer to avoid that right now.

[xxmichas]

Running into the same issue where { invalidateAll: true } would do too much and waste backend resources.

Would love something like what @gterras proposed.

goto( { invalidate: ['myidentifier'] } )