Interface AutoState<TState, TAction>

Optional state "factory" function that "auto-generates" state.

The "auto" phrase means the autoState function invocation is automatic:

• after an action gets dispatched
• after the new state is calculated in reducer and passed to this function in newState argument
• ...but before:
  • invoking any callback listeners
  • dispatching any new actions (taking an action from a queue and dispatching it)

In most cases the newState parameter is not useful and autoState recalculation function looks for the more useful changedPaths attribute.

Key points:

• the attribute(s) that are calculated in autoState should be somehow related to the changed attributes
• good examples of such state attributes are lookup tables, caches etc.
• autoState must be synchronous (so no possibility to call e.g. REST API)

Example: provided there is a state like this

type CarValuationContext = {
  // car brand
  brand: string;
  model: string;
  // production date yyyy-MM-dd
  production: string;

  chassis: "new" | "used" | "damaged";
  body: "new" | "used" | "damaged";

  // total mileage
  mileage: number;

  // valuation
  valuationUSD: number;
};

type State = CarValuationContext;
Copy

the brand, model, production are constants (as these never change), but the valuationUSD of the car is related to chassis, body and mileage attributes.

The key point is: there is no direct "decrease-valuation" action! . The valuationUSD is the consequence of calling one of the following:

• "damage-to-chassis"
• "damage-to-body"
• "add-miles" actions (and then appropriate reducers).

Moreover, "damage-to-chassis", "damage-to-body", "add-miles" actions don't require dispatching special "recalculate-valuation" action (although it could be done this way).

Please note: this is an experimental feature and could change in the future.