Ryan Kahn (he/him)Server Components are Cool! Frameworks may or may not be.
I, along with many ReactJS devs, have been following the development of the "new" React Server Components API with excitement. It solves some common problems in React around data fetching and efficiency in client side applications. If you're interested in learning more about the API I'd recommend you listen to the recent JS Party podcast with Dan Abramov and Joe Savona from the React Team on the future of React, and then check out the React Server Components Demo on GitHub.
One aspect of the planned Server Components API that I personally dislike is the reasoning from the core team that in order to make use of them, you should utilize a framework like Next or Remix. If you're already using one of these, then great! You will get this feature in time. But, if you're like me and would rather assemble right size tools on your own, or you have a large application you'd rather not completely refactor, this leaves something to be desired. I want there to be a way to use Server Components without a framework.
With this in mind, I've started building a compiler of sorts on top of TS-Morph that will allow you to write your client and server components together, and split them into two bundles automatically for deployment to your server of choice and client application. Ideally, this would work with both Typescript and JavaScript codebases. So far it does, but as I get deeper I can't make too many promises on this feature.
A tool for creating Server Components without a Framework
The emphasis of this tool would be to minimize both code and configuration, while introducing the least new dependencies into a code base. This starts with how you write your components. While the plan in Next, for example, is for developers to identify server and client components explicitly, their documentation points to a straightforward set of rules for how to divvy them up:
| What do you need to do? | Server Component | Client Component |
|---|---|---|
| Fetch data. | ✅ | ⚠️ |
| Access backend resources (directly) | ✅ | ❌ |
| Keep sensitive information on the server (access tokens, API keys, etc) | ✅ | ❌ |
| Keep large dependencies on the server / Reduce client-side JavaScript | ✅ | ❌ |
| Add interactivity and event listeners (onClick(), onChange(), etc) | ❌ | ✅ |
| Use State and Lifecycle Effects (useState(), useReducer(), useEffect(), etc) | ❌ | ✅ |
| Use browser-only APIs | ❌ | ✅ |
| Use custom hooks that depend on state, effects, or browser-only APIs | ❌ | ✅ |
| Use React Class components | ❌ | ✅ |
With these rules as a guide, it should be possible to separate server and client components into categories automatically based on their dependencies. In fact, I've already completed some of this work which you can check out on GitHub. The remainder of the work is more testing and implementation around third party dependencies, then creating and compiling the server and client bundles.
This would be exposed as a command line tool, as well as a Node API, to allow developers to integrate this optimization step into their build processes without adding additional dependencies outside of the compiler, some types if you're not using Typescript already, and some new React core packages for the client and server coordination.
What's "Next" and how you can help
At the very least, this would provide a way for all React devs to try out server components without the overhead of learning and implementing applications in a heavy framework. At the very best, it would allow application developers to integrate server components in a lightweight and seamless fashion into new and existing codebases. Overall I'm excited about the possibilities. Are you?
If so, I'd love ideas and contributions! I'd be happy to chat about:
- Would you use this tool?
- If so, or if not, what would make it a better fit?
- What might you do to contribute to this open source project?
Let me know in the comments, I'd love to chat and work with y'all!
