Usage of renderToStaticMarkup from react-dom/server in react Text component bloats client filesize about eo-locale HOT 7 OPEN

Make sense, issue reopened

from eo-locale.

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

from eo-locale.

@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

from eo-locale.

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.

from eo-locale.

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!"}</>

from eo-locale.

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.

from eo-locale.

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

from eo-locale.