feat(wizard): adds the pf wizard and modal components #69

priley86 · 2017-11-11T15:47:32Z

Adds the PatternFly Wizard pattern

Would like to merge #74 (list-group) and #76 (modal) first, and then rebase this.

Storybook:
https://rawgit.com/priley86/patternfly-react/wizard-storybook/index.html

What:
This PR makes several changes:

Adds wizard-pf classes for embedded wizard pattern into pf-react temporarily until they are contributed to PF Core, cc: @jgiardino
Adds ListGroup and ListGroupItem from React Bootstrap. Renames existing ListGroupItem implemented in ListView to ListViewGroupItem, cc: @jtomasek
Adds react-overlay / React Bootstrap Modal. To support React 16 / portals, we must update react-overlays to 0.7.3 (see issue here)
- Reinstalling / updating package-lock also updates Prettier and makes minor change noted in test(ListView): Fix linting errors in ListView #66 , cc: @sharvit
- Noted that react-overlay does not yet support Jest/react-test-renderer. Added upstream issue here
Implements Wizard, WizardSidebar, and related wizard templates.

I am happy to split the bullets above into individual PRs that we can test and release as the community desires.

ohadlevy

I didn't have a lot of time to review - but first glance seems awesome :)

a couple of concerns:

no tests yet (beside snaphosts)
pr is pretty large - maybe easier to get rid of the other stuff in smaller pr's - this will make reviewer life easier.
a lot of custom logic in the components, I wonder in redux land if we would like to use it like that?

thanks!

ohadlevy · 2017-11-11T18:46:18Z

src/Wizard/Wizard.js

+      activeStepIndex: props.initialStepIndex || 0,
+      activeSubStepIndex: props.initialSubStepIndex || 0
+    }
+    this.onSidebarItemClick = this.onSidebarItemClick.bind(this)


maybe use the helper at https://github.com/patternfly/patternfly-react/blob/master/src/common/helpers.js#L2

ohadlevy · 2017-11-11T18:46:32Z

src/Wizard/Wizard.js

+  constructor(props) {
+    super(props)
+    this.state = {
+      activeStepIndex: props.initialStepIndex || 0,


would this work with redux?

ohadlevy · 2017-11-11T19:08:17Z

src/Wizard/Wizard.test.js

+ * react-overlays / Jest opened issue
+ * Open issue: https://github.com/react-bootstrap/react-overlays/issues/225
+ */
+// test('Wizard modal renders properly', () => {


csn use xit instead to comment out the code. (not sure whats better tbh)

It looks like I can remove this test and convert to Enzyme now

jeff-phillips-18 · 2017-11-13T12:29:22Z

less/patternfly-react.less

+      margin-left: 5px;
+    }
+  }
+}


The naming of these should indicate that they are used for embedded wizards. These don't seem to match the embedded wizard designs http://www.patternfly.org/pattern-library/communication/wizard/#/design#embedded-wizard

Sure - am hoping to working thru the CSS contribution into PF Core soon w/ @jgiardino . I will tag you on this!

jeff-phillips-18 · 2017-11-13T12:36:10Z

src/Wizard/Wizard.js

+      }))
+    }
+  }
+


Do the buttons allow for the application to process the click and allow it to stop the navigation should there be an error or if there is a long running task associated with the navigation?

I am working under the assumption that a "higher level" component in an application which is connected to the Redux store would manage this state and feed it down appropriately to these stateless components, so yes!

jeff-phillips-18 · 2017-11-13T12:38:04Z

src/Wizard/WizardSidebar.js

