Style Guide
Below are suggestions for naming and style conventions.
State Suffix
A state should always be suffixed with the word State
. Prefer: ZooState
Avoid: Zoo
State Filenames
States should have a .state.ts
suffix for the filename
State Interfaces
State interfaces should be named the name of the state followed by the Model
suffix. If my state were called ZooState
, we would call my state interface ZooStateModel
.
Select Suffix
Selects should have a $
suffix. Prefer: animals$
Avoid: animals
Plugin Suffix
Plugins should end with the Plugin
suffix
Plugin Filenames
Plugins file names should end with .plugin.ts
Folder Organization
Global states should be organized under src/shared/state
. Feature states should live within the respective feature folder structure src/app/my-feature
. Actions can live within the state file but are recommended to be a separate file like: zoo.actions.ts
Action Suffixes
Actions should NOT have a suffix
Unit Tests
Unit tests for the state should be named my-state-name.state.spec.ts
Action Operations
Actions should NOT deal with view related operations (i.e. showing popups/etc). Use the action stream to handle these types of operations
Avoid Saving Class Based Instances in Your State
The objects stored in your state should be immutable and should support serialization and deserialization. It is therefore recommended to store pure object literals in your state. Class based instances are not trivial to serialize and deserialize, and also are generally focused on encapsulating internals and mutating internal state through exposed operations. This does not match the requirement for the data stored in state.
This also applies to the usage of data collections such as Set, Map, WeakMap, WeakSet, etc. Since they are not amenable to deserialization and cannot easily be presented for normalization.
Avoid
It is not recommended to add Class based object instances to your state because this can lead to undefined behavior in the future.
Prefer
Flatten Deep Object Graphs
The general recommendation for handling hierarchical data in Redux is to normalise it. This would entail flattening it in the same way that you would design relational tables, having keys for references to parent objects.
Avoid
Note: It is not recommended to use data collections such as Set, Map, WeakMap, WeakSet, etc. Since they are not amenable to deserialization and cannot easily be presented for normalization.
Prefer
Last updated