Advanced Usage
react-intl is optimized for both runtime & compile time rendering. Below are a few guidelines you can follow if you have a strict performance budget.
Pre-compiling messages
You can also pre-compile all messages into AST using @formatjs/cli compile command and pass that into IntlProvider. This is especially faster since it saves us time parsing string into AST. The use cases for this support are:
- Server-side rendering or pre-compiling where you can cache the AST and don't have to pay compilation costs multiple time.
- Desktop apps using Electron or CEF where you can preload/precompile things in advanced before runtime.
Since this approach uses AST as the data source, changes to @formatjs/icu-messageformat-parser's AST will require cache invalidation.
AST is also slightly larger in size than regular string messages but can be efficiently compressed.
react-intl without parser (40% smaller)
If you've made sure all your messages & defaultMessages are precompiled as above, you can resolve @formatjs/icu-messageformat-parser to @formatjs/icu-messageformat-parser/no-parser during bundling to get a much smaller bundler (~40% less). For example:
webpack.config.js
module.exports = {
//...
resolve: {
alias: {
'@formatjs/icu-messageformat-parser':
'@formatjs/icu-messageformat-parser/no-parser',
},
},
}
rollup.config.js
import alias from '@rollup/plugin-alias'
module.exports = {
//...
plugins: [
alias({
entries: {
'@formatjs/icu-messageformat-parser':
'@formatjs/icu-messageformat-parser/no-parser',
},
}),
],
}
In the future, we'll gear towards making this the default behavior.
Imperative APIs
Imperative APIs (e.g formatMessage...) are generally faster than Formatted component since it does not create extra ReactElement nodes. They should have the exact same capabilities as Formatted components.
More examples
Head over to https://github.com/formatjs/formatjs/tree/main/packages/react-intl/examples for more examples on how to use our libraries.