This Tuesday, solid-start is planned to be in BETA!
The docs (in progress) can be found at https://github.com/solidjs/solid-start/tree/main/docs
and you can see the stream about solid-start
solid-start is a meta framework built on top of @solid_js (like Nextjs for React, Nuxt for Vue, or SvelteKit for Svelte)
You can use SPA, SSR, or experimental Partial Hydration (islands) modes, with just a config change in vite.config.ts file.
You can create API routes easily with an export of just a get / post named function
You can use FileRoutes for file-based routes. If you choose to do it - export-default your page component in file created in src/routes/<your-route-or-path-for-route>.tsx
TypedRPC function with `server` - you can wrap an async function with server from solid-start/server and its content will be executed in server only. You can put those functions anywhere you want - even inside components
You can call this function directly in your app. Wherever you are on the server side - it will be called in the server, and if you call it from the client side - it will create a server nested route and will create a network request from the client to this route in the server
For page data loading, you can export a function named `routeData` in your routes page file and use its data in the page component with `useRouteData`. It will be called on navigation, and when the route param changes. You get TypeScript types with the use of `tyepof`.
We can combine `server` function with `routeData` and `createResource` for fetching data on the server (for 3rd party API or proxy for example).
Sometimes we don't want to refetch when the router param changes. We want to have react-query style cache. We want to make it stable and use actions to revalidate it.
So we can use `createServerData` which is like `useQuery`. Likewise, it gets a key function and a fetcher
It can be used with `createServerAction` which is like react-query `useMutation`. It revalidates the route when called but you can change its behavior. The invalidate keys can be configured in react-query key style.
You can put `createServerAction` / `createServerData` wherever you want - inside or outside your component. You can use the submit function from `createServerAction`, or use its form component.
It's natively in solid-start and builds on top of Transition and Suspense. Transition ensures there are no race conditions and everything ends up being the final version once you're into them
Suspense is the mechanism for tracking the resource reads.
Regularly, when doing optimistic updates you can have 2 approaches:
1. Refetch dependent data
2. Patching the cache
Only refetch dependent data make UX worse (because we want to show the user immediate feedback for example on the new todo he added) but it's consistent and simple to use.
Patching the cache is complex: you need to update the cache when the request from the backend succeeds (it can respond with new id/details that override your dummy data) or revert on error.
Your action can affect multiple cache keys that you need to be patched differently
If your optimistic data merges with your real data then there's no way for your rendering mechanism to differentiate between the two. Solid splits between the two so you know what is real and what is optimistic.
solid-start createServerAction return data contains `state` of the request, `pending` array that contains all the requests that haven't been resolved yet, `error`, and `data`.
So you can render the pending items separately to the user while the request is in flight, while `createServerData` will revalidate and returns the updated data. The pending items are easy to access in the render of the component.
So the optimistic logic sits in your component render, instead of the data layer like react-query