From 8921837491b0a950ff70f9d8fe13f6b8e3c329a5 Mon Sep 17 00:00:00 2001 From: Daniel Dimitrov Date: Mon, 23 Dec 2024 08:48:37 +0100 Subject: [PATCH] docs(mobile): improve code style --- apps/mobile/CONTRIBUTING.md | 69 ------------------------ apps/mobile/docs/code-style.md | 98 ++++++++++++++++++++++++++++++++++ 2 files changed, 98 insertions(+), 69 deletions(-) delete mode 100644 apps/mobile/CONTRIBUTING.md create mode 100644 apps/mobile/docs/code-style.md diff --git a/apps/mobile/CONTRIBUTING.md b/apps/mobile/CONTRIBUTING.md deleted file mode 100644 index 691c29345b..0000000000 --- a/apps/mobile/CONTRIBUTING.md +++ /dev/null @@ -1,69 +0,0 @@ -# React Native Code Guidelines - -## Code Structure - -### General Components - -- Components that are used across multiple features should reside in the `src/components/` folder. -- Each component should have its own folder, structured as follows: - ``` - Alert/ - - Alert.tsx - - Alert.test.tsx - - Alert.stories.tsx - - index.tsx - ``` -- The main component implementation should be in a named file (e.g., `Alert.tsx`), and `index.tsx` should only be used for exporting the component. -- **Reason**: Using `index.tsx` allows for cleaner imports, e.g., - ``` - import { Alert } from 'src/components/Alert'; - ``` - instead of: - ``` - import { Alert } from 'src/components/Alert/Alert'; - ``` - -### Exporting Components - -- **Always prefer named exports over default exports.** - - Named exports make it easier to refactor and identify exports in a codebase. - -### Features and Screens - -- Feature-specific components and screens should be implemented inside the `src/features/` folder. - -#### Example: Feature File Structure - -For a feature called **Assets**, the file structure might look like this: - -``` -// src/features/Assets -- Assets.container.tsx -- index.tsx -``` - -- `index.tsx` should only export the **Assets** component/container. - -#### Subcomponents for Features - -- If a feature depends on multiple subcomponents unique to that feature, place them in a `components` subfolder. For example: - -``` -// src/features/Assets/components/AssetHeader -- AssetHeader.tsx -- AssetHeader.container.tsx -- index.tsx -``` - -### Presentation vs. Container Components - -- **Presentation Components**: - - - Responsible only for rendering the UI. - - Receive data and callbacks via props. - - Avoid direct manipulation of business logic. - - Simple business logic can be included but should generally be extracted into hooks. - -- **Container Components**: - - Handle business logic (e.g., state management, API calls, etc.). - - Pass necessary data and callbacks to the corresponding Presentation component. diff --git a/apps/mobile/docs/code-style.md b/apps/mobile/docs/code-style.md new file mode 100644 index 0000000000..905f620174 --- /dev/null +++ b/apps/mobile/docs/code-style.md @@ -0,0 +1,98 @@ +# Code Style Guidelines + +## Code Structure + +### General Components + +- Components that are used across multiple features should reside in the `src/components/` folder. +- Each component should have its own folder, structured as follows: + ``` + Alert/ + - Alert.tsx + - Alert.test.tsx + - Alert.stories.tsx + - index.tsx + ``` +- The main component implementation should be in a named file (e.g., `Alert.tsx`), and `index.tsx` should only be used + for exporting the component. +- **Reason**: Using `index.tsx` allows for cleaner imports, e.g., + ``` + import { Alert } from 'src/components/Alert'; + ``` + instead of: + ``` + import { Alert } from 'src/components/Alert/Alert'; + ``` + +### Exporting Components + +- **Always prefer named exports over default exports.** + - Named exports make it easier to refactor and identify exports in a codebase. + +### Features and Screens + +- Feature-specific components and screens should be implemented inside the `src/features/` folder. + +#### Example: Feature File Structure + +For a feature called **Assets**, the file structure might look like this: + +``` +// src/features/Assets +- Assets.container.tsx +- index.tsx +``` + +- `index.tsx` should only export the **Assets** component/container. + +#### Subcomponents for Features + +- If a feature depends on multiple subcomponents unique to that feature, place them in a `components` subfolder. For + example: + +``` +// src/features/Assets/components/AssetHeader +- AssetHeader.tsx +- AssetHeader.container.tsx +- index.tsx +``` + +### Presentation vs. Container Components + +- **Presentation Components**: + + - Responsible only for rendering the UI. + - Receive data and callbacks via props. + - Avoid direct manipulation of business logic. + - Simple business logic can be included but should generally be extracted into hooks. + +- **Container Components**: + - Handle business logic (e.g., state management, API calls, etc.). + - Pass necessary data and callbacks to the corresponding Presentation component. + +### Commit Message Guidelines + +We follow the Semantic [https://www.conventionalcommits.org/en/v1.0.0/](Commit Messages convention). + +#### Format + +Each commit message should consist of a header, an optional body, and an optional footer. The header has a specific +format that includes a type, an optional scope, and a subject: + +``` +(): +``` + +**Types** + +- **feat**: A new feature +- **fix**: A bug fix +- **docs**: Documentation only changes +- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) +- **refactor**: A code change that neither fixes a bug nor adds a feature +- **perf**: A code change that improves performance +- **test**: Adding missing or correcting existing tests +- **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) +- **ci**: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) +- **chore**: Other changes that don't modify src or test files +- **revert**: Reverts a previous commit