Remove Search Autocomplete

Porting to
https://github.com/workarea-commerce/workarea-classic-search-autocomplete

docs/source/articles/analyze-storefront-search-results.html.md

@@ -184,8 +184,6 @@ Depending on the search query class these may include the following:
   * `Workarea.config.search_facet_sorts`
   * `Workarea.config.search_name_phrase_match_boost`
   * `Workarea.config.search_query_options`
-  * `Workarea.config.search_suggestion_min_doc_freq`
-  * `Workarea.config.search_suggestions`
 
 You may need to examine these values to determine how the request body reached its final state.
 

docs/source/articles/change-storefront-search-results.html.md

@@ -124,11 +124,7 @@ At this point, searching for "promo" returns all 4 test products.
 ![Before: promo products included in search results](../images/promo-products-included-search-results-before.png)
 
 To complete the change request, you must write the code necessary to exclude the promo products from these results.
-However, the retailer wants to exclude these products from _all_ search results, which includes autocomplete, categories, and product recommendations as well.
-
-You can see the products are currently included in autocomplete results:
-
-![Before: promo products included in autocomplete results](../images/promo-products-included-autocomplete-results-before.png)
+However, the retailer wants to exclude these products from _all_ search results, which includes categories, and product recommendations as well.
 
 And all four products are included in the "Promo Search" category, which merchandises the products using a product rule:
 
@@ -226,27 +222,6 @@ The example uses the logic "keywords.promo must not contain true" rather than "k
 The chosen logic excludes only those product search documents that have a `keywords.promo` field and whose value contains `'true'`.
 Existing search documents without a keywords.promo field will continue to match queries as expected.
 
-The decorator above does not cover the autocomplete feature, which relies on a separate query.
-So you must additionally decorate the `SearchSuggestions` query class, adding similar logic to this query's request body.
-This query's body is implemented almost entirely within the `#query` method, so apply your changes there:
-
-```ruby
-# app/queries/workarea/search/search_suggestions.decorator
-module Workarea
-  decorate Search::SearchSuggestions do
-    def query
-      result = super
-      # add a compound query clause to exclude promo products
-      result[:bool][:must_not] = [
-        { term: { 'keywords.promo' => true } }
-      ]
-      result
-    end
-  end
-end
-```
-
-
 Result
 --------------------------------------------------------------------------------
 
@@ -258,10 +233,6 @@ Search results:
 
 ![After: promo products excluded from search results](../images/promo-products-excluded-search-results-after.png)
 
-Autocomplete:
-
-![After: promo products excluded from autocomplete results](../images/promo-products-excluded-autocomplete-results-after.png)
-
 Categories:
 
 ![After: promo products excluded from search-based category results](../images/promo-products-excluded-search-category-results-after.png)

docs/source/articles/searching.html.md

@@ -764,16 +764,14 @@ puts searches.map(&:to_s).sort
 # Workarea::Search::ProductSearch
 # Workarea::Search::RelatedHelp
 # Workarea::Search::RelatedProducts
-# Workarea::Search::SearchSuggestions
 ```
 
 Each search query searches for results of a particular Elasticsearch document type. The following example groups the search queries by type.
 
 ```ruby
 pp searches.group_by(&:document)
 # {Workarea::Search::Storefront=>
-# [Workarea::Search::SearchSuggestions,
-# Workarea::Search::RelatedProducts,
+# [Workarea::Search::RelatedProducts,
 # Workarea::Search::ProductSearch,
 # Workarea::Search::CategoryBrowse,
 # Workarea::Search::Categorization],

docs/source/articles/storefront-search-features.html.md

@@ -24,16 +24,6 @@ These queries are built via a user interface and include a query string and opti
 Admins can customize the results of all searches via _search settings_ (terms facets, range facets, field boosts, product popularity multiplier), and they can customize specific searches via _search customizations_ (featured products, product rules, query rewrite).
 
 
-### Autocomplete
-
-Another obvious search feature in the Storefront is _autocomplete_.
-Storefront autocomplete is a _search-as-you-type_ feature that matches products, categories, pages, and searches to shoppers' queries as they type.
-
-![Storefront autocomplete](../images/storefront-autocomplete.png)
-
-There is no administration specific to this feature, but plugins and applications can extend autocomplete. For example, the Workarea Blog plugin extends this feature to include blog entries in the results.
-
-
 ### Categories
 
 Less evidently, _categories_ (i.e. category pages) in the Storefront are also a search feature.
