- Is it necessary?
- Does it make developing BinaryTree easier?
- Does it fix a bug? -> Create an issue with the steps to reproduce
- Does it break anything? -> Build locally, Run the tests
- Does it stick to the original goal of BinaryTree -> Developer Productivity Tools Designed to Help You Save Time
- Does it reduce the build size?
- Does it improve the user experience?
- Does it improve the performance?
Ensure these dependencies are installed before proceeding:
node -v
# 18.16.1
yarn -v
# 3.6.1If you don't have these installed, please visit Node.js official website and Yarn Package Manager to download and install them.
Install project dependencies using Yarn with the --immutable flag to ensure consistent package versions:
yarn install --immutableTo run the project locally, execute the following command:
yarn devRun the following command to execute the linter:
yarn lintYou can also run tests to ensure the project's functionality:
yarn test-
Fork the repo
-
Clone your fork
-
Sync your local main
3.1.
git remote add upstream git@github.com:lifeparticle/binarytree.git
3.2.
git fetch upstream
3.3.
git branch --set-upstream-to=upstream/main main
3.4.
git pull
-
Run locally
4.1 Move to the project directory and install dependencies
cd ui yarn install --immutable yarn start -
Create a branch
git branch issue-2 # use issue_number, replace issue-2 with appropriate branch name git checkout issue-2 -
Update the CHANGELOG file with the changes you have made.
-
Push your changes to your fork with git push
git add . git commit -m"Write a meaningfull commit message" git push
-
Create a pull request
8.1 Use the url from the terminal
remote: Create a pull request for 'issue-2' on GitHub by visiting: remote: https://github.com/........................
8.2 If you're having problem finding the url
a) https://github.com/lifeparticle/binarytree/pulls b) Click the button 'New pull request' c) Click the link 'compare across forks' d) Change head repository to your fork e) Change the branch to your branch f) Create pull request -
Repeat
git checkout main git pull
A: We follow the Semantic Versioning (SemVer) standard for versioning our project. Here's how we determine version updates:
| Change Description | Version Update |
|---|---|
| UI changes (backwards incompatible) | Major Version |
| New features or feature changes | Minor Version |
| Bug fixes (backwards compatible) | Patch Version |
Using absolute paths instead of relative paths can significantly enhance readability and maintainability.
Relative Path Example:
import MyComponent from "../../../components/MyComponent";Absolute Path Example:
import MyComponent from "components/MyComponent";When structuring folders and files, it's important to ensure they are organized in a way that makes sense for the project. This can help improve efficiency and maintainability. Here is a proposed structure that offers clear organization for pages, components, and utilities, facilitating seamless navigation within the project.
- Use PascalCase for component files and folders (e.g.,
Button.jsx).
PageName/
├── index.tsx
├── PageName.tsx
├── PageName.module.scss # Combines styles for PageName, CompA, and CompB
├── components/
│ ├── CompA.tsx
│ ├── CompB.tsx
├── useHookName.ts # Put this inside a hooks folder if you have more than one hooks
├── someData.ts
├── helper.ts
└── __tests__/
└── PageName.test.tsx
PageName/: Root directory for a specific page in the React application.
index.tsx: Entry file for thePageNamedirectory, typically used to export the main page component.PageName.tsx: The main React component file for the page, containing JSX and logic forPageName.PageName.module.scss: SCSS module with styles forPageNameand its child components.components/: Subdirectory for components part of or used byPageName.CompA.tsx: React component file forCompA.CompB.tsx: React component file forCompB.
hooks/: Directory for custom hooks relevant toPageNameor its components.useHookName.ts: Custom hook file.
someData.ts: File holding specific data relevant toPageName.helper.ts: File holding helper functions relevant toPageName.__tests__/: Directory for test files related toPageName.PageName.test.tsx: Test file for thePageNamecomponent.
Adopting consistent naming conventions helps in understanding and navigating the codebase.
Adding a new feature may seem daunting at first, but by following these steps and working together can ensure a smooth and efficient process.
4.1 If there is no related issue then create a new one and clearly describe the feature.
4.2 Design a low-fidelity mockup of the feature. This helps in visualizing the user interface and the user experience. Ensure that the design aligns with the project's design guidelines and style.
4.3 Wait for feedback and approval before proceeding. Make any necessary revisions based on the feedback received.
4.4 Once the mockup is approved, you can begin the development process. Remember to write clean, readable, and maintainable code.
4.5. Use scaffdog to create the page folder
npx scaffdog generate? Please select a document. page.md
? Please select the output destination directory. src/pages
? Please enter a page name. PageAIt will create the following files and folders structure:
PageA/
|── PageA.module.scss
|── PageA.tsx
|── __tests__/
| |── PageA.test.tsx
|── index.ts4.6. Update files
-
ui/src/pages/index.ts -
ui/src/data/featureData.ts -
ui/src/data/helpData.ts -
ui/src/data/menuData.ts -
ui/src/data/routeData.tsx
4.7 Add tests for a feature
- Identify the key functionalities of your feature that need testing.
- Define test cases for these functionalities, including both positive and negative scenarios.
- Ensure your test cases cover all critical paths and edge cases.
- Place your test scripts in the
__tests__folder within your feature directory (in this case,PageA/__tests__). - Mock any external dependencies or modules that your feature interacts with. This ensures that your tests are focused solely on the feature's functionality.
- Use faker to generate fake data for your tests.
4.8 Raise a PR for your feature