another crazy thought: reimplementation of Redux reselect.. built on top of this library

[warren-bank]

Hi.. it's me again :)

This issue is unrelated to my previous issue #78.. where I introduced a little library that is a light-weight wrapper around the redux-react-hook library to add an enhancement to useDispatch().

This issue pertains to another enhancement that I added to that library, which is a function called createReduxSelector which aims to provide a (very nearly) drop-in replacement for Redux reselect.

Links to learn more..

• README
• source code
• unit tests:
  • source code
  • run in browser

I just wanted to let you know about it..

• it's already extremely efficient
  • there's always room for improvement, and I'm very open to ideas/suggestions
• is this something you'd consider including in the upstream redux-react-hook library?

[warren-bank]

If you don't mind me picking your brain.. I'm on the fence about one topic that may have a slight impact on efficiency.. and I'm curious your thoughts.

Boiling the scenario down as much as possible.. here is the situation:

• there are a whole bunch of useMappedState functions
• when the component is forced to update, the output of all of these functions are used to calculate a new value

If a custom equality function (ex: shallow, deep, etc) was to be introduced to improve efficiency, would it be better to:

1. apply it to useMappedState.. to prevent the component from re-rendering unnecessarily (ie: every time the global Redux state changes)
2. apply it to the result of the function that depends on all the useMappedState output.. to memoize this result
3. apply it to both (1) and (2)

---

currently:

• useMappedState uses the default equality function, which depends only on top-level reference

  • so unless the function is returning an unmodified chunk of data as it exists in the Redux store.. any custom data structure that is derived from the Redux state is always going to trigger the component to re-render

• the result of the function that depends on all the useMappedState output is memoized

  • all input parameters are compared to their values from the previous render
  • by default, each value is compared by reference equality
  • by the options Object, this compare function can be replaced by 'shallow' or 'deep' equality

• ---

Specifically:

in useMappedState:

https://github.com/facebookincubator/redux-react-hook/blob/5275dffd8defce004afd6ea5de3c9e30a0f987a1/src/create.ts#L137-L139

---

I'm debating changing the shape of the options Object to maybe something like:

{
  equality: {
    forceUpdate: [],
    recalculate: ''
  }
}

where:

• options.equality.forceUpdate contains an Array of strings (ex: 'shallow', 'deep', null) that is the same length and order as the input-selectors in the input parameters
  • each value determines the custom equality function passed to the corresponding useMappedState
• options.equality.recalculate is a string (ex: 'shallow', 'deep', null)
  • this value determines how the result of the function that depends on all the useMappedState output is memoized

shortcuts:

• if (typeof options.equality === 'string')
  • options.equality = {forceUpdate: options.equality, recalculate: options.equality}
• if (typeof options.equality.forceUpdate === 'string')
  • options.equality.forceUpdate = inputSelectors.map(() => options.equality.forceUpdate)

but.. I'm not entirely sure if this is the best strategy

any thoughts?

[warren-bank]

update: I just made the proposed change. Ultimately, the default behavior is unchanged. This just adds the ability to precisely configure all of the equality functions.. to fine tune (a) when mutation to Redux state should trigger the React component to re-render, and (b) how the the Redux selector is memoized. ..Always good to have knobs and levers for when you need them.

[ianobermiller]

That looks interesting, I'm having a bit of trouble following what it is for, though. I see a lot of hooks being called conditionally which is usually not good, but if it is the same on every call it might be fine. What does this library buy you over just using reselect directly?

I'd like to keep this library (redux-react-hook) lean, so this should be a separate module. I'm going to close this issue, but we can have further discussion here.

[warren-bank]

I totally agree with your concern about hooks being called in conditional blocks. While this appears to violate the 1st rule of hooks, this particular usage is safe under the implied contract that:

• ~the number and type of arguments passed to createReduxSelector(..args) is always the same every time the React component renders~ (..refer to update 1 below)

