docs(storybook): update the storybook layout for patternfly-react to mimic Patternfly.org - #342

Pull Request Test Coverage Report for Build 1362

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 74.086%

Totals
Change from base Build 1359:	0.0%
Covered Lines:	1704
Relevant Lines:	2103

💛 - Coveralls

fantastic!!! 👏 👏 👏

I clicked through the stories and the hierarchy looks great. I think it helps simplify the documentation so much more. LGTM

@jgiardino @maryclarke @LHinson @serenamarie125 maybe you have additional thoughts?

no additional thoughts, LGTM

Sorry, I had overwritten my storybook with that from a different PR. What @maryclarke reviewed was likely not the result of this PR.

This PR is now reflected there.

This is great, and lgtm! I just have one question...

Modal currently is grouped under Widgets on pf.org. But in this storybook I see it under Communication as Modal Overlay. Was that intentional?

No. I guess I assumed Modal was under communication along with about modal and did not verify. I can fix that.

Update per comments:

@serenamarie125 @priley86 @maryclarke @jgiardino Could you please take another look?

I see the Modal Overlay is under Widgets now 👍

I also noticed that the first node was relabeled as "patternfly\react-console" and moved to the end. I like having this at the end. I'll defer to others who are more familiar with the monorepo work regarding the label, but when I look at the slides Patrick pulled together, I'm seeing this instead "@patternfly/react-console". Some questions I have are:

• Should it be a forward slash, like "patternfly/react-console"?
• Should we include "@" (or did you remove it for alphabetical sorting reasons?)
• Should the "patternfly-react" node follow a similar syntax (e.g. if we're displaying other packages similar to how they would be written for including in projects, then should we display the core package in the same way)?

Funny you should ask...

If I use forward slash, then all packages become subdirectories. I like them better at the top level.
If I include the @ then the packages will move back above patternfly-react
patternfly-react is not currently scoped as core so it would be inaccurate to display it in the same way.

With the monorepo updates, instead of importing from patternfly-react I would import from @patternfly/react-core or @patternfly/react-console, is that correct?

Since / is affecting storybook (and assuming we don't want to deal with patching storybook to fix that), then would the following labels work:

• Core package: react-core
• Package: react-console
• Package: react-[some other package name here]

This way, the core components are still first, and we are more consistent with the package name in that we include everything as written except @patternfly/.

You still need to import from patternfly-react

yes, apologies for the confusion on this. I was planning to make mention of it next week in the Community meeting. In the breakaway sprint, we discussed just leaving the core package distributed patternfly-react to avoid disrupting downstreams (although we went ahead w/ the monorepo folder structure that would support this). I think it makes sense to keep that package the same until we decide to either A. change the name to something "@patternfly" (such as what you suggest) or B. reserve that name for core PF next components. If we do change the name and require consumers to change the import, the codemod script would help upgrade downstreams automatically (so we just introduced that as an experimental feature right now). Depending on the approach we take though it may make sense to leave it as-is. We weren't sure about this at the time so decided to defer it for now to avoid disruptions...it is quite easy to change though!

Ooooh. My only suggestion is that the nodes in storybook are consistent with the naming consumers would use in the context of their project, to avoid potential confusion. And I think replacing the forward slash with a back slash could be confusing.

Would something like this work?

• Core package
• react-console
• react-[some other package name here]

Any other suggestions?

Also, when I look at the storybook, I no longer see the updates that are shown in Jeff's previous comment.

Sorry @jgiardino working on another story, we need to get storybook deploy to work per branch 😖

@jgiardino I can use that structure. The storybook link should be working correctly now.

@priley86 Does that structure make sense to you?

@jeff-phillips-18 This is what I see. Does that match your latest changes?

I haven't updated to the latest suggestion yet. Coming shortly...

Updated storybook:

I like how you labeled the "react-console (@patternfly)" node.

If other packages start with a letter higher than "p", would they be listed before "patternfly-react"? If so, do you have any thoughts on how to avoid that? The only thing I could think of was to prefix it with "Core package:" but that still leaves packages that start with "a" and "b".

On the other hand, maybe this isn't an issue if the plan is to move off of storybook.

I assume they will all start with react-

I like this approach for now if you are OK w/ it @jeff-phillips-18 and @jgiardino . What I was understanding before was that we'd like to mimic the PF Org website as close as possible for PF3 (like you do here). I agree that the "(@patternfly)" is useful for developers consuming the packages, but probably doesn't mean much to designers or folks just navigating the website. This approach should work fine for sorting purposes and allow us to add the label though.

Maybe when we look at the new site template we can find a way to introduce tags or labels for the respective components/patterns/layouts and their respective package names. I think we should follow PF Next convention as close as possible...

tagging @dmiller9911 and @dgutride for awareness - it looks like #352 is related (and not sure if they have any more suggestions)! This is exciting to be considering this now!

The stable release for the next version of patternfly is end of the year to early next year. I don't think we want to be making assumptions or configuring the current patternfly-react release to something that will be changing over the next 6-8 months.

I assume they will all start with react-

ha ha, yeah, I think you're right. I don't think my brain was fully functional earlier.