Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: show error details on insert COMPASS-8864 #6755

Merged
merged 15 commits into from
Mar 6, 2025

Conversation

paula-stacho
Copy link
Contributor

@paula-stacho paula-stacho commented Feb 26, 2025

Description

Side changes:

  • Updated InsertDocumentDialog from Class to FC.
  • add initial focus on another modal which was focusing on the copy button unexpectedly

The new dialog lives in the document tab. Even though the button says back, it is opened on top of the previous tab, not instead of. This is so that we can easily reuse it for other operations, whether they originate in a modal or directly from the documents list. Let me know if you see problems with this.
Added e2e test.

Checklist

Motivation and Context

  • Bugfix
  • New feature
  • Dependency update
  • Misc

Open Questions

Dependents

Types of changes

  • Backport Needed
  • Patch (non-breaking change which fixes an issue)
  • Minor (non-breaking change which adds functionality)
  • Major (fix or feature that would cause existing functionality to change)

@github-actions github-actions bot added the feat label Feb 26, 2025
@paula-stacho paula-stacho changed the base branch from main to validation-errors February 27, 2025 11:23
@paula-stacho paula-stacho added the no release notes Fix or feature not for release notes label Feb 27, 2025
@paula-stacho
Copy link
Contributor Author

paula-stacho commented Feb 28, 2025

Why I'm setting initialFocus: https://mongodb.slack.com/archives/G2L10JAV7/p1740755117364199.

But specifically in the context of these changes, it cost me some time and 5 sanity points to figure out why I need to click the "back" button two times 😅

@paula-stacho paula-stacho marked this pull request as ready for review February 28, 2025 15:08
<ErrorDetailsModal
open={!!errorDetailsOpen}
onClose={closeErrorDetailsDialog}
details={errorDetailsOpen?.details}
Copy link
Member

@Anemy Anemy Mar 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This modal error flow looks real nice! Noticed one small thing:

When we close this modal, we're also unsetting these details, which causes the modal to change in height as it does its close animation (it's not very noticeable, so if this is hard to change no worries). Would it make sense to have an isOpen boolean in the errorDetailsOpen instead of setting it to null to manage it's state? That way the content stays the same as it closes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, this feels much better!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change in store alone didn't prevent the flickering, I resolved this by only updating the code content when the modal is open. I also played around with setTimeout for cleaning up the details, but 0 is not enough and I didn't want to risk a race condition with next modal opening. I don't see any flicker if the modal opens with a different content.

Comment on lines 32 to 38
const [stringDetails, setStringDetails] = useState<string>('');

useEffect(() => {
if (open) {
setStringDetails(JSON.stringify(details, undefined, 2));
}
}, [details, open]);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This really doesn't belong in the effect, this is a derived value that, if we're trying to optimise the rendering here a bit and avoid stringifying too often, should be a memo.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was a memo, I changed it now because we saw a flicker (see conversation above). we set open -> close, details -> no details at the same time, but it renders sequentially - the modal closes a bit later than the details disappear. I see it as a problem with rendering, my best solution was to keep the details when the modal is closing.
I could rewrite this with memo + previousDetails ref, but this made more sense to me. But as I'm explaining it I see we need a comment at least. Would you prefer the memo + ref? Or do you have a better idea? I do admit it feels a bit hackish, maybe I'm missing something weird that we do that causes the issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Insert document modal has the same flicker. Bulk update does not.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would an alternative be to not un-set the error details when we close it? Then we can fully use the prop with useMemo. Not a blocker for me, might be nice to mention why we are doing it that way in a comment for future folks though.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my best solution was to keep the details when the modal is closing.

This is already a store state, if you want to not reset it when the modal is closed, just don't do it in the store itself and reset it on open in the store logic instead of splitting this logic between store and component in a hard to control and explain way.

Would an alternative be to not un-set the error details when we close it?

Yes, we already do this in a couple of places

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, I will change it in the store then. It seemed off to me as the store shouldn't be concerned with the rendering timing. But if it's a common pattern already, it'll at least lower the confusion

Copy link
Member

@Anemy Anemy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

@paula-stacho paula-stacho merged commit 2690a3f into validation-errors Mar 6, 2025
2 checks passed
@paula-stacho paula-stacho deleted the COMPASS-8864 branch March 6, 2025 12:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat no release notes Fix or feature not for release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants