webui: port deprecated Wizard component to new PF5 implementation - #5179
webui: port deprecated Wizard component to new PF5 implementation #5179adamkankovsky wants to merge 1 commit into
Conversation
| 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.
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.
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.
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
| id: s.id, | ||
| stepNavItemProps: { id: s.id }, | ||
| ...(s.isExpandable && { isExpandable: true }), | ||
| canJumpTo: canJumpToStep(s.id, currentStepId), |
There was a problem hiding this comment.
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.
rvykydal
left a comment
There was a problem hiding this comment.
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
| 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.
There is no need (it's weird) for this to be state variable. It should just be constant.
const inInstallationProgressStep = path[0] === "installation-progress";
| data: { | ||
| deviceData: storageData.devices, | ||
| diskSelection: storageData.diskSelection, | ||
| requests: storageData.partitioning ? storageData.partitioning.requests : null, |
There was a problem hiding this comment.
Thanks for shorting alphabetically the properties here and in the imports, but please do that in seperate commit if possible for code readability purposes.
| diskSelection: storageData.diskSelection, | ||
| requests: storageData.partitioning ? storageData.partitioning.requests : null, | ||
| language, | ||
| osRelease |
There was a problem hiding this comment.
osRelease here was removed? Is that on the purpose?
There was a problem hiding this comment.
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 steps = createSteps(stepsOrder); | ||
| const steps = createSteps(stepsOrder, componentProps); | ||
|
|
||
| const goToStep = (newStep, prevStep) => { |
There was a problem hiding this comment.
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.
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.
| setNextWaitsConfirmation(false); | ||
| onNext(); | ||
| setInstallationProgress(true); | ||
| window.location.hash = "#/installation-progress"; |
There was a problem hiding this comment.
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ý <akankovs@redhat.com>
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.