Prioritizing PFE migrations

[bennypowers]

Which elements, and in which order, do we need to port or migrate from PFE?

👉 Issues for migrations/ports should be opened here

What are we doing here?

We want to bring over all the elements from PFE into RHDS. Some of those elements, the ones which are designed upstream in PatternFly, will stay in PFE. In this thread, Let's call those elements PFE 1:1 elements. An example of a PFE 1:1 element is <pfe-button>, because it's design is designed upstream by PatternFly button.

The rest of the elements, those that are not designed upstream. Let's call those RHDS-only elements. We'll remove them from PFE once they are published under @rhds/elements. An example RHDS-only element is <pfe-cta> because it's not designed upstream, it's "root design" is in RHDS.

RHDS-Only Elements

In broad strokes, the RHDS-only elements have to be migrated to this repository. Just like their "root design" is in RHDS, so too their main implementation will be here. Migrating such an element might look something like this:

1. Copy the source files over to the feature branch here
2. Rename the tag and class from <pfe-* and Pfe* to <rh-* and Rh*
3. Either:

• replace pre-existing PFE CSS Custom Properties with conventional RHDS ones, OR
• assign the pre-existing PFE CSS Custom Properties to their RHDS counterparts

PFE 1:1 Elements

These elements have to be ported to this repository. Instead of reimplementing them here, we'll want to install and extend them. Porting such an element might look something like this:

