Merge Composed, ComposedUI, and ComposedLayouts packages

[composed-swift]

Merge Composed, ComposedUI, and ComposedLayouts packages

[JosephDuffy]

@shaps80 Given the lack of Discussions support on this repo (it looks to be still in beta, requioring 3+ contributors) I've created a Wiki page outlining a potential roadmap for 2.0: https://github.com/composed-swift/Composed/wiki/Version-2-Roadmap

We can't comment on the page itself, but we can both edit it. To try and move this forward shall we try the following?

• Keep all discussions on this repo (e.g. even ComposedUI talks, since as discussed above we will merge them)
• Open new issues to discuss any of the changes we need to discuss
• Create a "Project" in this repo to start tracking tasks for v2.0, v2.1, etc.

I know you've been using SwiftUI more recently so I'm interested in your thoughts for using the data side of Composed with SwiftUI? If we both worked on the data side of it, then I worked on UICollectionView and you on SwiftUI we might find any of the issues that could arise quicker.

[shaps80]

Would break the import yes but I think that's fairly minor. Agreed on all fronts otherwise! The package should be Composed in the end.

I particularly like this as I'm keen to have an almost separate version for iOS 13+ called ComposedUI(since we're dropping the existing package) that will have a SwiftUI familiarity to it. I've managed to get the function builders to work so far, although still a lot of work to be done under-the-hood.

But either way would be happy to free up the name for usage 👍

[shaps80]

Yeah I think that makes sense is certainly an interesting approach. I've actually made some interesting progress on the swift UI style API but as we know it depends on function builders. That's it I'm keen to explore further and see where it might fit because it really does simplify things considerably, but as you highlighted before it is a completely different API

[JosephDuffy]

Yeah I think that makes sense is certainly an interesting approach. I've actually made some interesting progress on the swift UI style API but as we know it depends on function builders. That's it I'm keen to explore further and see where it might fit because it really does simplify things considerably, but as you highlighted before it is a completely different API

I won't start on any of the changes if you're still exploring function builders. The overall goals are probably the same (better update propagation, etc.) but the methods of getting there could be a bit different so I don't want us to end with 2 different implementations that can't coexist.

[shaps80]

Yeah, would be great to hold off a little longer and see how far I can get. I'm making good headway.
That said, I do have an idea for you if you like.

Through my explorations what I'm come to realise more than anything is that in SwiftUI, swapping out different views to represent different bits of data is trivial. In UIKit, we're typically bound by the initial choice (e.g. Collection/Table View)

So what I'm focused on is a function builders approach that accepts data at the callsite. So if you want to work on the data composition, any required mappings improvements, etc... then we shouldn't overlap.

If later we have a SwiftUI API and I need to populate a List with some data, as long as that data can be represented in a ForEach for example then its not an issue, regardless of the actual structure under-the-hood. Similar to how we deal with nested structures > sections right now.

Where I'm most keen for 2.0 to improve is in the following areas:

• I want data composition to be cleaner (more function builder style even if we can't use it) so that its easier to reason about and to test. Writing tests shows how overly-complex this still is. Once you've written your structure, re-reading it back isn't so simple.
• I want a true separation between UI and Data. We've managed to keep these 2 areas fairly separate but only up until the point we hit a collection view for example. My SwiftUI implementation doesn't require anything, no conformances to CollectionProvider etc... at all. I'd love this to someone find its way to UIKit as well if possible.

[shaps80]

So my thinking is that you could spend your time on the data abstractions more purely without worry of overlap @JosephDuffy ?

EDIT: I think a closure-based approach would be preferable if we can get it right. Should require less type-definitions both in the library and from the consumer, but also hopefully be just as composable.

[shaps80]

FYI, my explorations do touch UIKit as well as SwiftUI & Function Builders, so just avoid those for the moment. Your focus should likely be on maintaining iOS 11+ support.

[shaps80]

Just another thought/realisation I've come to. In 1.x we generally handle conditional data at the data layer. SegmentedProvider for example. SwiftUI obviously allows this to exist in separate State, something we can't do.

My point being, I'd like to explore how we could at least remove this kind of thing from Composed, because pushing this downstream allows the consumer to decide how these conditions are set, without having to implement/integrate with Composed infrastructure.

Thoughts @JosephDuffy?

[JosephDuffy]

So my thinking is that you could spend your time on the data abstractions more purely without worry of overlap @JosephDuffy ?

I can start the removal of SectionProviderMapping but need to think out the delegate approach more before starting on it.

Just another thought/realisation I've come to. In 1.x we generally handle conditional data at the data layer. SegmentedProvider for example. SwiftUI obviously allows this to exist in separate State, something we can't do.

My point being, I'd like to explore how we could at least remove this kind of thing from Composed, because pushing this downstream allows the consumer to decide how these conditions are set, without having to implement/integrate with Composed infrastructure.

Thoughts @JosephDuffy?

So the UI layer would decide what's shown? I'm not sure how you'd recreate something like SegmentedSectionProvider when the data is flattened. The data and UI section indexes for example would be different so it becomes quick tricky to do the mappings.

Maybe I'm not really understanding what you're suggesting.

[shaps80]

Yeah to be honest after giving this a lot more thought yesterday I came to a similar place. I think what I was thinking, isn't possible.

[shaps80]

@JosephDuffy so I've had a little more time to ponder on this and I have some thoughts, ideas, questions.

Composed + SwiftUI
So now I've had a little more time to actually integrate Composed with SwiftUI. What I'm realised is that the most useful component is the core library itself, not ComposedUI in particular.

I'm not seeing a tonne of use-case of necessity for including something like SwiftUICoordinator for example. Its a very different beast and I think SwiftUI does a far better job on those abstractions anyway.

That said, it can be useful to use the same data-backing across for example, a UICollectionView and a List. This really helped me do some lightweight migrations where I decided to use SwiftUI for some newer screens and not support those 'features' in older versions at all. There's likely other use cases, but this is something I came across recently.

So my suggest is that we get #15 done to help support collections from Foundation. This should then allow easier use in things like ForEach, allowing our sections to be used in SwiftUI.

We may also want to consider something around Identifiable, as perhaps introducing an identifier on Section's to improve animation handling?

Packages

So I know this ticket is to get all the repos into a single repo. But I don't think from the conversation above we discussed the specifics. So here are my thoughts.

If we still keep separate target's in Package.swift this should allow us to keep the whole import ... while still improving discovery (since Xcode asks which targets you want to add when adding this as a dependency), as well solving the CI issues (I think?).

[JosephDuffy]

Should we go ahead with starting to make these changes then?

So far I've focused on bug and performance fixes but there are some changes like this that make sense to start on.

I don't know if using a beta branch is worth it or if we should just start merging in to master?

[shaps80]

I'm happy with either approach. Kinda leaning towards using beta.

[JosephDuffy]

#22 is pointing to 2.0-beta, which is also what I was leaning towards, especially since there are some bigger breaking changes I've been working on after branching off of merge-all-libraries (namely the flat section).

I'll close this and we can have any further discussion on the PR.