-
Notifications
You must be signed in to change notification settings - Fork 4
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
Conversation
Pull Request Test Coverage Report for Build 2861031284
💛 - Coveralls |
*/ | ||
export interface FieldValueStaticFilter extends FieldValueFilter { | ||
/** The kind of static filter. */ | ||
kind: 'fieldValue' |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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)[] |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
## 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)
Update the
StaticFilter
interface to only allow combinations of filters supported by the backend. After talking with Watson, onlyAND
s ofOR
s (conjunctions of disjunctions), or structures that can be trivially converted to such, are accepted. To reflect this,ConjunctionStaticFilter
andDisjunctionStaticFilter
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.