# Deep Dive Into the Internals
## Explaining "Stateful Logic" in English
Hooks solve the problem of "stateful logic," code that uses state but which doesn't directly render anything. The code might run effects, which ultimately rerender something, but rendering is not its primary goal.
We'll use the concept of a debouncer to further concretize this idea. A debouncer is an action that runs using the last value it received after it has not received a value for a specified amount of time. For example, let's consider a user who wants to use an auto-complete dropdown. The user types in some content, and the dropdown displays a list of options based on that content. Without a debouncer, we would update the list of options each time the user presses a key, even if the user will immediately press another key, thereby invalidating all of our work. If a user types the word, "apple," we will update the list five times, one for each letter, to our server. Only the last update actually mattered; the other four wasted resources.
This problem is solved by using a debouncer. Each time the user types a letter, we restart the countdown timer. Once the countdown timer ends, we calculate which items should be in the dropdown based on the content the user provided. If a user quickly types the word, "apple," we will recalculate this list once. The first four letters do not cause any recalculation because the countdown timer restarts. Once half a second has passed after the user types the "e," the list of options is recalculated.
With that in mind, what do we need to implement this debouncer logic? Without being verbose, we need two things. We need to store, get, and update state. We also need to run effects:
1. (state) the latest value received (e.g. the user's inputted search).
2. (effect) the action to run with the latest value (e.g. recalculating the list of options).
3. (state) whether the action is waiting for the initial value (countdown hasn't started) or next value (countdown has started) before it runs.
The three things above have nothing to do with rendering. It is simply "stateful logic," non-rendering code that requires state to work.
## The Problem: Components Lack "Same State Structure" Guarantees
Let's say you define a component called `Container`. `Container` is a parent component that renders a few other child components: `NavigationBar`, `Canvas`, and `Toolbar`. Each component has its own local state, but there is no guarantee that the state value used for all of them are the same. `Toolbar`'s state may be just an `Int` whereas `Canvas` may store an `Array Polygon` whereas `Container` may store `UserSettings`, a `Record` of various things. As a result, you cannot "get" `Toolbar`'s state value in the same way that you can "get" a `Polygon` inside `Canvas`' state value in the same way that you can get a value from inside `Container`'s `UserSettings` record. The same could be said for updating any of these values. While it is possible for all of these components to use the same state structure (e.g. use a `Record` for everything), no such guarantee exists.
This file has been truncated. show original
