-
Notifications
You must be signed in to change notification settings - Fork 7
feat: [SFCC-450] Attribute-sliced indexing model #249
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
base: develop
Are you sure you want to change the base?
Conversation
## What is Changed - Introduced new site preference and record model option
This PR implements Variation Group level indexing for the
`algoliaProductIndex` job.
In this first version, the grouping is done on the `color` attribute
because it's the most common one. We can introduce an option to
configure it if there is a need in the future.
It doesn't rely on SFCC's Variation Groups because they require to
be explicitly defined on products.
The implemented solution uses the variation attributes directly.
### Changes
#### Generation of the records
The main logic lives in the `generateVariationGroupRecords` function:
- For a given `variationAttributeId`, we loop on all the available values
- For each value, we `setSelectedAttributeValue` on the variation model
- We build an Algolia record (`AlgoliaLocalizedProduct`) using this
variation model. The record is similar to a Base-Product record, with
the following exceptions:
- the `variants` array contains only the variant of the selected color
- the `color` attribute is set at the root level
- the `objectID` is `<baseProduct.ID>-<colorAttributeValue.ID>`
The `algoliaProductIndex` job calls this function.
If a product doesn't have a `color` variation attribute, then we generate
variant records, using the existing `generateVariantRecords` helper.
---
SFCC-452
SFCC-453
SFCC-454
This PR implements variation-group level indexing for the `algoliaProductDeltaIndex` job. It uses the `generateVariationGroupRecords` helper introduced in #236 to generate variation-group records for the `color` attribute. If a product doesn't have a `color` variation attribute, then it generates variant records, using the `generateVariantRecords` helper. --- SFCC-453 SFCC-455
Adapt the SFRA frontend configurations to work with the variation-group-level model introduced in #236. **For InstantSearch:** Also use nested facets (`variants.xxx`) when record model is `variation-group-level` **For Autocomplete:** Copy the URL of the default variant at the root of the hits using transformResponse --- SFCC-457
Update our `inventoryUpdate` hook to take into account the `variation-group-level` record model introduced in #236 The main change is in the `createProductConfig` logic where we set the current variation attribute value to the base product variation model, to be able to rebuild the whole `variants` list. The rest is similar to how Base products are handled. --- SFCC-456
… don't have the specified variation attribute (#240) The original intention was to fall back to one variation per record for masters that don't have the specified variation attribute (currently "color" is hardcoded, will be changed later). This creates inconsistencies -- falling back to a record of the same shape as the variation group-level records is a better fit, this PR aims to do that. Features: - masters whose variants that can't be grouped by the specified variation attribute are now indexed as masters, with the `variants` array containing all its variants - updated `algoliaProductIndex.js` - updated `algoliaProductDeltaIndex.js` - records have the same shape no matter which job creates them (tested), variant deletion and record deletion also work with the delta job if any variant or all variants go out of stock, respectively (also tested), going back into stock when there's stock also works (tested). - the variation group-level records originally had a `color` attribute hoisted up to root level. If we make the variation attribute configurable in a subsequent PR, this is going to cause inconsistencies and confusion, moved it back to the variants in the `variants` array. - added a lot of explanatory comments to the job flows so that they're easier to follow and understand
…_LEVEL record model (#242) In order to stay consistent with masters and records grouped by a variation attribute, simple products now have a `variants` array when using the `VARIATION_GROUP_LEVEL` record model, just like masters do. The `variants` array contains the same attributes that a master's variant would have. This change was required in order for the general shape of the records to be the same and to make faceting work with both masters and simple products alike. * updated `algoliaProductIndex.js` job script to handle simple products * updated `algoliaProductDeltaIndex.js` job script to handle simple products * updated `algoliaLocalizedProduct.js` with the new model * created new helper method `isSimpleProduct` in `jobHelper.js` * updated the frontend Algolia component to handle the changes * created new unit tests and updated existing ones * updated JSDoc for some methods * added more explanatory comments to existing logic
General code improvements - added / clarified comments - added JSDoc where missing, updated existing ones with proper data types - changed to getters instead of accessing SFCC object properties directly - whitespace changes to make the code more readable - changed occurrences of `Id` to `ID` as per SFCC naming conventions
…ster-level (#244) Renamed variation-group-level to attribute-sliced master-level in order to suggest that the feature is based on SFCC variation groups or that SFCC variation groups have to be created in BM explicitly in order for the feature to work. Additional changes: - refactored the Algolia BM module's ISML template to avoid code duplication - reworked Algolia BM module tooltips for the Record model selector - additional whitespace, spelling and various other small fixes.
…the Algolia BM module (#245) Created new site preference `AttributeSlicedRecordModel_GroupingAttribute` which takes the place of the hardcoded 'color' value for the grouping variation attribute for the "Attribute-sliced" record model. The Algolia BM module was updated in such a way that the value of the new site preference is only editable if the user selectes the "Attribute-sliced" record model. The code throws an error and returns if the user selected the "Attribute-sliced" record model but haven't set `AttributeSlicedRecordModel_GroupingAttribute` as well. <img width="505" height="138" alt="image" src="https://github.com/user-attachments/assets/4c089ecf-e019-4be1-8953-e1caaae6b24e" /> <img width="505" height="138" alt="image" src="https://github.com/user-attachments/assets/c979d9f5-9d11-468c-acae-b3c11eeda932" /> #### **Testing notes** - In order to test, import `system-objecttype-extensions.xml` first! - the chosen variation attribute needs to be a proper variation attribute, not just any attribute, otherwise `variationModel.getProductVariationAttribute('<attribute>')` won't return anything and indexing falls back to the master-type record (all variations in the same record). - testing with 'size', the variants are grouped by size, storing the different color variations for a specific size in the same record. In order to make use of other variation attributes, the user will need to define their desired variation attribute in BM and creating variants for that variation attribute before using one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| attributeSlicedRecords.forEach(function (record) { | ||
| if (INDEX_OUT_OF_STOCK || (record.variants && (record.variants.length > 0))) { | ||
| processedVariantsToSend += record.variants.length; | ||
| algoliaOperations.push( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Guard delta attribute-sliced count when variants absent
In the delta indexer’s attribute-sliced branch, when Algolia_IndexOutOfStock is true the code unconditionally does processedVariantsToSend += record.variants.length inside the INDEX_OUT_OF_STOCK || … condition. If a custom variation group record has no variants array (e.g., all variants filtered out but still indexed because IndexOutOfStock is enabled), this line will throw Cannot read property 'length' of undefined, aborting the job before any operations are sent. The count should be guarded (as in the full reindexer) or default to 0 when record.variants is missing.
Useful? React with 👍 / 👎.
This is the main PR for the Attribute-sliced indexing model. It consists of the following: