Each row in a code app grid renders a dropdown of 60 cost centers, and every dropdown calls CostCentersService.getAll when it mounts. Cost centers change about once a quarter. The network trace shows hundreds of identical requests per screen. What is the best fix?
Select an answer to reveal the explanation.
Short Explanation
If 200 people each phone the same store to ask the same price, something's wrong with your process. Fetch the cost centers once, keep them in app state, and hand the same list to every row. Spreading the calls out or trimming each one still leaves you making hundreds of calls.
Full Explanation
Reference data that changes rarely should be retrieved once and shared. Loading cost centers a single time, with select limited to the ID and name columns the dropdown needs, and storing them in app state, such as a context provider or a query cache, lets every row render from memory. The screen then makes one request instead of hundreds, which reduces latency, network volume and exposure to service protection limits. A refresh strategy, such as reloading on app start or after a set interval, keeps the cached list reasonably current given quarterly changes. Adding top to each per-row call shrinks every response slightly but keeps the request count unchanged, which is the actual problem. Deferring calls to the focus event spreads requests over time and adds a delay every time a user opens a dropdown, while still issuing one call per interaction. A cloud flow does not cache results for callers by default, adds a flow run per call and costs more than a direct data request. Exam caveat: caching is appropriate for slowly changing reference data, not for transactional data that users expect to see updated immediately. Operational check: reload the screen with the network trace open and confirm a single cost center request appears regardless of the number of rows.