feat(compass-collection): Add mock data generator modal container CLOUD-333848

[ncarbon]

Description

Jira Ticket: https://jira.mongodb.org/browse/CLOUDP-333848

Adds MockDataGeneratorModal in the compass-collection package.

Checklist

• New tests and/or benchmarks are included
• Documentation is changed or added
• If this change updates the UI, screenshots/videos are added and a design review is requested
• I have signed the MongoDB Contributor License Agreement (https://www.mongodb.com/legal/contributor-agreement)

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)

[Copilot]

Pull Request Overview

This PR introduces a mock data generator modal component to the compass-collection package as part of feature CLOUD-333848. The modal provides a multi-step wizard interface for generating mock data with AI integration.

• Adds a new modal component with step-based navigation and proper state management
• Implements TypeScript types and constants for the mock data generation workflow
• Includes comprehensive test coverage for modal behavior and interactions

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
types.ts	Defines the MockDataGeneratorStep enum with 6 workflow steps
mock-data-generator-modal.tsx	Main modal component with navigation logic and step management
mock-data-generator-modal.spec.tsx	Test suite covering modal rendering, navigation, and user interactions
constants.ts	Maps step enum values to corresponding button labels

Comments suppressed due to low confidence (1)

packages/compass-collection/src/components/mock-data-generator-modal/mock-data-generator-modal.spec.tsx:91

• This test iterates through all button labels but doesn't verify that the modal actually progresses through the correct steps. The test should verify that clicking the button advances to the expected next step, not just check the label text.

    Object.values(StepButtonLabelMap).forEach((label) => {

[jcobis]

Nice test coverage!

[paula-stacho]

we use LG's spacing consts (import via @mongodb-js/compass-components)

[paula-stacho]

why isn't the currentStep state managed by this component?

[jcobis]

See this comment

[jcobis]

Essentially, modal isn't always initialized to same screen. An alternative I just thought of could be to pass in the initial current step as a prop, and still leave this component to manage the state. That's probably the cleanest actually

[jcobis]

Nice work Nataly! Approved, left one small nit we could consider (perhaps fixing in next ticket even)

[gribnoysup]

We're following React convention for callback prop naming

Suggested change

	isOpen: boolean;
	setIsOpen: (isOpen: boolean) => void;
	currentStep: MockDataGeneratorStep;
	setCurrentStep: (step: MockDataGeneratorStep) => void;
	isOpen: boolean;
	onOpenChange: (isOpen: boolean) => void;
	currentStep: MockDataGeneratorStep;
	onCurrentStepChange: (step: MockDataGeneratorStep) => void;

[gribnoysup]

Resetting the state like that means that the modal content jumps around while it animates from the screen, for that purpose in compass we usually reset the state when opening the modal, not closing, this is a way nicer visual experience usually, especially if your steps are very different visually

[jcobis]

I think what Sergey's saying is we can just take out those resetState calls, since we will be passing in currentStep anyway

[gribnoysup]

I'm saying you want to reset it on open, not on close, if you don't want UI to feel janky. I am not saying you don't want to reset the state at all. Even if you're passing currentStep from some other place (redux store or parent component), something would still need to reset the state at some point

[jcobis]

Q: So this corresponds to the 8px from before?

[ncarbon]

Yes https://github.com/mongodb/leafygreen-ui/blob/13a2ac4093507741367aba87e316b5ab10de5220/packages/tokens/src/spacing.ts#L7

[jcobis]

LGTM!

[gribnoysup]

This code is brittle as it allows to pass an arbitrary number value here, the code below is completely valid from TypeScript perspective:

      onCurrentStepChange(currentStep + 42);

If you are opting into using enums (we generally avoid them in the codebase, using string unions instead, even string enum would be a better choice) to introduce rigid typings for allowed steps, I would suggest that the step transitions are clearly defined through switch case statements to disallow such behavior (you can extract this logic into its own method that can be shared later with other parts of the code or easily moved around). I would also strongly recommend to switch to either string enums or string unions to make the transitions clearer and avoid the pitfals of using numbered enums