As suggested here, it could be powerful to extend our "token" searching (as opposed to substring searching) to more than just descriptions: namely, to keywords, and maybe even entity names!
"Why?": Why would this be impactful?
Lets people type more terms into the search bar and be more likely to hit a match.
"How?" How should this feature work?
Decide where we want to extend token searching. Just keywords? Or also names?
Add the tokens for keywords/names to the index when building the index. We might need to modify the index data structure so that each "hit" entry says where the token comes from (name, keyword, description), probably with the same prioritization structure we use when searching.
Modify our searching selectors to accommodate having hits from keywords/name in the feature index
Figure out how we want to handle these with our TextMatchHighlighter. We can probably make some kind of joint capture group that looks for the tokens with word boundaries, and also the full string. So if our search was foo bar, the regex would look like /(\b(foo|bar)\b|foo bar)/gi. Probably need to play with that and tweak it a little bit though!
"What": What is your idea?
As suggested here, it could be powerful to extend our "token" searching (as opposed to substring searching) to more than just descriptions: namely, to keywords, and maybe even entity names!
"Why?": Why would this be impactful?
Lets people type more terms into the search bar and be more likely to hit a match.
"How?" How should this feature work?
TextMatchHighlighter. We can probably make some kind of joint capture group that looks for the tokens with word boundaries, and also the full string. So if our search wasfoo bar, the regex would look like/(\b(foo|bar)\b|foo bar)/gi. Probably need to play with that and tweak it a little bit though!