Performance Potential?

I would recommend anyone interested in finding out more to bench (unless I get round to it first) and see if it is more efficient than vanilla react-redux . I have had people rightfully ask about bench-marking and if it is indeed more performant however in my local experiments it did appear so.

That said I am sure that react-reduX can perform faster with some careful consideration of connections and advanced setup or custom plugins but I believe as an alternative that with a low amount of setup it can be better straight out the box.

The Pillars of Synapse

Pillars of Creation (NASA)

SynapseRecords, Notifications and the underlying Observer

These are the pillars of redux-synapse and ultimately dictate how it works. It is a relatively simple system with just a few pieces that need to be setup in order to start enjoying the benefits, so let’s discuss the various roles they play:

synapse(function, function, Array<string>)(component) — This acts as your method of connecting components to the store. You provide your classic mapStateToProps , mapDispatchToProps functions, and a pathArray:Array<String> which is a series of paths that you are stating interest in. These paths would be paths of your redux state tree.

observer — The Observer handles the state in the background and is kicked off when the Provider is setup. It takes the default shape, dismantles it and builds up an internal dictionary of keypaths, and subscribers, based on the synapse ‘s that exist and have expressed an interest in a specific keypath.

prepareNotification — One of two ways to provide updates to synapses. You could use this in your reducer when you get certain updates, or outside of it in other areas if absolutely necessary.

Using prepareNotification with reducer

SynapseRecord — This is the recommended way to have updates provided on your apps and works based off Immutable.Records however can work off primitive state. You simply call generateSynapseRecord(new T(), STATE_KEY) where T is your record type, and the STATE_KEY matches the name of the key on the state. The below screenshot gives an example.

With this you can rest easy as all of your updates can now be handled through the Immutable APIs such as .set , .setIn and .withMutations . The SynapseRecord passes state updates through to the observer which informs the right components via a subscription made when they are synapse'd .

The SynapseRecord is the way to use the library, and offers the best benefits out the box; by abstracting away the need for the prepareNotification and taking advantage of the immutable Record .

Ta-da!

Of course there is more to it under the hood, as far as code is concerned but from a consumer perspective you can simply plug in and play very quickly by just using the redux-synapse Provider (import from package) and then wrapping your Records with generateSynapseRecord . Naturally it assume you have Immutable records — as mentioned above you can always use the prepareNotification API but at a cost of continuing to maintain it and potentially missing calls to it.

For more information you can read the docs to explain this but I am hoping it’s quite easy to grasp.

The State of Play

redux-synapse as an idea that came out of a very specific problem myself and others faced when dealing with moving to redux . That said I am not the sharpest tool in the box when it comes to other libraries as JS is certainly not my forte, and there are other libraries which work with similar concepts based around the Observer pattern.

The library was more of a proof of concept for me and proved that I could create something potentially useful.

Worth noting I have made some pretty grey assumptions around performance improvements that this could provide to users with frequently updating apps such as multiple videos emitting updates, or game engines.

Because the library started in 2016 and has had mixed low levels of maintenance and commitment over time, it still has some potential unknown problems. The library is currently dependent on Immutable 3.8.6. Last year there was a large major update to immutable which actually deprecated some of the APIs that are used in redux-synapse . As such an upgrade to that is necessary for many reason, but in doing so various areas will need to be rewritten.

Next Steps

For you: If you enjoyed the article, found it interesting or have some questions start a conversation below. In fact if you are super interested head over to the repository and contribute in whatever way suits you!

Fancy trying it out? Well lucky for you it’s on NPM:

For me: Now that this article is finally published I intend to get through a load of the issues I raised around the library back when I was actively working on it.

Add unit test coverage

Upgrade Immutable, Redux and React

Add more Immutable support (through the various APIs)

Get some performance logging

Add a demo page

Quite a few things there and I welcome any assistance on them as it’s going to be a long road but it deserves a 1.0.0 release.