Coding Standards

Coding Standards

---

Project structure

• use src folder for all code

.
└── root/
    ├── ios
    ├── android
    ├── web
    ├── src/
    │   ├── assets
    │   ├── screens
    │   ├── components (shared components)
    │   ├── services (utilities and core services)
    │   ├── core/
    │   │   ├── navigation
    │   │   ├── redux
    │   │   ├── auth
    │   │   ├── models
    │   │   └── localization
    │   └── index.js
    ├── package.json
    └── yarn.lock

Formatting Rules (Prettier)

• Default Prettier Rules

Sugested Linter Rules

• no trailing commas
• no use of semicolon
• use single quotes
• no unused imports
• no unused vars
• no explicit any (allow when necesary using exception to line)
• no empty interface
• no empty function
• no shadow

Sugested Plugings (use with default rules initially)

• eslint:recommended
• plugin:react/recommended
• plugin:react-hooks/recommended
• plugin:@typescript-eslint/eslint-recommended
• plugin:@typescript-eslint/recommended
• plugin:@typescript-eslint/recommended-requiring-type-checking
• @react-native-community

References

TypeScript Linter Rules

Tree Editor

State Management Guide Proposal

When developing a new component we need to determine the need for data storage through the lifecycle of the application and the lifecycle of the component. And the appropriate tools to be leveraged based on the different scenarios. Based on this requirement we suggest the following approach

Information With Global relevance

Information like user permissions, user preferences, and any other globally relevant information to be consumed by a single or multiple components should be stored on the redux store and access via slices.

• Use RTK Query or proper tool to retrieve the data from respective services

// Example
// Define a service using a base URL and expected endpoints
export const api = createApi({
  reducerPath: 'api',
  baseQuery: fetchBaseQuery({ baseUrl: '' }),
  endpoints: builder => ({
    getTransactions: builder.query<Transaction[], void>({
      query: () => 'transactions'
    })
  })
})

• Determine caching strategy, and lifespan to avoid the date becoming stale

Information With Component Relevance

Information only relevant to the component being develop should be stored locally.

• Use RTK Query or proper tool to retrieve the data from respective services

• Determine caching strategy, and lifespan to avoid the date becoming stale

What is next to be determined is the complexity of yor component.

Simple Components

If the component is simple and does not require communications between child components we should use simple state to manage the component data

Complex Components

If the component is complex in nature and will by composed a multiple child components in need communications and orchestration. We recommend that the Context API be used, to avoid props drilling and passing of handlers between child components.

• Define a Context

• Define actions

• Use the reducer pattern to dispatch actions across the different children

• Usage docs for RTK component state management can be found here https://redux-toolkit.js.org/usage/usage-with-typescript

As a general example you would create a slice with the properties you need stored and any actions to alter them:

const slice = createSlice({
  name: 'test',
  initialState: 0,
  reducers: {
    increment: (state, action: PayloadAction<number>) => state + action.payload,
  },
})
// now available:
slice.actions.increment(2)
// also available:
slice.caseReducers.increment(0, { type: 'increment', payload: 5 })

The initial state could also be an object:

interface UsersState {
  entities: []
  loading: 'idle' | 'pending' | 'succeeded' | 'failed'
}

const initialState = {
  entities: [],
  loading: 'idle',
} as UsersState