@@ -82,7 +72,7 @@ Extending any of these features therefore requires an understanding of their sha
 Querying
 --------------------------------------------------------------------------------
 
-In each of the features above, shoppers are requesting pages (or updating pages in the case of autocomplete) which contain search results.
+In each of the features above, shoppers are requesting pages which contain search results.
 Application code responsible for handling these _Storefront requests_ must make additional _search requests_ to Elasticsearch.
 Elasticsearch responds to these requests, and the application processes the results, allowing it to respond to the original Storefront requests.
 
@@ -122,7 +112,6 @@ The following table maps each search feature to its corresponding search query c
 Search Feature                                 | Search Query Class          | Potential Callers
 ---------------------------------------------- | --------------------------- | ---------------------------------------------------------------------------------------------------
 Searches                                       | `Search::ProductSearch`     | See [Storefront Searches](storefront-searches.html)
-Autocomplete                                   | `Search::SearchSuggestions` | `Storefront::SearchesController#index`
 Categories and category summary content blocks | `Search::CategoryBrowse`    | `Storefront::CategoryViewModel#search_query`
 Product recommendations                        | `Search::RelatedProducts`   | `Recommendations::ProductBased`, `Recommendations::OrderBased`, `Recommendations::UserActivityBased`
 
@@ -321,8 +310,7 @@ The fields within each of these search documents were derived from data in one o
 _Search models_ are objects used to index documents into Elasticsearch.
 They create search documents from MongoDB documents and put the search documents into the appropriate search indexes (i.e. send indexing requests to Elasticsearch).
 
-Storefront search results are primarily products, but autocomplete results may also be categories, pages, searches, and possibly additional types (depending on plugins and extensions).
-There are therefore different search model classes to handle the creation and indexing of documents of these various types.
+There are different search model classes to handle the creation and indexing of documents of various types.
 The following table maps each search result type to its corresponding Mongoid model class and Storefront search model class.
 
 Search Result | Mongoid Model         | Search Model

docs/source/upgrade-guides/from-3-4-to-3-5.html.md

@@ -103,3 +103,13 @@ As a part of this process, the `digital?` flag on products was no longer necessa
 ### What Do You Need To Do?
 
 The v3.5 migration script creates `Fulfillment::Sku` records for existing digital items, setting their policy to `ignore_digital`. This should preserve any behavior in your system for digital products. However, we strongly recommend reworking any code that relies on the `digital?` method of either `Catalog::Product` or `Order::Item`. Instead use `requires_shipping?` on `Order` and `Order::Item` to determine behaviors within this concern.
+
+## Move Storefront Search Autocomplete Functionality to Plugin
+
+### What's Changing?
+
+We've removed the default Search Autocomplete functionality from the Storefront into a plugin to be able to give applications more flexibility.
+
+### What Do You Need To Do?
+
+To keep this functionality present in your application you'll need to install the `workarea-classic_search_autocomplete` plugin. 

storefront/app/assets/javascripts/workarea/storefront/application.js.erb

@@ -44,8 +44,6 @@
   %w(
     workarea/core/templates/lorem_ipsum_view
     workarea/core/templates/reveal_password_button
-    workarea/storefront/templates/ui_menu_heading
-    workarea/storefront/templates/ui_menu_item
     workarea/storefront/templates/loading
     workarea/storefront/templates/message
     workarea/storefront/templates/message_dismiss_action
@@ -66,12 +64,8 @@
   # Plugin JST Templates
   append_javascripts('storefront.templates')
 
-  # Library Extensions
-  %w(
-    jquery_ui/storefront/categorized_autocomplete
-  ).each do |asset|
-    require_asset asset
-  end
+  # Plugin Library Extensions
+  append_javascripts('storefront.extensions')
 
   # Workarea Module Controller
   require_asset 'workarea/core/workarea'
@@ -124,7 +118,6 @@
     workarea/storefront/modules/primary_nav_content
     workarea/storefront/modules/product_details_sku_selects
     workarea/storefront/modules/popup_buttons
-    workarea/storefront/modules/search_fields
     workarea/storefront/modules/alternate_image_buttons
     workarea/storefront/modules/scroll_to_buttons
     workarea/storefront/modules/address_region_fields