React Native Tips, Notes and best practices
Hi! I'm James Jara, and this is my personal checklist that I use in React Native Mansion. If you want to learn about my point of view, you can read me.
This section defines some JavaScript and React Native naming conventions, which are split into several sections.
- Adding this configuration to your
.eslintrc
will allow your mind to read any code in the same pattern, this will create a code pattern. Remember to installsort-comp
.
"react/sort-comp": [1, {
"order": [
"type-annotations",
"static-methods",
"static-variables",
"instance-variables",
"lifecycle",
"/^on.+$/",
"/^render.+$/",
"everything-else",
"render",
],
}],
- Methods that return JSX starts with render
renderItem
- Methods that executes an actions starts with on
onLogout
- Prefer lowercase on any folder with exception of RN Screens.
- Prefer
-
over camelCase in ts, tsx and folders, egaction-creators.tsx
. - Prefer camelCase in React Native screens, eg
Login
.
Since working on many react native products I have seen many many leads always strugulling with the PR contrinutions from the other developers, I have been creating this template that can be applied to bitbucket or github.
* [] I am affirming this is my best work ever.
## Working on multiplatform implementations:
* [ ] Upload gif/SS from Android implementation.
* [ ] Upload gif/SS from iOS implementation.
## Working on components:
* [ ] Add the story book implementation.
* [ ] Upload gif/SS from story book implementation.
## Quality
* [ ] No new warnings in tests, storybook, eslint, package check.
* [ ] I test the suite case for this specific task.
## Unit testing
* [ ] Upload the new coverage in the description.
* [ ] Keep up to 50% of coverage.
* [ ] Add snapshot tests specially for components.
## Adding and Updating Packages? (If applicable)
* [ ] Explain an elaborate the package.
* [ ] Add to the packages list.
## Extra
* [ ] methods that returns JSX starts with `render`.
* [ ] methods that execute action starts with `on`.
This structure can be different that many of my other products, in this document I'm presenting this one just because of a matter of personal preference, but based on keeping a clean way to structure testing, styles, strings, continuous integration, etc :).
.
├── __mocks__
│ └── @enhancers
├── __tests__
│ └── __snapshots__
├── android
├── ios
├── server
│ ├── entities
│ ├── example
│ └── trips
├── src
│ ├── components
│ │ ├── Input
│ │ │ ├── __stories__
│ │ │ └── __tests__
│ │ │ └── __snapshots__
│ ├── config
│ ├── constants
│ │ ├── actions-types
│ │ ├── api
│ │ ├── colors
│ │ ├── images
│ │ ├── reducers-names
│ │ ├── routes
│ │ ├── schemas
│ │ ├── strings
│ │ └── typings
│ ├── enhancers
│ │ └── withKeyboardView
│ ├── navigation
│ ├── screens
│ │ ├── Global
│ │ │ ├── Auth
│ │ │ │ ├── Home
│ │ │ │ ├── Login
│ │ │ │ └── Register
│ │ │ ├── Boot
│ │ │ └── Home
│ │ └── ActivityFeed
│ ├── services
│ │ ├── navigation
│ │ └── permissions
│ └── state
│ ├── entities
│ └── global
│ └── auth
└── storybook
- Tslint configured with Airbnb styles and some overrides.
- VSCode Prettier compatible.
- Prefer using
PureComponen
t instead ofComponent
to use shallow rendering. - Do not mix types like using a JSX as a boolean.
- NavigationOptions goes at screens.
- Prefer singular alias when importing all, in this way it seems to make more sense when used later on.
import * as color from '@constants/colors'; console.log(color.RED);
- Implement configuration calls in
config/
likeAmplifyConfig
,GoogleMapsConfig
, etc. - No literal strings, create the literal string in the constants folder.
One phrase, the power of branches, as well a few other rules to keep or git log beatifull and clean.
- Daily Pull Request reviews at 11:00 AM.
- Prefer
rebase
overmerge
. - Keep enviroment clean, delete merged branches.
- Merge strategy for merge features branches into develop
git merge --squash
.
- Master: highly stable branch, it is always production-ready.
- Staging: derived from the develop, used for pre-release testing.
- Develop: derived from the master, used for integrating different feature branches.
- Feature: specific development.
- Hotfix: derived from master branch, it fixes a bug in production and it's merged into master and develop.
- Prefer enforcing properly formatted commit messages.
- Commit messages must meet the conventional commit format. conventionalcommits.
- Commit message must include the JIRA project and JIRA Id task.
git commit -m "SA-1001: fix(login) - Fixed bug on foo"
git commit -m "SA-1001: feat(profile) - Adds new form"
git commit -m "SA-1001: chore - Updated README"
git commit -m "SA-1001: feat(ui) - Added dark theme"
Another one quick phrase, agility with faster feedback.
- Enforced linting pre-commit and unit testing pre-push with husky's hooks.
- Enforcing clean and success builds on branches.
- Protecting your hard-earned code coverage.
# file: bitbucket-pipelines.yml
image: node:10.15.3
pipelines:
default:
- step:
caches:
- node
script:
- yarn
- yarn run lint
- yarn run test:package
- yarn run test
- Git hooks
- Feature Branches: Deployment triggered on new commits, IPA and APK binaries.
- Develop branch: Deployment triggered on new commits, IPA and APK binaries.
- Stage branch: Deployment triggered on new commits, TestFligth and Alpha Channel binary upload.
- Feature and develop branches are notified via Slack, Email and Jira automatized comment with the build.
- Staging and Master builds are notify via the oficial channel, a.k.a iOS TestFligth/App Store and Android Store.
- Autoincrement Semantic App Version.
- Private Keystore Secure Download.
- Extra SDK and Tools install.
- Android Build.
- Sign APK.
- Create QR Code Page (for QA Testers).
- Slack, email, JIRA build update.
- Cocoa Pods Install.
- Certificate and profile installer.
- XCode Archive.
- Create QR Code Page (for QA Testers).
- Slack, email, JIRA build update.
Column | Responsability |
---|---|
Todo | Item to be worked |
- Any story/task must contain the following properties:
-
- Mock: Link to the mock file.
-
- Description: Short description.
-
- Test Suite or Acceptance Criteria: link to the test suite steps.
- Any feature branch requires Manual testing to be approved and then merged.
- Regression Test must be executed over Develop branch when a milestine is reached or sprint is finished.
- Manual testing must run over physical devices.
- Manual testing must run over multi-platform devices iOS and Androd.
- Tests results must be attached as PDF or inmutable/versioned link in the JIRA task, so in future reference test logs can be reviewed.
Branch | Type | Testers | How |
---|---|---|---|
Master | Production | Final users | Distribution |
Staging | Pre-release | Stake Holders | Test-Flight and Android Channels |
Develop | Development | QA's | Binaries APK/IPA |
Feature | Development | Developer and QA's | Ad-hoc and APK |
- Create e2e tests under the root folder
__e2e__
folder. - e2e test should represent a test suites of functional type.
- Unit tests with Jest, Enzyme and react-native-testing-library.
- Codecov: coverage report.
- Create Unit Testing for any implementation under the
__tests__
folder, for examplecomponents/input/__tests__/
. - For Components also add snapshot testing. (+Jest).
- Create unit testing for Actions.
- Create unit testing for reducers.
- Create unit testing for Middlewares.
- Keep coverage over 80%, Coverage is enforced.
React Native developments should start from the concept, Components, designing components before screens is a very important steps for an organized and efficient development.
- Create a storybook per each new component.
- Build the component in isolation.
- Implement at least example case by each prop.
- Document the new component in the components library list.
- Create the story in the root of the component, under the
__stories__
folder, for examplecomponents/input/__stories__/
.
- Prefer Ambient declarations style.
- In components use type and not interface for state and props definitions.
- For global shared definitions use interfaces in the
constants/typings
folders. - DO NOT use
Any
.
- Redux: predictable state container
- Redux Persist: offline store
- Redux Standard API-calling Action: API well structured action types and action creators.
- Redux Selectors: helpers and selectors to access the reducers data.
- Normalizr: normalizing data.
Kepp each entity very atomic, so it can be easly mantained.
.
|____example
| |____selectors.ts
| |____actions.ts
| |____schema.js
| |____index.ts
| |____action-creators.ts
- withKeyboardView: Add description.
Already reviewed set of libraries by category.
Library | Usage | Coverage | License |
---|---|---|---|
Library | Usage | Coverage | License |
---|---|---|---|
Component | Description |
---|---|