feat: allow custom help text class

[petermakowski]

Done

• allow custom help text class

QA

Storybook

To see rendered examples of all react-components, run:

yarn start

QA in your project

from react-components run:

yarn build
npm pack

Install the resulting tarball in your project with:

yarn add <path-to-tarball>

QA steps

• Steps for QA.

Fixes

Fixes: #760

[webteam-app]

Demo starting at https://react-components-761.demos.haus

[bartaz]

I guess would be good to have some convention for adding those child class names, I think some other components do it as well (don't remember which one).

Not sure how detailed or strict we want to be on which elements have configurable class name and which don't. But at least some prop naming convention would be good.

elementClassName seems fine for start (and consistency with default className.

[petermakowski]

Agreed that this is needed (and I like your suggested naming convention).

I think we should have a common way of translating base/modifier classes that exist in vanilla to props in react-components as well, e.g. the help prop in Input should probably be named formHelpText instead to match p-form-help-text from Vanilla. There are many examples for inconsistencies like that.

This would make working with react-components more intuitive for people who are already familiar with the vanilla framework (and vice-versa).

If we agree on a naming convention it might be worth updating all components props at some point even though there will be breaking changes.

[petermakowski]

I created an issue for this #762

[petermakowski]

Considering that the related element in vanilla has a base class p-form-help-text, would you consider a name of the element to be formHelpText? That would result in formHelpTextClassName instead of helpClassName.

A bit lengthy, but I don't think that matters - having prop names that are long but consistent is much better than having props that are shorter but different in vanilla and react-components.

[bartaz]

Unfortunately form components in Vanilla have very inconsistent and lengthy names. There is no "p-form", but we do have "p-form-others"… and there are more issues like that, so forms are definitely not something we should base the naming convention on 😆

[petermakowski]

Okay, should we go with my initial suggestion (helpClassName) then? It's consistent with the related help prop that already exists on this component.

[Caleb-Ellis]

LGTM! I think it's good that its consistent with the current help prop and we can define a better naming convention later on