+  return (
+    <ListGroupItem className={classes} listItem {...rest}>
+      <a
+        href="#"


Is it ok to use href="" here to avoid any navigation or browser history changes?

+1, i believe it is.

actually...I believe this is OK as long as the event is handled, i.e. preventDefault()

In OpenShift, they are moving towards replacing anchors with buttons styled with btn-link to provide better accessibility. Is that something we want to consider here (and in general)?

@jeff-phillips-18 i think both are acceptable from what I've seen before. Do you have an example some place? I can try to mimic the anchor with a button and see how it goes...I noted that the ListGroupItem would support buttons.

Aside from saying that semantic html is accessible for free, I'm not aware of any standards that we have. Nor am I aware of what screen readers we should support. For now, I think the best thing we can do is to test using the devices we have access to.
Here is an article in favor of using <button> since accessibility is enabled by default: https://www.deque.com/blog/accessible-aria-buttons/
The article also provides details on how to enable an <a> element to be accessible using additional javascript if we are tied to using <a>.

I believe the ideas is to not require the call to preventDefault and to show the focus border when the item has focus.

I will try the button and see if it impacts styling within the current PF styles for this component...

Ok a quick browser test shows that Buttons do not have styles here.. i.e.: we have styles for:
.wizard-pf-sidebar .list-group-item>a but not: .wizard-pf-sidebar .list-group-item> button it seems.

So are we OK w/ using an <a>, or should we halt until pushing some additional CSS?

Yes, I would continue with using for now. PF core is currently working on a new wizard, so we can switch to that when it's available.

The article I mentioned also talks about what is needed when using <a> instead of <button>, such as using .preventDefault() (although that may not be needed if we using href="" without the #?).

(and I fixed the link to that article that I pasted in my previous comment)

priley86 · 2017-11-13T13:37:45Z

@ohadlevy great questions that I think provide some important discussion points for this repo. Here is my thoughts at this point...

I see a lot of value in focusing our tests at the integration/service layer (and remembering the test pyramid). That being said, we should still do our utmost to ensure all of our simple UI components are well tested. I think Jest snapshots does a great job of ensuring an API surface for UI components. From the Jest docs, it spells that snapshots can be used as a supplement to unit tests, but not replace. From a traditional sense, I think this means we can write less simple unit tests than we did before and reduce the maintenance debt of supporting those tests (as snapshots auto update). However, DOM level testing in React is still very important and provides needs for unit testing in additional areas (using a test renderer like JSDOM/react-test-renderer). From the response on the upstream issue I posted on Modals/Overlays, it looks like this is a perfect candidate for Enzyme. Are we OK with introducing this? What other areas would be suitable for Enzyme tests as opposed to Jest snapshots?
I am happy to reduce this PR. I think this week I will try to open smaller PRs for the following (in this order):

update package.json and add ListGroupItem/ListGroup
add initial Modal component/stories from React Bootstrap
rebase this PR and update Wizard after feedback

I am still trying to get a good idea of the level of state separation we want in this repo. Ideally we can target stateless functional components where possible (as we've done mostly up to this point), but the grey area is the top most component (where simple stateful wrappers can be introduced). I think for this pattern, managing the simple Wizard step state is small enough that it works inside this component and would save overhead downstream (and would still integrate well with Redux as you could initialize the initialStepIndex and the initialSubStepIndex based on a connector component w/ Redux). I took this approach after seeing our ListView state example (for managing list view expanded item), however I am open to changing this to using purely stateless component (and making Wizard a MockWizardManager if we prefer it). It turns out though, managing all UI state in Redux comes at a bit of a cost, albeit small, so we probably just need to get a good policy on this sort of thing... but in most cases, I agree to prefer Redux.

jgiardino · 2017-11-13T21:15:12Z

After reviewing the html/css of the modal wizard, I don't think the embedded wizard is going to be a simple modification to the css of the modal wizard. I created an issue against patternfly to track this work.

jtomasek · 2017-11-14T12:34:43Z

src/ListGroup/ListGroup.js

@@ -0,0 +1,2 @@
+import { ListGroup } from 'react-bootstrap'
+export default ListGroup


IIUC It should be possible to simply just re-export this in src/index.js
export { ListGroup } from 'react-bootstrap'

do we not prefer to break these out into their own individual stories and give PatternFly design examples (like in #74)? I think this is a good discussion point here on what we want to do with these kind of components that we are inheriting/exporting directly. My general thought is that it is good to detail them in stories if we can (and show different use cases that help the downstream consumers), but I'm not opposed to just exporting them.

The PF designers are used to seeing all of the components demo'd like we have in the test pages... thus the question ;)

https://rawgit.com/patternfly/patternfly/master-dist/dist/tests/

I believe this also follows the existing approach with MenuItem so if we change it, we should go back and update it too?

jtomasek · 2017-11-14T12:35:18Z

src/ListGroup/ListGroupItem.js

@@ -0,0 +1,2 @@
+import { ListGroupItem } from 'react-bootstrap'
+export default ListGroupItem


same as above

jtomasek · 2017-11-14T12:35:28Z

src/Modal/Modal.js

@@ -0,0 +1,2 @@
+import { Modal } from 'react-bootstrap'
+export default Modal


same as above

waldenraines

This is looking good so far, looking forward to using this.

waldenraines · 2017-11-30T16:47:39Z

src/Wizard/Wizard.stories.js

+    <Row>
+      <Col sm={12}>
+        <Wizard
+          className="wizard-pf"


Is this something we should default to in the wizard itself?

@waldenraines let me respond to this one after I update the PR later today... and let's see what gives.

jeff-phillips-18 · 2017-12-01T11:37:49Z

Noticed that clicking on the step in the header takes you to the first substep for that step even if you are on a substep of the step. It should not navigate if you are already on one of the substeps of the step.

priley86 · 2017-12-01T13:26:15Z

@jeff-phillips-18 good catch 👍 . Will update this PR today...

priley86 · 2017-12-01T21:05:51Z

i've rebased this component based on #76 (Modal) and updated a few things:

removed state logic from Wizard and moved it into some dummy mockEmbeddedWizardManager and mockWizardManager components. The Wizard is now a simple stateless component. The step state can be better managed in downstream application w/ Redux i.m.h.o.
Update the story source to reflect what was done in feat(modal) - adds the pf modal patterns #76 w/ Modal
fixed issue noted by @jeff-phillips-18 w/ clicking step headers
updated some snapshot tests

In general - I think to keep things moving quickly for now, we can focus on Snapshot tests on our simple stateless functional components here in PF React (the JS APIs have become much more flexible downstream w/ the approach taken here thus far, so the APIs don't have as much interaction state to test in this repo).

thoughts?

jgiardino · 2017-12-01T21:39:20Z

src/Wizard/__mocks__/mockEmbeddedWizardManager.js

+    const { activeStepIndex, activeSubStepIndex } = this.state
+
+    return (
+      <Wizard className="wizard-pf">


Currently, this class wizard-pf sets the width of the wizard to 900px wide, which doesn't make sense for the embedded wizard. Is it possible to remove this class for the embedded wizard storybook example?

OK - after hearing your's and @waldenraines feedback, I am thinking we can have <Wizard embedded> optional boolean prop which tells Wizard what the default class is and feeds down to child components interested. This should get us there...

jgiardino · 2017-12-01T21:54:29Z

src/Wizard/WizardTemplates.js

+  const classes = cx('wizard-pf-header', className)
+  return (
+    <div className={classes} {...rest}>
+      <h4 className="wizard-pf-title">{title}</h4>


What are your thoughts on making minimal class changes to better align the UI with what's shown here: http://www.patternfly.org/pattern-library/communication/wizard/

If it's simple enough to have two variations of the header, one for embedded and one for modal, then here are some changes you could make to get the embedded version closer to the pf design example:

remove the classes wizard-pf-header and wizard-pf-title.

use an <h2> instead of <h4>

With these changes, there will still be a border which isn't included on the design example of the embedded wizard, but I'm not seeing where that's getting applied.

Cool - I'll be happy to review this on Monday w/ you @jgiardino

jgiardino · 2017-12-01T22:09:35Z

I made a few comments about the embedded wizard and some changes that could get it closer to what the design page shows. I know we have an issue in patternfly to provide css for the embedded wizard, but until that's ready, there may be a few more minor adjustments we can make to this implementation to get it even closer than what I suggested above, if that's something you're interested in.

Other than the css, one thing I noticed is that the keyboard navigation could be improved by placing focus in the first field on the form after navigating to a new step. We can always capture that as a future issue if it's not a simple task.

jgiardino · 2017-12-06T15:11:11Z

After reviewing again to see if there are any other changes to better align the embedded wizard with the design documentation, I think the margins would be the only issue that we should try to address. I don't think we should attempt any other layout changes at this time, like layout of the footer actions to left-align them, and instead should wait for the embedded wizard pattern to become available in core patternfly.

However, to fix the margin, I need to see an example of how the embedded wizard would display in the context of an app (e.g. with the masthead and navigation). So that I know if the margin needs to be added to the title or removed from the sidebar. This shouldn't block us from merging, though. I can add this update in a separate PR.

I also created an issue in patternfly to address the lack of indication when a secondary step has focus: patternfly/patternfly#869

priley86 · 2017-12-06T16:03:19Z

thanks @jgiardino @jeff-phillips-18 . I plan to comment out the Embedded story for now and iterate on that pattern as well as the a11y approach in future PRs if that is acceptable. I am finishing up the Wizard Review steps today and would like to consider merging this PR tomorrow after that last update is done.

priley86 · 2017-12-07T05:48:46Z

update: I've added the relevant components for review steps (see step 3a in Storybook now). Commented out embedded example story for now (will follow up on this after PF Core issues resolve).

@jeff-phillips-18 @jgiardino @sharvit @waldenraines what else here?

sharvit

Good job @priley86
Added a few comments

sharvit · 2017-12-07T08:45:35Z

less/patternfly-react.less

+      margin-left: 5px;
+    }
+  }
+}


I think it would be easier to maintain if you separate it into a different file wizard.less

I agree completely... I think after reviewing it again, it is OK to remove that temporary Less for now (as plan is to push it to Core). Will update it...

sharvit · 2017-12-07T08:56:01Z

src/components/Modal/index.js

@@ -0,0 +1,2 @@
+export { default as CustomModalDialog } from './CustomModalDialog';
+export { default as Modal } from './Modal';


I am not sure I get it.

What is the difference between Modal and CustomModalDialog?

What so custom in this modal so it called CustomModalDialog?

Why do consumers need to consume both of them? Can't we have one configurable Modal?

This one is not obvious...

The problem w/ the About Modal pattern I was having was being able to add an additional class to the modal-content div (from Bootstrap). Currently, there is no simple way in the React Bootstrap API it seems other than providing a dialogComponentClass and extending the Dialog. I looked at several issues on this and this seems like the most flexible option...

react-bootstrap/react-bootstrap#1940

I prefer to have a JS API rather than having to carry around additional CSS like that issue suggests.

I also tried a lot of other options, but there is not a clear way with current RB apis. My guess is extending the Dialog like that and providing an additional contentClassName prop to extend the modal-content div with our own classes will be useful. I am exposing CustomModalDialog b/c the About Modal pattern will be common (and maybe there are other scenarios you want to extend modal-content too).

Long story short, I think this is likely a good enhancement upstream if the React Bootstrap team will accept one. This seems the best option for now...

Ok i understand the issue now, thanks!

What about implementing our own Modal component, that will receive some custom props and will render the Modal (with the CustomModal) appropriately?

Maybe even a prop call patternflyModalStyle that will choose between of them (and can support more styles).

I just prefer to consume only one Modal, flexible as possible.

+1 - should be easy enough. I don't think there is any issue w/ always using Custom Dialog but will test it... Custom Dialog will always be more flexible. We can move this to InnerComponents now.

I've made the updates to extend RB Modal w/ CustomDialog by default. This will allow us to always customize the modal-content div or anything else in the Modal Dialog we want.

sharvit · 2017-12-07T09:01:31Z

src/components/Modal/Modal.stories.js

+      </div>
+    ),
+  })(() => <MockAboutModalManager />),
+);


