Building a Purple Experience
Components
Search Component
11 min
this documentation provides a guide to the structure, functionality, and configuration of a search page in the purple experience for your purple app and/or website it also provides some details on how to configure the display of search results, navigation, or access fallback basic structure of a search page search field component publication type toggle list ( search results ) search field component the ' search field' component is the actual text box where the user enters the text search is handled by an api that accepts a search term and returns results there is an accessible search icon to trigger search and an "x" button to clear the input field a search box, which can be included on pages, allows users to search for specific content when the user confirms the search, a query parameter (default is 'phrase') is added to the url containing the searched text the search phrase is retrievable by default via $context phrase the query parameter from the url is available in the context, so $context phrase gets replaced with the searched phrase after the user has entered something into the search bar and pressed 'search' limits currently it's not possible to specify what fields are searched in the experience no type ahead possible search field component in views json basic configuration options param (optional string) as stated above, the param defaults to “phrase” it can be configured to be any string you like, ie , if you set it to “q”, your url will be appended with ?q=searchterm path (optional string) this is the page the user should be taken to after performing a search if you set a path, the app will go to that page and include the search in the url if you don’t set a path, it stays on the current page and just updates the url’s query parameters example setting path to “/search” results in a url like /search?phrase=searchterm label (optional string) if provided, this text will appear as an html label around the search input it helps with accessibility and makes it clear what the input is for params (optional object) extra query parameters that should be added to the url when a search happens these are combined with whatever is already in the url example { category 'products', sort 'date' } publicationtype (optional kiosk/channel) this allows you to limit search results to a certain type of publication it is passed along like any other filter or query parameter suggestions (optional object with a url property) this enables search suggestions while typing the app will send a request to the given url with the current search text, and the server should return a list of suggestions example { url '/api/search suggestions' } placeholder text (placeholder) defines the text displayed inside the search field when it is empty if not set, the system uses the default “search…” text based on the site language you may override this with custom text such as “what are you looking for?” or “search products…” publication type toggle the ' publication type toggle' component is where you can filter by which publication type you want to search this can later be used to filter the results or display the correct views based on the type the selection is accessible via $context publication type publication type toggle in views json list (accessing search results) the ' list' component is where the search results will be displayed for that, you are required to set the content to searchresult and the datasource to searchresultdatasource you can additionally show an individual styled search result for issues, posts and bundles by adding multiple views and use conditions bundles and dossiers are currently not fully supported, and we are still in the process of migrating the ' searchresult' component to fully support those the ' searchresult' component has a lot of customization options which are documented here https //gitlab sprylab com/purple/purple web/ /blob/develop/projects/storefront/src/app/component/issue search result/issue search results config ts here is an example setup example setup for the list component conditionals you can use conditions to conditionally show components like 'no search results' or 'please enter a search phrase' or to display search results differently based on publication type here you can see an example some more examples are listed after the screenshot 'no search' example for a condition search header conditional examples not searched { "value" "$context phrase", "operation" "not set" } search title { "value" "$context phrase", "operation" "not empty" } search results conditional examples search results (news) { "and" \[ { "value" "$context phrase", "operation" "not empty" }, { "value" "$context publication type", "comparevalue" "channel" } ] } search results (epaper) { "and" \[ { "value" "$context phrase", "operation" "not empty" }, { "value" "$context publication type", "comparevalue" "kiosk" } ] } navigation for navigation configuration see the docid\ yvk2ekejex9kmanjphtkz documentation fallback (a k a content access control ) this configuration defines what to do if the user is not allowed to access/view the content (i e not purchased) the most common actions here are navigateaction or popupaction the following example opens the content if the user has access otherwise shows the view "paywall" in a popup navigation example search results in issues if you search for issues / contents of type issue, you may configure the search results to display multiple results for the same issue if found to do so, you'll need to set up the pagehitlimit accordingly this defaults to 1 pagehits will open the page in the issue directly if the user is entitled accordingly if no valid entitlement for the content is present, the issue is opened according to its customer preview setup, on page 1