One Off the Slack: TextField and Names

Jan Skrasek asked:

Is there any issue/”initiative” to decompose TextField? Such simple thing as setting a background color seems quite impossible. (outline api doesn’t provide bg color property, filled text field applies 0.12% transparency on the passed value…) All building blocks are internal/private

The core problem is that TextField() is a part of the Material Design set of composables, whereas BaseTextField() is the non-Material basis for text entry. Or, as Google’s Ian Lake put it:

I mean, a Material TextField is a very, very specific thing with defined styles from the Material spec. BaseTextField is indeed the non-private building block you’d want to build your own custom styling on top of. Maybe also consider creating issues about what made it difficult to use BastTextField if you want a non-material style

Zhelyazko Atanasov then hit on the core problem: people not realizing that BaseTextField() exists and that TextField() represents a materialized approach:

It’s a bit confusing having a specific implementation of a component (the Material implementation) named after the generic component - TextField, while the barebone, non-specific implementation is BaseTextField. Wouldn’t it be better to rename:

or similar.

Louis noted that Compose UI used to work that way:

That used to be the case, but then we heard the opposite feedback - developers would intuitively reach for TextField first, and be confused because it has no opinionated UX or styling, and requires a lot of work to look like a Material TextField. The current rename was to point developers to the opinionated component first, as this is usually the desired component.

And, as Andrey Mischenko pointed out, the problem is prior solutions getting a bit too cute:

I think a part of expectations that TextField is styled as material design component comes from current situation with Android views, when material library replaces standard views during inflation of layout (edited)

This always worried me with the approach taken by AppCompat and similar libraries. XML elements in layout resources are supposed to indicate the Java class that is the implementation of the View or ViewGroup. AppCompat changes that, swapping in its own classes for the ones declared in the layout. This made AppCompat adoption easier, at the cost of causing some developers to not realize that AppCompat’s widgets were not the same as the framework’s widgets.

This sort of thing could be handled somewhat in documentation, such as mentioning BaseTextField() in the KDocs for TextField().

Read the original thread in the kotlinlang Slack workspace. Not a member? Join that Slack workspace here!