-
Notifications
You must be signed in to change notification settings - Fork 358
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
webui: port deprecated Wizard component to new PF5 implementation #5179
webui: port deprecated Wizard component to new PF5 implementation #5179
Conversation
// first reset validation state to default | ||
setIsFormValid(false); | ||
} | ||
|
||
// Reset the applied partitioning when going back from review page | ||
if (prevStep.prevId === "installation-review" && newStep.id !== "installation-progress") { | ||
if (prevStep.prevId === "installation-review" && currentStep.id !== "installation-progress") { | ||
setIsInProgress(true); | ||
resetPartitioning() |
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.
Seems that resetPartitioning is not called when moving from installation-review back. Which corresponds with failing TestBasic.testSidebarNavigation.
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.
Ah, you need to replace prevId
with id
(also at the other place).
Apart from that, you just seem to need some updates (rebase) for pixel tests to make them pass.
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.
Ah one more thing probably related also to one of the failing pixel tests: TestStorageMountPoints-testBasic-mount-point-mapping-table. When you go back (either by Back or in sidebar steps, for example to Installation Method
) the next steps (for example Review and Install
) are no more disabled (which they used to be).
It is probably caused by canJumpTo
being removed from WizardStep in PF5
stepNavItemProps: { id: s.id }, | ||
...(s.isExpandable && { isExpandable: true }), | ||
canJumpTo: canJumpToStep(s.id, currentStepId), |
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.
canJumpTo
seems to be removed in PF5, I guess we'll need to use isDisabled instead and the logic used in canJumpToStep
will need to be modified a bit.
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.
Need some update at least due to missing isPrev
and canJumpTo
in PF5. More details inline.
f3e32cc
to
6feda93
Compare
1b1413f
to
be91a7a
Compare
4dbdbc9
to
930c3f3
Compare
@@ -57,6 +55,7 @@ export const AnacondaWizard = ({ dispatch, isBootIso, osRelease, storageData, lo | |||
const [isFormValid, setIsFormValid] = useState(false); | |||
const [stepNotification, setStepNotification] = useState(); | |||
const [isInProgress, setIsInProgress] = useState(false); | |||
const [isInstallationProgress, setInstallationProgress] = useState(false); |
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.
There is no need (it's weird) for this to be state variable. It should just be constant.
const inInstallationProgressStep = path[0] === "installation-progress";
@@ -130,160 +130,143 @@ export const AnacondaWizard = ({ dispatch, isBootIso, osRelease, storageData, lo | |||
data: { | |||
deviceData: storageData.devices, | |||
diskSelection: storageData.diskSelection, | |||
requests: storageData.partitioning ? storageData.partitioning.requests : null, |
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 shorting alphabetically the properties here and in the imports, but please do that in seperate commit if possible for code readability purposes.
language, | ||
osRelease |
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.
osRelease here was removed? Is that on the purpose?
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.
Maybe it's a special commit again, but osRelease is sold by default to every component in componentProps and it was so even in drive, it's unnecessary to have it there twice
|
||
const goToStep = (newStep, prevStep) => { |
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.
Do you mind keeping the variable naming how is was before, just to cause less diff in the commit? Let's limit the commit to the required changes. Any improvements can come if you like in follow up, and be discussed separately.
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.
Yes, it looks quite redundant here, but otherwise usually when I changed variable names, it was in connection with similar implementations in patternfly demos, but I don't know if this was the case.
@@ -200,7 +200,8 @@ export const ReviewConfigurationConfirmModal = ({ idPrefix, onNext, setNextWaits | |||
key="confirm" | |||
onClick={() => { | |||
setNextWaitsConfirmation(false); | |||
onNext(); | |||
setInstallationProgress(true); | |||
window.location.hash = "#/installation-progress"; |
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.
Please use cockpit.location.go instead of writing to the window.location.hash object.
930c3f3
to
cba64f1
Compare
cba64f1
to
7f4ac3c
Compare
@garrett this PR has a design question for you. This in Patternfly is defined as 'progressive steps'. The Patternfly 5 when used with progressive steps, hides all the future steps (which makes sense IMO) whilst Patternfly 4 just disables these, so they can't be accessed from the NAV. The hiding makes sense IMO as the future steps are dependent on the selections inside the previous steps. (See Encryption is available only if mount point assignment is not selected) So, are you ok with introducing this UI change with the PF5 porting, and hide the future steps as seen in the PF5 demo above? |
Being able to figure out where you are in a process and estimate how much longer you have left is one of core functions in a Wizard. According to Nielsen Norman Group (well respected team who have written many of the fundamental books in the realm of software design): https://www.nngroup.com/articles/wizards/ — section "Recommendations for Designing Usable Wizards", subsection 2: "Communicate a clear mental model of the process by displaying a list or a diagram of the steps involved and highlighting the current step. Because the process is presented one step at a time, there is danger that users will miss the context, get confused, or not realize how long the progression will be. It best to set the right expectations and explain to the use what the process looks like and how many steps are involved. Especially with complicated processes, a clear labeling of each of the steps as well as a clear indicator of the current step can help keep users oriented." I would strongly suggest we only using progressive steps in sub-steps, not major steps. Keep the major steps consistent, so there's a goal to work toward. If there's a previous page that nullifies a future page, then drop the future page, but keep other future pages that still apply. That is: Dynamically adjust future pages, if needed. But don't hide all future pages. |
3af3776
to
20d14c3
Compare
Our Wizard is following the progressive steps model, as we can only move forward one step at time. The new PF5 implementation hides the steps that are in the future when the progressive model is chosen, so the only way forward is the 'Next' button. Previously the only difference was that the steps were visible just disabled. Co-authored by: Adam Kaňkovský <[email protected]>
20d14c3
to
8167044
Compare
In the end, the changes were a bit more extensive than I expected, but I tried to keep as much clarity and as much functionality as possible.