I've enabled synonym support in my elasticsearch, which means, for example, end users might search for "trousers" and get back results that do not contain "trousers" but do contain "pants". I think that getSuggestions is hiding these results. Have you put any thought into this scenario? I think I understand what the filtering here is trying to do, which is handle when the user has changed their search term by the time results come back ( right? ), but in my case it's hiding results I'd still like to see.

Auto suggest throws TypeError: i.toLowerCase is not a function when parseField hits a null label. label checking in parseField needs to be more defensive and force value to string before performing a toLowerCase()

Required for showing result-stats.

We are utilizing reactivesearch to query some Elastic data. We are utilizing the showMissing prop option on several filters that are using MultiList. Our understanding is that missing/null data is necessary for showMissing to function and this is all working.

There is also a DataSearch. Today, I was asked to connect the DataSearch to more dataFields and some of those fields are null for some records. For the showMissing to function, I can't (as far as I know) avoid having these null values. When I added the additional fields to the DataSearch's dataFields, the app would crash as soon as I typed anything into the input.

Stack trace showed it was crashing at the str.replace in replaceDiacritics (in suggestions.js) because str had a value of null:

function replaceDiacritics(s) {
	let str = s ? String(s) : s;

	const diacritics = [
		/[\300-\306]/g, /[\340-\346]/g, // A, a
		/[\310-\313]/g, /[\350-\353]/g, // E, e
		/[\314-\317]/g, /[\354-\357]/g, // I, i
		/[\322-\330]/g, /[\362-\370]/g, // O, o
		/[\331-\334]/g, /[\371-\374]/g, // U, u
		/[\321]/g, /[\361]/g, // N, n
		/[\307]/g, /[\347]/g, // C, c
	];

	const chars = ['A', 'a', 'E', 'e', 'I', 'i', 'O', 'o', 'U', 'u', 'N', 'n', 'C', 'c'];

	for (let i = 0; i < diacritics.length; i += 1) {
		str = str.replace(diacritics[i], chars[i]); // crash here
	}

	return str;
}

I won't say this is the best fix, but I put a band-aid on the issue by changing

