-
Notifications
You must be signed in to change notification settings - Fork 35
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
feat(commerce): clean up now replaced controllers #3857
Conversation
Pull Request Report PR Title ✅ Title follows the conventional commit spec. Bundle Size
SSR Progress
Detailed logssearch : buildInteractiveResultsearch : buildInteractiveInstantResult search : buildInteractiveRecentResult search : buildInteractiveCitation search : buildGeneratedAnswer recommendation : missing SSR support product-recommendation : missing SSR support product-listing : missing SSR support case-assist : missing SSR support insight : missing SSR support |
Code delete is the best kind of PR to review |
To understand changes this enables, see: - #3854 where the pagination sub-controller is put to use - #3855 where we expose the facet sub-controllers - #3857 where we remove now replaced top-level controllers - #3859 where we expose the breadcrumb manager sub-controller To understand how we came to this solution, see: - #3825 where we tried slicing the pagination as a `Record` - #3800 where we added pagination and sort as sub-controllers ~And see feat-capi-719-sliced-pagination-states...feat-capi-719-sliced-structured-pagination-states for the diff between this approach and the above PR~ [CAPI-719] [CAPI-719]: https://coveord.atlassian.net/browse/CAPI-719?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
@olamothe @louis-bompart @fbeaudoincoveo Some of the changes affect Atomic, and I'm not sure how to resolve them. The atomic commerce pager for example uses the top-level pagination builders which are removed in this PR: ui-kit/packages/atomic/src/components/commerce/atomic-commerce-pager/atomic-commerce-pager.tsx Lines 92 to 94 in d1ee1c3
I'm thinking we should expose the listing/search controller on the commerce bindings directly. Would that be right? |
Yes that could work and IMO it would make sense since you'd build the pagination, sort, and facets from those "parent" controllers... E.g., you'd have: public initialize() {
if (this.bindings.interfaceElement.type === 'product-listing') {
this.pager = this.bindings.productListing.pagination();
} else if (this.bindings.interfaceElement.type === 'search') {
this.pager = this.bindings.search.pagination();
}
} @olamothe what's your take on this? |
Let's do like this: https://github.com/coveo/ui-kit/pull/3895/files#diff-2fa6435e1e9a232914e7a52b08fc3d645170336854aba1f193646e220f23cdafR53-R60 |
@olamothe @fbeaudoincoveo applied that suggestion in d9932b7 |
See
commerce.index.ts
to understand the scope of the changes. We remove top-level pagination, sort and facet generator controllers, in favor of those accessible through sub-controllers.This PR is part of a series of cascading PRs: #3842
CAPI-719