Description
@nathanhammond on bluesky suggested that the checkout pattern could be abused for supporting partial records, because you could use a partial and then once mutation is needed rely on the async nature of checkout to inject a request to get the full data for the edit view.
In general this isn't needed because we support partials throughout; however, the idea that "I'm about to edit this resource and thus want to ensure I have the latest copy" is common. In the app I work on, most forms seem to make a reload request for the data about to be edited when rendering the page, in part to ensure certain relationships were fetched and in part just to ensure a clean recent-ish version of the resource.
I'm not sold this is a generally good pattern to encourage, but a beforeCheckout hook and/or giving checkout an API that isn't hidden behind a symbol could enable an app to more universally handle this requirement.
Other motivations for adding this hook include using it as an opportunity to clean or reset the edit state - since edits are preserved - if the app wants to ensure that a checkout always begins from the fresh server-state. This will become more desirable as a feature (I suspect) once we add support for persisting local mutations into the persisted cache.
Metadata
Metadata
Assignees
Type
Projects
Status