Whats the status of rendering only on changed properties

[sirpy]

I saw a couple of old PR and discussions about re-rendering the component only when the properties he subscribed too have changed and not on every store change. Whats the status with that? what's blocking it?

[bcherny]

Turns out, auto-detecting which fields are used isn't possible to do in all cases.

The best option for an API here is to overload useStore to accept a key:

function Foo() {
  const [foo, setFoo] = useStore('foo')
}

PRs are welcome, though this feels like it'll be a pretty significant change. My hunch is the easiest way to do it will be a full rewrite of Undux's guts.

[sirpy]

The only problem I see implementing this is that the "storeDefinition" is not exposed where defining "useStore" (returns react context) If the storeDefinition is available there we could expose another method "useStoreItem" with the following hooks code that should work

const useStoreItem = (item: string, value = null) => {
  let [itemValue, setItemValue] = useState(value)
  useEffect(() => {
    let subscription = store.on(item).subscribe(data => {
      if (data !== itemValue) setItemValue(date)
    })
    return () => subscription.unsubscribe()
  },[])
  let mutateItem = store.set(item)
  return [itemValue, mutateItem]
}

The "hook" subscribes to store changes of the item via the effects mechanism (both of undux and react) if value of item is changed then the hook state changes which causes the component using the "useStoreItem" hook to rerender. Once the hook is unmounted the subscription is canceled. a mutateItem is also returned by the hook to allow changing it in the store itself.

What do you think? is it possible to expose the storedefinition to the context where useStore,withStore is defined?

[sirpy]

@bcherny what do you think??

[bcherny]

Definitely worth playing around with this idea! Want to try submitting a PR with API #3 from https://github.com/bcherny/undux/pull/69? I'd suggest adding a bunch of unit tests to assert how many times a component renders, in order to make sure it only re-renders when a field that it uses changes.

[erixtekila]

Hi @bcherny and @sirpy

I've investigated further on this topic. I wasn't aware of an optional 2nd parameter in the createContect method. React tips — Context API (performance considerations)

Couldn't this technic be used to optimize the store value updating process ? Like so ☘️A speed optimization for a Context API

Thougths ?

[bcherny]

Yeah, there's probably room for optimization here! Want to put up a proof of concept PR, with some tests to make sure it works as expected?

In general, the React reconciler is so fast, that these sorts of optimizations won't yield all that much in practice. Of course, I may be wrong :)

[erixtekila]

Want to put up a proof of concept PR, with some tests to make sure it works as expected?

Sure !

In general, the React reconciler is so fast, that these sorts of optimizations won't yield all that much in practice. Of course, I may be wrong :)

I may be to, but it worth a try.