Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update static filters #204

Merged
merged 2 commits into from
Aug 15, 2022
Merged

Update static filters #204

merged 2 commits into from
Aug 15, 2022

Conversation

nmanu1
Copy link
Contributor

@nmanu1 nmanu1 commented Aug 15, 2022

Update the StaticFilter interface to only allow combinations of filters supported by the backend. After talking with Watson, only ANDs of ORs (conjunctions of disjunctions), or structures that can be trivially converted to such, are accepted. To reflect this, ConjunctionStaticFilter and DisjunctionStaticFilter models were created, with the latter having limitations on which filters it can combine so a disjunction of conjunctions is not allowed. Also, I added some Jest tests for a couple more edge cases that were being missed when serializing a static filter.

J=SLAP-2325
TEST=auto, manual

See that the new and existing Jest tests pass. Spin up the test-site and successfully fire vertical searches with static filters defined with the new interface.

@nmanu1 nmanu1 requested a review from a team as a code owner August 15, 2022 13:33
@coveralls
Copy link

coveralls commented Aug 15, 2022

Pull Request Test Coverage Report for Build 2861031284

  • 7 of 7 (100.0%) changed or added relevant lines in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage decreased (-0.05%) to 90.196%

Totals Coverage Status
Change from base Build 2842480999: -0.05%
Covered Lines: 211
Relevant Lines: 228

💛 - Coveralls

*/
export interface FieldValueStaticFilter extends FieldValueFilter {
/** The kind of static filter. */
kind: 'fieldValue'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have we thought about using an enum for filter kind? Not saying we should or shouldn't, I like the simplicity just making it a string is but we also seem to prefer enums in this library

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't really see a need because we don't currently refer to the kind values collectively. I think an enum makes sense in cases like for Matcher where we do refer to all the values as a single type that users can choose between

/** {@inheritDoc FilterCombinator.OR} */
combinator: FilterCombinator.OR,
/** The filters to combine together. */
filters: (DisjunctionStaticFilter | FieldValueStaticFilter)[]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So an $or filter is not able to have any $and's inside of it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly! That would be a disjunction of conjunctions, which is not allowed

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow I really thought they would allow for a single layer, but now I remember you said you switched a single $and and $or and it broke

@nmanu1 nmanu1 merged commit 2b15de3 into develop Aug 15, 2022
@nmanu1 nmanu1 deleted the dev/update-static-filters branch August 15, 2022 15:39
@yen-tt yen-tt mentioned this pull request Sep 6, 2022
yen-tt added a commit that referenced this pull request Sep 8, 2022
## Version 2.0.0

### Changes
- `additionalQueryParameter` is now a public field in `SearchConfig` models (#217)

### Breaking Changes
- Updated default and sandbox URL endpoints from `../answers/..` to `../search/..` as part of rebranding process (#196 )
- Restructured StaticFilters models for better developer experience and enforce proper restriction in the kind of combinations of filters supported by the backend
  - Now, static filters can be either a field value filter or a nested object that is composed by combining field value filters. (#201 )
  - `ConjunctionStaticFilter` and `DisjunctionStaticFilter` models were created to reflect such limitation. For example, ANDs of ORs combination is allowed, ORs of ANDs combination is not allowed.  (#204 )
- Updated `FieldValueDirectAnswer` model to properly handle different `value` types. Previously, FieldValueDirectAnswer interface enforces that the `value` field will always be of type `string`. Now, `FieldValueDirectAnswer` is a union type of predefined interfaces with known `value` type and `UnknownFieldValueDirectAnswer` with a generic `value` type for other `fieldType` outside of `BuiltInFieldType`. (#200 #202 )
   - The newly added built-in interfaces can be found in the document page [**here**](https://github.com/yext/search-core/blob/develop/docs/search-core.fieldvaluedirectanswer.md)  (#206 #208 #210 #211 #205 #209 #203 #220 )
- Narrow down `FeaturedSnippetDirectAnswer` TypeScript model to be a union type of   `MultiLineTextSnippetDirectAnswer` and `RichTextSnippetDirectAnswer` as a featured snippet direct answer can only be of fieldType `multi_line_text` or `rich_text`. (#207 #212 )
- All exports marked as `@deprecated` in previous version(s) as part of the rebranding process is now removed in V2 (#216 )
  - For more details, the deprecated identifiers are listed in [v1.8 release notes](https://github.com/yext/search-core/releases/tag/v1.8.0)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants