endpoints
section in the navigation has, though.Depict Search and PLP is provided through a number of API endpoints:
Search and PLP have very similar functionality, which means that the API for Search Results and Category Listings are very similar.
Ignoring everything besides the result page, the flow looks like this:
Depending on merchant configuration, different sort modes might or might not be available. The default mode relevance is always available.
Which filters are available depends on the merchant configuration so need to be handled dynamically. Depending on the setup different filters might be available for a subset of product attributes are.
There are currently three types of filters:
The base filter structure looks like this:
When a user have interacted with a filter it should be included in the filters
array of a new SearchRequest
. When doing so, field
, data
and op
are what’s mandatory to include for every filter object. data
is the field where the current state should be stored.
For this filter data
is an array containing the range selected, in the format [min, max]
.
The type of the filter represents the UI behaviour. In a radio filter only one value can be selected at a time, where in a checkbox filter multiple values can be selected. A checkbox-grid
works the same as a checkbox filter, but the UI should be more compact by being formatted as a grid instead of a list. checkbox-grid
is usually used for sizes of clothes, where there are many options available.
For this filter data
should be a list containing the selected values.
The data represents a tree of values, some of which might be selected. Note that if a parent is selected all children must also be selected.
Here’s an example of a category tree where the user has clicked on Shirts and Jeans:
The corresponding data
is a list of lists representing the path of the selected nodes, like this:
endpoints
section in the navigation has, though.Depict Search and PLP is provided through a number of API endpoints:
Search and PLP have very similar functionality, which means that the API for Search Results and Category Listings are very similar.
Ignoring everything besides the result page, the flow looks like this:
Depending on merchant configuration, different sort modes might or might not be available. The default mode relevance is always available.
Which filters are available depends on the merchant configuration so need to be handled dynamically. Depending on the setup different filters might be available for a subset of product attributes are.
There are currently three types of filters:
The base filter structure looks like this:
When a user have interacted with a filter it should be included in the filters
array of a new SearchRequest
. When doing so, field
, data
and op
are what’s mandatory to include for every filter object. data
is the field where the current state should be stored.
For this filter data
is an array containing the range selected, in the format [min, max]
.
The type of the filter represents the UI behaviour. In a radio filter only one value can be selected at a time, where in a checkbox filter multiple values can be selected. A checkbox-grid
works the same as a checkbox filter, but the UI should be more compact by being formatted as a grid instead of a list. checkbox-grid
is usually used for sizes of clothes, where there are many options available.
For this filter data
should be a list containing the selected values.
The data represents a tree of values, some of which might be selected. Note that if a parent is selected all children must also be selected.
Here’s an example of a category tree where the user has clicked on Shirts and Jeans:
The corresponding data
is a list of lists representing the path of the selected nodes, like this: