Selection-State Class for an Infinite-Scroll Checkbox List with Select All

Write a class that handles the data for a list rendered with infinite scrolling. Every row in the list has a checkbox, and a Select All checkbox sits above the list. The class should load more items as the user scrolls, let the user check and uncheck individual rows, and let the user toggle Select All. It must stay correct across the many combinations of these interactions. Focus on the data-handling class and its API for the UI, not on styling or scroll detection. ```hint Decide what Select All means for unloaded rows Consider what the selection should mean for rows that have not loaded yet when Select All is checked, and whether one boolean per loaded row can express that. ``` ```hint Compute the header state Treat the Select All checkbox's appearance (checked, unchecked, or partly checked) as a value computed from the selection rather than as separate stored state. ``` ### Constraints and Clarifications - Items arrive in pages from an asynchronous fetch function you can call with a cursor or offset; each item has a unique, stable id. - The UI renders from the class's state and must be notified when the state changes. - Scroll detection, such as an intersection observer, is outside the class; the UI calls a method like `loadMore()`. - There are many interaction scenarios, and edge cases are the main point of the exercise. ### Clarifying Questions - When Select All is checked, does it cover only the rows loaded so far, or every row in the full list, including rows that load later? - Is the total number of items known from the server, or only whether more pages exist? - When some rows are selected, should the header show a partly checked state, and what should clicking it do: select all or clear all? - What does the consumer need from the selection, such as a list of selected ids or a description a bulk-action API can apply on the server? - Can the list change while it is displayed, for example through a filter change, deletions, or new items arriving, and what should happen to the selection then? ### What a Strong Answer Covers - A selection model that correctly handles Select All when not every row has loaded, and a way to describe the selection when not every row id is known. - A derived header state with checked, unchecked, and partly checked cases, including returning to fully checked or fully unchecked as rows are toggled. - Loading logic: preventing duplicate requests while one is in progress, tracking whether more pages exist, removing duplicate items across pages, recovering from errors, and ignoring responses from a list that has since been reset. - An API the UI can subscribe to, with immutable snapshots suitable for rendering. - Edge cases: an empty list, the last page, checking every row one by one, unchecking one row after Select All, loading pages after Select All, and a reset. - Tests for these scenarios. ### Follow-up Questions 1. How would you send the selection to a bulk-action endpoint when Select All is on and a few rows are unchecked? 2. How does the design change if rows can be inserted or deleted on the server while the user is scrolling? 3. How would you add Shift-click range selection? 4. With many thousands of loaded rows, what would you change so rendering and selection checks stay fast?