[flohofwoe]

> How does the system know when that can be done?

At the earlist in the first frame the application UI description code doesn't mention an UI item (that means UI items need a persistent id, in Dear ImGui this is a string hash, usually created from the item's label which can have a hidden `##` identifier to make it unique, plus a push/pop-id stack for hierarchical namespacing.

> then the others will lose their state because of this

Once an item is visible, the state must have been provided by the application's UI description code, when the item is invisible, that state becomes irrelevant.

[amelius]

> when the item is invisible, that state becomes irrelevant.

What happens when the item moves out of view, e.g. because the user scrolls down?

State should be preserved, because the user might scroll back up.

[flohofwoe]

Once the item becomes visible, the application's UI code provides the item's state again.

E.g. pseudocode:

    for (firstVisibleItemIndex .. lastVisibleItemIndex) |itemIndex| {
        ui_list_item(itemIndex, listItemValues[itemIndex]);
    }

For instance Dear ImGui has the concept of a 'list clipper' which tells the application the currently visible range of a list or table-column and the application only provides the state of the currently visible items to the UI system.