 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
There are few good reasons not to try React server actions and React server components (RSC), argued Andrew Clark, a software engineer at Vercel, whose Next.js framework will support both.
For instance, if you aren’t running JavaScript on your server, that would be a good reason not to embrace RSCs, he acknowledged — although, maybe reconsider that choice, he quipped.
React Native doesn’t have a server components implementation yet, so it still requires traditional methods, Clark added. Otherwise: Try RSC, he suggested during a panel discussion on React Server Components during the React Summit U.S. 2023 held in New Jersey earlier this month.
Server actions are functions that run on the server and can be used to fetch data, perform calculations, or mutate data before it is sent to the client. React Server Components are what the name says: React components that run on the server to render dynamic content.
“RSCs are just way simpler and it might take like a year or two, or some time, to convince everybody of this,” Clark said. “Server actions — I know there’s some controversy, but if you give it a shot and keep an open mind, it’s just way simpler than not using server actions.”
RSC is particularly useful if you’re using a lot of data on the server side, according to panelist Kathryn Middleton, a Meta engineering manager on the React team.
It misses the point to think about RSCs as appropriate for some uses and not others, suggested panelist Matt Carroll, a Meta developer advocate on the React team. Instead, he advised developers to look at the individual constraints of their projects. That said, he agreed that developers who are starting afresh should embrace RSCs, because it’s easier than not doing so.
“If you already have an internal app that’s working with Create React App, and you don’t have any problems with it, I don’t feel like you’d need to use server components just to use server components,” Carroll said. “But if you’re encountering some problems with bundle sizes, or some latency, making network requests from the client that would be better served making those requests from the server, that could be something to look at.”
Josh Comeau, a software engineer who runs The Joy of React — and maybe the person with the least reason to promote RSC — added that while there’s “no big urgency,” RSC is cool and should be considered if building a new application today.
Ultimately, using RSCs gives developers more choices, the panel agreed.
“React, forever, has been: you ship everything to the client and if you want to fetch something, well, use query, I guess, because use effect is scary,” said Benjamin Holmes, a full stack developer with the web framework company Astro. “There hasn’t really been an answer for I need to go back to the server and get more stuff. Server actions is that answer to get more stuff, and it injects into forms really nicely.”
The panel then responded to audience questions, including whether the panel thought RSC offers anything beyond what a single page application (SPA) model offers.
“I definitely do,” Clark said.
The mental model of server components is simpler, contended fellow panelist Tom Preston-Werner, co-founder of the fullstack framework RedwoodJS, which committed to being “all in” on React at the conference.
“If you think back to some traditional multi-page application kind of frameworks, like Ruby on Rails, etc., it’s very easy to think about how that works,” he said. “You have a server, you fetch some data on the server, you produce a page and deliver HTML to the client…. Then you might layer some JavaScript on top. React server components allow you to do the same thing, but now fully with React, choosing where your boundary between the server rendered and the client rendered functionality goes.”
It’s even useful with single page applications, the panelists agreed.
“When you’re starting, if you start with server components, you can build a single page app — but what if you don’t start with [a] server component compatible framework, you cut yourself off from being able to leverage the server later on, without having to do a very rough rewrite,” Carroll warned.
There are plenty of examples of people building complete client-side applications that just deploy to a content delivery network (CDN) building with a server component framework, he said. If they do decide to leverage the server, it’s just one component, he added.
“You might have some infrastructure you need to work with, but as far as the migration on the React side, you don’t need to do anything,” Comeau said.
It’s still early days for RSC and many are still exploring how it fits in with frameworks. Next.js is known for its canary experimentation with RSC, which led one audience member to ask the panel if it was a requirement for adoption.
Preston-Werner took that one.
“We’re working on RedwoodJS and incorporating React server components into RedwoodJS as an additional framework that you could choose if you want to choose React server components,” he said.
Meta’s Carroll is working with the Redwood team on that effort and said that he’d love to help anyone out who wanted to build a framework that leverages RSC.
“I’m really rooting for all these other frameworks, so I can stop having to answer that question,” joked Clark.
