suggestion: add overload for "solo selector" without input selectors

[phryneas]

This is just something I wanted to explore.

Of course, people can always just call defaultSelector, but that's an additional function people have to be aware of, and it makes code bases less uniform. Right now, people oftentimes use identity functions, either as input selectors, or worse, even as result functions.

This would just allow a single function without input selectors to be memoized directly.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit b099da9:

Sandbox	Source
JavaScript	Configuration
Vanilla Typescript	Configuration

[aryaemami59]

Very interseting idea, do you think it would be simpler to just have a new API called something like createSoloSelector or createSimpleSelector instead of adding another function signature to CreateSelectorFunction?

[phryneas]

That would defeat the purpose.

People write bad code like

const selector = createSelector(
  state => state.slice,
  slice => slice
  )

or

const selector = createSelector(
  state => state,
  state => state.slice
)

because they don't know any other api.

They could already write

const selector = defaultMemoize(state => state.slice)

but they don't do it, because they don't know about defaultMemoize.

If we now offered

const selector = createSoloSelector(state => state.slice)

it would face the same problem - people don't know about it and won't discover it. They will resort to the bad alternatives above instead.

That's why I suggest

const selector = createSelector(state => state.slice)

here to "just work" - it solves the problem at the root without introducing mental overhead.

[aryaemami59]

That's a good point, do you think #645, will help mitigate some of the problem?

[aryaemami59]

@phryneas Do you want me take a look at this to see if I can get the types to work?

[phryneas]

@aryaemami59 I think #645 would help people spot the error, but currently it would still send people to use another function, which still adds the mental overload, so I think these two would complement each other.

As for fiddling with the types here: please go ahead, I don't currently have the time to take a deep dive here, and you're much more familiar with the code base. I assume that changing the signature order might already mitigate the warnings, but I could be wrong :)

[aryaemami59]

@aryaemami59 I think #645 would help people spot the error, but currently it would still send people to use another function, which still adds the mental overload, so I think these two would complement each other.

As for fiddling with the types here: please go ahead, I don't currently have the time to take a deep dive here, and you're much more familiar with the code base. I assume that changing the signature order might already mitigate the warnings, but I could be wrong :)

I do not possess your skills, but I will certainly try my best :)

[markerikson]

FWIW I'd like to defer consideration of this one until after RTK 2.0 / Reselect 5.0 is out. It isn't critical, it's something we could do in a minor, but I'm also still not convinced it's something we should do atm.

My top priority atm is doing some more scenarios to test how weakMapMemoize behaves (recreating the memory leak possibility, checking if we need resultEqualityCheck, checking how it works as a shared selector for list item components, etc)