Usage about use-context-selector

[dai-shi]

Hi,

It's nice to see you try my library intensively.
Wow, so many points here, let me respond each.

What do you think about these patterns?
Gallery/Gallery.tsx

This pattern is pretty much the same as what I do in react-tracked.

It's going to be like this

import { createContainer } from 'react-tracked'

const useGalleryState = () => {
  console.log('state')
  const [searchTerm, setSearchTerm] = useState('')
  const { status, data } = useQuery([searchTerm], fetch)

  return [{
    isLoading: status === 'loading',
    data,
    searchTerm,
  }, setSearchTerm]
}

export const {
  Provider,
  useSelector: useGalleryContext,
  useUpdate: useSetSearchTerm,
} = createContainer(useGalleryState)

There is also performance test.

Please note that when you test performance you'd want to use production build to get real numbers.

Thinking towards useReducer and will experiment with your useAsyncReducer.

Check this out, if you haven't: https://react-tracked.js.org/docs/tutorial-04

Btw it is slower than yours.

Looking at their code, I'm not quite sure why so different.

BTW, I already developed a next major version: #12

what is the actual reason to manage immutable store, other than time travel ?

(not sure what you mean by time travel)

About the immutability (wouldn't call immutable store, because store is mutable. state objects are immutable), it's in a sense a preference or a style. For example, we have Redux and MobX. Both are good and not interchangeable.

However, React itself leans to immutability. It supports both patterns (immutable and mutable) by default, but React.PureComponent and React.memo are for the immutable pattern.
With upcoming Concurrent Mode, it allows to branch state, so the mutable pattern will have some difficulties. In short, the immutable pattern fits better with React philosophy.

The question arose when it was easier for me to put an array with other methods into useRef, mutate it in the methods and just call 'forceUpdate'. It worked. So what is the reason to manage immutability ?

It works in legacy mode, but it will not in concurrent mode. That's the reason. Basically, you want to avoid using useRef for "states". It behaves unexpectedly in concurrent mode.

I used to use forceUpdate hack a lot in my various libs, but not any more.

[lishine]

Yes, right, in production the two variants do not differ.
The difference though when passing props or memoized vs context is still substantial. But even if to neglect it, there is additional benefit of the convenience of not passing props and not declaring their types, etc.

Yes, I see there is 2alpha of the useMutableSource. For the react-tracked you also developing 2nd version.

Yes, because the react way is immutability, this is the reason I once started looking into redux at all. Mobx was so convenient. But for certain things Mobx problematic. I did this form lib https://github.com/lishine/mobx-hooks-form. And because of accessing dynamic path form.a.b.c I had to do some workaround. Mobx way is the way of Rxjs, observables etc, it is different world.

Will start looking into react-tracked. But it is more heavy. Good for app.
I would convert this form lib to use use-context-selector. Then I would want the lightest store so that lib size will be small. Probably useReducer+use-context-selector will be enough. There is debouncing there though. Will see.

Pattern of asyncActionHandler of use-reducer-async reminds me of thunk of easy-peasy. They have createContextStore btw.

[dai-shi]

there is additional benefit of the convenience of not passing props and not declaring their types

I'm not sure if I understand this.

Mobx was so convenient.

I don't have much experience with MobX, but it you like it, you might like react+tracked + immer. I hope this combination gives similar DX. I'm interested in your feedback on it. No rush.

[dai-shi]

Closing as stale. Please open a new one if needed.