-
Notifications
You must be signed in to change notification settings - Fork 7
The game-changing RSC framework #9
I'm the author of the Navigation router, a fully spec-compliant RSC framework that's completely different to any other. You can get a taste by running the master-details sample from the repo. It has a people listing page where you can filter by name and selecting a person takes you to their details page.
The pages or scenes are composed of views. The 'active' prop determines which view is shown based on the URL. You can see that it looks like a traditional React app from the pre-RSC days.
const App = ({url}) => ( <html> <NavigationProvider url={url}> <SceneView active="people"><People /></SceneView> <SceneView active="person"><Person /></SceneView> </NavigationProvider> </html> );
Each scene view is itself made up of scene views. The people view renders a separate view for the list. It also renders the name input which triggers a navigation whenever the filter changes.
const People = () => { const {data: {name}, stateNavigator} = useNavigationEvent(); return ( <> <label>Name</label> <input value={name} onChange={({target) => stateNavigator.refresh({name: target.value}} /> <SceneView active="people"><List /></SceneView> </> ); };
These scene views refetch independently. You specify the URL data that a view is dependent on and, whenever that data changes, the view refetches its RSC content. The list needs to update whenever the name filter changes.
<SceneView active="people" refetch={['name']}><List /></SceneView>
With the list view updating itself, the people view never needs to update at all. We turn off refetching by passing in an empty array.
<SceneView active="people" refetch={[]}><People /></SceneView>
But the name filter doesn't useOptimistic so isn't typing in the input next to impossible? Won't the user have to wait for the list to render before the URL updates and the new keystroke appears in the input?
Nope. Any navigation that stays on the same scene will useDeferred instead of useTransition (only navigation that changes the scene will useTransition). So the person view sees the up-to-date URL instantly, because it doesn't refetch, and the list view sees the old URL while it refetches.
There are many other differences which you'll see by running the sample.
All reactions
Replies: 1 comment 1 reply
I'm not familiar with scene-based UI architectures so I can't speak much to that.
What makes this a spec-compliant RSC framework? I haven't seen mention of use client, Server Functions etc. in the docs. Telling that story is especially interesting for React Native where RSC support is only experimental.
All reactions
Another thing that singles out the Navigation router from other RSC frameworks is that you use it in exactly the same way regardless of whether you're using RSCs or not. The documentation reflects that because there is no separate RSC api to write about. For example, the useNavigationEvent hook provides access to the navigation data in client-only SPAs, in client components and even in server components. There is one RSC-specific page but that's mostly to cover the extra client and server setup files (it assumes users are already familiar with server and client components and server functions).
The Navigation router supports React Native and I have all the pieces in place to add RSC support to React Native. You can see evidence of this supporting work in another RSC sample. It's a (server-rendered and hydrated) stack of scenes, just like on native. Each scene is a server component fetched over RSC as the user navigates. I'm just waiting for the announcement that the metro bundler follows the RSC-bundler spec. Has this already happened?