@Janpot not sure if I am missing something here
besides the console output, what is the expected handling for the state change?

Once the row is out of the draft, it is removed from rows

const rows = React.useMemo(
  () => (draft ? [draft, ...rowsFromExternalApi] : rowsFromExternalApi),
  [draft]
);

This is why row data cannot be fetched here and we end up with the error (in dev mode) and some missing data in the callback args

Having a separate rows state like in the CRUD example that you have shared, solves the issue

https://stackblitz.com/edit/react-xqph3o-j4obgd?file=Demo.tsx

besides the console output, what is the expected handling for the state change?

• The function has a type signature and that doesn't include null for its second parameter. My expectation is that it never gets called with arguments that don't satisfy their types.
• The row switches from edit to view in the same render as it disappears. I think the behavior of switching edit to view of a row that doesn't exist anymore needs to be defined.
  • If processRowUpdate gets called, I expect it to get passed the original row and the updated row. i.e. store the row values when edit starts and use that value when row edit stops instead of trying to read it from the grid state.
  • If it doesn't get called I expect to see an error in the console. i.e. "a row that is in edit mode has been removed,..."

Having a separate rows state like in the CRUD example that you have shared, solves the issue

IMO the example is too simplistic:

1. In many cases, rows will be fetched from an external API. Libraries like react-query will potentially even invalidate and refetch them in the background while the create flow is active. The code in the example feels a bit anti-react to me as it requires careful curating of the rows state instead of deriving it from "am I in row creation mode or not" state.
2. In many use-cases the backend only assigns an id during the creation API call and it's not quite intuitive how the example needs to be updated to account for that.
3. There are also several UX issues with this demo:
   • It's possible to open multiple rows in edit mode at the same time. Potential solution: Make only one row editable at the same time. Close the currently editable one if a new one is opened if it doesn't have edits, otherwise ask to commit/discard/cancel.
   • It's possible to scroll away from those rows with no visual indication they are in edit mode. As well as switch pages or filter. The user may have something in draft on a different page without realizing it. Potential solution: Add a floating button when the edit row is out of the viewport which scrolls or moves page to it after clicking
   • It's possible to open the create flow at the same time, and scroll away from it. Potential solution: disable create button when already editing a row.
   • It's possible to open multiple rows in create mode
   • When there are multiple pages, the "add record" button creates a row at the end of the last page, regardless of which page you are on. Potential solution: pin created row to the top, regardless of which page you are on.

Lets add this to the board for further discussion!