[FEATURE] Refactor listing composable

[patzick]

Description

useListing composable is complicated and introduces errors for different useCases. We should split it from search listing context and provide separate solutions.

Use Case

For the context of this issue we should propose new API for listing and deprecate old solution.

Proposed Solution

No response

Alternatives Considered

No response

Additional Context

No response

[BrocksiNet]

WIP:

What I, as a Buyer (Website User), expect from a product listing:

• A result page should always show some products (no empty pages)
• I can only select filter options that have a result (disable options)
• I can see that I selected some filter also without opening it
• The filter name and value is readable in the URL (no UUIDs)
• The sub-category navigation stays the same and highlights the current one
• The sub-category navigation remembers my filters when I change categories
• There is one place where I find the filters (top), and they do not use that much space
• Every filter has its reset button (remove all selected filters) and its save button (executes the search)
• When I share the link or open it again later (hard reload), the same Filters are selected

What I, as a shop owner, expect from a product listing:

• Showing all filter options always, disabling not possible options, or hiding not possible options
• Choosing between a general AND or OR connection for all selected filters
• Choosing between an AND or an OR connection for every filter separate
• Showing the product count of an option or not to the Website User
• I want to have the option to update the h1 of a page with some filter name/value

[mkucmus]

loose proposal

since there is no way to have more product listings than 1 at the same cms page, maybe we could consider splitting up the useListing by it's areas, sharing the same state/context:

• useProductListingFilters
• useProductListingSorting
• useProductListingPagination
• useProductListingProducts

pros:

• smaller responsibility area
• easier to understand

cons:

• potential problems with reactivity and shared state
• BC for vue-demo-store and docs

[BrocksiNet]

What I also have in mind is that we could push the Core team a bit to fix this issue, or someone with PHP skills from our team could suggest not loading Products on CMS (via a Flag). That would speed up the CMS Request and allow us to load our listing as needed.

[BrocksiNet]

Copied description from #1057

Problems:

Filters are changed after refreshing the page. This problem exists because we are building it at the init page request. After applying any filter, the context changes, and we do not refresh the list. To decide what strategy should be implemented

What we need:

Only one function will handle API calls (currently, we have two different calls. From search.vue and useListing composable

We should send two requests. Init a request to give us all available filters for searching and the next one to get active filters.

Change the structure of the filter request. It should be a part of the filter property.

Add examples of how to use listing/search filters with different variants