automatic dependency detection?

[faassen]

I'm not sure whether this makes any sense, but I just found this comment in a reddit thread on redux:

https://www.reddit.com/r/javascript/comments/3g20ts/what_the_flux_lets_redux/ctv78fy

I am not sure it makes sense yet: maybe automatic dependency tracking makes more sense when you have mutable data?

If it doesn't make sense to implement this at all, then it may be wise to include some information as to why in the documentation.

[mindjuice]

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.

[mindjuice]

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.

[speedskater]

@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

[ellbee]

Doesn't seem to be an appetite for this, so closing due to inactivity.