Consider Exposing React Components as an Alternate API

[sebmarkbage]

It would be cool to have format.js React components instead of the mixin. Something like:

return <div><Number style="percent">{0.9}</Number></div>

That way you don't need the mixin in your component.

Currently this requires an extra wrapper element, but I think we'll be able to get rid of that limitation in React.

[juandopazo]

@ericf just had this same idea last week!

[ericf]

Yeah, I had this same thought last week. The declarative form reads much better (when using JSX).

In the example you have above, you'd need to also pass a value for the locales prop. In general we found that threading the locales, formats, and messages props through the entire component hierarchy gets noisy. Which is why we ended up going the mixin route to begin with.

So I think we'll still want this package to also export a mixin that can optionally be used to pipe the i18n metadata through the hierarchy of components via the context. This way you could do something like:

<App locales="en" messages={...} formats={...}>
  <Number style="percent">{0.9}</Number>
  <div>
    <Number>{1000}</Number>
  </div>
</App>

The App component would use the mixin (as would Number, Date, etc.) so that Number could then reference the locales value within its context. This would keep things DRY since these i18n metadata values are usually constant through the app's rendering hierarchy.

@sebmarkbage do you think that combo sounds like a good design (mixin being optional, but helps keep things DRY)?

[sebmarkbage]

Yea, you can use context to implicitly thread the locales down.

The app just needs to do something like:

getChildContext() {
  return: { reactIntlLocale: 'en' };
}