Make a package instead of a framework, so we can more easily integrate it into all the existing SPAs.
Something we could integrate with route loaders for instance.
13.12.2025 18:58
👍 1
🔁 0
💬 0
📌 0
Make a package instead of a framework, so we can more easily integrate it into all the existing SPAs.
Something we could integrate with route loaders for instance.
@en-js.bsky.social
I guess this is the relevant bug for the thing I was asking about earlier:
github.com/facebook/rea...
Much appreciated! 🙌
Maybe pull connect out in a separate “compat” package in a major?
Oops! 😅
It’s the right thing to do, it’s time 🙂
Very exciting! 🙌🏻
Yes. Still like it. Especially for code navigation.
Tried switching to VS Code a few times but just doesn’t feel as powerful, even with all the recommended plugins.
But you need a powerful machine to run it smoothly.
Also hoping that Concurrent Stores will eventually make the Redux + Transitions story more viable. So far it’s seemed to me that transitions can only work if React controls the state, which of course is not the case for us.
Very cool. Although gotta say, gonna have to read it a few more times to groc it 🤷🏼♂️😅
Our apps tend to use Redux and RTKQ, which uses uSES under the hood I think. Will that mean it cannot be enabled? Or does it depend on how and where we use Redux? Needs to be tested I guess.
I ended up removing the useCallback and switching to the "set state in render" recommendation anyway, so just curios.
react.dev/learn/you-mi...
Why does the "preserve-manual-memoization" rule require that we add state setters to the useCallback deps?
I guess the 'react-hooks/react-compiler' rule is completely gone now?
We were on React 18, eslint-plugin-react-hooks ^6.0.0-rc.1, and react-compiler-runtime 19.1.0-rc.3.
Suddenly our linter is failing all over the place with "Definition for rule 'react-hooks/react-compiler' was not found.
Is it a drop-in replacement for the useNonReactiveCallback in the Bluesky codebase?
The author of this article might have a good example?
blog.theodo.com/2019/07/how-...
The “custom dataStrategy to do even more advanced stuff” sounds like an interesting blog post 🙂
So it’s using createBrowserRouter?
Or do you mean framework mode with loaders?
«But I also feel that the "recommendation" has turned into an overly-broad prescription that doesn't give enough credit to the variety of ways React is used in practice throughout the ecosystem.»
100%!!!
blog.isquaredsoftware.com/2025/06/reac...
Could you share some examples of how to use it for non-forms stuff?
What’s the module federation story with Parcel? Does it work with the new “core” package, probably with the runtime part I would guess in that case?
It’s great that there is a viable path now, but my point is more that there should have been one from the start if the team expected more adoption.
This is great, but migrating from Webpack or Vite is also not always feasible.
I think the React team have underestimated the size of the ecosystem, and how difficult it might be to completely migrated the stack of an existing app.
This is why RSC doesn’t have a lot of adoption yet imo.
If there was a Webpack plugin + Node adapter people could plug into their existing spas then that would facilitate it a lot more.
I’ve played with it Next for sure, but Next not an option for us.
Just don’t get this impression that devs “don’t get it” from the react team.
There aren’t a lot of ways to adopt it outside Next.
Support in Vite + React Router will help.
The BFF? Node.
React + Webpack on the client.
Had it for 10 years. Still waiting for a way to start using RSC.
Finding it super hard to get wins (zero build).
The first season of this chapter was cool tho, with the proper katana and more fully fledged Japanese theme all over.
Personally I'm excited about RSCs, but still haven't found a path to adoption, since Next is out of the question for us.
Recently migrated an app to React Router 7 (framework), so now I'm waiting for support in Vite I guess.
For better or worse, the vast majority of existing web apps use webpack, and are moving towards Vite. "Releasing" RSCs without any way for those developers of adopting it made it fairly predictable imo that it would struggle to get properly understood. "Use a framework" didn't help with the FUD.
It would also help if it was possible to use RSCs outside of Next :)
And Parcel now, I know. But making some type of general plugin for webpack, similar to how Parcel now supports it, would have given RSCs a much better chance of success imo.
