Performance and Optimisation

The site is built in React with state management handled via MobX. Many optimisations are already provided and there are a few things that it is worth developers being aware of:

React Component, PureComponent, Memo with MobX

React has different tools to control how often a component render/re-renders, however, Mobx overrides default behaviours with its own optimisations (they can update without prop changes). As a rough rule:

• Components decorated with MobX observers should be regular components. Mobx will handle optimisation
• Components receiving props from a store will likely also remain as regular components
• When developing with MobX try to follow the advice as outlined here: https://mobx.js.org/best/react-performance.html
• When developing new components/features try to roughly benchmark renders using console.count within the render function. Make optimisations to reduce as recommended here: https://reactjs.org/docs/optimizing-performance.html

Forms

One of the easiest sources of inefficiency is from forms created with react-final-form. A couple of specific tips:

• If using validation, always include a validateFields prop as this specifies how often the validation check should be run, and by default it is on any change to any other field. simply specifying validateFields={[]} will ensure validation only occurs when the field itself is changed. See: https://final-form.org/docs/react-final-form/types/FieldProps#validatefields
• Again, try to benchmark how often the form re-renders, validation occurs etc. Typically any top-level validation will happen on every change so should be kept as simple as possible, doing any necessary calculations in advance on relevant field change.

General

During v1 development of the platform not much time was spent on optimisation (quite simply there was a lot to do and learn), so likely there will be lots of examples of inefficient or poorly-optimised code throughout so do not assume what is there is always the best practice. If you enjoy fine-tuning and refactoring then please be encouraged to do so(!), although try to focus on smaller chunks at a time to avoid too many knock-on effects.