Code Review Comments Typescript - msupply-foundation/open-msupply GitHub Wiki
useTranslation() doesn't need to include common
When using the useTranslation() webhook, you don't need to include the common
translation file as it is included by default.
Prefer
const t = useTranslation('distribution');
Rather than
const t = useTranslation(['distribution','common']);
useTranslation() with multiple translation files (namespaces)
We're using react-i18next for localisations. Collections of translatable items are grouped into namespaces so that we can reduce bundle sizes and keep files contained to specific areas. The namespace files are json files - kept separate from the main bundles and downloaded on demand. These are also cached locally in the browser.
When using translations in your code, if you specify multiple name spaces, only first one will to be used by default.
const t = useTranslation(['distribution', 'app']);
t('button.add-item'); // This will use the distribution.json translation
t('button.open-the-menu', { ns: 'app' }); // This will use the app.json translation
the common
namespace is always included as a fallback option, so you do not need to specify it as a namespace
const t = useTranslation();
useTranslation() with plurals
When translating strings, it's common to need a singular and plural option.
This can be accomplished using a _one
and _other
suffix on the translation key and passing a parameter to the translation request called 'count'.
Example
common.json
{
"permissions_one": "Permission",
"permissions_other": "Permissions"
}
example.ts
const t = useTranslation();
let permissionList = ['Permission a'];
let translation = t("permissions", {count: permissionList.length});
// translation will contain 'Permission'
let permissionList = ['Permission a', 'Permission b'];
let translation = t("permissions", {count: permissionList.length});
// translation will now contain 'Permissions'
Avoid using type assertions ('as' keyword)
Use of type assertion should be avoided, it can cause runtime errors in what looks like safe code. If type assertions have to be used, the resulting type should be consumed entirely in the same scope (with maximum amount of safety checks):
const myCanvas = document.getElementById("main_canvas") as HTMLCanvasElement;
if (!myCanvas) throw new Error("no canvas");
if (!myCanvas.getContext) throw new Error("not a canvas");
const gl = myCanvas.getContext("webgl", {
antialias: false,
depth: false,
});
Example of why type assertions can be dangerous
interface Check {
id: string,
willBeMissing: string
}
// ..
const doCheck = (check: Check) => {
console.log(check.id)
// ..
helper(check)
}
const helper = (check: Check) => {
console.log(check.willBeMissing.length) // runtime error (if check not Check)
}
// ..
const getLooksLikeCheck = () => ({ id: 'one' });
doCheck(getLooksLikeCheck() as Check) // runtime error
Union alternative to the above (with minimum changes)
Imports
If using co-pilot ( and possibly other helpers 🤷 ), you may have an auto generated import appear which has the format 'packages/..' Do not use these! While it will work as a standard runtime import, it will cause jest tests to fail.
Prefer
import { InternalSupplierSearchModal, NameRowFragment } from '@openmsupply-client/system';
Instead of
import { InternalSupplierSearchModal, InternalSupplierSearchModal, NameRowFragment, NameRowFragment } from 'packages/system/src';
You can generally find an aliased path to use instead, or a reference which is relative to the current file.
When exporting from packages, if an item is to be used outside of the package, export it from the package itself. This may require exporting from the root index.ts
of the package and back up the tree of index files.
Prefer
import { InternalSupplierSearchModal, NameRowFragment } from '@openmsupply-client/system';
Instead of
import { NameRowFragment } from '@openmsupply-client/system/src/Name/api';
This makes is clear exactly what is being exported, and therefore depended on, out of the package. It's also neater ( personal opinion! ) and less fragile. If you are exporting from the root of the package then the internal structure can safely change.