https://github.com/daostack/common-web
The web UI for the Common project
https://github.com/daostack/common-web
Last synced: 3 months ago
JSON representation
The web UI for the Common project
- Host: GitHub
- URL: https://github.com/daostack/common-web
- Owner: daostack
- Created: 2021-10-20T15:42:02.000Z (over 3 years ago)
- Default Branch: dev
- Last Pushed: 2024-12-31T10:44:13.000Z (6 months ago)
- Last Synced: 2025-01-24T14:18:26.900Z (5 months ago)
- Language: TypeScript
- Homepage: https://common.io
- Size: 149 MB
- Stars: 1
- Watchers: 0
- Forks: 0
- Open Issues: 111
-
Metadata Files:
- Readme: ReadMe.md
- Support: docs/supporters-flow.md
Awesome Lists containing this project
README
This project was bootstrapped with [Create React App](https://github.com/facebook/create-react-app).
## Available Scripts
In the project directory, you can run:
`yarn start` -
Runs the app in the development mode.
Open [http://localhost:3000](http://localhost:3000) to view it in the browser.
The page will reload if you make edits.
You will also see any lint errors in the console.
`yarn test` - Launches the tests.
`yarn run test:watch` - Launches the test runner in the interactive watch mode.
`yarn build` - Builds the app for production to the `build` folder.
It correctly bundles React in production mode and optimizes the build for the best performance.
The build is minified and the filenames include the hashes.
Your app is ready to be deployed!
See the section about [deployment](https://facebook.github.io/create-react-app/docs/deployment) for more information.
## Project architecture
Check out structure of the `components` folder [here](./docs/page-structure.md).
## Principles
1. We should make the logic to be more abstract. Lots of our components are tied to specific types, even though we need only a few fields from that type. Later this leads to the point where for example we use discussion messages everywhere and now we have chat messages, the types are different and we should reinvent the wheel to make it working in a kinda good way.
A lot of such code issues are because we do not have enough time, or we didn't know future plans that time. But, anyway, big feature should be written in an abstract way with understanding that it may be extended somehow in the future.
## Storybook
Check out [Write stories](https://storybook.js.org/docs/react/writing-stories/introduction) series of articles on Storybook docs site to understand what is "story" and how to write them. [Testing](https://storybook.js.org/docs/react/writing-tests/introduction) articles will show which kind of tests we can write for our stories.
In our project we put stories next to the component file itself and name it as `ComponentName.stories.tsx`.
`yarn run storybook` - Runs storybook
`yarn run test:storybook` - Runs tests for Storybook stories
`yarn run test:snapshots` - Runs snapshot tests for Storybook stories
`yarn run update:snapshots` - Updates snapshot tests for Storybook stories
## Testing
For testing purposes we are using **React Testing Library**. The main idea of this library is to avoid testing implementation details or testing again the logic of a nested component which already is covered by tests.
️Please read small instruction from the library regarding writing the tests: [link 1](https://testing-library.com/docs/#what-you-should-avoid-with-testing-library) and [link 2](https://testing-library.com/docs/guiding-principles) ❗️️️
[Here](https://kentcdodds.com/blog/testing-implementation-details) is a good article about why testing of implementation details is not good.
Of course, sometimes it is necessary to know something about the inner logic and here we can just mock it to use our [logic from the tests](./src/pages/MyAccount/components/Billing/BankAccount/BankAccount.spec.tsx#L14-L56).
Cases where we need to test calls to BE, test store changing after BE call, test redirecting, etc... is more related to integration tests, which our project doesn't use.
### Unit testing
What we should test:
- utils or any helpers we are writing for our components;
- components, which are units on our pages. It is hard to write unit tests for the components which use under the hood some other components and have some logic with those components. To test such components we should use integration tests. But we still can cover by unit tests nested components;
- cases where we use different logic based on user viewport (desktop or mobile);
- reducers.
### How to write test
Create a new file near the file you are going to test. Use the same file name, but add `spec` before the extension.
Examples:
- `formatDate.ts` -> `formatDate.spec.ts`
- `Button.ts` -> `Button.spec.ts`
If you need to mock something you can create a file in [utils/tests](./src/shared/utils/tests) and import a newly created file in the [setupTests.ts](./src/shared/utils/tests/setupTests.ts) file.
## Run the project with local Back-end
1. Check out [common-backend](https://github.com/daostack/common-backend) repository and follow the `Installation` and `public Dev env` sections to run the project in the dev mode;
2. Go to the [controller](https://github.com/daostack/common-backend/blob/dev/functions/src/users/controllers/create.ts#L20-L27) for user creation. Look for the `if` statement `process.env.NODE_ENV !== 'local'` and remove `else` part, as well as `if` check (leave the code which is in that `if` block);
3. Open [package.json](./package.json) file and change `REACT_APP_ENV=dev` to `REACT_APP_ENV=local` in the `start` script.
4. `yarn start`
## Supporters Flow
The documentation is [here](./docs/supporters-flow.md).