amannn
commented
3 years ago An alternative (or possibly addition) is a concept based on the recently announced server components.
Code like this:
function LatestFollower({user}) {
const t = useTranslations('LatestFollower');
function onFollowClick() {
UserAPI.follow(user.id);
}
return (
<>
<Text>{t('latestFollower', {username: user.name})}</Text>
<IconButton
aria-label={t('followBack')}
icon={<FollowIcon />}
onClick={onFollowClick}
/>
</>
);
}… could be turned into:
function LatestFollowerServer({user}) {
const t = useTranslations('LatestFollower');
return (
<LatestFollowerClient
$1={<Text>{t('latestFollower', {username: user.name})}</Text>}
$2={t('followBack')}
$3={<FollowIcon />}
/>
);
}
function LatestFollowerClient({$1, $2, $3, user}) {
function onFollowClick() {
UserAPI.follow(user.id);
}
return (
<>
{$1}
<IconButton aria-label={$2} icon={$3} onClick={onFollowClick} />
</>
);
}These are the interactive features that React currently has:
- useState
- useReducer
- use(Layout)Effect
- refs (and thus useImperativeHandle)
- event listeners
Most are easy to detect, but event listeners seem a bit tough, since it could potentially be a render prop. A convention like on[A-Z].* would definitely help here.
nbouvrette
yashvesikar
gurkerl83
stylehuan
Messages can either be consumed in Server- or Client Components.
The former is recommended in the docs, as it has both performance benefits as well as a simpler model in general since there is only a single environment where code executes. However, for highly interactive apps, using messages on the client side is totally fine too. The situation gets a bit hairy when you need to split messages based on usage in Client Components (e.g. by page, or a mix of RSC / RCC).
Ideally, we'd provide more help with handing off translations to Client Components.
Ideas:
(1) User-defined namespaces
This is already possible (and shown in the docs), but unfortunately not so maintainable. For single components it can be fine however, so when you have many small interactive leaf components, this is quite ok.
(2) Manually composed namespaces
This worked well for the Pages Router and was documented, but unfortunately doesn't work with RSC.
Apollo has a similar situation with static fragments: https://github.com/apollographql/apollo-client-nextjs/issues/27
A potential solution could be to use a build-time macro that is evaluated separately.
(3) Compiler-based approach
See https://github.com/amannn/next-intl/issues/1#issuecomment-1497645889. Similar to fragment hoisting in Relay, if the collection of namespaces happens at build time, we could provide this list to Server Components. This seems to be the best option.
Current progress:
See also: Dependency tree crawling