The spec is currently missing a model for dealing with subsequent call to get() (i.e., subsequently calling .get()).
We have two options. A subsequent call to get():
- aborts the current get request (AbortError). New call to get() takes over.
- gets aborted or invalidated (with the respective exceptions). Current call continues until it settles.
Given that we always show UI, the implications of 1 could be annoying to users. It would mean it would that it could be used to serve the same purpose as the abort controller.
Thus, my preference is that we use 2, as it prevents accidental tear down of the presentment UI. Developers can still tear down the UI with the abort controller whenever they choose.
Thoughts?
The spec is currently missing a model for dealing with subsequent call to get() (i.e., subsequently calling
.get()).We have two options. A subsequent call to get():
Given that we always show UI, the implications of 1 could be annoying to users. It would mean it would that it could be used to serve the same purpose as the abort controller.
Thus, my preference is that we use 2, as it prevents accidental tear down of the presentment UI. Developers can still tear down the UI with the abort controller whenever they choose.
Thoughts?