Implement UpdateEl for iterators

[theduke]

I noticed that UpdateEl is not implemented on iterators.

Would be great to add an implementation.
That saves me a annoying collect.

div![
  // Want: 
  items.iter().map(render_item)
  // Required now:
  items.iter().map(render_item).collect::<Vec<_>>()
]

[David-OConnor]

Agree. Expect soon.

[David-OConnor]

I'm not sure if it's possible to differentiate the type of an Iterator. Getting conflicting requirements issues, where the compiler can't tell if we should add Els, Listeners, or text, due to all of them being Iterators.

[MartinKavik]

The only way how I can compile:

fn render_item(number: &i32) -> El<Msg> {
    div![ format!("{}", number) ]
}
fn view(_: &Model) -> El<Msg> {
    let items = vec![1,2,3];
    div![
      items.iter().map(render_item)
    ]
}

Is to implement UpdateEl for Map:

impl<Ms, T, U> UpdateEl<El<Ms>> for std::iter::Map<T, U>
    where
        T: Iterator,
        U: FnMut(T::Item)->El<Ms>
{
    fn update(self, el: &mut El<Ms>) {
        el.children.append(&mut self.collect());
    }
}

But I don't know how to make it more generic, so it's not very useful in the current form.

[MartinKavik]

I've exhausted all my ideas.
@theduke Do you have an advice how to implement it? Otherwise I recommend to close it.

[David-OConnor]

Let's leave open for now. I don't have a fix now, and suspect their may not be one... But this would be a syntax improvent. Maybe some macro magic we haven't thought of?

[MartinKavik]

You motivated me to do some more investigation.

The most generic implementation for iterators I can come up with:

impl<Ms, I, U, F> UpdateEl<El<Ms>> for std::iter::Map<I, F>
    where
        I: Iterator,
        U: UpdateEl<El<Ms>>,
        F: FnMut(I::Item)->U
{
    fn update(self, el: &mut El<Ms>) {
        self.for_each(|item|item.update(el));
    }
}

It let us to use iter().map(f) when f maps to something that implements UpdateEl<El<Ms>>.
So it should cover the most used case when you want to iterate over a list of something from model and render its items.
(I tested it only with some examples so there can be some problems.)

---

I think that we need to wait for specialization:

• RFC: https://github.com/rust-lang/rfcs/blob/master/text/1210-impl-specialization.md
• Forum post + link to example: https://users.rust-lang.org/t/how-to-use-specialization-features/6023

It should resolve conflicting implementations between Iterator and structs which implement Iterator and also allow us to implement UpdateEl for ToString. However I don't know if it allow e.g. to differentiate associated types.

---

Maybe some macro magic we haven't thought of?

I don't know if some macro magic resolves it, but if you feel very adventurous, you can try TypeId or some Any magic with downcast.

[David-OConnor]

Nice! That appears to work on my end for Els. Using map in this way is, I imagine, a common use-case; not having to explicitly use collect is nice, even if it doesn't work for all iterators as originally requested. We can modify to use specialization when it's ready, and keep your implementation for now.

[MartinKavik]

Notes:

• We can probably use the same "trick" like the one in styles! https://github.com/David-OConnor/seed/pull/273/files with traits as a workaround for unstable specialization.
• I have type problems with .map when I was also using itertools. I don't know exact problem (yet).

[MartinKavik]

TODO: Fix commented-out UpdateEl implementation for Filter - https://github.com/seed-rs/seed/blob/master/src/virtual_dom/update_el.rs#L147