Gutenberg 11.6 added supports for thunks. You can think of thunks as of functions that can be dispatched:
// actions.js
export const myThunkAction = () => ( { select, dispatch } ) => {
return "I'm a thunk! I can be dispatched, use selectors, and even dispatch other actions.";
};
Thunks expand the meaning of what a Redux action is. Before thunks, actions were purely functional and could only return and yield data. Common use-cases such as interacting with the store or requesting API data from an action required using a separate control. You would often see code like:
export function* saveRecordAction( id ) {
const record = yield controls.select( 'current-store', 'getRecord', id );
yield { type: 'BEFORE_SAVE', id, record };
const results = yield controls.fetch({ url: 'https://...', method: 'POST', data: record });
yield { type: 'AFTER_SAVE', id, results };
return results;
}
const controls = {
select: // ...,
fetch: // ...,
};
Side-effects like store operations and fetch functions would be implemented outside of the action. Thunks provide alternative to this approach. They allow you to use side-effects inline, like this:
export const saveRecordAction = ( id ) => async ({ select, dispatch }) => {
const record = select( 'current-store', 'getRecord', id );
dispatch({ type: 'BEFORE_SAVE', id, record });
const response = await fetch({ url: 'https://...', method: 'POST', data: record });
const results = await response.json();
dispatch({ type: 'AFTER_SAVE', id, results });
return results;
}
This removes the need to implement separate controls.
Let's take a look at an example from Gutenberg core. Prior to thunks, the toggleFeature
action from the @wordpress/interface
package was implemented like this:
export function* toggleFeature( scope, featureName ) {
const currentValue = yield controls.select(
interfaceStoreName,
'isFeatureActive',
scope,
featureName
);
yield controls.dispatch(
interfaceStoreName,
'setFeatureValue',
scope,
featureName,
! currentValue
);
}
Controls were the only way to dispatch
actions and select
data from the store.
With thunks, there is a cleaner way. This is how toggleFeature
is implemented now:
export function toggleFeature( scope, featureName ) {
return function ( { select, dispatch } ) {
const currentValue = select.isFeatureActive( scope, featureName );
dispatch.setFeatureValue( scope, featureName, ! currentValue );
};
}
Thanks to the select
and dispatch
arguments, thunks may use the store directly without the need for generators and controls.
Imagine a simple React app that allows you to set the temperature on a thermostat. It only has one input and one button. Clicking the button dispatches a saveTemperatureToAPI
action with the value from the input.
If we used controls to save the temperature, the store definition would look like below:
const store = wp.data.createReduxStore( 'my-store', {
actions: {
saveTemperatureToAPI: function*( temperature ) {
const result = yield { type: 'FETCH_JSON', url: 'https://...', method: 'POST', data: { temperature } };
return result;
}
},
controls: {
async FETCH_JSON( action ) {
const response = await window.fetch( action.url, {
method: action.method,
body: JSON.stringify( action.data ),
} );
return response.json();
}
},
// reducers, selectors, ...
} );
While the code is reasonably straightforward, there is a level of indirection. The saveTemperatureToAPI
action does not talk directly to the API, but has to go through the FETCH_JSON
control.
Let's see how this indirection can be removed with thunks:
const store = wp.data.createReduxStore( 'my-store', {
__experimentalUseThunks: true,
actions: {
saveTemperatureToAPI: ( temperature ) => async () => {
const response = await window.fetch( 'https://...', {
method: 'POST',
body: JSON.stringify( { temperature } ),
} );
return await response.json();
}
},
// reducers, selectors, ...
} );
That's pretty cool! What's even better is that resolvers are supported as well:
const store = wp.data.createReduxStore( 'my-store', {
// ...
selectors: {
getTemperature: ( state ) => state.temperature
},
resolvers: {
getTemperature: () => async ( { dispatch } ) => {
const response = await window.fetch( 'https://...' );
const result = await response.json();
dispatch.receiveCurrentTemperature( result.temperature );
}
},
// ...
} );
Thunks' support is experimental for now. You can enable it by setting __experimentalUseThunks: true
when registering your store.
A thunk receives a single object argument with the following keys:
An object containing the store’s selectors pre-bound to state, which means you don't need to provide the state, only the additional arguments. select
triggers the related resolvers, if any, but does not wait for them to finish. It just returns the current value even if it's null.
If a selector is part of the public API, it's available as a method on the select object:
const thunk = () => ( { select } ) => {
// select is an object of the store’s selectors, pre-bound to current state:
const temperature = select.getTemperature();
}
Since not all selectors are exposed on the store, select
doubles as a function that supports passing selector as an argument:
const thunk = () => ( { select } ) => {
// select supports private selectors:
const doubleTemperature = select( ( temperature ) => temperature * 2 );
}
resolveSelect
is the same as select
, except it returns a promise that resolves with the value provided by the related resolver.
const thunk = () => ( { resolveSelect } ) => {
const temperature = await resolveSelect.getTemperature();
}
An object containing the store’s actions
If an action is part of the public API, it's available as a method on the dispatch
object:
const thunk = () => ( { dispatch } ) => {
// dispatch is an object of the store’s actions:
const temperature = await dispatch.retrieveTemperature();
}
Since not all actions are exposed on the store, dispatch
doubles as a function that supports passing a redux action as an argument:
const thunk = () => async ( { dispatch } ) => {
// dispatch is also a function accepting inline actions:
dispatch({ type: 'SET_TEMPERATURE', temperature: result.value });
// thunks are interchangeable with actions
dispatch( updateTemperature( 100 ) );
// Thunks may be async, too. When they are, dispatch returns a promise
await dispatch( ( ) => window.fetch( /* ... */ ) );
}
Registry provides access to other stores through dispatch
, select
, and resolveSelect
methods.
They are very similar to the ones described above, with a slight twist. Calling registry.select( storeName )
returns a function returning an object of selectors from storeName
. This comes handy when you need to interact with another store. For example:
const thunk = () => ( { registry } ) => {
const error = registry.select( 'core' ).getLastEntitySaveError( 'root', 'menu', menuId );
/* ... */
}
Nice work on this Adam. Just adding some suggestions below as I find them.
A thunk has direct access to a store.
or
Thunks have direct access to the store.
?
A thunk may return a
Promise
.Are we destructuring from thestore
here? If so would it be helpful to usestore.select
andstore.dispatch
just for absolutely clarity that thestore
object is provided to the thunk?Ok I just read https://gist.github.com/adamziel/2ee2a22b417825e9324f9dad26c17e73#thunks-api so we don't receive the
store
object directly.In that case please could you clarify what you mean by "A thunk have a direct access to store"?
This title
resolveSelect
under theThunks API
section has lost it's formatting.When you mention this is it worth clarifying that this means the
state
argument is already applied to the selector function as a convenience in order that you don't need to provide it?This section has no explanation. Perhaps "dispatch is an object of the store’s actions" although perhaps "an object containing the store's actions" might be clearer?
Could we clarify the purpose of/why we might need to use this? I assume it's just on the occasion your state depends on accessing another store then this is how you can do it without importing that store...etc.
@jsnajdr I am very much aware of it but haven't read for a long time. Probably time to revisit it soon...