-
Notifications
You must be signed in to change notification settings - Fork 42
Conversion Host Configuration Wizard Step #1 (Location), and introducing common reducers #871
Conversation
...ts/ConversionHostWizard/ConversionHostWizardLocationStep/ConversionHostWizardLocationStep.js
Outdated
Show resolved
Hide resolved
...ts/ConversionHostWizard/ConversionHostWizardLocationStep/ConversionHostWizardLocationStep.js
Outdated
Show resolved
Hide resolved
...ts/ConversionHostWizard/ConversionHostWizardLocationStep/ConversionHostWizardLocationStep.js
Show resolved
Hide resolved
...ts/ConversionHostWizard/ConversionHostWizardLocationStep/ConversionHostWizardLocationStep.js
Outdated
Show resolved
Hide resolved
...ts/ConversionHostWizard/ConversionHostWizardLocationStep/ConversionHostWizardLocationStep.js
Outdated
Show resolved
Hide resolved
b085fb6
to
50093c9
Compare
...ts/ConversionHostWizard/ConversionHostWizardLocationStep/ConversionHostWizardLocationStep.js
Show resolved
Hide resolved
...ts/ConversionHostWizard/ConversionHostWizardLocationStep/ConversionHostWizardLocationStep.js
Outdated
Show resolved
Hide resolved
...ts/ConversionHostWizard/ConversionHostWizardLocationStep/ConversionHostWizardLocationStep.js
Outdated
Show resolved
Hide resolved
932d24e
to
74ecb8a
Compare
...ts/ConversionHostWizard/ConversionHostWizardLocationStep/ConversionHostWizardLocationStep.js
Show resolved
Hide resolved
ee90f7b
to
2d29e21
Compare
Checked commits mturley/manageiq-v2v@68da0c4~...2d29e21 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0 |
This needs unit tests, but is otherwise ready to go. @michaelkro, I'm adding you as a reviewer here since you were kind enough to offer, but since it's past 5pm on your last day, feel free to revoke that offer at your discretion! Once again it's been a real pleasure working with you. Cheers 🍻 |
payload: API.get(url) | ||
}); | ||
|
||
export const fetchProvidersAction = url => { |
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.
Food for thought...
There is already a system in place for fetching and maintaining a list of providers in the Overview screen. Now that we need similar functionality here in Settings, we are duplicating that code, and maintaining the same data in two separate places.
When resources are shared across screens like this, it might make sense to have "application level" actions/reducers. These could be made available to the screens/components that need them in the same way we're already doing it (map state to props in the container components)
A few benefits for this approach
- Reduce code duplication
- It would reduce the size of our reducers and make them easier to read.
- Screen reducers would only need to concern themselves with the UI state and resource reducers would manage data
That being said, the work here is in line with the state management system that is already in place. I just wanted to point this out
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.
@michaelkro thanks for reviewing! I hope you're enjoying your time off.
That's a really good point, and something I considered while implementing this. I didn't go through with it because I thought it would be a huge refactor out of scope of this change (since we already have a bit of this duplication elsewhere), but actually I think it is a really good idea to do that incrementally. I think I'll create a SharedReducer
and start with providers and target compute resources. Thanks for convincing me :)
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.
@michaelkro I did a major refactor to create the new providersReducer
and targetResourcesReducer
based on this advice. I'm curious what you think of this implementation.
class ConversionHostWizardLocationStep extends React.Component { | ||
componentDidMount() { | ||
const { fetchProvidersAction, fetchProvidersUrl } = this.props; | ||
fetchProvidersAction(fetchProvidersUrl); |
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.
Since we're fetching providers on mount, we could use this data to dynamically populate the provider type dropdown with only what is available.
Oh, that makes me think, what happens on the conversion hosts tab if there are no providers? Do we show the provider empty state like in Mappings and Overview?
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.
That's a really good point, I hadn't considered that. I think as implemented, it would just show the conversion hosts empty state and prompt the user to open the conversion host wizard, where the providers dropdown would be empty. That's a case I need to handle.
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.
Also handled this.
...ts/ConversionHostWizard/ConversionHostWizardLocationStep/ConversionHostWizardLocationStep.js
Show resolved
Hide resolved
...ts/ConversionHostWizard/ConversionHostWizardLocationStep/ConversionHostWizardLocationStep.js
Show resolved
Hide resolved
...ts/ConversionHostWizard/ConversionHostWizardLocationStep/ConversionHostWizardLocationStep.js
Show resolved
Hide resolved
...ts/ConversionHostWizard/ConversionHostWizardLocationStep/ConversionHostWizardLocationStep.js
Show resolved
Hide resolved
c608caa
to
b6b46a0
Compare
...reens/App/Settings/screens/ConversionHostsSettings/__tests__/ConversionHostsSettings.test.js
Show resolved
Hide resolved
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 think that introducing the common redux reducers is going to be really valuable moving forward. Really nice job taking this on
Things I tested
- Creating mappings (OSP and RHV)
- Creating plans (OSP and RHV)
- Running RHV migration. Due to our new check that waits for an available conversion host, this test was inconclusive. However, everything up till that point seems ok
- Checked to see that provider type dropdown is only populated with what is available
- Checked to see that provider empty state is shown if available providers are insufficient
- Checked functionality of Wizard Step 1
Looks good to me!
3590834
to
ab27150
Compare
@michaelkro thanks so much! I really appreciate your feedback, and your help moving towards a nicer pattern for the common reducers. Now go relax! |
Conversion Host Configuration Wizard Step #1 (Location), and introducing common reducers (cherry picked from commit a0ee080) https://bugzilla.redhat.com/show_bug.cgi?id=1696423
Hammer backport details:
|
@mturley Can you please review the bakcport of this PR and make necessary changes in a new PR? I skipped renaming of providers.fixtures file as the file doesn't exist in
The conflits backporting this PR were:
|
@simaishi sure, I'll take a look first thing in the morning. |
Part of the Conversion Hosts UI feature BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1693339
This is part of #855.
This PR adds the contents of the Location step (Step 1) of the Configure Conversion Host wizard:
This PR also adds a check for sufficient providers before displaying the Conversion Hosts tab of the settings page, to prevent errors in this wizard step when a user has insufficient providers configured. In this case, the empty state is shown with a button for configuring providers, similar to the Plans and Mappings views:
Since this PR would have otherwise duplicated a bunch of code related to providers and target clusters/projects, I also introduced a new pattern of reducers coupled to API resources rather than to views. We have a good amount of this kind of code duplication elsewhere in the codebase, but that's outside the scope of this PR, so I only created the
providersReducer
and thetargetResourcesReducer
(which so far only handles target clusters). We can move things into common reducers like these incrementally, rather than duplicate code, as the need arises.