feat: add negotiated fulfillment location context - #671
Open
igrigorik wants to merge 1 commit into
Open
Conversation
Store-scoped Catalog results had no advertised way to preserve the Business location through Cart and into Checkout. Defining the field on base Context would make every Shopping implementation accept an opaque Business-scoped identifier without advertising the behavior that produces or consumes it. Have Fulfillment contribute `context.location` to Catalog requests, Cart, and Checkout through explicit parent composition. Cart receives only the location context, and implementations supporting both Catalog and Cart should extend both to preserve continuity. For example, `loc_123` can scope Catalog availability, continue through Cart, and become explicit only when selected as a Checkout destination. Introduce a shared Location Identifier and reuse it for Fulfillment context, Catalog method locations, destination filters, and retail locations. This preserves one identity across surfaces while each containing field defines its role. Keep `selected_destination_id` generic because it may also reference non-location destinations.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR supersedes #642, which identified the need to preserve the Business location behind store-scoped Catalog results through Cart and Checkout. Instead of adding #642's raw
locationfield to base Context, this PR makes support explicit through Fulfillment.context.locationto Fulfillment's Catalog, Cart, and Checkout projections;Adding a Business-defined location ID to base Context would define its syntax without advertising which Businesses recognize it, which operations consume it, or what behavior it affects. Fulfillment owns the relevant surfaces: Catalog methods report resolved locations, Catalog filters name destinations, and Checkout exposes destinations and selections. Contributing
context.locationthrough Fulfillment lets parties negotiate each parent capability withextends.Contract
The same Location Identifier can appear in several fields without giving them the same meaning:
context.locationfilters.fulfills_tovariants[].fulfillment.methods[].locationcontext.location.Journey example...
The new
common/types/location_id.jsonreuses the existing string wire type across Fulfillment context, Catalog method locations, destination filters, and retail locations. Within one Business, the same value identifies the same location; its containing field determines its role.selected_destination_idstays generic because it can select other destination types.Checklist
!for breaking changes).