✨ Add support for a custom style in uiSchema

[justtonytone]

Reasons for making this change

More flexibility to use inline styles. Handles #1200

If this is related to existing tickets, include links to them as well.

Checklist

• I'm updating documentation
  • I've checked the rendering of the Markdown text I've added
• I'm adding or updating code
  • I've added and/or updated tests
  • I've updated docs if needed
  • I've run npm run cs-format on my branch to conform my code to prettier coding style
• I'm adding a new feature
  • I've updated the playground with an example use of the feature

[epicfaace]

Looks good! Can we make style an attribute under ui:options? That way, this change won't impact schemas that already have properties named "style".

[justtonytone]

@epicfaace, that is a good point. I wanted to keep it under uiSchema to keep it consistent with classNames.

Just wanted to make sure I understood your concern. When you say schemas that already have properties named style, do you mean under the properties key? Or do you mean under the uiSchema key?

[epicfaace]

@justtonytone Both. If a schema has a property named style under properties, then its corresponding uiSchema entry will have a property named style under uiSchema.

I think it's unfortunate how classNames was designed, but at least it's been around for a while and so schema creators know not to call a field with key "classNames". At this point, though, adding a styles attribute that is not under ui:options could break existing schemas that already have the property style in them. See #1248 for more problems with namespacing.

[epicfaace]

@justtonytone I'd be glad to merge this PR if you are able to change it so that the style attribute is accepted as follows:

"ui:options": {
    "style": {...}
}

[jaxomlotus]

hi @epicfaace do you have an eta on when this feature might be included? thanks!

[heath-freenome]

Reimplemented in #3378