Default namespace is called common
and contains translations used on all pages (Layout, Nav, etc) and is stored at frontend/public/locales/{locale}/common.json
Namespaces (scopes, domains) are stored in separate json files at frontend/public/locales/{locale}/{namespace}.json
One namespace can combine the translations keys from several pages with common reusable strings ex. auth
scope collects keys for login
and register
pages.
It is preferred to use kebab-case for translation keys and extract another level of nesting when the common prefix of the keys is above 3 or makes sense to be separated as new keys might be added in the future.
Namespace is separated with :
Translation nesting levels are separated with .
Words in a translation key are separated with -
domain:pages.nested-level.another-nested-level.translation-key
Usage of translation hook useTranslation
is preferred over usage of <Trans />
component, whenever possible.
Simple strings are mapped directly to their respective translation
Complex translation keys are being evaluated upon translation
Commonly used translations with the same translation key
Custom translations with keys defined right next to the form
A common way to sort the imports in the file is by their source: external
, absolute
, relative
separated by an empty line. Each of those groups can be sorted by line length, but that's not super important.
Inherits AirBnb naming convention https://github.com/airbnb/javascript/tree/master/react#naming
Use PascalCase for React components and camelCase for their instances
Pascal cased file names src/components/GenericForm.tsx
Filename and default component of the file should have the same name.
Camel cased file names src/utils/hooks/useUser.ts
Lowercase kebab cased folders src/components/common/password-reset/ResetForm.tsx
Lowercase kebab cased files located in src/pages/sample-page.tsx
which correspond to /sample-page
url.
The common convention is that the main type of the component's props is called after the component itself with suffix -Props
. Prop types of AdvancedForm
becomes AdvancedFormProps
.
Nice IDE support and readability
Named function
Const arrow function
Discouraged as hooks cannot be used inside the class components
There are three common ways to style a component:
<Box />
componentSingle component that inherits all sizing props from MUI https://material-ui.com/system/basics/#all-inclusive
useStyles()
hookNext.js supports SCSS out of the box. Read more at https://nextjs.org/docs/basic-features/built-in-css-support#sass-support
File convention is based on a suffix .module.scss
(ex. about.module.scss
)
Allows attaching static props to the function
Nice for locally defined components
Okay for default exports, but not preferred
Unnamed arrow function
Class components
Nice for quick layouts that should follow the theme
Not the best for custom scenarios with more than _six props passed to it. Use hooks
instead
Not nice when the children have clear nesting structure of more than _three levels. Use hooks
or scss
instead
Nice for very specific styling that leverages theme
methods and props
Too verbose for simple use cases, if it contains less than 2 css rules. Use Box
instead
Not the best when dealing with styling of deep nested structures within the same component. Use scss
instead
Nice when dealing with complex nested structures that are scoped in a single component. When dealing with sub-components we're not sure if some of the rules will be left unused.
Too verbose for simple use cases, if it contains less than 2 css rules in a dedicated file. Use Box
instead
Cannot use theme support or theme variables Use hook
instead