The filter map uses a prioritized structure of top-level objects and nested sub-objects. CCStoreConfiguration
compares the data in the context object to that prioritized structure when locating the key. The following code sample shows the out-of-the-box filter map that Commerce Cloud uses. In it, the filter map sets the priorityList
variable to ["endpoint","page","identifier"]
, meaning that CCStoreConfiguration
will first try to find a top-level object that matches the endpoint in the context object, then it will search inside that object for a matching page object, then it will search inside that object for a matching identifier object.
define( //------------------------------------------------------------------- // DEPENDENCIES //------------------------------------------------------------------- ['ccStoreConfiguration'], //------------------------------------------------------------------- // Module definition //------------------------------------------------------------------- function(CCStoreConfiguration) { 'use strict'; return { onLoad : function() { console.log("Loading Application Level JS"); var priorityList = ["endpoint","page","identifier"]; var newFilterMap = { "getCollection":{ "megaMenuNavigation": {"ccFilterConfigKey": "categoryNavData"}, "categoryNavigation": {"ccFilterConfigKey": "categoryNavData"} }, "listProducts":{ "productListingData": {"ccFilterConfigKey": "PLPData"}, "collectionWidget": {"ccFilterConfigKey": "collectionData"}, "getProductData": {"ccFilterConfigKey": "productData"}, "getProductDataAndRedirect": {"ccFilterConfigKey": "productData"} } }; CCStoreConfiguration.getInstance().updateFiltersToUse(newFilterMap); }, } } );
The top-level objects in the out-of-the-box filter map correspond to endpoints and their sub-objects correspond to identifiers. In other words, getCollection
and listProducts
represent endpoints and their children (megaMenuNavigation
, categoryNavigation
, productListingData
, and so on) represent identifiers. (Note that the getCollection
and listProducts
endpoints return data that is page-independent so, even though the priority list includes page
, page
objects are not defined for these two endpoints in the out-of-the-box filter map.)
To understand how CCStoreConfiguration
compares the contents of a context object to the filter map, we will compare the following context object to the out-of-the-box filter map:
var contextObj = {}; contextObj["endpoint"] = "getCollection"; contextObj["identifier"] = "categoryNavigation";
When considering this context object, CCStoreConfiguration
first looks for a matching endpoint among the top-level objects in the filter map (because endpoint
is first in the priority list). In this case, CCStoreConfiguration
finds the getCollection
top-level object. Next, CCStoreConfiguration
looks for a matching page
sub-object within the getCollection
top-level object (because page
is second in the priority list). The context object does not have page
data, however, so CCStoreConfiguration
moves on to find the next piece of data in the priority list, which is identifier
. The thing to note here is that CCStoreConfiguration
continues to look for the next piece of data in the current object. In other words, it looks for a categoryNavigation
sub-object in the getCollection
top-level object. When CCStoreConfiguration
finds the categoryNavigation
sub-object, it sees that the object has a ccFilterConfigKey
defined for it. CCStoreConfiguration
retrieves this filter key, categoryNavData
, and returns it to the widget.
You can set your priority list and the object structure of your filter map in any way that makes sense for your implementation and then define context objects in your widgets that use that updated structure. However, keep in mind that the out-of-the-box filters, and the widgets that use them, may be affected by changes you make and may need modifications as a result.