1. Install the associated @patternfly/pfe-* package (if it isn't already installed)
2. Extend the PFE class and give it RHDS naming.
3. Assign RHDS CSS properties (hardcoded as well as custom properties) to the relevant PFE custom properties

The goal of those steps would be to get a functional Red Hat branded and styled element as quickly as possible. Later on, we can go back to the PFE version and adjust it's APIs and designs to suit the original PatternFly design and APIs

Implementation Pre-Reqs

Implied in the above is that RHDS' CSS Custom Property convention has to be decided before any work can proceed, and the specific element ready to port needs it's specific properties defined (i.e. named).

Future Elements

For brand-new elements that we want to create here in RHDS, if the element is defined in PatternFly, we should implement the minimum API surface there first, then "reskin" it for RHDS, per the "PFE 1:1 Elements" workflow above. If the element is not defined by PatternFly, we can go ahead and implement it here right away.

The goal here is to allow RHDS to develop at pace, without diverging widely from PatternFly, which would create undue technical debt in PFE and RHDS both.

cc @markcaron @methomps @marionnegp

[bennypowers]

PFE 2.0 -> latest

Seems to me that once we've done with the work-to-be-prescribed-in-this-thread, that would be the right time to consider exiting pre-release season in pfe, in other words graduating from next dist tag and cutting the real-deal semver major releases for all the pfe packages

[bennypowers]

WDYT @heyMP ? @kylebuch8 ? @zhawkins ?

[bennypowers]

@marionnegp asks:

How can you tell that an element's been designed upstream in PatternFly?

[bennypowers]

if it's listed on https://www.patternfly.org/

[bennypowers]

@marionnegp asks

For an element that's designed upstream like <pfe-button>, does making it a PFE 1:1 element mean that we won't have an <rh-button>?

[bennypowers]

Nope, it means we'll have both a <pfe-button> and an <rh-button>

It also means that we plan to make <pfe-button> look and behave as much like PatternFly's Button as possible, while <rh-button>, though based on <pfe-button>, will ultimately take all it's design from RHDS

[bennypowers]

@zeroedin adds

So all elements right now, will move to RHDS. Some will be deleted from PFE if they don't exist it PF. The ones that do exist in PF will still exist in PFE, and then in RHDS they will extend the class of the PFE element.

[bennypowers]

Should color context be moved over to RHDS? Meaning, should PFE drop support for context, and RHDS adopt it? The reasoning for asking is that context is a PFE-only feature, not mentioned in PFv4.

[zeroedin]

Should color context be moved over to RHDS? Meaning, should PFE drop support for context, and RHDS adopt it? The reasoning for asking is that context is a PFE-only feature, not mentioned in PFv4.

Moving it over to RHDS and removing it from PFE makes the most sense if it's not something in Patternfly.

[bennypowers]

@markcaron and @methomps identified some ambiguity in the New Component and Ready for Development issue template titles.
So perhaps we should rename them to Request a New Design and Design-to-Developer Handoff, so make their purposes crystal clear?

That doesn't solve the "handoff issue form is super intense" problem, for that, designers and developers should just dive in and we'll workshop the experience as we go.

[marionnegp]

If the New Component form is renamed to Request a New Design, will it still serve as a parent issue? I'd be on board with not using it as a parent issue because we won't have to keep the Request a New Design form updated if anything has to change during the dev stage. Can we use milestones to determine what's in design and what's in dev?

[bennypowers]

<pfe-cta> seems like a prime candidate for migration. Lots of pages use it, and it has a simple API.

[methomps]

++ and seeing notes about some issues blocked with this as a predecessor. Example here: #238

[markcaron]

I'd love to tackle CTA next. It's simple and it's widely used. It'd be a good test case too for the red —> blue theming as well.

[bennypowers]

Today I browsed the web pages for PatternFly v4, RHDS and PatternFly Elements to collect information on which components exist in which systems.

In particular, the lists of components which exist in all three systems and the list of components which exist in PFv4 and PFE but not in RHDS are of interest, since we can develop them right away.

We should also carefully read the list of components that ONLY exist in PFE, as they will disappear when PF1:1 is done, unless we find a project to adopt them.

Components Represented in PF, PFE and RHDS

These components are not blocked on questions of ownership, so we can work on them immediately.

• Accordion
• Avatar
• Button
• Card
• Jump Links
• Dialog (Modal)
• Progress Steps
• Tabs

Orphaned PFE components

These components are not (yet) defined or planned in RHDS.

Defined in PFv4

These components we may keep in PFE.

• Badge
• Clipboard
• Dropdown
• Label
• Progress Indicator
• Readtime
• Select
• Toast

PFE-only

These have no representation in RHDS. When removed from PFE, will have no where else to go.

• Collapse
• Datetime
• Health index
• Icon and Icon panel
• Markdown
• Number
• Page Status
• Primary Detail

PFv4-only components

These are PatternFly components which don't exist or aren't planned in RHDS or PFE. We may not prioritize for implementation.

Show list

• Action list
• Alert group
• Application launcher
• Back to top
• Backdrop
• Background image
• Banner
• Brand
• Calendar month
• Checkbox
• Chip
• Chip group
• Code editor
• Context selector
• Data list
• Date picker
• Description list
• Disclosure
• Divider
• Drag and drop
• Drawer
• Dual list selector
• Empty state
• Expandable section
• Filter
• Form control
• Form select
• Helper text
• Hint
• Inline edit
• Input group
• Label group
• List
• Login page
• Masthead
• Menu
• Menu toggle
• Notification badge
• Notification drawer
• Number input
• Options menu
• Overflow menu
• Page
• Panel
• Radio
• Sidebar
• Simple list
• Slider
• Tab content
• Table
• Text
• Text area
• Text input
• Text input group
• Tile
• Time picker
• Title
• Toggle group
• Toolbar
• Tree view
• Truncate
• Wizard

All Components

Which components exist in which system?

• ✅ - Exists
• 📅 - Is Planned
• ❌ - Doesn't Exist

Show Table

Name	PFv4	RHDS	PFE
Accordion	✅	✅	✅
Action list	✅	❌	❌
Alert	✅	✅	❌
Alert group	✅	❌	❌
Announcement	❌	✅	❌
Application launcher	✅	❌	❌
Audio player	❌	❌	❌
Autocomplete	❌	❌	❌
Avatar	✅	✅	✅
Back to top	✅	❌	❌
Backdrop	✅	❌	❌
Background image	✅	❌	❌
Badge	✅	❌	✅
Banner	✅	❌	❌
Brand	✅	❌	❌
Breadcrumb	✅	📅	❌
Button	✅	✅	✅
Calendar Month	✅	❌	❌
Call to action	❌	✅	✅
Card	✅	✅	✅
Checkbox	✅	❌	❌
Chip	✅	❌	❌
Chip group	✅	❌	❌
Clipboard	✅	❌	✅
Code block	✅	📅	✅
Code editor	✅	❌	❌
Collapse	❌	❌	✅
Context selector	✅	❌	❌
Data list	✅	❌	❌
Date picker	✅	❌	❌
Datetime	❌	❌	✅
Description list	✅	❌	❌
Disclosure	✅	❌	❌
Divider	✅	❌	❌
Drag and drop	✅	❌	❌
Drawer	✅	❌	❌
Dropdown	✅	❌	✅
Dual list selector	✅	❌	❌
Empty state	✅	❌	❌
Expandable section	✅	❌	❌
File upload	✅	📅	❌
File upload - multiple	✅	📅	❌
Filter	✅	❌	❌
Footer	❌	✅	❌
Form	✅	✅	❌
Form control	✅	❌	❌
Form select	✅	❌	❌
Health index	❌	❌	✅
Helper text	✅	❌	❌
Hint	✅	❌	❌
Icon	❌	❌	✅
Icon panel	❌	❌	✅
Inline edit	✅	❌	❌
Input group	✅	❌	❌
Jump links	✅	✅	✅
Label	✅	❌	✅
Label group	✅	❌	❌
Link	❌	✅	❌
Link with icon	❌	✅	❌
List	✅	❌	❌
Login page	✅	❌	❌
Markdown	❌	❌	✅
Masthead	✅	❌	❌
Menu	✅	❌	❌
Menu toggle	✅	❌	❌
Modal (Dialog)	✅	✅	✅
Navigation	✅	✅	❌
Notification badge	✅	❌	❌
Notification drawer	✅	❌	❌
Number	❌	❌	✅
Number input	✅	❌	❌
Options menu	✅	❌	❌
Overflow menu	✅	❌	❌
Page	✅	❌	❌
Page status	❌	❌	✅
Pagination	✅	✅	❌
Panel	✅	❌	❌
Popover	✅	✅	❌
Primary Detail	❌	❌	✅
Progress (indicator)	✅	❌	✅
Progress steps	✅	✅	✅
Promo	❌	✅	❌
Quote	❌	✅	❌
Radio	✅	❌	❌
Readtime	❌	❌	✅
Search bar (Search input)	✅	✅	❌
Select	✅	❌	✅
Sidebar	✅	❌	❌
Simple list	✅	❌	❌
Skeleton	✅	📅	❌
Skip navigation (Skip to content)	✅	✅	❌
Slider	✅	❌	❌
Spinner	✅	📅	❌
Sticky card	❌	✅	❌
Sticky banner	❌	✅	❌
Switch	✅	📅	❌
Tab content	✅	❌	❌
Table	✅	❌	❌
Tabs	✅	✅	✅
Text	✅	❌	❌
Text area	✅	❌	❌
Text input	✅	❌	❌
Text input group	✅	❌	❌
Tile	✅	❌	❌
Time picker	✅	❌	❌
Title	✅	❌	❌
Toast	❌	❌	✅
Toggle group	✅	❌	❌
Toolbar	✅	❌	❌
Tooltip	✅	✅	❌
Tree view	✅	❌	❌
Truncate	✅	❌	❌
Video thumbnail	❌	✅	❌
Wizard	✅	❌	❌

[bennypowers]

I think there are three options for those "orphaned" components:

1. Spec them out in RHDS
2. Move them to some outside repo (CP Elements?)
3. Abandon them

[heyMP]

On the table it looks like JumpLinks is checked in the RHDS. That's not the case correct?

[bennypowers]

https://ux.redhat.com/components/jump-links/

notwithstanding we've discussed renaming/changing/splitting-into-two

[heyMP]

@zhawkins we should review these potentially orphaned components to see if they are being used in FTS.

[alazzara]

These are currently being used in one or more of the following webrh, webdrupal, target, and rhdc and need to be migrated:

• pfe-collapse
• Pfe-datetime
• pfe-icon
• pfe-icon-panel (In `raw.tests.json and some .js and .umd files but I don’t seem it in any templates)
• pfe-progress-indicator (product trials in main.bundle.js)
• pfe-readtime
• pfe-table
• pfe-clipboard

[bennypowers]

progress indicator will get a 1:1 treatment and rename to pfe-spinner

pfe-table has been much ballyhoo'd in the past cc @ronniemcbride. I'm optimistic that we can include table in the 1:1 project, but everyone will need to be upfront and proactive in airing their requirements

pfe-icon will get 1:1'd to use font-awesome from pfv4. the rh-icon implementation may change somewhat, it requires discussion cc @heyMP

pfe-clipboard will be renamed to pfe-clipboard-copy