You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: