IssueTracker

This is probably happening because there are multiple instances of DataStore active. You should consider managing the DataStore as a singleton. See the attached bug for more info.

I'm not sure I understand the use case here - do you have a specific example in mind / some code you can share?

The goal of defaultMinSize is to let a component have a default size that can be overridden and make it smaller - but if no size modifier is supplied it should be at least x size. For the max constraint, if you want this to be overridden then you could just not set a max constraint at all.

Our use case is for components that should not span the full size of a screen (particularly, large screens), however we want users to have the option to override what the maximum width is. For a specific example, we are opinionated on bottom sheets not stretching edge to edge on large screens, with a max with of 640.dp, but for some users, a different maximum size may make more sense. The attached blocking bug has more context on this use case.

Is there a meaningful maximum value a developer would set though? I.e do they explicitly want to set the max to let's say, 800.dp? From the blocking bug it sounds like the developer wants it to take up the full screen width. There wouldn't really be a way to do this with a modifier, at least not semantically, since you would have to set a very large number without knowing screen width, or something hacky like infinite. I think for this specific use case it m akes more sense to have a boolean parameter to control whether we restrict max width or not

My two cents: Why would the user overriding a default max size with an infinite constraint be considered hacky? Constraints.Infinity seems like it was meant for this exact use case. As for the alternative of using a boolean to control this behavior, this would involve 1) changing the API surface, and 2) feels like a bad semantic fit for components that aren't really "layouts" (Edit: "containers") but only care about their maximum size. See the child bug for text fields, for example (b/175670824).

I think there are two (related) things: semantically the user isn't trying to make it literally infinitely sized, they want it to fill the screen size. Setting infinite size also won't work here because the case where there is infinite size is one of the cases where we would want to set the max width - so in the implementation of a theoretical defaultMaxSize modifier you wouldn't be able to disambiguate between the default case (no / infinite constraints), and the case where a user explicitly wants to relax the constraints.

For defaultMinSize the case we look for is if the incoming constraints are 0, and if they are, we apply the default. If a developer tried to do Button(Modifier.size(0.dp)) this would break for the same reason (and also doesn't make much sense) - and this is basically the same case for min as infinite is for max.

I agree that a boolean isn't the neatest way of doing this, but it is semantically fair. Not sure how a text field isn't a layout, a text field having a 'default' max size is explicitly part of the behavior of the component, in the same way it has a height, minimum width, etc. I'm also not sure if there's a way to solve this from the layout system, nor whether there should be: it seems like a pretty explicit layout breaking change to want to go from a max width to filling the screen.

Some context on the FR: The analogous feature can be found in some Views components, with android:maxWidth being an overridable attribute. Additionally, the two current options of either constraining to a non-overridable max width or indefinite spanning within a layout does not seem sufficient for large screen experiences, where many components are agreed to not be functional in full screen, but the actual maximum width may be subjective.

Code sample for a generic use case:

MyBox(modifier = Modifier) { // I want the box to span most small screens, but to be constrained in large screens. Box(modifier.maxWidth(800.dp)…) } User agrees it should be constrained, however their design would prefer 900.dp for large screen.

---

Current Options:

1:

MyBox(modifier = Modifier, maxWidth = 800.dp) { Box(modifier.maxWidth(maxWidth)…) }

Less than ideal pattern because exposing both the modifier and a parameter for the modifier seems unintuitive.

2: Don’t set a maxWidth

Not ideal as our component would by default span the layout based on internal content, bad fullscreen experience.

3:

MyBox(modifier = Modifier, setMaxWidth: Boolean){ val myModifier = if (setMaxWidth) modifier.maxWidth(800.dp) else modifier … }

Similar issue to 1, but at least setting maxWidth to false gives a clean 1:1 relationship for modifier, easier to reason about. However: MyBox(modifier = Modifier.maxWidth(800.dp), setMaxWidth = false) also does not semantically read well.

From the blocking bug it sounds like the developer wants it to take up the full screen width. There wouldn't really be a way to do this with a modifier, at least not semantically, since you would have to set a very large number without knowing screen width, or something hacky like infinite

I think that is a different use case, our use case is being opinionated that a component should never go past a certain size, but are flexible on what that threshold is. Let’s say we have some visual that works up until 800.dp and after becomes warped or other undesired behavior, however the user provides one that works until 900.dp. It’s specific but a use case nonetheless. The goal isn’t to arbitrarily set this to infinity, but another default value.

In writing all this, would an internal logic of:

MyBox(modifier) {
	val myModifier = Modifier.maxWidth(800.dp).then(modifier)
}

Achieve our intended behavior of overriding out max width with a user provided maxWidth?

Discussed offline, for the component use case we discussed that it probably makes sense to explicitly have maxWidth as a parameter, as it is a spec-defined value that should be user-overridable, so having an explicit parameter to control the behaviour of the component in this sense makes sense.

It's not clear to me that having a defaultMaxSize modifier would really help the semantics here, ignoring the implementation challenges of building such a thing, so closing this given we don't really have a compelling use case for this.

In hindsight the naming of defaultMinSize might be confusing here, but I think it's a different and valid use case: increasing the minimum size will change the resultant size for components with a smaller intrinsic size than the min, which is the use case we have in other components: to make sure a button even with small text will always be at least some size. There isn't really a similar use case for the max constraint, if you want to allow the max to be anything, then that's equivalent to not setting a max. If you set a max then the intention is for it explicitly to be that size, allowing the max to be 'overridden' doesn't really work as in most cases it will be override by the layout above it.