Closed SachaG closed 3 weeks ago
Technically async libs like React Query might be considered state management, but that’s probably ok to keep it this way.
I would also add the React Context API in this category because it’s often used alongside other small libs (Zustand, useState) to provide “global” state management.
Use React for: I feel like the very important “dynamic content site” option is not really present here. As an e-commerce or marketing CMS-based-site, I’m not static and I’m not really an app either. There’s a big difference between an app (SPA, can show spinner on load) and a site that need SEO, perf and great loading UX. I’m not sure to understand the difference between desktop app (electron?) and web apps (figma? e-commerce?).
Rendering patterns: I’m not sure many will know if they even use features such as “progressive hydration” or “streaming SSR”. They might keep it unchecked despite using it if they don’t have the option “I don’t know what it is”
Most excited about:
N/A
There are React design decisions that @rickhanlonii could probably advise us on, such as:
useInsertionEffect
, act()
, useDebugValue
, useImperativeHandle
?React.cache
in this year's survey? I thought it was not planned for v19.0 but apparently it's documented already.hydrateRoot
, renderToString
, renderToPipeableStream
... ?Suspense
, useTransition/startTransition
, useDeferredValue
belong to the "New APIs" section useMemo
+ use
) be mentioned as an exciting upcoming feature?Server Actions -> renamed as Server Functions
Server Actions still exist. The "parent" category is called Server Functions, implying there will be other function-like things that, well, run on the server. So I'd recommend keeping Server Actions.
React.cache()
isn't going anywhere AFAIK.Awesome feedback! Also as a more general point, beyond simple features/libraries/etc. questions, I'm also happy to consider more targeted questions that might help address specific issues that the Next.js, React, etc. teams might be having. e.g. it could be something like "what are the obstacles preventing you from adopting RSCs in your codebase", etc. if that happens to be a topic you guys would like to learn more about.
First thanks @slorber for this extended feedback which is awesome :eyes:
Regarding Application patterns, we could simplify and stick to most common patterns, and maybe provide a free text for "your favourite pattern this year" (eventhough that's more work for us). The current list mixes framework specific wording like islands, patterns that are slightly redundant etc.
I would propose:
Basically I removed stuff that are automatically brought by the framework, eg streaming SSR or island, and focused on patterns that are actual decision from the user
NP 👍
The question I find the most confusing is not the Application Pattern but the React usage one. I wouldn't know how to classify an e-commerce/media/marketing/blog/cms-based content site.
Maybe it could be useful to explain what you mean for each option. For example: Desktop apps (Electron or corporate web backoffice app?), Web apps (websites included?).
Maybe adding a "Web sites" option, and a description for each option would be useful?
For application patterns, I don't really know what's best.
What I don't like is to present boolean choices to things that are implementation details, and that users may not be aware of using. The boolean choice (yes/no) might bias the results. All the options would be fine if there was a way to answer "I don't know"
SPA/view transitions: pure client-side routing
I find this option a bit confusing because of cross-docuent view transitions, it also works for MPA despite not using pure client-side routing
act
useDebugValue
seems a bit too niche?useImperativeHandle
useInsertionEffect
useLayoutEffect
because of the warning in the docs. But if you think it's important I'll add it. useTransition
and usedeferredvalue
are both includedI’m not sure if Suspense, useTransition and useDeferredValue should appear in that New section. Maybe worth consulting the React core team on their opinion.
Forms: I would find it interesting to have some kind of “Form Practice” question and add uncontrolled + controlled choices including positive/negative feedback on each
I would also add the React Context API in this category because it’s often used alongside other small libs (Zustand, useState) to provide “global” state management.
I'm kind of leaning towards removing useState
rather than adding Context to be honest. I think it's kind of an unfair comparison to include a core API among libraries, although I added it to have a baseline of sorts.
Would replace Fetch/Axios by useEffect. You can use those libs as an implementation detail of fetching with useEffect, but also with React-Query, SWR etc.
I think it'd be confusing to have useEffect
here. Maybe instead some generic term like "generic data loading library" or "network library" like you suggested?
Add a comment in Remix such as “including React Router using with the new Vite plugin”, since Remix is kind of merging back into React Router the line is blurry.
This reminds me of the Angular.js vs Angular situation… I'll think about it but I think it'd be better for everybody to keep the "Remix" brand alive to avoid confusing people.
Great 👍
useInsertionEffect
is clearly niche and I don't know anyone using ituseImperativeHandle
is more commonuseLayoutEffect
is very common despite the docs warningI think it'd be confusing to have useEffect here. Maybe instead some generic term like "generic data loading library" or "network library" like you suggested?
To me useEffect
for data fetching is directly comparable to react-query
, swr
and others that are just abstractions build on top of it. You can use all 3 with fetch or Axios. Separating data loading from network lib might be better indeed.
We're live!
https://survey.devographics.com/en-US/survey/state-of-react/2024
Sorry, I know this was all a bit short notice, but I'm trying to get all the surveys out before the end of the year.
By the way, if you're able to share the survey (which would be very helpful!) please include a ?source=foo
tag at the end, such as:
https://survey.devographics.com/en-US/survey/state-of-react/2024?source=this_week_in_react
This will help us track where respondents are coming from, and see if it influences their answers in any way.
Under component libraries, I noticed that React Aria is the only one that has a description, not sure why that is. It is also using a bit of an outdated description, since React Aria is not only hooks anymore, it's also components. Think we can update that to avoid confusion (i.e. people might think this is only referring to the hooks and not the components)?
New description, from readme:
A library of unstyled React components and hooks that helps you build accessible, high quality UI components for your application or design system.
@devongovett yeah I need to remove library descriptions from the survey itself I think, they were meant for the survey results originally.
Update: the survey is now live! (and has been for ~10 days, actually)
It'd be a huge help if you can share it with your audience, especially @leerob !
FYI the OG image seems broken.
yes, looks like the meta is wrong @SachaG : https://assets.devographics.com/surveys/react2024-og.png
should be https://assets.devographics.com/surveys/react2024.png ?
Thanks @slorber I was exactly on it this morning ^^ so the "-og" variation is missing in our images repository. It's not so easy to detect automatically, as I would need to send a request to see if the URL exists. And it won't fallback automatically to another image, because we do have a non empty URL in the placeholder.
Fixed :)
Also see previous suggestions here: https://github.com/Devographics/surveys/issues/243