As for my motivation to experiment with a re-implementation of this library:

• it serves a very important purpose
  • memoizing a (potentially costly) function that depends on values either directly obtained from or indirectly derived from the Redux store
• it does not:
  • subscribe to the Redux store to listen for updates to the global state
  • integrate with React components
  • ex: to force a render update when the value of the memoized result changes

Since the purpose of this library is to provide good integration between Redux and React, these 2 missing ingredients (taken together) felt like a good candidate for inclusion. The useMappedState() method provides a very easy path to do so, since it already does most of the heavy lifting.

• provided by useMappedState():
  • it subscribes to the Redux store to listen for updates to the global state
  • it forces a render update when the value of the memoized result changes
• strategy to utilize this method:
  • pass each input-selector to useMappedState()
  • the equality function can be configured for each
  • when equality returns false:
    • useMappedState() is going to force a render update
    • the "costly" function is going to receive new input, which causes memoization to update and the function to run

update 1 (correction):

• the thing I said about there being an implied contract needs clarification..

  • I wrote this code about a week ago and forgot the nitty-gritty implementation details
  • though what I said is (strictly speaking) accurate, the usage suggested by this statement is an anti-pattern
  • it's better to call createReduxSelector(..args) outside of the React component
  • it returns a consolidated function, which is what gets called within the React component's render function
  • all of the ...args are scoped within the closure and cannot be changed.. so the same if/then block(s) will always be evaluated every time the consolidated function is called
    • these conditional block(s) determine which hook(s) get called, and since the same blocks are always evaluated (ie: there's no possibility to branch and run different blocks).. it's logically equivalent to there being no branches.. and consequently the 1st rule of hooks is obeyed
  • the consolidated function accepts any number of optional input parameters
    • these values have no bearing on whether or not hooks get called
    • these values are passed as optional input to all input-selectors (following the required Redux state)

  • ~incomplete/untested~ example (that entirely ignores Redux state for brevity):

    const selector = createReduxSelector(
    (state, props) => props.msg || "I did , did I",
    (msg) => {console.log(msg); return msg.split('').reverse().join('')}  // reverse string
    )
    
    const Component = (props) => {
    let rev_msg = selector(props)
    return (
      <div>{rev_msg}</div>
    )
    }
    
    ReactDOM.render(
    <Component msg="hello world!" />,
    document.getElementById('root')
    )

update 2 (live examples @ codesandbox):

1. no-frills (same as above):
   • code editor
   • rendered
2. adds counters to track when functions execute (w/ interval timer to force a render every 2.5 secs):
   • code editor
   • rendered
3. adds Redux state w/ corresponding input-selector (which derives a "debounced" counter value that changes once for every 3x the component renders)
   • code editor
   • rendered
4. adds performance optimizations to reduce the frequency of component renders, such that it only occurs after the Redux selector returns a new value
   • code editor
   • rendered

[warren-bank]

To be entirely honest, I only glanced at the recommended methodology because it strikes me as very overly complicated.

If that methodology is feasible, then I would challenge you to fork example # 4 and rewrite it (using only redux-react-hook and optionally reselect) to produce the same output.

I'm honestly curious what that solution would look like, and how well it would scale to having more than only one input-selector that derives its value from Redux state.. as this example is a fairly trivial use-case.

update 1:

ok.. I took a closer look, and now I see what's happening in the recommended methodology. I'm going to accept my own challenge, and will post the link to a working example ~(..soon)~.

update 2:

• I stand corrected..
  • code editor
  • rendered
• comments:
  • only very minor modification was needed
  • the "methodology" was abstracted into a new custom hook called useSelector

• tl;dr:

  const useSelector = (selector, ...params) => {
    return useMappedState(
      React.useCallback(state => selector(state, ...params), params)
    );
  };
  
  //...
  
  const Component = (props) => {
    let rev_msg = useSelector(selector, props)
    return (
      <div>{rev_msg}</div>
    )
  }