I have been doing React development for a good amount of time now and I really like what hooks allow. It does diverge a bit from classic OO ideas though, which

I have been doing React development for a good amount of time now and I really like what hooks allow. It does diverge a bit from classic OO ideas though, which can be tricky to wrap your head around the first time. Hooks do a good job of nudging you to make better decisions about how to design your app, primarily by making bad decisions harder to make. This feels bad initially but once you get it, I think its better. That said, lets address your issues: 1. Yes/No. There is no reason you cannot have both props and state effect your component, however I don't think thats your question. If you need something outside the component to effect what is typed into the box, (e.g. the app can clear the text) then yes, you should be passing the text in as a prop, along w/ an onChange callback prop for when the text is changed within the component. I think of it as, if the state can be changed somewhere else then it doesn't belong to the component, and is thus a prop. Note, the options could be filtered in the component or not, also up to you. 2. I agree with this question. The main use I've found of useCallback is to avoid triggering changes to other hooks. ¯\_(ツ)_/¯ I think react team members have even asked about how people use it: https://twitter.com/brian_d_vaughn/status/1174359975600091136 https://twitter.com/brian_d_vaughn/status/117435997560009113... 3. useRef is great. It allows you to store state which does not trigger re-renders. This gives you a finer detail control of your component. I would not use it to "hack around the fact that state changes don’t take effect until the next tick" though. I think it would be bad practice to have to think about when state changes take effect. (This might be one of the "making bad decisions harder to make" moments) P.S. I agree about typing .current everywhere, but it makes sense from a JS perspective. useRef is simply keeping track of an object instance and you are accessing a member of that object. I'm not sure if it has to be 'current' or if thats just convention (anyone know?). 4. I can't answer this without an example. Generally, if you need the value to render, you either have it via a prop or it it is already stored in state. If you need to transform that value in order for it to look right, you do that inside your function. If it is a complicated calculation, do it with useMemo, so it only has to be done if your value changes. If something causes your state to change, you should just update the value and then allow it to rerender, thus it becomes the already in state case. Those changes should really only be part of other actions though, not your render function itself. So that was long winded, but hopefully useful. I think hooks are good and generally use the following heuristic: - useState: state which causes rerenders on change - useRef: state which does not cause rerenders on change - useMemo: calculated state based on other props/state (only needed if the calculation is expensive) - useCallback: useMemo for functions :p - useEffect: Do something based on state or lifecycle of component (e.g. mount/unmount) (edited for formatting)