Harmonize Collection and Collection.gather
atomrc opened this issue · 2 comments
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.
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
@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)