Add send_future_batch to ComponentLink

[hgzimmerman]

Description

I'm submitting a feature request

Similar to send_back_batch which takes a closure that returns a Vec<Msg>, and re-rendering happens if any of these return true as their ShouldRender return value, an async variant of this might be a useful to compliment send_future.

This has the application of someone joining a series of fetch requests together and re-rendering once all of them finish.

I currently have code in my project that looks like this:

    fn mounted(&mut self) -> bool {
        // This will always cause 2 updates to the component.
        let fetch = fetch_to_state_msg(&GetPublicBuckets, Msg::FetchedPublicBuckets);
        self.link.send_future(fetch);

        let fetch = fetch_to_state_msg(&GetParticipatingBuckets, Msg::FetchedUserBuckets);
        self.link.send_future(fetch);

        false
    }

When what I really would like is:

    fn mounted(&mut self) -> bool {
        // This will always cause one update to the component,
        // but all futures need to complete first.
        let fetch = futures::future::join_all(
            fetch_to_state_msg(&GetPublicBuckets, Msg::FetchedPublicBuckets),
            fetch_to_state_msg(&GetParticipatingBuckets, Msg::FetchedUserBuckets)
        );

        self.link.send_future_batch(fetch);

        false
    }

This would allow you to load and display everything at once initially, and then be able to individually reuse each Msg to update parts independently once the component enters its normal update loop.

---

What might be tangentially worth exploring would be a "thunkable" future that you register multiple futures to and after a defined delay after the first future resolves, it will batch any other resolved futures up to that point and send them to the component to be updated at once, doing this until all consumed futures are accounted for.

This could be used to manage fetching 8 things at once, where the first 6 resolve really quickly and can be re-rendered at once, but the remaining 2 take a while to finish. A mechanism like this would allow the developer using Yew to not have to think about the expected fetch timings in order to minimize re-renders, by exchanging 50-100ms of latency to wait for other futures to resolve in that window.

[jstarry]

Thanks @hgzimmerman! This is actually making me realize that we didn't need to add send_back_future to the main framework. It's just a nice wrapper around the existing ComponentLink api. Now that ComponentLink implements Clone, we can just move the link into the future.

What do you think about adding send_future and send_future_batch to a middleware type crate? Maybe add it to yewtil?

[hgzimmerman]

I think that's reasonable.

[hgzimmerman]

I think once a lot of the current Readme's content is moved into external documentation, a section could be added to enumerate related crates to Yew, where yewtil, the router, various templates, along with other supported ecosystem crates people come up with could be featured.

I'll try to migrate current futures functionality to Yewtil in a couple of days, at which point I'll open a PR removing it from this project.

[hgzimmerman]

Actually, I think that a send_self_batch is needed on component link in order to implement the external send_future_batch because access to the underlying scope isn't provided.

[jstarry]

Ah yeah you're totally right, let's add that then!

…

On Mon., Nov. 18, 2019, 3:40 p.m. Henry Zimmerman, ***@***.***> wrote: Actually, I think that a send_self_batch is needed on component link in order to implement the external send_future_batch because access to the underlying scope isn't provided. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#742?email_source=notifications&email_token=AAIGXMIJXWMDUVDIK57PS2LQUL4SVA5CNFSM4JNSBRSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEL2V2Y#issuecomment-555199211>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIGXMNMHCVUZBDPUQ7CAJ3QUL4SVANCNFSM4JNSBRSA> .

[jstarry]

@hgzimmerman can this be closed?

[hgzimmerman]

Yes, this can be closed.