useSelector is poor naming

[ChezMose]

I'm sorry to point that out, and some people will obviously disagree, but I live in a world where redux is not getting much hype and people are hard to convince and try something if it's hard to get or if the benefit is not obvious.

A good naming is the best way to help people apprehend something unfamiliar, and I think Redux needs and deserves this <= this is my motivation for writing this issue as I strongly believe Redux is a great way to organize a scalable application !

Watch those :

const [counter, setCounter] = useState(0);
const onClick = useCallback(e => { ... });
const contextData = useContext(MyContext);
const myRef = useRef(null);
const dispatch = useDispatch();

And watch this only exception, which has the particularity of returning nothing :
useEffect(() => { ...my effect code ... });

Let's face this implicit rule of hooks: a hook named use{something} is a hook that returns {something}

When I saw you introduced 'useDispatch', I already knew how to call it. I quick-checked the documentation and it was how I expected it to be.

But I did not find the hook to access the data in my Redux store. Until I guessed it was useSelector... but... I don't want to use a selector, I want to use data from the store.

The selector is just the way to access it, it's a detail. To me it's like useRef was named useDefaultValue of course you provide a default value, but that's not what you want to use in the end.

useRedux would be bad as well, as you have no idea what it can return.

My best proposal right now is useStored which is shorter than useStoredData, but clear when you read the code and discover the API. Plus it's a reminder of the Redux Store.
But maybe you have a better name ?

[markerikson]

We debated this one over in #1179 . I see the point you're getting at, but it's not entirely accurate. For example, React provides these hooks:

• useState: describes the result
• useReducer: describes the argument
• useContext: actually describes the argument - you are receiving the value from the context
• useEffect / useLayoutEffect: describes the argument
• useCallback: describes the argument
• useMemo: describes... the behavior?
• useRef: describes the result

So no, I'd disagree that use{Something} always describes the result.

I'm going to close this one. If you want to debate it further, please comment in #1252 .