Comments (4)
I think it's interesting, but here are a few points to consider:
- I like the current ability to rename the dependencies in the selector function (e.g.,
selectedCartItems
can become just(items)
in the selector function. - Manual dependencies helps avoid accidentally introducing dependencies you might not really want.
- Manual dependencies allow you to instantly see what the dependencies of a given selector actually are without looking through all the code.
I was also going to say "Automatic dependency management takes additional code and time", but that's probably just my old embedded systems side talking. I'm generally in favor of wasting computer time instead of human time.
Having said that, I prefer cases where the computer's time saves me time over and over again. I'm not sure that is the case here. It seems more like the computer wastes time over and over again every time the apps runs, and only saves me time once or twice (when I write or modify the code).
I didn't look too closely at the code, but I wonder if it properly handles if/else
clauses, where maybe the if
depends on selectorA
, but the else
depends on selectorB
. Presumably, the choice of whether to branch is a result of some other selectorC
. So the code would need to update the dependencies after each selector call. That seems like a lot of unnecessary overhead on a per-selector-call basis.
from reselect.
In some cases, not having an active (automatic) dependency on a given selector would reduce how often the dependent selector gets called, which could be significant in some cases.
In code like the following, conditionSelector
is a dependency, and when it is 1, then selector1
needs to have an up-to-date value (or have it immediately recalculated when called) and selector1
would then get added as a dependency. When conditionSelector
is 2, selector2
needs to have an up-to-date value and then selector2
would get added as a dependency, while selector1
would no longer be a dependency.
if (conditionSelector === 1)
return selector1;
else
return selector2;
The benefit is that when conditionSelector
is 1, any changes to selector2
are irrelevant, so there is no subscription to selector2
. Vice versa for conditionSelector
== 2 vs selector1
.
I can see how this type of dependency management would be attractive to some people, but if you want to proceed with this, I would suggest making it optional.
from reselect.
@faassen It might be interesting, but I would vote against it for similar reasons as @mindjuice . It is too much magic for me. The reasons are:
- Only top level properties are observed (no recursion)
- Conditional code and dependent selectors are not considered
- It does not work for other datastructures like immutable.js
from reselect.
Doesn't seem to be an appetite for this, so closing due to inactivity.
from reselect.
Related Issues (20)
- Investigate potential memory leak issues with `weakmapMemoize` HOT 11
- unstable_autotrackMemoize Errors HOT 1
- How to type redux state and selectors with readonly? HOT 3
- Consider dev mode checks for `x => x` result functions HOT 2
- More Reselect addons to investigate HOT 1
- Add identifiable information to dev mode check log messages HOT 3
- Documentation ignores links in the table of contents entries HOT 1
- Type loss in `createSelector` with inline function declarations passed as separate arguments
- lastResult.deref is not a function (it is undefined) HOT 6
- Better call stack for selector warnings HOT 11
- Unable to use `resultEqualityCheck` with `weakMapMemoize` HOT 3
- Incorrect weakMapMemoize alternative example using useCallback HOT 1
- using createSelector.withTypes prevents build HOT 7
- Question: Why can't we support `createAsyncSelector`? HOT 7
- TypeError: (0 , _reselect.createSelector) is not a function HOT 12
- `weakMapMemoize` with `resultEqualityCheck` is provided empty objects for first call. HOT 3
- Library do not work in Safari < 14.1 HOT 1
- Why the LRUCache implementation is using Array over the Doubly Linked List with Map? HOT 8
- Question: should OutputSelector be used as an InputSelector? HOT 3
- Current documentration loose article about passing parameters HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from reselect.