feat(Content): introduce Content component (replacement for Text)

[adamviktora]

Do not merge this PR, file history is not tracked properly.
NEW PRs:

• part 1:feat(misc): Replace Text, TextContent, TextList and TextListItem with Content - PART 1 #10611
• part2: feat(misc): Replace Text, TextContent, TextList and TextListItem with Content - PART 2 #10643

---

Followup issues:

• Codemod
• org update

Questions:

• Do we need the ContentVariants enum? I lean towards removing it as we use the typescript union type in the component anyways. Codemode-wise it shouldn't be a problem.

[patternfly-build]

Preview: https://patternfly-react-pr-10579.surge.sh

A11y report: https://patternfly-react-pr-10579-a11y.surge.sh

[nicolethoen]

🤔

Creating a new Content component (and the noted follow up issue opened to deprecate the Text component) is raising some :red_flag: for me. Text is the MOST used component from PF according to our analytics. Is there a way we can make this change under the hood without deprecating our most used component?

[wise-king-sullyman]

@nicolethoen we could definitely keep Text around either as-is or as essentially an alternative API for this Content component (which I think would be my preferred route of the two).

That being said we'll be able to handle the Text -> Content changes for consumers via a codemod, so I'm not sure I see the same red flags 🤔 Is the objection just based on consumer familiarity with Text?

[nicolethoen]

I'm primarily concerned that we might be creating a scenario where products are going to need to make possible dozens or hundreds of manual changes to their static text and that will not go over well. If all changes here are non-breaking or something that can be handled completely by codemods, then I'm less concerned.

I dont' think we have the luxury to deprecate the old Text component (move it to a deprecated directory) and expect that they need to make any manual changes to move off of it.

[adamviktora]

It is all fixable via codemods (I forgot to open a codemod issue). We can do this change directly, without deprecating Text, but I think it would be good to keep the Text component on the website and announce "Here is a link to the new Content component".

[wise-king-sullyman]

Looks great!

I love the test suite 🚀 but I do think we should also test that the contentH1, contentP etc classes are all appropriately applied.

Regarding the enum I do know that some consumers prefer having an enum available for that sort of thing instead of passing a string.

[tlabaj]

@adamviktora are you going to open new PR or update this one?

[adamviktora]

@tlabaj I'll update this one, regarding the new tests Austin mentioned. We will see after Office hours today if we have some new feedback - working on the slides now. But about #10580 I plan to do that in a separate PR.

[tlabaj]

@adamviktora I think we should update this PR or open a new on so that it modifies Text rather than introduce a new componet since that is what we are doing.

[mcoker]

LGTM, just one comment around what we chatted about in office hours.

[mcoker]

As discussed in office hours, I would remove this under the assumption that if you want to be able to write plain HTML, you'll need to wrap that markup in <Text>.

I think the idea for an isContentWrapper (or whatever it's called) prop that could be applied to a list, paragraph, etc, is a great idea and would give the functionality that exists in this PR currently, though IMO that could be an enhancement for later. If we add that, I'd like some time to test it and make sure it works as intended.

[adamviktora]

@tlabaj I think I will have to remove Text in a separate PR after the Content goes in. The docs build will always fail, because the pf-docs-framework which is a part of patternfly-org uses a Text component.

So I think it should go in these steps:

1. Create a Content component
2. Create codemod
3. Update patternfly-org to use Content component (probably with that codemod, because there is a ton of places using Text, like the releaseNotes)
4. Remove Text, TextList, TextListItem, TextContent in react

I am starting to be sceptical about the change, and it might waste time and resources for not that big of a reason.

[tlabaj]

@tlabaj I think I will have to remove Text in a separate PR after the Content goes in. The docs build will always fail, because the pf-docs-framework which is a part of patternfly-org uses a Text component.

So I think it should go in these steps:

1. Create a Content component
2. Create codemod
3. Update patternfly-org to use Content component (probably with that codemod, because there is a ton of places using Text, like the releaseNotes)
4. Remove Text, TextList, TextListItem, TextContent in react

I am starting to be sceptical about the change, and it might waste time and resources for not that big of a reason.

Hi. I see what you are saying. The issue with doing it this way is that you loose the history of the Text componet since Content is a brand new componet in source control. I would say we should force merge it and break the build, an then make the update in org. Or we update org first, removing Text then go back and update it once your Pr merges…

[adamviktora]

Closing this PR, because the change will be handled with 2 new PRs: #10611, #10643