How to prevent page reload from action?

[caseybaggz]

I'm using Tauri with vanilla Solid/Router and am trying to use an action to submit a form for a chat feature but the action keeps triggering a page refresh and calling the cache function? I know in (super) Beta Solid-Start, there was the invalidate feature that worked great - but I'm not seeing it on the router side?

I've tried using revalidate('string'), revalidate(cacheFun.key), and revalidate(cacheFun.keyFor(id) and every time - the page refreshes providing a less than ideal UX. 😢

To be clear, I'm wanting to call the action on a form submit, but prevent a page refresh since I'm managing a client state for real-time updates.

Am I missing something here? Help!

[rvlzzr]

const action = useAction(whatever);

and then prevent the default submit action and instead on submit do

action(new FormData(formRef)).then(...)

[ryansolid]

The revalidate is exposed through the response helpers now. So the action returns a response option that we basically handle through headers. See: https://github.com/solidjs/solid-router?tab=readme-ov-file#action

If you don't want anything to revalidate send some garbage string through.. like revalidate: "none". You could also use revalidate function if you are doing it pure client side.

In any case the page shouldn't refresh as our form handling prevents it. Unless you are handling form submit yourself in case you need to preventDefault on the event.

[caseybaggz]

Follow up question - is it a better approach in Solid to reserve actions specifically when the response should result in some type of redirect and signals/resource in all other cases?

For example, here, I don't want anything to change about the route - only the bonus widget itself. So am I just approaching this design the wrong way from what Solid is best utilized for by using an action to update the DB?

EDIT: Even using only the createResource approach somehow triggers a complete reload of the parent component :/

[ryansolid]

Is the form default not being prevented? If we don't handle the form submit properly, that would cause a reload. It is just nothing we do should cause a reload. I thought you meant all the data updated so instructed how to avoid that. But if actual components are running again that is unexpected.

It is just all actions do is trigger cache functions that trigger createAsync. I don't see how that could ever cause a rerender unless some higher up decision depends on that async resource.

[caseybaggz]

From what I can tell, none of my form actions are being prevented? It's just more noticeable in that video because I'm animating stuff in. For example, if I removed the fade in effect - Solid would be so fast re-rendering that the human eye would see no difference.

Route info

Here is the full hierarchy of the route. Let me know if I'm executing in a poor way:

Route: app/:groupId/battle/:battleId
 ├── PlayerAppBar (lazy)
 ├── MetaWidgetBar (lazy)
 ├── BattleSheet (lazy)

Battle Route

Uses load, cache, and multiple createAsync (is this the problem? 👀) for the data. Also uses createMemo to cache some values from the data to pass into the children.

PlayerAppBar

These are the action buttons on the top right side to update health and conditions. Each button is a form with an action that updates the DB and causes unwanted widget re-renders the UI when submitted.

MetaWidgetBar

This is the parent of all the widgets. All use createResource to fetch the data for that specific widget. The only one that is using form and action is the Inspiration widget which causes the UI re-render upon submit (video). However, because createResource is not triggered, the UI is also stale.

---

I put a log into both a onMount and createEffect to catch the parent route (with all the async cached calls) to see if it was re-rendering but nothing logged. Same thing with the widgets (which makes sense). A question I have is - if the parent route is triggering the child JSX reloads wouldn't the lifecycles all run? Or, is that more React nonsense I need to de-culture from my brain?

The only thing I haven't tried is not using forms but instead the useAction/Submission combo which I don't love but if that is the correct Solid usage, then I'm happy to apply that.

[caseybaggz]

Confirming useAction with no form does the same. I also confirmed the design I have is almost identical to the Strello example you posted on X today. The only diff between that app and this one is using Solid Start/Web vs. Tauri(vanilla solid/router)/Native 🤔

[caseybaggz]

@ryansolid ok, I figured it out. It was 200% my fault and I'm so so sorry for wasting your time. But, I think this is a great lesson for people who might find this thread.

TL;DR - I had createAsync/cache vomit 🤮

Basically, I was thinking (due to the naming convention) that if the cache functions ran once within 5m or so, it would just return the data and not make server calls. However, I noticed this was incorrect watching my network tab.

To your point - action triggers cache which by nature triggers the createAsync.

Answer

After analyzing my codebase, I updated my "root context" to hold a few more values that I now know I need in a lot of diff routes. Thus, I was able to eliminate a ton of createAsync calls and just source the context which is loaded from the root createAsync data at the highest level.

Without the createAsync in this specific view, the actions no longer trigger anything. This is why I really appreciate Solid. I literally have a more performant app - doing the same amount of things, with less code - mind blowing.