A dataset code component on a model-driven app view renders each row as a card. Users sort the view by Estimated Revenue, but the cards appear in a different, inconsistent order. How should the component read the rows?
Select an answer to reveal the explanation.
Short Explanation
The dataset gives you two things: a bag of records and a numbered list telling you their order. You walk the list, sortedRecordIds, and pull each card from the bag; if you just dump the bag, you get whatever order it falls out in.
Full Explanation
A dataset property exposes rows through two members. records is a map from record ID to an entity record object that provides formatted and raw values, and sortedRecordIds is an array of IDs in the order defined by the current view, sorting and paging. Rendering in the order of sortedRecordIds and looking up each record by ID keeps the component consistent with the sort the user applied, including after the user changes the sort. Object key order of the records map is not a documented contract for view order, so relying on it produces the inconsistent ordering the users see. Sorting in the component by the primary name ignores the user's chosen sort column entirely, and the premise that rows always arrive in creation order is false. Querying the Web API separately duplicates data the dataset already supplies, bypasses the view's filters and paging, adds a network call on every updateView, and can disagree with the grid. Exam caveat: when the component lets users sort, it should update dataset.sorting and call refresh so the platform returns rows in the new order rather than sorting locally, which keeps paging correct. Operational check: sort the view by different columns in the running app and confirm the card order matches the grid order every time.