lukebarnard1/journal

Create matrix-redux-sdk

Closed this issue · 2 comments

lukebarnard1 commented

As part of #62, we need a Redux store that contains the same state that matrix-js-sdk exposes. There are two options here:

  1. The Easy Option.
    Wrap matrix-js-sdk with async actions that will fire state into a Redux store.
  2. The Hard Option.
    Create matrix-redux-sdk proper by reimplementing matrix-js-sdk from the ground-up, but potentially not in its entirety; some bits could be reused (e.g. crypto stuff).

1. The Easy Option

Advantages:

  • Less code to write because matrix-js-sdk provides the necessary logic for syncing, cryptography, timeline management.
  • Simpler because wrapping matrix-js-sdk events as actions is trivial.
  • Could be rewritten later by implementing 2. and the depending app(s) would in theory not require changes.
  • Uses the matrix-js-sdk, which is the best js library for all things matrix (duh).

Disadvantages:

  • Not optimised at all/high memory footprint because matrix-js-sdk is stateful so state would end up duplicated.
  • Uses the matrix-js-sdk, which is tricky to use in a data-flow-driven way.

2. The Hard Option.

Advantages:

  • Can be highly optimised, with a low memory and processing footprint; no duplication of state or computation.

Disadvantages:

  • Lots of code to write because it would reimplement existing logic in matrix-js-sdk in a Redux-y way. A lot of the logic in matrix-js-sdk is highly coupled via event emitting and by the client singleton which many components are given reference to. This makes reuse non-trivial.

Prior Work

Prior work can be found here: https://github.com/ZBoxApp/matrix-redux, and this largely follows option 1. It too wraps matrix-js-sdk but sadly seems unmaintained.

lukebarnard1 commented

Looks like it'll be best to go for option 1 to begin with. If that turns out to perform poorly, it will still be possible to implement option 2 anyway, but this is likely only to impact the memory footprint.