Simplify server data boilerplate: routeData () => createServerData$(async (_ request)) =>

[obask]

Currently passing server data gives public static void main String[] System.out.println vibes. It also get lost between similar looking methods when you scan a file quickly to understand what it's doing with-auth example:

export function routeData() {
  return createServerData$(async (_, { request }) => {
  ...
  }
}
export default function Login() {
  const data = useRouteData<typeof routeData>();
  ...

I'd like to suggest a simpler approach which is aligned with other API routes patterns:

export async function SERVER_DATA({ request }) {
   ...
}

export default function Login() {
  const data = useServerData<typeof SERVER_DATA >();
  ...

---

Type checking works fine for me with a following helper function:

function useServerData<T>() {
  const tmpRouteData = () => createServerData$(async (_: any, { request }: any) => SERVER_DATA({ request }));
  return useRouteData<typeof tmpRouteData>();
}

*but it should be possible to be lifted into a library with a bit of type inference magic

It may also requires tweaking start/fs-router/router.js:

          if (exports.find($ => $.n === "SERVER_DATA")) {
            routeConfig.dataPath = path + "?data";
          }

---

Please let me know if you find these suggestions feasible. I personally think that it makes onboarding for new people(like myself) way easier because they don't have to copy all of these boilerplate and learn about optional parameters and tags.

[ghalle]

How would SERVER_DATA work exactly?
Would it completely replace routeData or are you suggesting we add it as an alternative to routeData?

As a complete replacement it wouldn't work as we need to be able to have client side data fetching.

As an alternative it would be pretty limited, how would it handle parallel data fetching with different re-fetching requirements? (see example below)

Definitely open to alternatives though as long as it can retain all the functionality.
The createServerData$ API is also currently under review (see #576 API Reflections)

export function routeData({
  data,
  location,
}: RouteDataArgs<typeof parentRouteData>) {
  // refetch when ?page changes
  const items = createServerData$(([_, page]) => fetchItems(page), {
    key: () => ["items", location.query.page],
  })

  // fetch on navigation to this route only
  const announcement = createServerData$(() => fetchAnnouncement(), {
    key: "announcement",
  })

  // fetch with a dependency on the parent's routeData
  const profile = createServerData$(
    ([_, accountId]) => fetchProfile(accountId),
    {
      key: () => ["profile", data.accountId()],
    }
  )

  // client side fetch / server side fetch during ssr
  const randomCat = createRouteData(
    () => fetch("https://cataas.com/cat?json=true"),
    {
      key: "randomCat",
    }
  )

  return { items, announcement, profile, randomCat }
}

[obask]

How would SERVER_DATA work exactly?

I'm unsure about how routeData gets compiled into something that Node can execute to implement $SERVER_DATA. However, I think it may be possible to move repetitive parts into a library like in my example.

Would it completely replace routeData

I understand that SERVER_DATA would not completely replace routeData, as routeData is also used for client-side code. However, I think it is easy to comprehend SERVER_DATA's approach, as it functions similarly to GET/POST/DELETE API methods.

How would it handle parallel data fetching with different re-fetching requirements?

Regarding how it handles parallel data fetching with different re-fetching requirements, thank you for providing a comprehensive example. I haven't done anything complex yet, but based on the Solid Start examples, it seems that most cases can be covered by a single server data fetch.

I don't think this would be limiting, as it seems similar to SvelteKit's +page.server.ts functionality (as shown in my attempt to use it). The main difference compared to Svelte is that everything is located in the same file and there is less confusion when accessing the $page.data._ magic variable.

PS all of this reasoning is based on an assumption that routeData () => createServerData$ will be used to make a single http call to the same route as the current page, so the server will be responsible for collecting information from other API routes.