I don't like the fact you are overriding the text, we are losing tons of benefits.
Some times something like this worked for me:

() => MockAboutModalManager()

same in wizards

Nice 👍 ! I will try it. This would be a huge relief...

Any update?

Unfortunately, it works only with stateless components
I guess there is no trivial solution, would be nice if storybook had an option to manually trigger knobs updates.

@sharvit I think this might be something for us to consider in the future... not sure if it helps the React docgen/withInfo content... but it would help make the state more visible.
https://github.com/ndelangen/storybook-state

sharvit · 2017-12-07T13:00:13Z

src/components/Modal/CustomModalDialog.js

+const Size = {
+  LARGE: 'large',
+  SMALL: 'small',
+  XSMALL: 'xsmall',


XSMALL is never used

sharvit · 2017-12-07T13:02:03Z

src/components/Modal/CustomModalDialog.js

+  XSMALL: 'xsmall',
+};
+
+const propTypes = {


Why do wee need to store propTypes as a variable? we never did it till now...

priley86 · 2017-12-08T15:23:29Z

@jeff-phillips-18 @jgiardino last call here (am planning to merge this one soon if we can). I can't think of any more updates right now, but will try to tackle anything else before Monday if needed.

I made notes about the open PF Core issues around a11y and embedded styles. Also planning to circle back later on the new mobile styles. It should be pretty easy to update this component for that later.

patternfly/patternfly#869
patternfly/patternfly#841
patternfly/patternfly#851

jgiardino · 2017-12-08T16:40:54Z

The only issues I see in your implementation is the structure of the ListGroup and ListGroupItem components on the summary. In the runtime html, I'm seeing a structure like this:

<ul class="list-group">
  <li class="list-group-item">
    <a href="#" class="">First Step</a>
    <div class="wizard-pf-review-substeps">
      <ul class="list-group">
        <li class="list-group-item">
          <a href="#" class="">...</a>
          <div class="wizard-pf-review-content"></div>
        </li>
      </ul>
    </div>
    <div class="wizard-pf-review-substeps">
      <ul class="list-group">
        <li class="list-group-item">
          <a href="#" class="">...</a>
          <div class="wizard-pf-review-content"></div>
        </li>
      </ul>
    </div>
  </li>
  <li>...</li>
</ul>

Those two <ul> elements that are nested should be a single element. So where you have this structure:

<div class="wizard-pf-review-substeps"><ul><li>...</li></ul></div>
<div class="wizard-pf-review-substeps"><ul><li>...</li></ul></div>

You should instead have this structure: (plus the classes that you currently have)

<div class="wizard-pf-review-substeps">
  <ul>
    <li>...</li>
    <li>...</li>
  </ul>
</div>

jgiardino · 2017-12-08T16:44:05Z

Other than my comments above, LGTM!

priley86 · 2017-12-08T20:57:23Z

@jeff-phillips-18 @jgiardino thanks for the reviews 👍

We have established a new convention in #95 which has address this.

…ternfly#69)

priley86 mentioned this pull request Nov 11, 2017

Component - Modal Overlay #68

Closed

priley86 requested review from ohadlevy, jtomasek and jgiardino November 11, 2017 15:52

ohadlevy reviewed Nov 11, 2017

View reviewed changes

jeff-phillips-18 reviewed Nov 13, 2017

View reviewed changes

priley86 mentioned this pull request Nov 13, 2017

feat(list-group): adds the pf list-group pattern #74

Merged

jtomasek previously requested changes Nov 14, 2017

View reviewed changes

priley86 mentioned this pull request Nov 15, 2017

feat(modal) - adds the pf modal patterns #76

Merged

waldenraines reviewed Nov 30, 2017

View reviewed changes

priley86 force-pushed the wizard branch from cca8ec8 to 565a06e Compare December 1, 2017 21:02

jgiardino reviewed Dec 1, 2017

View reviewed changes

priley86 force-pushed the wizard branch 5 times, most recently from f3529f7 to f9ba919 Compare December 6, 2017 05:00

jgiardino mentioned this pull request Dec 6, 2017

Wizard: show keyboard focus in the steps patternfly/patternfly-3#869

Closed

priley86 force-pushed the wizard branch 2 times, most recently from 6a7d16f to 3d05f53 Compare December 7, 2017 05:40

sharvit suggested changes Dec 7, 2017

View reviewed changes

sharvit reviewed Dec 7, 2017

View reviewed changes

priley86 mentioned this pull request Dec 7, 2017

Embedded Wizard: HTML/CSS is needed patternfly/patternfly-3#841

Closed

feat(modal): adds the pf modal patterns

9b0f3d9

priley86 force-pushed the wizard branch from 3d05f53 to 32f02ea Compare December 7, 2017 22:26

jeff-phillips-18 approved these changes Dec 8, 2017

View reviewed changes

priley86 force-pushed the wizard branch from 32f02ea to 9201676 Compare December 8, 2017 20:55

priley86 changed the title ~~WIP: feat(wizard): adds the pf wizard and modal components~~ feat(wizard): adds the pf wizard and modal components Dec 8, 2017

feat(wizard): adds the pf wizard and modal components

160bfc8

priley86 force-pushed the wizard branch from 9201676 to 160bfc8 Compare December 8, 2017 21:03

priley86 merged commit 14514f3 into patternfly:master Dec 8, 2017

priley86 mentioned this pull request Dec 8, 2017

Component - Wizard #64

Closed

HarikrishnanBalagopal pushed a commit to HarikrishnanBalagopal/patternfly-react that referenced this pull request Sep 29, 2021

chore(paths): ensure asset paths are relative to the root of app (pat…

4e1ed02

…ternfly#69)

		@@ -0,0 +1,2 @@
		import { ListGroup } from 'react-bootstrap'
		export default ListGroup

		@@ -0,0 +1,2 @@
		import { ListGroupItem } from 'react-bootstrap'
		export default ListGroupItem

		@@ -0,0 +1,2 @@
		import { Modal } from 'react-bootstrap'
		export default Modal

		@@ -0,0 +1,2 @@
		export { default as CustomModalDialog } from './CustomModalDialog';
		export { default as Modal } from './Modal';

feat(wizard): adds the pf wizard and modal components #69

feat(wizard): adds the pf wizard and modal components #69

Conversation

priley86 commented Nov 11, 2017 • edited Loading

ohadlevy left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

priley86 Nov 13, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jgiardino Dec 5, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

priley86 commented Nov 13, 2017 • edited Loading

jgiardino commented Nov 13, 2017

Choose a reason for hiding this comment

priley86 Nov 14, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

waldenraines left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jeff-phillips-18 commented Dec 1, 2017

priley86 commented Dec 1, 2017

priley86 commented Dec 1, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jgiardino Dec 1, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jgiardino commented Dec 1, 2017

jgiardino commented Dec 6, 2017

priley86 commented Dec 6, 2017

priley86 commented Dec 7, 2017 • edited Loading

sharvit left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sharvit Dec 8, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

priley86 commented Dec 8, 2017 • edited Loading

jgiardino commented Dec 8, 2017

jgiardino commented Dec 8, 2017

priley86 commented Dec 8, 2017

priley86 commented Nov 11, 2017 •

edited

Loading

priley86 Nov 13, 2017 •

edited

Loading

jgiardino Dec 5, 2017 •

edited

Loading

priley86 commented Nov 13, 2017 •

edited

Loading

priley86 Nov 14, 2017 •

edited

Loading

priley86 commented Dec 1, 2017 •

edited

Loading

jgiardino Dec 1, 2017 •

edited

Loading

priley86 commented Dec 7, 2017 •

edited

Loading

sharvit Dec 8, 2017 •

edited

Loading

priley86 commented Dec 8, 2017 •

edited

Loading