I want to create a custom layout that places child...

# compose

[ursus]

I want to create a custom layout that places children which fit, and show overflow with number of children in overflow

if overflow size was static its easy

but since overflow width depends on the count, I need to subcompose the overflow multiple times with different data

but subcompose(key) cant be triggered multiple times with same key

can I have multiple keys, like subcompose("overflow-0") ... subcompose("overflow-1") etc? or is that some sort of party foul

[shikasd]

Can you just:

val overflowCount = totalCount - alreadyComposed
subcompose("overflow") { Overflow(overflowCount) }

[shikasd]

Ah, I see, the size depends on the text width

[ursus]

Yes

I worked around it with TextMeasurer and measured as many times as I need and it works

but it works only because in this case the overflow is just text, if it were something else I dont see how to do it? (other than multiple ids)

[shikasd]

Usually we would use intrinsics to measure in these cases I think

[shikasd]

I remember some limitations about intrinsic usage in subcompose layout case though, so it might apply here

[shikasd]

(that's maxIntrinsicWidth and friends)

[ursus]

Hmm I dont follow, so is multiple slot ids okay? Or how else can I subcompose the same slot in the same measure pass?

[shikasd]

Yeah, it is the best solution ig, but I would try to figure out something that does not require that. Hard to tell without product req

[ursus]

Imagine tab row, where only tabs which fit get placed, and if there is overflow the overflow is placed, however the overflow can display a badge, if any of the overtlowing tab data items contain a badge, so it changes widths

So I would measure which tabs fit against total parent width, get overflowing items, and then loop subtracting overflow width based on current overflow count, and append to the overflow list if it doesnt fit.. loop until stable

works well but requires me to subcompose the overflow multiple times because the width can change

[ursus]

so.. do you see some other option?

Currently I just keep a single "probe" overflow, where I assume worst case width = overflow with badge

and run it against that

but there are edge cases where its not precise because yea its oversubtracting always

[shikasd]

Yeah, probably subcomposing to a different slot is the best idea here
Maybe it is worth retaining some state so that updates / remeasures are cheaper tho

[ursus]

just to clarify, this way (remeasuring overflow in a loop) I am adding these nodes to the tree, which is what im trying to avoid with subcomposeLayout in first place right?

[shikasd]

Yeah, but also there's no good alternative for same frame compose - measure loop

[ursus]

our designers broke compose, thats a first 😀

[ursus]

thanks for the info

[shikasd]

I mean knowing exact specs it might be possible to agree on something that works single pass

[shikasd]

But yeah, it kinda does break some things about data flow

[ursus]

not to mention they want me to change the spacing betweem the tabs based on placed count, which ofc again changes what fits 😀