Dispatches an action. It is the only way to trigger a state change.
The reducer
function, used to create the store, will be called with the
current state tree and the given action
. Its return value will be
considered the next state of the tree, and the change listeners will
be notified.
The base implementation only supports plain object actions. If you want
to dispatch a Promise, an Observable, a thunk, or something else, you
need to wrap your store creating function into the corresponding
middleware. For example, see the documentation for the redux-thunk
package. Even the middleware will eventually dispatch plain object
actions using this method.
A plain object representing “what changed”. It is a good
idea to keep actions serializable so you can record and replay user
sessions, or use the time travelling redux-devtools
. An action must
have a type
property which may not be undefined
. It is a good idea
to use string constants for action types.
For convenience, the same action object you dispatched.
Note that, if you use a custom middleware, it may wrap dispatch()
to
return something else (for example, a Promise you can await).
Interoperability point for observable/reactive libraries.
A minimal observable of state changes. For more information, see the observable proposal: https://github.com/tc39/proposal-observable
Reads the state tree managed by the store.
The current state tree of your application.
Replaces the reducer currently used by the store to calculate the state.
You might need this if your app implements code splitting and you want to load some of the reducers dynamically. You might also need this if you implement a hot reloading mechanism for Redux.
The reducer for the store to use instead.
Adds a change listener. It will be called any time an action is
dispatched, and some part of the state tree may potentially have changed.
You may then call getState()
to read the current state tree inside the
callback.
You may call dispatch()
from a change listener, with the following
caveats:
The subscriptions are snapshotted just before every dispatch()
call.
If you subscribe or unsubscribe while the listeners are being invoked,
this will not have any effect on the dispatch()
that is currently in
progress. However, the next dispatch()
call, whether nested or not,
will use a more recent snapshot of the subscription list.
The listener should not expect to see all states changes, as the state
might have been updated multiple times during a nested dispatch()
before
the listener is called. It is, however, guaranteed that all subscribers
registered before the dispatch()
started will be called with the latest
state by the time it exits.
A callback to be invoked on every dispatch.
A function to remove this change listener.
JSONForms store.