Do we necessarily want to mount a deletion dialog for each individual task? We would only ever have one open at a time, and while theConfirmDialog shouldn't load any DOM nodes while closed, we're still making JSX for each one

Wondering if we could have something like a piece ofactiveTaskId state, and then that affects the content and logic that gets fed into the main dialog. Then, if it starts off asnull, thenull case would be treated as closed, and all other values would be treated as open

Rendering the delete dialog within the row follows the same philosophy as dropdowns: only one is open at a time, but we handle it per row. I know placement matters, but performance-wise I’d expect it to be similar.

Another point: keeping state in the list would re-render the entire list, whereas putting it inside the row means only that row re-renders, which should be more performant. Also, controlling state from the parent adds indirection; following the principle of colocation, keeping state close to where it’s used tends to make the code easier to reason about.

Does that make sense?

Do we also need to pass intask andonClose since those are non-optional args?

It’s not necessary, and Storybook won’t complain about it, or it is what I would expect but I see some storybook errors related toonClose.

Ah yeah I noticed there is no actual enforcement of the types in Storybook tests, but really seems like there should be. 🤔 Seems weird to discard type safety for tests.

Just curious if there is a reasononSuccess is being destructured above but notonClose.

onSuccess isn’t part of theConfirmDialog props—that’s the only reason.

I might be misunderstanding, butonClose is not a part ofConfirmDialog props either? BothonClose andonSuccess are called in thisonConfirm callback, so it looks inconsistent.

No big deal though, just wondered if there was a reason for it or was just random.

You're right, my bad.