Vue wrapper component for handling the searching actions on list/search pages. Handles both "simple lists" where the output of the search is an array with pagination, but also "grouped lists" where multiple paginations exist for multiple groups.

• Simple list search example: https://www.roskilde.dk/da-dk/nyheder/
• Grouped list search example: https://www.roskilde.dk/da-dk/sogning/

yarn add @limbo-works/search

Install the component by extending the layer in nuxt.config.js.

export default defineNuxtConfig({
    extends: [
        '@limbo-works/search',
        ...
    ],
    ...
});

Then you can use the LimboSearch component anywhere within that solution:

<!-- As written in Vue -->
<LimboSearch
	:search-filters="{
		endpointUrl: '/api/search/',
		fields: [/* some fields expected syntax: {name:'freetext', value: ''}, {name:'siteId', value: ''}*/ ],
	}"
	#default="{ data, pagination }"
>
	<pre>{{ data }}</pre>
	<pre>{{ pagination }}</pre>
</LimboSearch>

<!-- As it may appear in the dom -->
<div class="c-limbo-search">
	<pre>[{ title: "test1" },...,{ title: "test12" }]</pre>
	<pre>{ limit: 12, offset: 0, total: 99 }</pre>
</div>

You can also use the useLimboSearch composable within a solution. This is a more flexible solution in many cases.

const limboSearch = await useLimboSearch({
	searchKey: route.path, /* or whatever key you want. This makes the search not interfere with other searches */
	searchFilters: {
		endpointUrl: '/api/search/',
		fields: [/* some fields expected syntax: {name:'freetext', value: ''}, {name:'siteId', value: ''}*/ ],
	},
	config: {
		immediateSearch: { useUrlQuery: true, ssr: true },
		...
	},
});

useLimboSearch gives access to

The configuration object (config-prop) allows you to finely tune the behaviour of the search component.

One important feature of this search component is the ability to do grouped searches, ie. multiple separate searches with individual paginations. This is handled by having an id assigned to each group, which will then be combined with paginations (l1, o1, l2, o2, etc.) and used to sort out the search data. When "fetching more", to tell the endpoint which group to fetch more of, the groupParameter is sent as part of the request.

The response from the endpoint is expected to look somewhat like this:

{
    ...,
    data: [
        /* array of items */
    ],
    pagination: {
        limit: 12,
        offset: 0,
        total: 99,
    },
    ...,
}

Ie. .data is expected to be an array of items and .pagination is expected to contain the currently set limit, offset as well as the total - the total amount of existing results for the search. These values are required for the searching to work internally in the component. Of course status code etc. should be naturally part of the response as well.

If the response data is different, the searchResponseTransformerMethod should be used to make sure .data and .pagination is there. If the data is formatted differently, but you for some reason or another want to keep it that way, you should use the dataMergerMethod to manually handle the merging when doing "fetch more/all".

The response may also contain the properties .facets, .meta and/or .misc, which will be relayed to the slot-props and event data as well. This allows extra data to be sent from the API, but are not used by the LimboSearch component itself in any capacity.

When doing grouped searches, the response data is expected to look a little different, as we need to handle the groups:

{
    groups: [
        // Instead of .data and .pagination, an array of groups are expected
        ...,
        {
            id: 9, // Each group needs an id
            items: [
                ...,
                /* array of items in the group */
            ],
            limit: 12,
            offset: 0,
            total: 99,
        },
        ...,
    ],
}

Ie. the grouped search adds an extra layer to it all and moves the pagination to the root of each individual group, but other than that the logic stays the same. Especially the pagination is important to get right, as this is handled entirely internally - the items/data you can always just handle with the dataMergerMethod.

The update event is the most important event here, mirroring the same data you will have accessible through the slot props. Following are the properties you will receive through the event:

The exposed slot props on the default slot will be the same data as sent out by the update-event. Refer to the same table above.

• Currently, when using allowSearchFiltersMutation, only single values are accepted. This means that array-parameters (ie. for checkbox lists) will not be correctly set or mutated. Only use when such filters/inputs aren't needed.
• facets, meta and misc exist in the component, as they were part of the legacy SkyList solution, and they may be a good place for extra data relevant to the search.

• Make allowSearchFiltersMutation handle multi-value inputs and parameters as well.
• Insert a small cache of the most recent search, to allow for easy back-button'ing without doing a re-search.
• Allow for deep-linking alá "when the search is done, go to this result".
• Make a server-side search so that the results are already there when the page loads.
• Improve handling of extra data from the search.
• Important: Re-align with [forms](https://gist.github.com/abjerner/7a539fbaa0657a7a1acfc23c9e30384a) setup in terms of filter mutation and query transformation.
• Possibly move these items to be issues.