Status quo
The first versions were made in order to solve certain issues in Sententiaregum such as the dispatcher handling and the execution tree during single published events. But internally certain ES6 classes that fragment the code and make everything more complex.
Refactoring
Dispatcher
The dispatcher should finally become an implementation detail: in order to achieve that, only one module should be exported which returns a singleton. The dispatcher itself should be completely stateless, but some listeners should be adjusted.
Store
The internal store API is quite fragile. In order to simplify that, the only API should be the store
API which uses a simple variable internally to keep the state and build all utility around itself. Furthermore it should return a simple object composed of stateless functions to avoid side-effects, but a useful public API.
Handle store changes
When combining it with React.JS, the component lifecycle will be used to flush store changes into the view. This is quite handy as the view is capable at deciding for itself how to maintain its internal state.
Currently one issue need to be fixed:
- rename
useWith
to subscribe
as it's more convenient with unsubscribe
.
The view engine can be handled using a custom module which connects stuff to react internally.
Actions
The current action system is quite nice, but might experience further improvements to make it easiert to work with.
One step might be to decouple the event related stuff from the actual action-related logic: This could happen by creating one creator per module which is capable at defining multiple actions:
// buildTestActions.js
export default publish => {
function receiveTestData() {
ajax.get('/rest/test/data.json')
.then(r => publish(r);
}
return {
[TEST_RECEIVE_DATA]: receiveTestData,
// further stuff...
}
};
This API is somehow consistent to the current store API as it associates event constants to a config which is a flat function in this case which publishes the payload.
This could be called like this from a view;
// ...
runAction(TEST_RECEIVE_DATA, buildTestActions)
A third argument might be introduced which is an array of arguments for the actual action creator. This will be injected into the function returned by the receiveTestData
HOF as normalized list.
No event name is needed as it's already configured in the returned list. The publish
argument simply needs a payload as argument.
A last note about error/success handling: in this example it's not possible to differ from error and sucess events. This is intended as we build functions for each action in the store (lots of other implementations have huge classes with switch/case instructions or stateless "reducers" for that). However when a certain action is triggered the handler in the should be capable at handling any result comming from that action. To achieve this, a success
parameter might be added to the payload.
Tasks