Remote Functions: allow opt out of refresh.

[jjones315]

Describe the problem

Allow for commands and form remote functions to opt out of refreshing. Currently I have created a blank nothing query to handle this. But it feels like there should be something built in to opt out. For example I have a command for extendSession that doesn’t require any new data, only setting a cookie.

Describe the proposed solution

Add refreshNothing or similar to svelte kit to opt out of refreshing,

Alternatives considered

This is sort of solvable in useland by creating an empty query and specifying to refresh it, but it’s not obvious and require some (minor) overhead.

Importance

would make my life easier

Additional Information

No response

[Rich-Harris]

my_command().updates(null)?

[pepa-linha]

@Rich-Harris null is not a valid argument, but if it's supposed to be an idea, then I think it would be ideal :)

Svelte: Argument of type null is not assignable to parameter of type RemoteQueryOverride | RemoteQuery

[Rich-Harris]

Yeah I'm proposing it as the API

[samuba]

I like my_command().updatesNothing() as its easily discoverable from Intellisense, and when read by a newbie, crystal clear on what it does without the need to visit the docs.

EDIT
Currently using the empty query workaround for this but a server call is still being fired.
Thanks @jjones315, I overlooked that you can call await nothing().refresh() on the server to get rid of the nothing fetch request.

[jjones315]

Would be nice to be able to use the api at the function definition aswell. .updates(null) or .updatesNothing() would both be used where the function is called.

I typically prefer to declare the invalidations in the command/form so I have a single place for most of these.

Right now I have an empty query and using await nothing().refresh() before the return works, but ideally something would be built in.

[madeleineostoja]

I'd strongly second the ability to opt out of automatic invalidation in the command definition itself. I didn't read the documentation carefully enough and found this default behaviour highly confusing, causing difficult to debug infinite loops on reactive queries that I manually invalidate as necessary elsewhere in my app.

Needing to specify .updates(null) or similar on every consumer feels like a footgun, and while it sounds like I'm in the minority here I feel like this behaviour should be inverted, with automatic invalidation of the entire query tree being an opt-in rather than opt-out behaviour. On forms it kinda makes sense, but on commands it feels bizarre (and overly "magical") that calling a completely unrelated utility RPC invalidates all queries on my page for... reasons.

[Rich-Harris]

Yeah, I think I agree with that. It would introduce a slight inconsistency between commands and forms (unless we also made forms not update queries, which I don't think we should do, since that would introduce an inconsistency between progressively enhanced and not-progressively-enhanced forms and would generally be unhelpful) but I'm also encountering these situations. It would nudge people towards single-flight mutations as well

[Rich-Harris]

This is implemented for commands — the question is whether we also need to be able to opt out of automatic updates for forms. Are there any cases where that would be desirable? If not then we can get away without adding any new API, which would be nice

[sillvva]

No forms should stay as is and invalidate all queries. Command should be opt in, which the dev can do by manually refreshing specific queries or calling invalidateAll.

[madeleineostoja]

I'm in two minds, I definitely see the argument for forms invalidating all queries, to shadow native behaviour and "refresh" the page when submitted. But I'll always favour explicitness and this still feels like a feature that would rely on thorough documentation rather than intuitive understanding, and could result in hard-to-debug behaviour if you forget that.

That said I feel much less strongly about forms on this point than commands, because (unlike commands) I think their primary use-case would follow the happy path of "submit data then refresh related data".

I do feel that forms should have a way to opt out of all invalidation though, regardless of default behaviour, similar to an event.preventDefault on a native form submit. I'm imagining cases like a contact form calling an email service, that would be a fitting use of a progressively enhanced remote form but you wouldn't want to refresh any data on submit

[jjones315]

it would still be nice to define this behavior at the definition instead of at every caller. Right now refreshAll() doesn't work on the server so i have to make sure that every where a function is called in the client has it called on success.

I understand the complications of making refreshAll a single flight mutation but imo even allowing it to be called on the server and executed on the client would be a win.

[Sendouc]

Let's say I have a form that also might return an error back to the customer to display in the form to indicate a username is taken for example. In the error case I would like to opt-out of the default refresh behavior as there was no modification to the data. Currently in the view I'm trying to implement it just wastefully refreshes all the queries on the page even when I know no data was modified.

So I would fix it with the proposed "nothing query" but this feels like a hack and personally unless I'm missing something I would prefer there was a real way to do it.