Selector use case: optimize rendering of pure/surjective functions

The issue I often deal with involves “surjective” functions for deriving state (from other state slices). That is to say, several different inputs might output the exact same state. I want to avoid re-rendering in that circumstance. Clearly the computation must occur, but for instance, not every useEffect dependency change necessarily changes state.

Managing the sequential dependency, where one slice is a computationally complex derivation from another, And requires the end-user to review and further “configure” the computed state, while still having the ability to “backtrack” in order to change the inputs, is something I suspect recoil might help with.

Thank you in advance for clarifying how the library might support this use case.

- E

[drarmstr]

What gets in the way of making that assumption?

Even with completely pure functions, we can’t say anything about uniqueness of results. f(0) -> 'a' and f(1) -> 'a' So, #314 should control propagation of updates based on the actual result of selector evaluation. In addition, simple reference equality is not always appropriate; we would want to allow for some user-defined value-equality check.

Redundant calculations for equivalent inputs are already limited based on selector caching. The current policy is based on reference equality. Internally we use different policies now, but that should not be necessary with #314

I know I would love to avoid calculations based on the input. An alternative that makes this less of an issue would be if #317 is implemented, as each map, bind, etc would be a separate selector and halt processing after getting a known output.

Limiting propagation of updates would be really awesome with a functional atom map() in #317. Though, it is still fun and useful without that. We actually have implemented it already in #319. However, we don’t want to merge it yet because it encourages risky usage of mapping during a render function. Without memoizing the map function this would lead to a new selector with every render. We tossed around some ideas, but currently thinking of just adding a simple lint rule to protect against this.

I’m going to close this issue now as a duplicate of #314, but please clarify if you see a specific example use-case that wouldn’t be covered by that approach.

[Shmew]

@edmundsecho

What gets in the way of making that assumption?

Impurity, I’d imagine.

I know I would love to avoid calculations based on the input. An alternative that makes this less of an issue would be if #317 is implemented, as each map, bind, etc would be a separate selector and halt processing after getting a known output. However, it would encourage splitting what would normally be an acceptable function into more pieces to avoid further computations.

Meaning instead of myAtom.map(x => (x + 5) * 2) it may encourage myAtom.map(x => x + 5).map(x => x * 2). I don’t know if the number of selectors becomes an issue with splitting things up like that though, so it’s possible that’s a non-issue.