const populateSuggestionsList = (val, parsedSource, source) => {
		// check if the suggestion includes the current value
		// and not already included in other suggestions
		const isWordMatch = skipWordMatch || currentValue
                .....

into

const populateSuggestionsList = (val, parsedSource, source) => {
		// check if the suggestion includes the current value
		// and not already included in other suggestions
                val = val ? val : ''; // new
		const isWordMatch = skipWordMatch || currentValue
                .....

There may be reasons I'm not aware of that you wouldn't want to support the possibility of autosuggest encountering null values, but I thought I would open the issue to inquire if this was the intended behavior.

Hi

I have a ReactiveComponent in the form of an single input that sets a custom query, a RangeSlider with a custom query and a ReactiveList. When the page loads the query from the reactive component loads into the search results and then the same query loads but with the addition of the custom query from the RangeSlider.

I would rather the ReactiveList didnt do anything until it considered what was coming from the RangeSlider. I cant see any way of using the react prop to stop this happening?

ReactiveSearch.DataSearch component provides properties for customHighlight and parseSuggestion to customise suggestions for current search input. Unfortunately it appears the highlight entry of the returned ES hits are being neglected/discarded during the query result processing here. (the customHighlight query configuration is properly included in the query sent to ES though!)

Maybe I miss something but it seems to be caused by calling getSuggestions of this packages utils/suggestions.js module as can be seen in onSuggestions( query.result ) call here for WEB Version or Vue.js Version.

If the above is true, would it be possible to add/maintain highlight either as new field in suggestions option dict, e.g. suggestion.highlight or as entry in the suggestion.source field e.g. suggestion.source._highlight?

NOTE: highlight may? not be present in hits/query result if customHighlight is not configured

X-Request-Tag or X-Query-Tag are echoed back by our API and can be used to resolve the rendering issue by using sequential/timestamp values, this will only work for appbase.io service as ES still doesn’t support this - elastic/elasticsearch#19778

This is quite helpful when connecting ReactiveBase without a type prop and filtering out results in onAllData.

Not sure if I should post this here or on the ReactiveSearch repo.

I have had ReactiveSearch running great. Two days ago I started getting errors because it is requiring Vue.js as a dependency. I'm using this on a React app, and though I have things working now that I have installed Vue, but I really don't want to have to include Vue unnecessarily.

Can someone explain why Vue is a dependency

When a user specifies they want their data to be highlighted the highlighted data returns a truncated portion in the _source.

Please see my comments below. I didn't think a pull request was appropriate as all I would be doing is deleting a function.

Is there a reason for mutating the source of the highlighted data?

Best,
Ryan

// src/utils/helper.js


// Why are we mutating the original _source object here?  
// This takes away information for the end-user given by elasticsearch

// My use case of ElasticSearch is to store parsed pdfs as strings 
// These contain 1000+ chars each

// The highlighted information given by elasticsearch have many fewer characters than this. 
// Around 100 chars 

// I want to be able to send the whole of the information to the end-user in the results

// If you remove this function (highlightResults)
// the user still retains the highlighted information in the main result object
//  and the original _source information

const highlightResults = (result) => {
	const data = { ...result };
	if (data.highlight) {
		Object.keys(data.highlight).forEach((highlightItem) => {
			const highlightValue = data.highlight[highlightItem][0];
			data._source = Object.assign({}, data._source, { [highlightItem]: highlightValue });
		});
	}
	return data;
};

export const parseHits = (hits) => {
	let results = null;
	if (hits) {
		results = [...hits].map((item) => {
			const streamProps = {};

			if (item._updated) {
				streamProps._updated = item._updated;
			} else if (item._deleted) {
				streamProps._deleted = item._deleted;
			}



                        // no need to mutate the data! below

			const data = highlightResults(item);

			return {
				_id: data._id,
				_index: data._index,
				...data._source,
				...streamProps,
			};
		});
	}
	return results;
};

While using reactivesearch with the latest version of elastic cloud(6.4), I was getting a warning "Deprecated aggregation order key [_term] used, replaced by [_key]".
Are there any plans to eliminate the deprecated terms anytime soon in the new build?

Expected behavior:
isLoading property must be true while executing a request & set to false when it's completed.

Current behavior:
Initially isLoading is undefined, after making request it turned out to be false & remains the same.

Affected Projects: Reactivesearch / ReactiveCore

Library Version: 3.0.1

Describe the bug
Using the Reactivesearch documentation as a baseline, I changed the request API endpoint as follow:

The request was processed nicely by Elasticsearch. However, the following error was thrown while the library was processing the response:

As I checked, the problem is that the handleResponse method tries to directly access a "responses" property from the body, and the search API doesn't return an array of responses - it returns a single response.

To Reproduce
Steps to reproduce the behavior:
Just modify any request using transformRequest as described above.

Expected behavior
The single response from the _search API should be processed succesfully.

react prop with or and not do not generate any query

How I am using DataSearch:

<DataSearch
                className="datasearch"
                componentId="q"
                dataField={["Vendor_Short", "Vendor_Short.raw", "Vendor_Short.search", "P21_Part_#", "P21_Part_#.search", "P21_Part_#.raw", "Description", "Description.raw", "Description.search", "Description_2", "Description_2.raw", "Description_2.search", "Description_3", "Description_3.raw", "Description_3.search", "Description_4", "Description_4.raw", "Description_4.search"]}
                placeholder="Search by Part No or Manufacturer"
                innerClass={{
                  "input": "searchbox",
                  "list": "suggestionlist"
                }}
                defaultSuggestions={[{
                  "label": "Ge Mao Rubber",
                  "value": "Ge Mao Rubber"
                }, {
                  "label": "VOR232",
                  "value": "VOR232"
                }, {
                  "label": "Les Joints",
                  "value": "les joints"
                }]}
                autosuggest={true}
                iconPosition="left"
                filterLabel="search"
                URLParams={true}
              />

All the fields in the dataField array of Text / Keyword / Search / Autosuggest type (no nesting of fields anywhere).

Console Error I see:

The GraphQL fetch should allow for more custumization:

• Currently the fetch call is fixed to query elastic50, feels weird to have to use elastic50 as my query name even if I'm using 7.2

• enforces the usage of a host parameter(which I dont use as the graphql proxy takes care of the host + credentials, therefore resulting in an error for me)

• Uses content type application/graphql while lots of implementations like Apollo seem to prefer application/json

• ReactiveBase could take a transformRequest parameter, which seems to be ignored in case graphQLUrl is used.