`CollectionCoordinatorDelegate`'s background view does not behave as documented

[composed-swift]

`CollectionCoordinatorDelegate`'s background view does not behave as documented

[shaps80]

Perhaps I forgot to 'finish' implementing this correctly. Thanks!

[JosephDuffy]

Perhaps I forgot to 'finish' implementing this correctly. Thanks!

This could be quite useful, maybe with a method of extending it to support other states (e.g. errors). Somehow passing this up from the Sections would be pretty amazing!

[shaps80]

So I agree in having some kind of 'state' so you could support other types of backgrounds, etc...

As for passing up from the section's, that's actually very similar to how the early DataSource's worked if you remember. But because its 'global' we decided it 'felt odd' to do it that way.

If multiple sections have a different opinion on what it should be, how do you resolve that? If you remember our solution back then, was to have a special type called GlobalDataSource which could only be used as a top-level parent. Ensuring it could make those calls decisively.

Anyway, just reflecting on the old days ahahaha!

[JosephDuffy]

As for passing up from the section's, that's actually very similar to how the early DataSource's worked if you remember. But because its 'global' we decided it 'felt odd' to do it that way.

If multiple sections have a different opinion on what it should be, how do you resolve that? If you remember our solution back then, was to have a special type called GlobalDataSource which could only be used as a top-level parent. Ensuring it could make those calls decisively.

I think it would have to be something along the lines of "the first section that provides a background" but there's a similar issue with the FlatSection: which section's header should be used? Maybe this specific example can be worked around by adding extra supplementary views between cells (if that's possible?), but a more library-wide solution to this would also be nice.

Currently FlatSection ignores the headers and footers of its children since there's no obviously good way to handle this using our existing infrastructure.

Perhaps we can open a discussion for this once my time on this project isn't as focussed on performance and correctness.

[shaps80]

Yeah I tend to agree. I'm not sure this is truly 'solvable' btw. If you look at Compositional layouts for example. You can add multiple headers to a single section (they stack) but again there's no meaningful way to associate nested section headers such that they relate to the original content appropriately. Also, the layout would determine how this should be represented, something Composed should never be responsible for.

Thinking about it like that, perhaps the conversation would be how we expose an API that allows you to fetch all headers for a given section and/or its children, so you can make smart choices in your layout?

[JosephDuffy]

Thinking about it like that, perhaps the conversation would be how we expose an API that allows you to fetch all headers for a given section and/or its children, so you can make smart choices in your layout?

Updating header/footers to be an array could be a good option. How does a collection view reference multiple headers for example? I thought they were always at index 0 of the section, can they be at other indexes?

[shaps80]

TLDR

Headers and footers (as a concept) are specific to the layout. They are not 'free' in a custom layout either.

Longer version:

A layout adds attributes for supplementary view types. The concept of a header/footer is more of an API consideration and Visual representation. So Flow Layout for example, exposes dedicated elementKind values for headers and footers for convenience. The collectionView then uses those pre-defined types in those specific layouts, to call the appropriate API instead of the usual supplementaryViewForElementOfKind.

If you checkout the original FlowLayout I made in the Composed org, you can see how I used the same approach to make that API work.

Since compositional layouts are declarative, they allow you to define a stacking order for multiple headers/footers. Internally, it'll just use separate indexes for each I assume, although haven't tested this.

This is kind of why I never wanted to handle this directly (at leasts initially) because each layout is different. So I built-in the most common case (single section, single header, single footer) and then exposed a fallback on the CoordinatorDelegate for those special cases, so a consumer could handle those there (although perhaps not ideal)

[JosephDuffy]

I hadn't thought about multiple headers/footers being usable before but I see what you mean now.

Once you get to the collection view level there are functions purely based on "give me the supplementary view of kind X at index Y". Maybe we can do something similar? Allow sections to provide an array of supplementary views independent of layout and then it's up to the consumer how/if any of these get displayed.

This would provide a solution for the flat sections:

• Section A
  • A:0
  • A:1
• Section B

If section b has a header it can return a supplementary view for index 0 but when flattened it would just be at index 2. Flow layouts would probably just ignore this but another layout could be used to then display the header. I don't see this being a likely scenario (since flattening sections is mainly used for sticky headers) but it's nice to not have to include a bunch of caveats with it.

Hopefully this keeps Composed focussed on the composition of the data while not preventing any kind of layout.

[shaps80]

Yeah I guess that makes sense. The concept of headers and footers is fairly presentational in general if you think about it. Yes, grouping of data isn't unusual, but that doesn't naturally imply a 'view' for repenting a header, even less so a footer.

That being said, I definitely think it has a large enough use-case to warrant consideration.