-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* feat(search-box): new search box design update (#462) * fix: trade form updates and fixes (#464) * fix(trade-form): add refresh prices and fix price formula * refactor: add i18n * fix: fix broken test * feat: updated portfolio page (#461) * feat: various responsive fixes for home and market/auction pages * feat: portfolio summary card * chore: updating snapshots * feat: updated market cards on portfolio * feat: fixing market values * chore: adding symbols * chore: commit with reward rows progress (missing rewards data) * feat: working styled portfolio page, needs some spacing * feat: updated portfolio spacing/styling * fix: fixing issues with portfolio * chore: updating to use premade functions Co-authored-by: Shubhendu Shekhar <[email protected]> * fix: footer issue (#463) * feat: various responsive fixes for home and market/auction pages * fix: small issue with footer titles overlapping * chore: removing issue with floating points * chore: updating tests, improving logic * feat: fixing tests * feat: add new chart selector design and misc changes * feat(filter): implement new design for filter (#466) * add radio * add radio button to menu' * optional radio button * remove radio * add icon, change styles * remove listitemicon, adjust margins on focus * remove svg and change bg color for sort by * update snapshot tests * add phase icon component and test * add phase icon story * refactor: refactor code for consistent naming convention and code re-use * test: update drop down test * chore: update ci config Co-authored-by: shekhar-shubhendu <[email protected]> * chore: disable sentry debug * feat(weekly-change): calculate and show weekly change (#467) * feat(weekly-change): calculate and show weekly change * feat: add weekly change to header * fix: use PMM to buy and token as sell unit * feat(setting-dialog): add settingDialog component (#471) * fix(portfoliopage): add handleWithdrawAuction function * Revert "fix(portfoliopage): add handleWithdrawAuction function" This reverts commit 96003d4. * feat(settingdialog): add settingDialog component * refactor(settingdialog): get and set localStorage Co-authored-by: Shubhendu Shekhar <[email protected]> * feat: open market card (#468) * feat: various responsive fixes for home and market/auction pages * feat: adding closed markket data * chore: removing log * chore: fixing open issues * chore: updating test * chore: yarn * chore: updating tests * chore: removing close date * feat: initial structure * feat: adding working market cards * feat: closing open issues on card * chore: updating snapshots * chore: removing test * chore: fixing issue with resolution not appearing * chore: adding toasts * chore: remove console log * feat: adding local storage test * feat: hiding interactions after they are complete * chore: fixing bug * feat: checking date * cfeat: moving local storage to utils * feat: updating react imports * chore: fixing broken test Co-authored-by: Shubhendu Shekhar <[email protected]> * feat: add new position summary in trade form (#473) * feat: add meta tags * feat(trade-form): new design for buy/sell * fix: remove unused import * fear(setting-dialog): fix initial value in setting dialog (#474) * fix(portfoliopage): add handleWithdrawAuction function * Revert "fix(portfoliopage): add handleWithdrawAuction function" This reverts commit 96003d4. * feat(settingdialog): add settingDialog component * refactor(settingdialog): get and set localStorage * fix(settingdialog): fix initialValue * fix(settingdialog): add translate for mins Co-authored-by: Shubhendu Shekhar <[email protected]> * feat(trading-date): add expected trading date to auction page and change styles (#472) * add start date * change styles on marketdetailcard * change date style * update snapshots * add market details titles to translations * remove wrapper Co-authored-by: Shubhendu Shekhar <[email protected]> * feat: add slippage settings * fix: misc fixes and cleanup * refactor: cleanup * docs: update readme * feat: portfolio weekly change (#475) * feat: various responsive fixes for home and market/auction pages * chore: in progress * chore: in progress * chore: fixing claim winnings * chore: clean up old positions * feat: adding weekly change to prices * chore: fixing memo issue * chore: updating snapshots * chore: removing console.log * chore: updating snaps * docs: create contributing.md * feat(required):add required text to form buttons (#476) * add required fields text, create market * add required fields liquidity and trade form * update snapshots * fix: fix failing test ] Co-authored-by: Shubhendu Shekhar <[email protected]> Co-authored-by: shekhar-shubhendu <[email protected]> * feat: start preparing for granada migration (#465) * feat: start prepareing for granada migration * fix: update graphql queries * fix: update env * fix: update graphql query * chore: bump version Co-authored-by: Timothy LeBon <[email protected]> Co-authored-by: Cynthia <[email protected]> Co-authored-by: Shohreh Modarrei <[email protected]>
- Loading branch information
4 people
authored
Aug 19, 2021
1 parent
44fce69
commit 53ca553
Showing
147 changed files
with
2,963 additions
and
1,469 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -55,6 +55,4 @@ workflows: | |
| build_and_test: | ||
| jobs: | ||
| - build | ||
| - test: | ||
| requires: | ||
| - build | ||
| - test | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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://[email protected]/5756958f | ||
| REACT_APP_GRAPHQL_API=https://kt1lybgnsg2gymfchavcxunjecqy59ujrwbf.tzconnect.berlin/graphql | ||
| REACT_APP_SENTRY_DSN= |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -29,3 +29,4 @@ test-results/** | |
| eslint-report.json | ||
| Dockerfile | ||
| .dockerignore | ||
| .env | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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 <path/of/file/to/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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
53ca553There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Successfully deployed to the following URLs: