- Prettier
- ESLint
- IntelliCode
- GitLens
- Live Share
- GitHub Pull Requests and Issues
- Bracket Pair Colorizer
Please use conventional commit messages: https://www.conventionalcommits.org/en/v1.0.0/
The idea is to use the approach described in the bottom of the document: React for element creation, D3 as the visualization kernel
Please read the following blog post:
https://dev.to/glebec/four-ways-to-immutability-in-javascript-3b3l
And in particular we use Immer: https://github.com/immerjs/immer
If you have a component that re-renders because of a hook that changed but you
don't know which hook it was, you can temporarily add a call to
useWhatChanged
.
It will print to the console what changed at each render.
Do not forget to remove the call and the import when you have finished to debug!
import { useWhatChanged } from '@simbathesailor/use-what-changed';
export default function SomeComponent() {
const [state, setState] = useState();
const context1 = useSomeContext();
const context2 = useSomeOtherContext();
useWhatChanged([state, context1, context2], 'state,context1,context2');
return <div />;
}
We use the Vitest test runner.
Keep the tests simple and focused. Do not hesitate to write many tests instead of doing everything in the same test. This is important because in case one test fails, the others will still run.
Use describe()
blocks to group tests in a meaningful way. It is not useful to have only one big describe()
with the name of the file.
Please write any unit test as close to the tested file as possible, in a __tests__
subdirectory.
The test file's name should end with .test.{js,jsx,ts,tsx}
.
For example, tests for the file located in src/data/data1d/autoPeakPicking.js
should be written in src/data/data1d/__tests__/autoPeakPicking.test.js
.
You can run all unit tests with npm run test-only
.