Why is it called `createRouteAction` instead of just `createAction`?

[xluk9]

Still learning SolidJS and SolidStart. One thing that is confusing me is the name createRouteAction. I understand createRouteAction is executed on the client side.

• Can't I call that function in a component? What I mean is, can't I call it in non-page component?
• Can't I call it without a Form?

Suppose i have I global like button in every page, that doesn't need any input params.

import { createRouteAction } from "solid-start/data";
import { createSignal } from "solid-js";

// Global signal, that I should also use in other places
export const [globalLike, setGlobalLike] = createSignal(0);

export function LikeButton() {
  const [liking, like] = createRouteAction(async () => {
    fetch("/increase-like")
    // Should parse response....but for the sake of simplicity
    .then((likes) => setGlobalLike(likes) )
  });

 if ( liking.pending ) return <div>Liking</div>;
 return <div onClick={like()}>Likes are {globalLike()}</div>
}

Would this be wrong? Is this not a best practice?
In this situation, this is not a route action, right? Unless I'm misunderstanding the purpose of createRouteAction

Wouldn't make more sense to just call it createAction ?

While we are at it, is this best practice?

import { createRouteAction } from "solid-start/data";
import { createSignal } from "solid-js";

// Global signal, that I should also use in other places
export const [globalLike, setGlobalLike] = createSignal(0);

// Extract liking logic from the component
export const [liking, like] = createRouteAction(async () => {
    fetch("/increase-like")
    // Should parse response....but for the sake of simplicity
    .then((likes) => setGlobalLike(likes) )
  });

export function LikeButton() {
 if ( liking.pending ) return <div>Liking</div>;
 return <div onClick={like()}>Likes are {globalLike()}</div>
}

[ryansolid]

I'm going to move this one to discussions. But there was some debate here.

1. It was unclear if we were going to backport a generic action to Solid so we didn't want to just use createAction because well this extra behavior is based on how it interacts with specific data related to the route. Ie it invalidates the route data on completion.

2. Because of the way it interacts with route data (ie knows location) it needs to be declared in the component flow. It can't be declared outside of components like server$ can. I don't think this matters a ton for naming but it's why the choice was route.

3. We needed to differentiate from createServerAction$. I'm leaning more and more to wondering if we shouldn't have just have left the combining to the end user. Ie.. have createRouteAction + server$ applied manually. It's more to type and to explain but it means less primitives and less overlap. If we did go that way I'd strongly lean towards renaming createQuery and createAction. But I'm not in a rush to make that decision (and easy to have a deprecation path if we go that way).

As for your questions:

You can call action in your components. And you can use it without forms. The latter was very much a design goal. Forms give us progressive enhancement but they are definitely bulkier to deal with. You can set your goal.

Using signals global like that is not recommended for SSR generally since you could share state between requests. It's often recommended to use context. Or even jump in the routeData. As I mentioned you can't hoist createRouteAction itself outside of the component but you could export the underlying function and use that elsewhere.

The idea here isn't so much to use these like API routes but as RPCs for the specific UI you are working on. If you have underly data model/API logic I'd extract it. The real expectation is most would lean towards createServerAction$ and it just all be wired up always working on the server without an API. However, there is flexibility here.