huan
commented
4 years ago Hello luke, Thank you very much for your great project and idea-sharing!
I have a similar idea like yours that wrap all the events to Redux Actions for easy State management, I have created my own redux wrapper at Wechaty Redux, it's currently only an idea with some code from scratch at https://github.com/wechaty/HAWechaty/tree/1fdfa1a4cfe22cd0072c4955fd39bf64ad2062ae/src/ducks/wechaty
P.S. I'm the author of a Bot SDK for WeChat named Wechaty and a WeChat bridge for Matrix: Matrix Appservice Wechaty
lukebarnard1
Having implemented a simple chat client built atop matrix-redux-wrap, I've realised a few things.
There is more to Async Redux than thunks
Enforcing redux-thunk limits the app developer. In reality there are a multitude of redux middlewares for handling side effects and mrw should accommodate as many as possible.
This means deprecating
asyncAction, which assumes the redux-thunk middleware and suggesting any alternative. (FTRasyncActionhas a similar API to redux-pack.)Practically speaking, this means using some alternative in the examples (e.g. redux-pack) and not exporting
asyncAction. But this is low priority.The js-sdk emits too many events
By default, with a typical matrix account, too many events are emitted by the js-sdk. These would normally correspond 1-1 with actions dispatched by the
wrapSyncingClientfunction, but mrw now exports an alternative that batches several actions into an array that are applied to a store in serial, blocking view updates on several sequential store updates.The result is far from optimal, with the view "jumping" forward with the newly represented state.
This is a general short-coming of the architecture of mrw and mjssdk. It is a direct consequence of the matrix-js-sdk sync logic being ambivalent to the distinction between receiving a live event and loading a client that needs to catch-up to the current state of rooms.
The solution is unclear for now, and only impacts accounts with a high number of rooms, where the rooms have a high number of members.
Sharing mrw state with app state is confusing
Keeping mrw state in the same tree as app state is a strange experience. In my chat app, I had a single call to
matrixReduce, followed by derivation of state from the mrw state.Ideally, the state would already lend itself to being used directly, but use-cases will differ per client so I think it's safe to err on the side of simplicity in the library and allow for customisation of state in the app.
Given that reducers are typically composed by separating the state they work on, it would be interesting to consider keeping the
matrixReducereducer completely separate from the reducer that the app uses to maintain state outside of mrw. This would mean moving the state derivations out of the reducer entirely and into the view, which is not necessarily a more expensive thing, especially if the view is only rendered when absolutely necessary. This also has the advantage of less redundant state being stored and persisted.