Harmonize Collection and Collection.gather

[atomrc]

I am currently re-writing @cycle/collection in typescript (#28). In the process, I am asking myself a few questions about the API design. The main question I have is: do we really have to distinguish Collection and Collection.gather?

They both have different behavior that I don't really understand: Collection.gather will wrap additional sources in streams while Collection won't. Why is that exactly? I find it pretty confusing, even more because those streams are created inside cycle/collection so cannot change over time (except with a shamefullySendNext of course).
In fact, I don't really see any real use cases for the Collection function, most of the time collections are tied to a model that evolves over time (I might be wrong about this!)

My suggestion would be to remove the gather method and make Collection behave like gather. This would induce some breaking changes, but I think we can be smart about default values and try to have the smallest footprint possible.
It might be also time to implement the sort function to be able to reorder items of the collection (#3).

This could be the signature of the new Collection function (actually the same as the gather method):

function Collection(Component, sources, items$, idAttr, transformKey)

This means that the user will have to implement the remove case (by updating the item$ stream) be we would benefit form a simpler API and it would remove the confusion about the add$ https://stackoverflow.com/questions/41910459/in-cycle-js-collections-how-does-the-second-sources-stream-relate-to-the-first/41915677

What do you think? I'd be happy to implement this.

[atomrc]

So looking at staltz/cycle-onionify#28 it seems the collection implementation in onionify will handle all those issues.

I guess @cycle/collection will somehow become obsolete when onionify-collection will be released

[Widdershin]

@atomrc sorry for the lack of response.

I'll copy and paste my response from another issue, since it pretty much sums up what I view as the future of collections:

I remember @Widdershin preferred to keep both Onionify and Collections as two options where users pick what they feel is best. Does that stance remain, now that we have the two things blended?

I feel that onionify and collection address different problems. In past I've said that I view onionify's handling of dynamic lists as being one of its biggest weaknesses.

I very much like the idea of blending them together, and in my mind this would address one of the biggest weaknesses in onionify. A standalone collection library could be useful, but the current collection codebase needs much love.

I also recently read about a philosophy for creating libraries where you create simple, composable primitives as the base of the library. You then create a prebuilt component that addresses 80% of the common use case.

collection was originally a simple primitive one would fold over. We then changed it to be the prebuilt component. I want to see both of these well balanced in a standalone collection library, to allow users simple use and flexibility for more complex problems.

So here's what I would like to see happen:

• onionify meets collection! there is much rejoicing
• onionify continues to have its own implementation of collection
• we rewrite standalone collection with the lessons from the onionify implementation
• onionify can then depend on the nice and shiny standalone library

This road also allows us to enable ongoing innovation instead of putting all of our onions in one basket. Other libraries might spring up and choose to also depend on the standalone collections library.

Source: cyclejs/cyclejs#620 (comment)