Status Update
Comments
an...@google.com <an...@google.com>
ap...@google.com <ap...@google.com> #2
Hi Nick!
TextField currently have no skinning, borders etc, and it let's the API users (i.e. FilledTextField) to define those. Even though hint (placeholder) is a common TextField feature, material had animations etc on that feature which made us believe that it highly depends on the design system to provide the hint, and foundation should ideally be independent of the design system.
Previously we had only 2 Textfield implementations, 1 on material, 1 in core. If that structured did hold, I would recommend against adding the placeholder to core.TextField. However now we have 3 of them :)
I added nona, matvei and lpf to the ticket to get their opinions.
lo...@gmail.com <lo...@gmail.com> #3
I agree with Siyamed's analysis here, the implementation of a placeholder is evidently something specific to a design system. If you aren't using the Material implementation of a text field, it seems reasonable for you to need to build your own placeholder implementation - I think there is too much complexity and room for customization with transitions etc for it to be possible to build a generic version that is flexible enough to support all use cases.
ch...@google.com <ch...@google.com> #4
Yes, I agree. Maybe we should add a sample to the documentation so that developers have something to begin with when they need to develop their own?
ns...@gmail.com <ns...@gmail.com> #5
Adding a sample makes sense to me. I thought we previously had it but right now I couldn't find it.
Nick does it sound good to you as well?
ch...@google.com <ch...@google.com> #6
I'm not sure I agree that it depends upon design system; I can see many users wanting a simple placeholder that appears when no text is entered and disappears otherwise. Correctly implementing could be complex to correctly synchronize alignment, lines height, cursor etc. I see the benefit of having this in a library function that we can update etc.
Also asking many developers to implement this or directly copy a sample seems to be an indication the we should provide it?
Would we consider a PlaceholderTextField
in foundation?
na...@google.com <na...@google.com> #7
I'm strongly against PlusOneFeature components in foundaiton, so I don't think PlaceholderTextField is a good component to have.
However, Nick's concerns make total sense to me, so I imagine we could end up with some placeholder api in foundation, but I'm not sure what is it now.
Anastasia, let's keep an eye on what we have in MaterialTextFields and maybe it will make sense to extract some placeholder functionality to the foundation version
ns...@gmail.com <ns...@gmail.com> #8
I have ~strong opinions but I agree that we can observe more.
PlaceholderTextField sounds like a good idea, increases the API surface to manage. If we can have TextFieldPlaceholder in a way that you still need to add a TextField inside without carrying all the parameters of TextField, that makes more sense to me.
TextFieldPlaceHolder(placeholder api, content = TextField())
instead of
PlaceHolderTextField(placeholder api, all the TextField arguments...)
Description
After upgrading to compose 1.3.0-beta03, my app started crashing. After investigating the issue, I was able to reproduce it in a minimal example which you can find here:https://github.com/ln-12/compose-1.3.0-crash-example
For me, it is only happening with the
AlertDialog
component.Steps to Reproduce or Code Sample to Reproduce:
produceState
to create a simple state which changesStack trace (if applicable):