React idiomatic controlled input (useCallback, props and scope)

Question

I was building a good old read-fetch-suggest lookup bar when I found out that my input lost focus on each keypress.

I learnt that because my input component was defined inside the header component enclosing it, changes to the state variable triggered a re-render of the parent which in turn redefined the input component, which caused that behaviour. useCallback was to be used to avoid this.

Now that I did, the state value remains an empty string, even though it's callback gets called (as I see the keystrokes with console.log)

This gets fixed by passing the state and state setter to the input component as props. But I don't quite understand why. I'm guessing that the state and setter which get enclosed in the useCallback get "disconnected" from the ones yield by subsequent calls.

I would thankfully read an explanation clearing this out. Why does it work one way and not the other? How is enclosing scope trated when using useCallback?

Here's the code.

export const Header = () => {

    const [theQuery, setTheQuery] = useState("");
    const [results, setResults] = useState<ResultType>();

    // Query

    const runQuery = async () => {
        const r = await fetch(`/something`);
        if (r.ok) {
            setResults(await r.json());
        }
    }

    const debouncedQuery = debounce(runQuery, 500);

    useEffect(() => {
        if (theQuery.length > 3) {
            debouncedQuery()
        }
    }, [theQuery]);



    const SearchResults = ({ results }: { results: ResultType }) => (
        <div id="results">{results.map(r => (
            <>
                <h4><a href={`/linkto/${r.id}`}>{r.title}</a></h4>
                {r.matches.map(text => (
                    <p>{text}</p>
                ))}
            </>
        ))}</div>
    )

    // HERE
    // Why does this work when state and setter go as 
    // props (commented out) but not when they're in scope?

    const Lookup = useCallback((/* {theQuery, setTheQuery} : any */) => {

        return (
            <div id='lookup_area'>

                <input id="theQuery" value={theQuery}
                    placeholder={'Search...'}
                    onChange={(e) => {
                        setTheQuery(e.target.value);
                        console.log(theQuery);
                    }}
                    type="text" />
            </div>
        )
    }, [])

    return (
        <>
            <header className={`${results ? 'has_results' : ''}`}>

                <Lookup /* theQuery={theQuery} setTheQuery={setTheQuery} */ />

            </header>

            {results && <SearchResults results={results} />}
        </>
    )
}

Answer 1

It's generally not a good idea to have what are essentially component definitions inside of another component's render function as you get all the challenges you have expressed. But I'll come back to this and answer your original question.

When you do the following:

    const Lookup = useCallback((/* {theQuery, setTheQuery} : any */) => {

        return (
            <div id='lookup_area'>

                <input id="theQuery" value={theQuery}
                    placeholder={'Search...'}
                    onChange={(e) => {
                        setTheQuery(e.target.value);
                        console.log(theQuery);
                    }}
                    type="text" />
            </div>
        )
    }, [])

You are basically saying that when the Header component mounts, store a function that returns the JSX inside of Lookup, and also put this in a cache on mount of the component and never refresh it on subsequent renders. For subsequent renders, react will pull out the definition from that initial render rather than redefining the function -- this is called memorization. It means Lookup will be referentially stable between all renders.

What defines that it's only on the mount is the deps array []. The deps array is a list of things, that when changed between renders, will trigger the callback to be redefined, which at the same time will pull in a new scope of the component its enclosed within from that current render. Since you have not listed everything used inside of the callback function from the parent scope inside of the deps array, you are actually working around a bug that would be flagged if you used the proper lifting rules. It's a bug because if something used inside like theQuery and setTheQuery changes, then the Lookup callback will not refresh/be redefined -- it will use the one stored in the local cache on mount which is in turn referencing stale copies of those values. This is a very common source of bugs.

That said since you've done this, Lookup remains stable and won't be refreshed. As you said, if it does refresh, you are going to see it gets remounted and things like its implicit DOM state (focus) are lost. In react, component definitions need to be referentially stable. Your useCallbacks are basically component definitions, but inside of another component render, and so it's being left up to you to deal with the tricky memorization business to "prevent" it from being redefined on each render. I'll come back to how you work around this properly shortly.

When you add theQuery={theQuery} setTheQuery={setTheQuery} you are working around the actual root problem by passing this data through to the callback from the parent scope so that it does not need to use the stale ones it has at hand from the initial render.

But what you have done is essentially write a component inside of another component, and that makes things much less encapsulated and gives rise to the problems you are seeing. You just need to simply define Lookup as its own component. And also, SearchResults.

const Lookup = ({theQuery, setTheQuery}: any)) => {
        return (
            <div id='lookup_area'>

                <input id="theQuery" value={theQuery}
                    placeholder={'Search...'}
                    onChange={(e) => {
                        setTheQuery(e.target.value);
                        console.log(theQuery);
                    }}
                    type="text" />
            </div>
        )
}

const SearchResults = ({ results }: { results: ResultType }) => (
    <div id="results">{results.map(r => (
        <>
            <h4><a href={`/linkto/${r.id}`}>{r.title}</a></h4>
            {r.matches.map(text => (
                <p>{text}</p>
            ))}
        </>
    ))}</div>
 )


export const Header = () => {

    const [theQuery, setTheQuery] = useState("");
    const [results, setResults] = useState<ResultType>();

    // Query

    const runQuery = async () => {
        const r = await fetch(`/something`);
        if (r.ok) {
            setResults(await r.json());
        }
    }

    const debouncedQuery = debounce(runQuery, 500);

    useEffect(() => {
        if (theQuery.length > 3) {
            debouncedQuery()
        }
    }, [theQuery]);


    return (
        <>
            <header className={`${results ? 'has_results' : ''}`}>

                <Lookup theQuery={theQuery} setTheQuery={setTheQuery} />

            </header>

            {results && <SearchResults results={results} />}
        </>
    )
}

Since the components are defined outside of render, they are by definition defined once and they can't access the scope of the Header component directly without you passing it to it via props. This is a correctly encapsulated and parameterized component that removes the opportunity to get into a scoping and memoization mess.

It's not desirable to enclose components in components just so you can access the scope. That is the wrong mindset to move forward with. You should be looking to break up the components as much as makes sense. You can always have multiple components in one file. In React, a component is not just a unit of reuse, but also the primary way of encapsulating logic. It's supposed to be used in this exact situation.