Examples
AppProvider works by default without any additional options passed to it.
App provider is a required component that enables sharing global settings throughout the hierarchy of your application.
AppProvider works by default without any additional options passed to it.
The app provider component is required to use Polaris. Without it, the components in your application will not function correctly. You must wrap the root (the top) of your application in the app provider component. We’ve created several examples to show how that’s done.
Translations are provided in the locales folder. When using Polaris, you are able to import translations from all languages supported by the core Shopify product and consume them through the i18n
prop.
If a project has only one locale, then you can pass the JSON content from the locale file into AppProvider
.
import AppProvider from '@shopify/polaris';
// en.json is English. Replace with fr.json for French, etc
import translations from '@shopify/polaris/locales/en.json';
function App() {
return <AppProvider i18n={translations}>{/* App content */}</AppProvider>;
}
If a project supports multiple locales, then load them dynamically using @shopify/react-i18n
. This ensures that you load only the translations you need.
import AppProvider from '@shopify/polaris';
// en.json is English. Replace with fr.json for French, etc
import translations from '@shopify/polaris/locales/en.json';
import {useI18n} from '@shopify/react-i18n';
function App() {
const [i18n] = useI18n({
id: 'Polaris',
fallback: translations,
translations(locale) {
return import(
/* webpackChunkName: "Polaris-i18n", webpackMode: "lazy-once" */ `@shopify/polaris/locales/${locale}.json`
).then((dictionary) => dictionary && dictionary.default);
},
});
// i18n.translations is an array of translation dictionaries, where the first
// dictionary is the desired language, and the second is the fallback.
return (
<AppProvider i18n={i18n.translations}>{/* App content */}</AppProvider>
);
}
By default Polaris renders <Link>
elements (and action objects) as <a>
tags. That works well for simple one-page demos. However for more complex multi-page applications that use a router such as react-router
you will want links to use the components provided by your router. If you don't then every link will be an <a>
tag and thus trigger a whole page refresh instead of navigating client-side.
The linkComponent
prop allows you to customise how links behave within Polaris by allowing you to inject your router's own Link component. The following example demonstrates using react-router's Link
component.
import {BrowserRouter, Link as ReactRouterLink} from 'react-router-dom';
function App() {
return (
<BrowserRouter>
<AppProvider linkComponent={Link}>
{/* App content including your <Route> components */}
</AppProvider>
</BrowserRouter>
);
}
const IS_EXTERNAL_LINK_REGEX = /^(?:[a-z][a-z\d+.-]*:|\/\/)/;
function Link({children, url = '', external, ref, ...rest}) {
// react-router only supports links to pages it can handle itself. It does not
// support arbirary links, so anything that is not a path-based link should
// use a reglar old `a` tag
if (external || IS_EXTERNAL_LINK_REGEX.test(url)) {
rest.target = '_blank';
rest.rel = 'noopener noreferrer';
return (
<a href={url} {...rest}>
{children}
</a>
);
}
return (
<ReactRouterLink to={url} {...rest}>
{children}
</ReactRouterLink>
);
}
You must include Polaris context in your tests when you use Polaris components.
To make this easier for you, we’ve provided: