-
Notifications
You must be signed in to change notification settings - Fork 8.5k
[App Search] Migrate Create Engine view #89816
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
[App Search] Migrate Create Engine view #89816
Conversation
| const { name, rawName, language } = useValues(CreateEngineLogic); | ||
| const { setLanguage, setRawName, submitEngine } = useActions(CreateEngineLogic); | ||
|
|
||
| // TODO these need to come from AppLogic and/or the Enterprise Search server |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're following along commit-by-commit I remove this in 207f8b
|
|
||
| export const ENGINES_PATH = '/engines'; | ||
| export const CREATE_ENGINES_PATH = `${ENGINES_PATH}/new`; | ||
| export const CREATE_ENGINES_PATH = `/create_engine`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zumwalt is good with this change #89156 (comment)
| </EuiButton> | ||
| </EuiPageHeaderSection> | ||
| </EuiPageHeader> | ||
| <FlashMessages /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need this for displaying the setQueuedSuccessMessage from CreateEngineLogic.actions.onCreateEngineSuccess
| </h1> | ||
| </EuiTitle> | ||
| </EuiPageHeader> | ||
| <FlashMessages /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't need this here... but it seems silly not to include this the normal view if I'm including it in the empty state view
|
@constancecchen how do you handle decisions about release notes? |
5f8beff to
60bb55f
Compare
| defaultMessage="Create an engine" | ||
| /> | ||
| </EuiButton> | ||
| </EuiButtonTo> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome catch on this button! 🎉
| expect(mockTelemetryActions.sendAppSearchTelemetry).toHaveBeenCalled(); | ||
| it('sends a user to engine creation', () => { | ||
| expect(button.prop('to')).toEqual('/engine_creation'); | ||
| }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not clear to me why this had to be split up into separate it blocks / beforeEach's etc. Just IMO, neither the component nor the test descriptions are distinct enough to warrant this extra amount of cruft. I would probably have opted to added a single line of expect(button.prop('to')).toEqual('/engine_creation'); to the original test and called it a day.
| </EuiPageHeader> | ||
| <EuiPageBody> | ||
| <FlashMessages /> | ||
| <EuiPanel> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Super optional/not a change request, just me thinking out loud] I think if we use EuiPageBody here that shows up w/ the panel appearance as well - that being said I don't 100% know what the semantic distinction is over PageBody vs Panel, or how much that's changing in Amsterdam 🤔 Mostly just posting to see if anyone else does haha
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for clarifying, I'll keep this in mind as I'm wrapping up Meta Engine Creation
| it('EngineCreationForm calls submitEngine on form submit', () => { | ||
| const wrapper = shallow(<EngineCreation />); | ||
| const simulatedEvent = { | ||
| preventDefault: jest.fn(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[optional] If we're defining preventDefault in a referenceable var, we might as well check that it was called at the end of the test, e.g.
expect(simulatedEvent.preventDefault).toHaveBeenCalledTimes(1);
expect(MOCK_ACTIONS.submitEngine).toHaveBeenCalledTimes(1);While I'm here also, .toHaveBeenCalledTimes(1); (vs. just .toHaveBeenCalled()) is a little more specific than we're doing in other files. I don't feel super strongly either way we go, but it would be nice to be consistent across files vs writing things slightly differently across the codebase.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the specificity personally
| const wrapper = shallow(<EngineCreation />); | ||
| const formRow = wrapper.find('[data-test-subj="EngineCreationNameFormRow"]').dive(); | ||
|
|
||
| expect(formRow.contains('Your engine will be named')).toBeTruthy(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This assertion feels like it's missing the actual name? Is there any way we can assert on that?
| expect(formRow.contains('Your engine will be named')).toBeTruthy(); | |
| expect(formRow.contains('Your engine will be named un-sanitized-name')).toBeTruthy(); |
not sure if the DOM works out that way, but that would make the test make a lot more sense when reading it. If it takes more than 5 minutes to do or it's a pain than no worries.
|
Sorry just to clarify, all of my new comments are optional except for #89816 (comment) - would ask that file change be reverted since the branch needs to be rebased / |
cee-chen
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving as my blocking/requested comments have been addressed. Would love to hear your thoughts on the optional ones added recently if you have time!
💚 Build SucceededMetrics [docs]Module Count
Async chunks
History
To update your PR or re-run it, just comment with: |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
2 similar comments
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
* New CreateEngine view component * Add CreateEngine to index router * Add Layout-level components for CreateEngine * Static create engine view * Add new POST route for engines API endpoint * Logic for Create Engine view WIP tests failing * Fix enterpriseSearchRequestHandler path * Use setQueuedSuccessMessage after engine has been created * Use exact path for CREATE_ENGINES_PATH (but EngineRouter logic is still firing??) * Add TODO note * Put CreateEngine inside the common App Search Layout * Fix CreateEngineLogic jest tests * Move create engine view to /create_engine from /engines/new * Add Create an Engine button to Engines Overview * Missing FlashMessages on EngineOverview * Fix test for CreateEngine route * Fix strong'd text in santized name note * Use local constant for Supported Languages * Disable submit button when name is empty * Bad conflict fix * Lint nits * Improve CreateEngineLogic tests * Improve EngineOverview tests * Disable EnginesOverview header responsiveness * Moving CreateEngine route * create_engine/CreateEngine -> engine_creation/EngineCreation * Use static values for tests * Fixing constants, better casing, better ID names, i18ning dropdown labels * Removing unused imports * Fix EngineCreation tests * Fix Engines EmptyState tests * Fix EnginesOverview tests * Lint fixes * Reset mocks after tests * Update MockRouter properties * Revert newline change * Lint fix
|
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
2 similar comments
|
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
|
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
Summary
This PR migrates the Create Engine view from
ent-search, with improved test coverage and no custom STUI components.Screenshots
Create Engine view: Empty state
Create Engine view: Supported languages
Create Engine view: Acceptable name
Create Engine view: Sanitized name
Create Engine view: Sanitized name with length of 0
Create Engine view: Duplicate engine name error state
Engine Overview view: Success message after engine creation
Checklist
Delete any items that are not applicable to this PR.