Hi guys, is combining `width(IntrinsicSize.Max)` a...
# compose
s
Hi guys, is combining
width(IntrinsicSize.Max)
and
animateContentSize
intended to throw an exception (
Can't represent a size of 2147483647 in Constraints
)? Code in thread
Copy code
@Preview
@Composable
fun TestPreview() {
    Column(modifier = Modifier.width(IntrinsicSize.Max)) {
        TestElem(text = "Short Text", color = Color.LightGray)
        TestElem(text = "Well, a medium Text", color = Color.Yellow)
        TestElem(text = "A very very very very long Text", color = Color.Green)
    }
}

@Composable
fun TestElem(text: String, color: Color) {

    var isExpanded by remember { mutableStateOf(false) }

    Column(modifier = Modifier
        .animateContentSize()
        .fillMaxWidth()
        .background(color)
        .clickable { isExpanded = !isExpanded }
    ) {
        BasicText(text = text)
        if (isExpanded) {
            BasicText(text = "$text 2!")
        }
    }
}
Behaviour without
animateContentSize
:
And without
width(IntrinsicSize.Max)
,
fillMaxWidth()
When using
AnimatedVisibility
instead of
animateContentSize
, it crashes (same error) on collapse
z
That does not look like the message of an intentional exception. I would file a bug (tracker link is in channel topic).
👍 1
s
Alright, thanks
w
Did you figure this out or file a bug? I’m running into the same issue @ste
s
@Walter Berggren Nope! I didn't file a bug nor figure it out unfortunately
👍 1
s
This seems like a problem that still exists. Just experienced it with
AnimatedVisibility
inside a row that has
.height(IntrinsicSize.Min)
. Was there a bug filled back then, or should I just create a new one now?
w
Took a quick glance and I didn’t find any. I think we worked around the issue by using a different kind of animation.
👍 1
s
Doesn't mean it shouldn't be fixed for other users, it feels like a very standard use-case, shouldn't just crash without any hint as to why
w
I agree