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

Async combinators for capabilities #91

Closed
lvrg-acc opened this issue Apr 3, 2023 · 2 comments
Closed

Async combinators for capabilities #91

lvrg-acc opened this issue Apr 3, 2023 · 2 comments

Comments

@lvrg-acc
Copy link

lvrg-acc commented Apr 3, 2023

Sometimes, it's necessary to request multiple APIs to display something on the screen. For instance:

cap.http(STORIES, Event::Stories)
cap.http(FEED, Event::Feed)

However, we need to ensure that nothing is displayed until both results are returned. There are two main reasons for this: data consistency and rendering efficiency. Data consistency ensures that we display a complete view of the screen, without jumping between different states. Rendering efficiency is important because we don't want to re-render the screen twice.

I don't know how to address this, but probably we need something like combinators that allow us to express concurrent capabilities. An example of this would be:

cap.join!(cap.http(STORIES), cap.http(FEED), Event::StoriesAndFeed)

Edit: As @charypar pointed, we can avoid emitting render in the "mid-state", until both tasks are completed. On the other hand, this may lead to conditional rendering inside n calls, so perhaps it's better should be phrased as an ergonomic problem, not rendering problem.

@charypar
Copy link
Member

charypar commented Apr 3, 2023

Yes, some level of effect combinators would be useful and we need to look at how that might work.

Until then you can solve your situation by keeping track of the state of the requests in the app, updating your model as they arrive, and only calling the render capability when both feed and stories have completed. (The other option is having a slightly more inteligent view implementation that knows not to display anything until both feed and stories are available.)

I do agree that both of those solutions feel a litte bit like workarounds, and will probably get out of hand in a larger app.

As a note to our future selves: it seems like one approach could be to allow layering of capabilities, such that one capability could call another to produce the other capability's effect. Then the parent capability could use the async runtime to orchestrate across multiple effects, even across different capabilities. The flip side is that it would move some of what is arguably application logic into the capabiliites.

@charypar
Copy link
Member

This has been released in crux_core-0.7.2.

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

No branches or pull requests

2 participants