What's the best way to contribute to the Material ...

# compose

[Alex]

What's the best way to contribute to the Material Components for Jetpack Compose?

[Adam Powell]

Starting the discussion here is probably a good start. 🙂 What are you looking to contribute?

[Alex]

Right now the OutlinedTextField does not allow changing the border-width in any way (its hardcoded in private vals). In the old xml material components changing the border width this was possible through styling (and our design system uses a different border width). I would like to just create a PR and fix that so that the material team doesn't need to bother. And also I fear that if I don't do it, the fix will probably take a couple of months before it hits any release due to it being a rather obscure thing 😄

[Adam Powell]

Some of the team working on the material library would be better equipped to comment on the design intent of the OutlinedTextField in particular here, but I think the answer is likely to be, "build your own starting from BasicTextField" - we largely consider the broad proliferation of design tweak parameters for Views to have been a mistake, as opposed to layering the system such that these components are easy to fork, tweak, and move on. cc @matvei @Louis Pullen-Freilich [G]

[Adam Powell]

to the extent that such forks pull along a lot of other internal dependencies that also must be forked to accomplish it though, we're definitely open to more discussion on how to make that process easier

[Adam Powell]

or what would need to be opened/structured differently to make it easy

[Louis Pullen-Freilich [G]]

Exactly the above - we expose parameters for customization based on the Material design specification, it is an explicit non-goal to support the customization of every internal design element of a component. As for any other component, the intended pattern is instead to just fork the component, and make the necessary changes.

with that said, text fields are a unique example of a component that are so complicated in nature that forking is uniquely challenging, compared to creating your own Button for example. For text fields specifically, we have future plans to expose a middle layer of building blocks that make it easier to build your own Material-esque text field, without adding more and more parameters to the high level APIs.

[Alex]

What I am kind of missing though is, that this customization was possible via a style when using the xml based implementation of the OutlinedTextField and now it's gone in the compose version.
Adding the ability to change the border width would be as simple as adding another constructor parameter with a default value, in the same way as TextFieldColors are provided already.
I completely understand your point about not wanting to bloat textfields, but completely reimplementing a TextField just to change the border size seems pretty strange to me?
Changing the outline shape was added recently, adding the border width parameter would be the last 5% to have feature parity with the xml based variant.

Heck, it seems like CompositionLocal was meant to be the solution to this.

[Louis Pullen-Freilich [G]]

that this customization was possible via a style when using the xml based implementation of the OutlinedTextField and now it’s gone in the compose version.

Parity between XML / Compose is a non-goal: we aim to implement the Material specification, and customization provided by the spec. Adding customization for things not in the spec makes it hard to reconcile our APIs with spec updates, and it makes it hard for us to define what our components actually support.

I completely understand your point about not wanting to bloat textfields, but completely reimplementing a TextField just to change the border size seems pretty strange to me?

It’s not really about how large the change is - if there is a change from the component we have provided, it is natural to need to build your own. This very quickly devolves into a slippery slope of customization too - if you can change the border width in the public API, then maybe that will work for a while, but what if you then want to also change the border to be dashed, and add a separate internal divider between an icon and the text. At some point you will need to build your own, and if we don’t have the clear line of ‘we support the specification’, then it becomes very hard for developers to reason about what they can expect to do, and also very hard for us to manage feature requests and decide what is reasonable to add. The text field APIs are already some of if not the most complicated Material APIs due to their size, so ensuring they are easy to use and understand for the default cases is also important. On a side note we have received many requests to customize the internal padding, but I believe this is the first request for border width, so this would appear to be lower priority for most developers.

Also as I mentioned previously, we would like for ‘reimplementing a text field’ to be a few lines of intermediary API (similar to other components like if you wanted to build your own Button or Tab), not the large amount of copy and pasting you would need currently. In that case, there really isn’t much cost to building your own version with a different border, most of the challenge here is because of how complicated text fields are, with all their different states and moving internal components.

Changing the outline shape was added recently

This is something explicitly mentioned in the spec - outlined text fields should use a shape from the theme by default, so naturally this should be customized locally too. Border width is fixed and not something that should be customized - it is intrinsic to the component itself.

[Alex]

Thanks for the explanation behind your reasoning! I get your point, although of course this does suck for our company 😬
The easiest solution here for us was to convince the designers to work with a border width of 1dp, which worked in the end.
It really seems like you guys are between a rock and a hard place here. Text Fields are hard (with all the requirements like screen readers and accessibility).

To make my point a little here though: I think adding values that exist internally already to the constructor would make sense, the change is very different from adding different or supporting new features. When using the API it does feel a bit like the API is hiding this value that should be very easy to pass via constructor on purpose and it's hard to see the reason why without your detailed explanation above.

In any case, thank you for working on Jetpack Compose, everyone that I get to try it just loves it. It feels like going from Java to Kotlin but for UI.

[louiscad]

Considering most folks there came from xml to Compose, it's even bigger of a jump!