diff --git a/.circleci/config.yml b/.circleci/config.yml index edee27aeb..802c4b360 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -55,6 +55,4 @@ workflows: build_and_test: jobs: - build - - test: - requires: - - build + - test diff --git a/.env b/.env deleted file mode 100644 index c576aeaf7..000000000 --- a/.env +++ /dev/null @@ -1,10 +0,0 @@ -REACT_APP_APP_NAME=Prediction Market -REACT_APP_MARKET_CONTRACT=KT1Cupwd7N6Gx2nXXkrDoyUe7zTwXy2MxqEX -REACT_APP_FA12_CONTRACT=KT1XgDkZxyVQY3Gxs7UzfE7LKBJoC5jrb2Jv -REACT_APP_IPFS_POST_API=https://ipfs.newby.org/ -REACT_APP_IPFS_GET_API=https://tzconnect.mypinata.cloud/ipfs/ -REACT_APP_NETWORK_TYPE=FLORENCENET -REACT_APP_RPC_URL=https://florencenet.smartpy.io -REACT_APP_RPC_PORT=443 -REACT_APP_GRAPHQL_API=https://pmcache.newby.org/graphql -REACT_APP_SENTRY_DSN=https://1c98f7e1cc524d7684c2764e64fb9b04@o640348.ingest.sentry.io/5756958f \ No newline at end of file diff --git a/.env.example b/.env.example index c576aeaf7..e7a58657e 100644 --- a/.env.example +++ b/.env.example @@ -1,10 +1,11 @@ REACT_APP_APP_NAME=Prediction Market -REACT_APP_MARKET_CONTRACT=KT1Cupwd7N6Gx2nXXkrDoyUe7zTwXy2MxqEX -REACT_APP_FA12_CONTRACT=KT1XgDkZxyVQY3Gxs7UzfE7LKBJoC5jrb2Jv +REACT_APP_MARKET_CONTRACT=KT18sHKbZtXhXtnf6ZrHEW9VgEe2eCvRr2CS +REACT_APP_FA12_CONTRACT=KT1NRh99x6eY5Kh1DoXGmjm88aG7Te9J9pY8 +REACT_APP_FA12_SYMBOL=PMM REACT_APP_IPFS_POST_API=https://ipfs.newby.org/ REACT_APP_IPFS_GET_API=https://tzconnect.mypinata.cloud/ipfs/ -REACT_APP_NETWORK_TYPE=FLORENCENET -REACT_APP_RPC_URL=https://florencenet.smartpy.io +REACT_APP_NETWORK_TYPE=GRANADANET +REACT_APP_RPC_URL=https://granadanet.smartpy.io REACT_APP_RPC_PORT=443 -REACT_APP_GRAPHQL_API=https://pmcache.newby.org/graphql -REACT_APP_SENTRY_DSN=https://1c98f7e1cc524d7684c2764e64fb9b04@o640348.ingest.sentry.io/5756958f \ No newline at end of file +REACT_APP_GRAPHQL_API=https://kt1lybgnsg2gymfchavcxunjecqy59ujrwbf.tzconnect.berlin/graphql +REACT_APP_SENTRY_DSN= \ No newline at end of file diff --git a/.eslintrc.json b/.eslintrc.json index bdd1c4faf..7bb23dd50 100644 --- a/.eslintrc.json +++ b/.eslintrc.json @@ -3,6 +3,7 @@ "airbnb-typescript", "airbnb/hooks", "plugin:@typescript-eslint/recommended", + "react-app", "plugin:react/recommended", "plugin:react-hooks/recommended", "plugin:jest/recommended", diff --git a/.gitignore b/.gitignore index 87a91c781..32dc5683b 100644 --- a/.gitignore +++ b/.gitignore @@ -29,3 +29,4 @@ test-results/** eslint-report.json Dockerfile .dockerignore +.env \ No newline at end of file diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 000000000..1da402f17 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,161 @@ +# Contribution Guidelines + +## Dependency Checklist + +Before adding a dependency to the project please make sure it satisfies the below criteria: + +1. Is open-source and has a permissive license [MIT, ISC, Apache, etc.] +2. Is actively maintained + + 1. Check if the author/owner/maintainer is active in the github issues, fixing issues, adding features with new releases etc. + 2. Merging dependabot PRs should not be classified as activity on a repository. + +3. Dependency should be tree-shakable. Check on [bundlephobia](https://bundlephobia.com/) +4. Should have a low footprint than others that provide same functionality. Check on [bundlephobia](https://bundlephobia.com/) + +## Creating a commit + +This repository conforms with [conventional commits](https://www.conventionalcommits.org/) and uses commitilint for that. So when making a commit please always perform below steps: + +1. git add +2. yarn commit + +`yarn commit` will start the commitilint wizard which will help you to create a commit message that follows conventional commit guidelines. + +You can read the conventional commit specification [here](https://www.conventionalcommits.org/en/v1.0.0/#specification). + +Note: PRs without proper commit messages might get rejected. + +## Creating and Merging PRs + +1. PR title should not be same as branch name but should follow the convention commit guidelines. + + Invalid PR title: + + ```text + Add component Button + ``` + + Valid PR title: + + ```text + feat(Button): add button component + ``` + +2. All PRs require at least 1 approval during the review. + +3. All feature/bug fix branches should be merged using `Squash and merge` button. + +## Creating a Release + +1. Create a `release` branch from develop. +2. Bump the version and commit in the release branch. +3. Merge release branch in `main`. DO NOT `Squash and merge`. Create a merge commit instead. +4. Create a release from `main`. +5. After merging, create a `realign` branch from `main` and `Squash and merge` the realign branch in `develop`. + +--- + +## Conventions + +This section of the readme defines the coding conventions and rules that should be followed by all the contributors. +This section is more based on taste and style and should not be taken as absolute truth. +If you want to modify/add/remove any part of this section then please open a issue on GitHub and start the discussion. +Comments and suggestions for improvements are most welcome. + +### Goals + +**Why do we need conventions?** + +Most of the time the software once developed is not supported or maintained by the original author and as new members join the team (and others leave) it +becomes difficult to maintain the project and discussions like "my style is bette than your style" start. The goal here is to minimize these discussions and lay a solid groundwork for new members to work upon. + +These are the 5 base goals that we'll try to achieve when creating a rule or coding convention: + +1. **Consistency** - Conventions enforce consistency. If we are doing something bad it is best to do it in a consistent way than to do things in an inconsistent manner. Consistency throughout the project allows reader to focus on the content rather than the structure. +2. **Bug Reduction** - Rules and conventions help us to identify and quash bugs easily. +3. **Speed of development** - Doing things as per given set of rules the speed of development increases as everyone in the team know what X method or Y component will do and how to use it. +4. **Scalability** - With a proper structure we can scale any project easily be it 5 component app or 500. +5. **Ease of Refactoring** - Refactoring a piece of code that was written 3-4 years back becomes easy for new member refactor and add new features. + +### Rules + +#### General + +1. Minimize the use of `any`. Read when to use `never` and `unknown` [here](https://blog.logrocket.com/when-to-use-never-and-unknown-in-typescript-5e4d6c5799ad/). +2. Always use `async/await` and never `then/catch`. +3. Co-location: Files that belong together should be kept in same folder or at least near each other. +4. Always catch and log errors. All the code that can break should be enclosed inside `try/catch`. +5. Always question the design that you are given. You do not need to blindly implement all the designs provided. + +#### React + +1. Always use functional components. +2. Always try to decompose the components in smaller section. [Read](https://medium.com/dailyjs/techniques-for-decomposing-react-components-e8a1081ef5da) +3. A `tsx` file should always export a component with same name as the file. e.g a `XYZ.tsx` file should not export `ABC` component. +4. When creating a component in `design-system` (and `pages`), make sure the below requirements are met: + 1. It should be in its own folder. + 2. A storybook file (`.stories.tsx`) with proper stories defined showing all the available states. **Not required for `pages`** + 3. A test file (`.test.tsx`) with proper and meaningful tests incl. at least one snapshot. A single snapshot test should not be considered as proper testing. + 4. An `index.ts` file that exports the main component and its props. + 5. It is properly categorized as `atom`, `molecule` or an `organism`. + 6. It the component requires a child component then keep it in the same folder. **This should only be done if the child component will not be re-used anywhere outside of the parent component** +5. Component importing: When importing a component refer the below example + + ```jsx + // bad + import Footer from './Button/Button'; + + // bad + import Button from './Button/index'; + + // good + import Button from './Button'; + ``` + +6. Redux should be used only in the `pages` and only to share the state with the other `pages`. It should never be used to store API results. +7. `atom`, `molecule` or an `organism` should never trigger an API call. +8. `atom` should never import a `molecule` or `organism`, `molecule` can import `atom` components but not another `molecule` or `organism` and `organism` can import both `atom` and `molecule`. +9. API calls should always have their own method (No nested or multiple API calls inside same method). + + ```js + // bad + const getAllUserData = async () => { + const data = await axios.get('/api/v1/user/1'); + const profile = await axios.get('/api/v1/user/profile/1'); + return { ...data, ...profile }; + }; + + // good + + const getUserData = async () => { + const userData = await axios.get('/api/v1/user/1'); + return userData; + }; + + const getUserProfileData = async () => { + const profile = await axios.get('/api/v1/user/profile/1'); + return profile; + }; + + const getAllUserData = async () => { + const data = await getUserData(); + const profile = await getUserProfileData(); + return { ...data, ...profile }; + }; + ``` + +10. `pages` should never call an API method directly but via a custom hook created with the help of `react-query`. +11. All the forms should be created using `Formik`. +12. When handling complex state update prefer `useReducer` over `useState`. + +#### Styling + +1. Never use `px` always use `rem`. Read the difference between `em` and `rem` [here](https://zellwk.com/blog/rem-vs-em/). +2. Never use `cursor: pointer` on a normal button. [Read here why](https://medium.com/simple-human/buttons-shouldnt-have-a-hand-cursor-b11e99ca374b) +3. Never use `style` prop and try to minimize the use of `sx` prop. Use styled-components (using emotion) as much as possible. +4. Use `Typography` atom for all text related things. The `size` prop accepts material-ui [variants](https://next.material-ui.com/customization/typography/#variants) as well as custom size. +5. We use [emotion global styles](https://emotion.sh/docs/globals) together with [material-ui themes](https://material-ui.com/customization/theming/). + 1. We use a primary color with varying opacity levels to differentiate between the states (e.g. disabled, active, hover) of a given component. + 2. If the primary color needs to be changed then that changes the theme and goes to the theme section. **Approval from designer is required** + 3. If you need to override color(or other attribute) of a material-ui component then that goes to the Global style section. diff --git a/README.md b/README.md index 47c197d9c..502a8ffee 100644 --- a/README.md +++ b/README.md @@ -18,164 +18,20 @@ In the project directory, you can run: --- -## Contribution Guidelines - -### Dependency Checklist - -Before adding a dependency to the project please make sure it satisfies the below criteria: - -1. Is open-source and has a permissive license [MIT, ISC, Apache, etc.] -2. Is actively maintained - - 1. Check if the author/owner/maintainer is active in the github issues, fixing issues, adding features with new releases etc. - 2. Merging dependabot PRs should not be classified as activity on a repository. - -3. Dependency should be tree-shakable. Check on [bundlephobia](https://bundlephobia.com/) -4. Should have a low footprint than others that provide same functionality. Check on [bundlephobia](https://bundlephobia.com/) - -### Creating a commit - -This repository conforms with [conventional commits](https://www.conventionalcommits.org/) and uses commitilint for that. So when making a commit please always perform below steps: - -1. git add -2. yarn commit - -`yarn commit` will start the commitilint wizard which will help you to create a commit message that follows conventional commit guidelines. - -You can read the conventional commit specification [here](https://www.conventionalcommits.org/en/v1.0.0/#specification). - -Note: PRs without proper commit messages might get rejected. - -### Creating and Merging PRs - -1. PR title should not be same as branch name but should follow the convention commit guidelines. - - Invalid PR title: - - ```text - Add component Button - ``` - - Valid PR title: - - ```text - feat(Button): add button component - ``` - -2. All PRs require at least 1 approval during the review. - -3. All feature/bug fix branches should be merged using `Squash and merge` button. - -### Creating a Release - -1. Create a `release` branch from develop. -2. Bump the version and commit in the release branch. -3. Merge release branch in `main`. DO NOT `Squash and merge`. Create a merge commit instead. -4. Create a release from `main`. -5. After merging, create a `realign` branch from `main` and `Squash and merge` the realign branch in `develop`. - ---- - -## Conventions - -This section of the readme defines the coding conventions and rules that should be followed by all the contributors. -This section is more based on taste and style and should not be taken as absolute truth. -If you want to modify/add/remove any part of this section then please open a issue on GitHub and start the discussion. -Comments and suggestions for improvements are most welcome. - -### Goals - -**Why do we need conventions?** - -Most of the time the software once developed is not supported or maintained by the original author and as new members join the team (and others leave) it -becomes difficult to maintain the project and discussions like "my style is bette than your style" start. The goal here is to minimize these discussions and lay a solid groundwork for new members to work upon. - -These are the 5 base goals that we'll try to achieve when creating a rule or coding convention: - -1. **Consistency** - Conventions enforce consistency. If we are doing something bad it is best to do it in a consistent way than to do things in an inconsistent manner. Consistency throughout the project allows reader to focus on the content rather than the structure. -2. **Bug Reduction** - Rules and conventions help us to identify and quash bugs easily. -3. **Speed of development** - Doing things as per given set of rules the speed of development increases as everyone in the team know what X method or Y component will do and how to use it. -4. **Scalability** - With a proper structure we can scale any project easily be it 5 component app or 500. -5. **Ease of Refactoring** - Refactoring a piece of code that was written 3-4 years back becomes easy for new member refactor and add new features. - -### Rules - -#### General - -1. Minimize the use of `any`. Read when to use `never` and `unknown` [here](https://blog.logrocket.com/when-to-use-never-and-unknown-in-typescript-5e4d6c5799ad/). -2. Always use `async/await` and never `then/catch`. -3. Co-location: Files that belong together should be kept in same folder or at least near each other. -4. Always catch and log errors. All the code that can break should be enclosed inside `try/catch`. -5. Always question the design that you are given. You do not need to blindly implement all the designs provided. - -#### React - -1. Always use functional components. -2. Always try to decompose the components in smaller section. [Read](https://medium.com/dailyjs/techniques-for-decomposing-react-components-e8a1081ef5da) -3. A `tsx` file should always export a component with same name as the file. e.g a `XYZ.tsx` file should not export `ABC` component. -4. When creating a component in `design-system` (and `pages`), make sure the below requirements are met: - 1. It should be in its own folder. - 2. A storybook file (`.stories.tsx`) with proper stories defined showing all the available states. **Not required for `pages`** - 3. A test file (`.test.tsx`) with proper and meaningful tests incl. at least one snapshot. A single snapshot test should not be considered as proper testing. - 4. An `index.ts` file that exports the main component and its props. - 5. It is properly categorized as `atom`, `molecule` or an `organism`. - 6. It the component requires a child component then keep it in the same folder. **This should only be done if the child component will not be re-used anywhere outside of the parent component** -5. Component importing: When importing a component refer the below example - - ```jsx - // bad - import Footer from './Button/Button'; - - // bad - import Button from './Button/index'; - - // good - import Button from './Button'; - ``` - -6. Redux should be used only in the `pages` and only to share the state with the other `pages`. It should never be used to store API results. -7. `atom`, `molecule` or an `organism` should never trigger an API call. -8. `atom` should never import a `molecule` or `organism`, `molecule` can import `atom` components but not another `molecule` or `organism` and `organism` can import both `atom` and `molecule`. -9. API calls should always have their own method (No nested or multiple API calls inside same method). - - ```js - // bad - const getAllUserData = async () => { - const data = await axios.get('/api/v1/user/1'); - const profile = await axios.get('/api/v1/user/profile/1'); - return { ...data, ...profile }; - }; - - // good - - const getUserData = async () => { - const userData = await axios.get('/api/v1/user/1'); - return userData; - }; - - const getUserProfileData = async () => { - const profile = await axios.get('/api/v1/user/profile/1'); - return profile; - }; - - const getAllUserData = async () => { - const data = await getUserData(); - const profile = await getUserProfileData(); - return { ...data, ...profile }; - }; - ``` - -10. `pages` should never call an API method directly but via a custom hook created with the help of `react-query`. -11. All the forms should be created using `Formik`. -12. When handling complex state update prefer `useReducer` over `useState`. - -### Styling - -1. Never use `px` always use `rem`. Read the difference between `em` and `rem` [here](https://zellwk.com/blog/rem-vs-em/). -2. Never use `cursor: pointer`. [Read here why](https://medium.com/simple-human/buttons-shouldnt-have-a-hand-cursor-b11e99ca374b) -3. Never use `style` prop and try to minimize the use of `sx` prop. Use styled-components (using emotion) as much as possible. -4. Use `Typography` atom for all text related things. The `size` prop accepts material-ui [variants](https://next.material-ui.com/customization/typography/#variants) as well as custom size. -5. We use [emotion global styles](https://emotion.sh/docs/globals) together with [material-ui themes](https://material-ui.com/customization/theming/). - 1. We use a primary color with varying opacity levels to differentiate between the states (e.g. disabled, active, hover) of a given component. - 2. If the primary color needs to be changed then that changes the theme and goes to the theme section. **Approval from designer is required** - 3. If you need to override color(or other attribute) of a material-ui component then that goes to the Global style section. +## Environment variables + +`.env.example` file is the example `.env` file and can be used to initialize base `.env` file required by the project. + +The app uses below environment variables: + +- REACT_APP_APP_NAME: App name to be disabled and used to initialize wallet provider. (default: Prediction Market) +- REACT_APP_MARKET_CONTRACT: Market contract address. +- REACT_APP_FA12_CONTRACT: FA1.2 contract address. +- REACT_APP_FA12_SYMBOL: FA1.2 token symbol +- REACT_APP_IPFS_POST_API: API used for [IPFS Pinning](https://github.com/tzConnectBerlin/ipfs-pinning-service) +- REACT_APP_IPFS_GET_API: IPFS Gateway URL used to fetch IPFS data. +- REACT_APP_NETWORK_TYPE: Tezos network to use. (default: FLORENCENET) +- REACT_APP_RPC_URL: Tezos node rpc url (default: https://florencenet.smartpy.com) +- REACT_APP_RPC_PORT: Tezos node rpc port (default: 443) +- REACT_APP_GRAPHQL_API: [Indexer](https://github.com/tzConnectBerlin/storage-sql) service Postgraphile URL. +- REACT_APP_SENTRY_DSN: Sentry DSN if you want to enable logging via sentry diff --git a/package.json b/package.json index be29f09cc..4e4989a81 100644 --- a/package.json +++ b/package.json @@ -1,7 +1,7 @@ { "name": "prediction-market-ui", - "version": "0.5.1", - "private": true, + "version": "0.6.0", + "private": false, "license": "MIT", "dependencies": { "@airgap/beacon-sdk": "2.3.1", @@ -20,14 +20,13 @@ "@sentry/react": "^6.10.0", "@sentry/tracing": "^6.10.0", "@storybook/react": "^6.3.6", - "@taquito/beacon-wallet": "10.0.0", - "@taquito/michelson-encoder": "10.0.0", - "@taquito/rpc": "10.0.0", - "@taquito/signer": "10.0.0", - "@taquito/taquito": "10.0.0", + "@taquito/beacon-wallet": "10.1.0", + "@taquito/michelson-encoder": "10.1.0", + "@taquito/rpc": "10.1.0", + "@taquito/signer": "10.1.0", + "@taquito/taquito": "10.1.0", "@tezos-contrib/react-wallet-provider": "^1.0.0-alpha.11", "axios": "^0.21.1", - "bignumber.js": "^9.0.1", "blockies-ts": "^1.0.0", "date-fns": "^2.23.0", "date-fns-tz": "^1.1.6", @@ -67,7 +66,7 @@ "build-storybook": "build-storybook -s public", "format": "prettier --write src/**/*.ts{,x}", "tsc:compile": "tsc", - "lint": "yarn tsc:compile && eslint src/**/*.ts{,x}", + "lint": "eslint -c './.eslintrc.json' src/**/*.ts{,x}", "clean:test-results": "rimraf ./test-results/junit && mkdir -p ./test-results/junit", "test-ci": "yarn clean:test-results && yarn test --ci --maxWorkers=2 --coverage --watchAll=false --reporters=default --reporters=jest-junit" }, @@ -260,8 +259,5 @@ "presets": [ "react-app" ] - }, - "eslintConfig": { - "extends": "react-app" } } \ No newline at end of file diff --git a/public/index.html b/public/index.html index 947ae3ace..bfa4024a8 100644 --- a/public/index.html +++ b/public/index.html @@ -6,7 +6,6 @@ -