Usage of renderToStaticMarkup from react-dom/server in react Text component bloats client filesize

[morbidick]

Hi, thank you for this nice and small translation library.

In commit 3c1d0a0 renderToStaticMarkup from react-dom/server was introduced to the Text Component, unfortunately that leads to the inclusion for react-dom-server in the client build and bloating the filesize.

[pret-a-porter]

@morbidick Yes it is, but it allows to use React components as parameters for Text component

[appbak3r]

@pret-a-porter That's actually an issue for vite for example, having react-dom/server increases bundle size by 25% and it makes no sense to use the library

[lubieowoce]

Yes it is, but it allows to use React components as parameters for Text component

@pret-a-porter Right, but that component won't have access to things like context, because it's rendered in isolation. That feels like a pretty big footgun.

[pret-a-porter]

Make sense, issue reopened

[lubieowoce]

AFAIK the "proper" way to handle it is to make Text return a fragment, and let react handle the rest. So, something like the following:

// messages: { hello: 'Hello, {name}. Nice to meet you!' }

// a Text like this:
<Text id="hello" name={<SomeComponent />} />

// should output (return) this:
<>{"Hello, "}<SomeComponent />{". Nice to meet you!"}</>

[pret-a-porter]

Unfortunately it does not cover case, when string contains html tags. React fragments does not support dangerouslySetInnerHTML and this proposal reactjs/rfcs#129 still in RFC stage for more than two years.

[lubieowoce]

yes, html strings would probably need to be parsed into a react tree (a la react-html-parser). not ideal, but i don't think there's a way around it if you want to have <Elements> work properly. i guess at least its cacheable (the translations don't really change much) so shouldn't be a big perf problem