Compose: Add DaxTextField #7247

landomen · 2025-11-28T15:57:07Z

Task/Issue URL: https://app.asana.com/1/137249556945/project/1210594645151737/task/1211659112661196?focus=true

Description

Adds a Compose version of the DaxTextField.

Steps to test this PR

ADS Preview

Go to ADS Preview screen and click on Text Input tab
Check compose versions

UI changes

See ADS Preview screen

landomen · 2025-11-28T15:57:59Z

...design-system/src/main/java/com/duckduckgo/common/ui/compose/textfield/DaxSecureTextField.kt

+ * Figma reference: https://www.figma.com/design/BOHDESHODUXK7wSRNBOHdu/%F0%9F%A4%96-Android-Components?m=auto&node-id=3202-5150
+ */
+@Composable
+fun DaxSecureTextField(


This needs to be a separate composable as it's using a OutlinedSecureTextField underneath instead of the regular OutlinedTextField

landomen · 2025-11-28T16:02:14Z

...ystem/design-system/src/main/java/com/duckduckgo/common/ui/compose/textfield/DaxTextField.kt

+enum class DaxTextFieldLineLimits {
+    /**
+     * The TextField will take up a single line and will scroll horizontally if the text is too long.
+     */
+    SingleLine,
+
+    /**
+     * The TextField will start with a one line height and then expand vertically as needed to accommodate the text.
+     */
+    MultiLine,
+
+    /**
+     * The TextField will always take at least 3 lines of height and then expand vertically as needed based on the input.
+     */
+    Form,
+
+    ;
+
+    /**
+     * Converts this [DaxTextFieldLineLimits] to a [TextFieldLineLimits] used by the underlying TextField.
+     */
+    fun toLineLimits(): TextFieldLineLimits = when (this) {
+        SingleLine -> TextFieldLineLimits.SingleLine
+        MultiLine -> TextFieldLineLimits.MultiLine(minHeightInLines = 1)
+        Form -> TextFieldLineLimits.MultiLine(minHeightInLines = 3)
+    }
+}


I initially had three separate composables that called a base composable underneath: DaxSingleLineTextField, DaxMultiLineTextField and DaxFormTextField. But all three were exactly the same, with same arguments, only difference was what they used for TextFieldLineLimits, so I thought it was clearer this way.
It was also a bit hard to make and maintain the same changes across four composables, as any change to the base one needs to be propagated.

If there is a strong preference towards having separate composables, I can easily split this.

I prefer having one instead, good call!

Another approach with Compose is to define one generic component that will handle for us all the UI customisation and then, propose easy to use variant components for dedicated cases. It depends a lot the experience we want to propose to the team.

@GerardPaligot I agree, that was my initial approach. But there was no difference between the components apart from the number of lines, so the maintenance overhead of having three separate composables vs one argument didn't seem worth it. However, I'm okay with going with separate composables if that is our approach we want to take.

The password text field is a separate composable as it's has a number of differences, including a different base composable.

landomen · 2025-11-28T16:39:43Z

...ystem/design-system/src/main/java/com/duckduckgo/common/ui/compose/textfield/DaxTextField.kt

+ */
+@Composable
+fun DaxTextField(
+    state: TextFieldState,


Decided to go with the state-based text fields as that is the recommended approach. There is a synchronization issue with the old value-based text fields.

malmstein

very nice work, just a couple of nits. I’ll leave it to @mikescamell for the final approval.

malmstein · 2025-11-28T20:13:38Z

...id-design-system/design-system/src/main/java/com/duckduckgo/common/ui/compose/theme/Theme.kt

        window = colorResource(R.color.white),
        destructive = colorResource(R.color.alertRedOnLightDefault),
        lines = colorResource(R.color.black9),
+        borders = colorResource(R.color.black30),


borders is too generic, so far it only applies to the input field. how do you feel about doing inputFieldBorders instead?

My preference is to keep it generic. This list of colors should be enough to build any component that follows ADS. I don't think we should add one-off colors to this. But I don't feel strongly about this, especially since it doesn't seem any other component has borders and uses T-Control/Border-Primary color as it's named in Figma.

One other option is that each component specifies it's own colors. We kinda already do that for the DaxText. So for text field it would be something like:

textField = DuckDuckGoTextFieldColors( text: Color, error: Color, borders: Color, ... )

We could either provide all needed colors or just the ones that are not generic.

What do you think?

It depends a lot on the design spec. This borders is used only in the text field or every time we need to use a border, they'll use the exact same border color?

@GerardPaligot I'm not familiar enough with the ADS to answer that confidently. I didn't see any other references to this color in Figma page for ADS components. For now, the borders is only used by the text field. But keep in mind that the text field is only the second Compose component we have 😅

malmstein · 2025-11-28T20:14:41Z

...ystem/design-system/src/main/java/com/duckduckgo/common/ui/compose/textfield/DaxTextField.kt

+enum class DaxTextFieldLineLimits {
+    /**
+     * The TextField will take up a single line and will scroll horizontally if the text is too long.
+     */
+    SingleLine,
+
+    /**
+     * The TextField will start with a one line height and then expand vertically as needed to accommodate the text.
+     */
+    MultiLine,
+
+    /**
+     * The TextField will always take at least 3 lines of height and then expand vertically as needed based on the input.
+     */
+    Form,
+
+    ;
+
+    /**
+     * Converts this [DaxTextFieldLineLimits] to a [TextFieldLineLimits] used by the underlying TextField.
+     */
+    fun toLineLimits(): TextFieldLineLimits = when (this) {
+        SingleLine -> TextFieldLineLimits.SingleLine
+        MultiLine -> TextFieldLineLimits.MultiLine(minHeightInLines = 1)
+        Form -> TextFieldLineLimits.MultiLine(minHeightInLines = 3)
+    }
+}


I prefer having one instead, good call!

GerardPaligot · 2025-12-02T08:47:06Z

...ystem/design-system/src/main/java/com/duckduckgo/common/ui/compose/textfield/DaxTextField.kt

+fun DaxTextField(
+    state: TextFieldState,
+    modifier: Modifier = Modifier,
+    hint: String? = null,


Warning: We need to take care about the naming here. The Compose TextField has two native parameters: placeholder and label. placeholder is displayed when you click on the text field but the user didn't enter anything yet and label is displayed at the beginning in the text field and is pushed at the top when the user click on the component.

hint seems too vague and according to the Figma specification, it seems that the placeholder isn't documented in our component specification. Maybe we should ask to a designer what they want and impact the api contract here according to their feedback?

@GerardPaligot I'm open to changing the name. I was on the fence between hint and label, but went with hint for two reasons: it's also used in the old DaxTextInput component and combines both label and placeholder since we're not using placeholder.

We're not using the placeholder parameter, but only rely on the label parameter, because it matches how our current View-based TextInput component works. The label is displayed inside the text field when it's empty and not focused, and animates to the top of the text field when it's focused or has text.

GerardPaligot · 2025-12-02T08:55:03Z

...ystem/design-system/src/main/java/com/duckduckgo/common/ui/compose/textfield/DaxTextField.kt

+    keyboardOptions: KeyboardOptions = DaxTextFieldDefaults.TextKeyboardOptions,
+    inputTransformation: InputTransformation? = null,
+    onClick: (() -> Unit)? = null,
+    onFocusChanged: ((Boolean) -> Unit)? = null,


Suggestion: Instead of declaring a callback, maybe we can expose a interactionSource: MutableInteractionSource to observe a focus change on the consumer side (interactionSource.collectIsFocusedAsState())?

@GerardPaligot I like the idea, could you expand a bit more what you had in mind? We're using Modifier.onFocusChanged to observe and dispatch changes and to detect clicks on the text field.

GerardPaligot · 2025-12-02T08:58:43Z

...ystem/design-system/src/main/java/com/duckduckgo/common/ui/compose/textfield/DaxTextField.kt

+    trailingIcon: DaxTextFieldTrailingIcon? = null,
+    keyboardOptions: KeyboardOptions = DaxTextFieldDefaults.TextKeyboardOptions,
+    inputTransformation: InputTransformation? = null,
+    onClick: (() -> Unit)? = null,


Question: It seems that this parameter is used when you click on the text field (L115) and when you click on the trailing icon (L142), can we distinguish these two sub components?

Suggestion: Or do we really need to add this callback on the root component and maybe add an api slot for the trailing icon where we'll declare the callback when we need to observe user click on this sub component? This will allow us to propose an api contract much more cleaner on the text field component and a better responsibility definition for every sub components.

@GerardPaligot Great question! I initially had a composable slot for the trailing icon so consumers could put their own IconButton there as that's the Compose way. However, we would then need to set up lint rules to ensure people are not putting other elements there or using wrong styling. It also puts more burden on the consumers as they need to be aware of what to put in the slot. But I'm open to using that or other approaches if we think it would be better. It depends on what we want to do with our Compose ADS.

I went with a single onClick() callback based on how the old TextInput works. There are four possible options:

there is no icon and text field is not clickable

icon is clickable

text field is clickable

both are clickable
I felt having two separate callbacks could be a bit confusing, but I'm open to changing that.

GerardPaligot · 2025-12-02T09:02:07Z

...ystem/design-system/src/main/java/com/duckduckgo/common/ui/compose/textfield/DaxTextField.kt

+    lineLimits: DaxTextFieldLineLimits = DaxTextFieldLineLimits.MultiLine,
+    enabled: Boolean = true,
+    editable: Boolean = true,
+    clickable: Boolean = false,


Question: enabled, editable and clickable are very confusing and I didn't find a clear design spec about these 3 states. Are they really necessary? 🤔

This was ported from the existing View-Based DaxTextInput to support various different states (like having a non-editable, but enabled and clickable input). Taking a second look I agree it's a bit confusing, especially since enabled for example can be overwritten by editable or clickable. Maybe using an enum could be better? I'm open to suggestions

GerardPaligot · 2025-12-02T09:06:11Z

...ystem/design-system/src/main/java/com/duckduckgo/common/ui/compose/textfield/DaxTextField.kt

+enum class DaxTextFieldLineLimits {
+    /**
+     * The TextField will take up a single line and will scroll horizontally if the text is too long.
+     */
+    SingleLine,
+
+    /**
+     * The TextField will start with a one line height and then expand vertically as needed to accommodate the text.
+     */
+    MultiLine,
+
+    /**
+     * The TextField will always take at least 3 lines of height and then expand vertically as needed based on the input.
+     */
+    Form,
+
+    ;
+
+    /**
+     * Converts this [DaxTextFieldLineLimits] to a [TextFieldLineLimits] used by the underlying TextField.
+     */
+    fun toLineLimits(): TextFieldLineLimits = when (this) {
+        SingleLine -> TextFieldLineLimits.SingleLine
+        MultiLine -> TextFieldLineLimits.MultiLine(minHeightInLines = 1)
+        Form -> TextFieldLineLimits.MultiLine(minHeightInLines = 3)
+    }
+}


Another approach with Compose is to define one generic component that will handle for us all the UI customisation and then, propose easy to use variant components for dedicated cases. It depends a lot the experience we want to propose to the team.

GerardPaligot · 2025-12-02T09:08:59Z

...id-design-system/design-system/src/main/java/com/duckduckgo/common/ui/compose/theme/Theme.kt

        window = colorResource(R.color.white),
        destructive = colorResource(R.color.alertRedOnLightDefault),
        lines = colorResource(R.color.black9),
+        borders = colorResource(R.color.black30),


It depends a lot on the design spec. This borders is used only in the text field or every time we need to use a border, they'll use the exact same border color?

landomen added 6 commits November 19, 2025 18:04

WIP: compose text field

e65570d

Finalize component

e1bc060

Finalize component

0469850

Add previews

b213b35

Revert DaxText change

976db7d

Remove unused color

6f8c59f

landomen requested review from malmstein and mikescamell as code owners November 28, 2025 15:57

landomen commented Nov 28, 2025

View reviewed changes

landomen assigned mikescamell Nov 28, 2025

landomen added 2 commits November 28, 2025 17:05

Fix code formatting

081b402

Fix lint issue

89c6858

landomen commented Nov 28, 2025

View reviewed changes

malmstein reviewed Nov 28, 2025

View reviewed changes

GerardPaligot reviewed Dec 2, 2025

View reviewed changes

Compose: Add DaxTextField #7247

Are you sure you want to change the base?

Compose: Add DaxTextField #7247

Uh oh!

Conversation

landomen commented Nov 28, 2025

Description

Steps to test this PR

UI changes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

malmstein left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GerardPaligot Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GerardPaligot Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

GerardPaligot Dec 2, 2025 •

edited

Loading

GerardPaligot Dec 2, 2025 •

edited

Loading