Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'Add' from child to parent #18

Open
staltz opened this issue Jun 23, 2016 · 7 comments
Open

'Add' from child to parent #18

staltz opened this issue Jun 23, 2016 · 7 comments

Comments

@staltz
Copy link
Member

staltz commented Jun 23, 2016

Here's a question or something to consider. I was staring at the Collection API and thinking about the 3rd parameter, add$. It assumes the add events are given from the parent to the collection of children. What if a child component has an add button that would create a neighbor on the list? How do we handle that?

Maybe with the handlers/reducer API this would have been simple: just specify the reducer when an event is emitted on item.add$. Perhaps the handler/reducer API could remain as a generic solution? And another thing to consider is a reducerSelector argument:

const parentAdd$ = ......;

const items$ = Collection(Item, sources, function reducerSelector(item) {
  const addReducer$ = xs.merge(
    item.add$.map(......),
    parentAdd$.map(......)
  );
  const removeReducer$ = item.remove$.map(......);
  const reducer$ = xs.merge(addReducer$, removeReducer$);
  return reducer$; 
});

Just exploratory suggestions.

@Widdershin
Copy link
Member

Definitely something worth considering, and the sinks -> stream selector approach has been great so far.

Can you think of an example of a real world application where this functionality might be needed? It's easier to solve problems when they're less abstract.

@Hypnosphi
Copy link
Collaborator

Hypnosphi commented Jun 24, 2016

Maybe even separate addSelector and removeSelector?

const parentAdd$ = ......;

const items$ = Collection(Item, sources, item =>
  xs.merge(
    item.add$,
    parentAdd$
  ), item => item.remove$
});

Then current examples just change to Collection(Item, sources, _ => add$, removeSelector)

@Hypnosphi
Copy link
Collaborator

But the problem here is that we risk to end up merging add$ with itself many times

@Hypnosphi
Copy link
Collaborator

Btw, this assymetry of external adds vs internal removes resembles REST, where POSTs are made on collection's path, and DELETEs on item's

@staltz
Copy link
Member Author

staltz commented Jun 25, 2016

Can you think of an example of a real world application where this functionality might be needed? It's easier to solve problems when they're less abstract.

Any list of stuff where an item has a "duplicate this" button. Seems quite common. :)

Maybe even separate addSelector and removeSelector?

That may work! We could experiment.

@UrKr
Copy link

UrKr commented Sep 28, 2016

Any list of stuff where an item has a "duplicate this" button.

I second this. I currently have a use case for it, where I have a tree structure wherein the branches and leaves can be duplicated.

@Widdershin
Copy link
Member

This can be achieved using imitate.

const duplicateProxy$ = xs.create();
const addClick$ = DOM.select('foo').events('click').mapTo({});

const add$ = xs.merge(
  addClick$,
  duplicateProxy$
);

const items$ = Collection(Item, sources, add$);

const duplicate$ = Collection.merge(item => item.duplicate$);
duplicateProxy$.imitate(duplicate$);

Although, I personally prefer to pull any circular deps into the library itself.

It also seems like this could be supported by allowing a function to be passed in place of add$, like item => xs.merge(item.duplicate$, add$). Similar to removal. This seems like a complex and confusing abstraction though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants