[WIP] Convert advanced-list to use cycle-collections

[Widdershin]

I'm not sure if we should ever merge this, but this is mostly for the sake of discussion and feedback atm.

[Widdershin]

@staltz have a look at the updated version.

I've renamed initialTickers.action$ to tickers.effect$. I thought about tickers.reducer$ but I think a reducer is (state): state but an effect is (state, item, event): state.

I cleared up the rest of the language around reducers. I've also moved the declaration of "child actions" or as I am now thinking of them, "effect handlers" inline to the Collection declaration. I think this improves the clarity of what they're actually doing, but I still wonder if it's too opinionated.

[Widdershin]

Actually thinking about it, tickers.effect$ is actually (state): state, since it's wrapped. Maybe tickers.reducer$ would be clear.

[staltz]

Just to make sure I understood correctly, this remove$ function was named like this to match the remove$ in the child sinks object. Right? So Collection matches those.
And what is the semantics of this? "How to map child sinks to reducers for the parent" ?

[Widdershin]

You're on the money. The reasoning goes a little something like this.

tickers is a collection of Ticker components. It's immutable, because in Cycle values that change are streams.

tickers$ is a stream of tickers, changing over time. It's a common and useful pattern to build that stream by folding over a stream of reducers.

Sometimes a component in a collection needs to send a message to it's parent. The most common example is a remove button. However, taking the sinks of each component, wrapping it with an id and setting up a circular dependency takes a lot of boilerplate and adds a lot of syntactic noise to the application.

Instead we provide sink handlers to Collection, which as you've noted map item sinks into reducers, so that they can be used in the creation of tickers$. Sink handlers are passed (state, item, sinkEvent) but are then wrapped so that they're called as (state) => state. This means the user is saved the trouble of setting up ids or isolation.

[staltz]

Ok, great explanation. 👍

[staltz]

Thanks @Widdershin this is looking good and getting better. I'm still bike-shedding on some details, but that's just a sign that I like what I see so far, and I want to also fully understand the essence of this solution.

[Widdershin]

I've addressed most of your feedback @staltz. Collection is pretty much ready for initial release. Did you want to do that under the @cycle namespace? I'm keen if you are.

I'm just in the process of writing a nice readme.

[staltz]

Great. Here's the repo: https://github.com/cyclejs/collection
You already have write access on it. It would be easy to move (by git pushing) your existing repo because there aren't issues or PRs there to be moved.

Let's start using @cycle/collection in examples and promoting it to the community, but it will probably only become "practically official" once it's documented on cycle.js.org.

👍 Great stuff

[Widdershin]

@staltz awesome, I've pushed up to that repo. How can I publish to @cycle/collection? I don't appear to have permission.

[staltz]

I have to do the first publish, and then I'm able to add you as a contributor and then you'll be able to publish.

[Widdershin]

Okay, well it should be ready to go when you have time to publish.
On 23/05/2016 8:18 PM, "André Staltz" notifications@github.com wrote:

I have to do the first publish, and then I'm able to add you as a
contributor and then you'll be able to publish.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#25 (comment)

[staltz]

https://www.npmjs.com/package/@cycle/collection ;)

[Widdershin]

Awesome, thanks! 😺

[Widdershin]

Closed in favour of #27 as this example is now gone!

[staltz]

Yeah I moved this example as a "test" in cycle DOM, because that's what its purpose has always been. I didn't want people to look at this source code as an "example" of what they should be coding.