reselect VS effector-react

Each one of those method calls represents a potentially huge tree of nested method calls. And if we've implemented memoization, it would all run in O(n), where n is the total number of methods. There is no performance impact from the nested calls and we're guaranteed to respect all business rules at every level (DRY), while keeping each method easily readable. reselect is a perfectly good library that provides composability and memoization.

But we needed this in Reselect because it has an incredibly variadic JS runtime API. You can pass in any number of input selectors, as either individual function arguments or one big array, and all the rest of the output behavior depends on those. This one giant MergeParameters type is effectively replacing 3300 lines of copy-pasta'd typedefs for 1...12 input selectors.

One thing that can help is the new customization options in Reselect 4.1.x. You don't need a deep equal check here. Instead, you could use a shallow check as the resultEqualityCheck option. It would still end up having to re-run the filter statement, because the input array is being changed to a new reference when you do an update to any item in the array. Filtering the array does create a new result array reference. But, resultEqualityCheck: shallowEqual will reuse the previous result as long as the contents of the array are the same, and that will prevent the component from re-rendering.

Over the years, as I've been using Redux, I've tried quite a few different forms of testing. Actions, reducers, sagas, selectors, some with more boiler plate results than others. One of the evolutions of testing that I've enjoyed the most has been with the library I use for selectors, reselect.

While Reselect has always been a separate library from Redux itself, it's in our Github org. The previous maintainer had to stop working on it, so a couple months ago we did some major updates to Reselect. Reselect 4.1.x has huge improvements to its TS types for better inference, and adds a new set of customization options like cache sizes > 1.

Fourth, Use Reselect / Re-reselect in Redux to Avoid Frequent Re-render. Reselect is a library for building memoized selectors that is commonly used for redux.

Another great tool used in the Redux world is Reselect. Storing the bare minimum data in the Redux store and then deriving data with memoization using Reselect. I had to create a poor man's version here. Feel free to check it out :)

We've completely revamped the Reselect types in the last few weeks and added new cache size options to its API - see https://github.com/reduxjs/reselect/releases

Reselect

https://ngneat.github.io/elf/ https://effector.dev/

New API allows to setup each class independently. Proposal. It is based on browser API classList.

EffectorJS

https://effector.dev/ We use it on production in several projects

To understand this part of the article, it is better to read Effector’s documentation first. Effector has a game-changer feature — Fork API. To understand it, we should talk about one important concept — scope.

The issue with using eventemitter for state coordination is that when the UI grows into complexity you run into race conditions where some component isn't showing the right data because it got mounted too late or something somewhere up the hierarchy changed a key and the component got recreated and its state got lost.

I guess as long as long as the component hierarchy fits in your head, it is likely straightforward to reason about all the event interactions.

The lifted state model ala redux (and similar alternatives) doesn't suffer from this problem.

I personally prefer effector [1] these days because it combines the convenience of event emitter with multiple stores and you usually find yourself thinking much less about what changed the store causing my component to rerender much less often.

[1] https://effector.dev/

It’s worth noting that there is a thing called Effector and I have heard a lot of good stuff about it. Maybe you should give it a try and take a peek at its documentation as well.

Personally I'm finding Effector to be very useful for the kinds of projects I'm working on. It encourages small atomic stores which means you don't need selectors to avoid rerenders throughout the app. Effectors stores also handle updates from multiple dependent async effects and derived states really well.

This looks really cool to me and reminds me a lot of Effector, and looking at one of the open issues it seems that you are aware of it. Does this project have goals that specifically set it apart from Effector? You seem to lead with bundle size as a defining characteristic. Is that your long term goal? You seem to have plans to handle effects. How similar or different will that be from Effector?

I found effector[1] after I started looking around for a state manager which:

1. Either supported multiple stores or provides a way to subscribe to individual branches (as opposed to the entire store).

2. Had an action/event abstraction similar to redux where multiple branches (or multiple stores) could subscribe to the same action and update independently (and without knowledge of invoker).

I have been using it for some time and have had a good experience.

The core is framework agnostic (with additional integrations for react & vue).

I started used it with Svelte and its API matches the expectations of Svelte stores so you can use it without needing any additional integration, which was cool. Later I used it with lit-element through a 5 line custom integration and that worked pretty well too.

[1] https://github.com/effector/effector