Potential alternative RSC approach recommendation #2284
pawelblaszczyk5
started this conversation in
General
Replies: 1 comment 3 replies
-
👋 Hi there! Nice summary and investigate. Yes indeed when that decision was made the knowledge was very limited, more over it's still limited on my side because i don't have project using RSC, so i cannot dogfood that solution. So summarizing your post, the best solution for Lingui would be just |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello 👋
I'm playing with RSC in various setups a lot and recently I started implementing a first app that needs i18n to work. Obviously I immediately started experimenting with Lingui as I like this approach the most. However after reading the documentation it felt to me like the current setup could perhaps be simplified for most of the users. It'd also solve a lot of existing issues/discussions that I found browsing the repository
So before getting into a different solution, let's talk about few issues about current recommended setup:
cache
functionality. It leads to a few issues, e.g. How to make Lingui RSC translations work for "special" nextjs loading file? #2121 or people just forgetting about callingsetI18n
While reading this discussion - #1698 it feels to me like at the time the decision was made, the understanding of React Server Components and the surrounding ecosystem was still evolving. I think there's an opportunity to revisit some design decisions with the current understanding of RSC. So what can we do?
Currently the approach at a library is simple -
useI18n
/Trans
implementation is branched based onreact-server
condition. But let's think about one thing - do we need the translations in RSC environment at all? This was already proposed by one of the commenters here - #1698 (comment) but the main issue was that it'd lead many components to become a client components - #1698 (comment)However, that's not entirely true, let's look at this:
is a valid pattern to render from RSC environment. It won't cause any issues with
ServerComponent
, orSharedComponent
JS being delivered to the client or anything like that. FromClientComponent
perspective - it just got someReactNode
passed as a children. So we can have a client component high up in the tree, without changing whole tree into client components - as long as we use composition.That leads us to one big thing - by using
Trans
as a client component we'll actually send less data to the client:Trans
is usually used as a leaf node and more importantly it doesn't render any meaningful content by itself. It only does two things (simplifying stuff a bit) - renders translation string for a given ID and merges any ReactNode's passed to it via props to the final content version. AndTrans
will be delivered to the client either way, unless someone is not using translations inside of client components at all, which is rather an uncommon case.and then pass these messages to slightly adjusted
I18nProvider
- it won't be serialized. It'll be sent as a reference to JS bundle, which includes these messages. That means these can be cached, they aren't duplicated, don't need to be refetched on each revalidation etc.That's a setup that's 100% possible to use right now without any changes to the library itself - you can use
runtimeConfigModule
to loadTrans
from an entry point that's marked with "use client" easily. However, I feel like it'd be nice to lead more users into this kind of setup, because it imho has a lot better tradeoffs than currently recommended one. It'd solve a lot of pain points they're currently facing without major drawbacks for most of the cases.Moreover, it'd make the setup more portable around different RSC implementations - e.g. I currently used it with Vite without any issues. https://github.com/pawelblaszczyk5/vite-rsc-experiments/tree/main/apps/lingui The same setup without any changes would work in any RSC implementation, even if someone is doing e.g. an SPA using the RSCs.
I know that RSCs can get pretty complicated and they're a new paradigm that still evolves and ecosystem constantly looks for better solutions. I'm really eager to answer any questions regarding RSC/the setup here and I'd be happy to provide any PRs/examples if you'd be open to them. I thought that it'd be much better to open a discussion to know what do you think about this setup first. Maybe I'm missing something that you considered? I've read all the stuff through various issues/discussions there but I guess there was a lot more going through your minds when implementing this into Lingui. Appreciate all the work you've put into Lingui – it's one of the best i18n solutions out there.
Beta Was this translation helpful? Give feedback.
All reactions