[App Search] Suggestions Callouts for Engine, Analytics, and Manual Curation Detail#113864
Conversation
There was a problem hiding this comment.
This is weird, but it seems more readable than {...MOCK_VALUES, {...MOCK_VALUES.curation, curation: etc etc, and I think its better than just writing a whole new object, because this highlights specifically whats changed vs the defaults. But it is kinda weird (I wish lodash.set didn't mutate the source object)
There was a problem hiding this comment.
See comment above about lodash fp
There was a problem hiding this comment.
Thanks for the tip! I did this in a2a3a8a
ecf9a61 to
7b1a5bd
Compare
7b1a5bd to
9771822
Compare
| iconType="eyeClosed" | ||
| size="s" | ||
| onClick={() => { | ||
| setLastDismissedTimestamp(new Date().toISOString()); |
There was a problem hiding this comment.
An ISO timestamp is of form 2021-10-04T22:53:20.588Z. This matches the style of the timestamp we get back from the API. We've used both ISO timestamps and unix timestamps interchangeably in our codebase so far.
56a2234 to
d9a33bb
Compare
|
This has conflicts but should still be reviewed, they will be resolved once #113885 is merged |
d9a33bb to
6b38c07
Compare
JasonStoltz
left a comment
There was a problem hiding this comment.
I'm good with this, just a couple of optional suggestions to consider. Let me know what you think.
| import { ENGINE_CURATION_SUGGESTION_PATH } from '../../../routes'; | ||
| import { generateEnginePath } from '../../engine'; | ||
|
|
||
| import { SuggestionsCallout } from '../components/suggestions_callout'; |
There was a problem hiding this comment.
Nice, I like how these share a base callout component.
| curation: { suggestion, queries }, | ||
| } = useValues(CurationLogic); | ||
|
|
||
| if (typeof suggestion === 'undefined' || suggestion.status !== 'pending') { |
There was a problem hiding this comment.
Just curious why you check for undefined rather than falsy.
There was a problem hiding this comment.
Would be nice to have statuses in an enum or at constants.
There was a problem hiding this comment.
Just curious why you check for undefined rather than falsy.
To be honest, I default to checking specifically for undefined so I don't have to remember whether false/0/""/{} etc are a valid value for the variable or not.
Would be nice to have statuses in an enum or at constants.
This field uses a union to enforce specific values
status: 'pending' | 'applied' | 'automated' | 'rejected' | 'disabled';
VSCode and tsc will complain if you use a value here that's not one of these strings. And I can still hover over stuggestion.status and it lists all the valid strings. In fact its kind of more useful than enums because for an SuggestionStatus enum it would just say status: SuggestionStatus.
When I used enums on Crawler there was some pushback against that and towards using unions. I dunno which is better tbh. For what its worth I think using a union still enforces a single "source of truth" for valid values, and I think its unlikely we'd change these valid values (that would be a breaking API change) so I'm not super worried about having to search/replace this. Anyway tsc would let us know which values we forgot to update.
There was a problem hiding this comment.
OK, maybe adding the strings to a constants file at least. We can deal with that in a different PR if we want.
|
|
||
| it('is empty when curation status is not pending', () => { | ||
| const values = cloneDeep(MOCK_VALUES); // set mutates so we cloneDeep first | ||
| set(values, 'curation.suggestion.status', 'applied'); |
There was a problem hiding this comment.
Nice, using set makes these tests more concise, I like it.
I think you could use lodash/fp which is immutable...
import { set } from 'lodash/fp';
set('curation.suggestion.status', 'applied', values)
That would avoid the cloneDeep
There was a problem hiding this comment.
Thanks for the tip, I did this in a2a3a8a
|
|
||
| interface SearchRelevanceSuggestions { | ||
| count: number; | ||
| curation: { |
There was a problem hiding this comment.
Do we have a type for curation already that we could use here?
There was a problem hiding this comment.
So this is more like a summary/details type than the CurationSuggestion type use get back from our endpoints. These are aggregated details coming from an internal endpoint. We do this for meta engines and crawler as well to track similar top-level engine level information we want to be aware of in the whole Engine UX. I tried to clarify that with new names in e0ed6a4
There was a problem hiding this comment.
See comment above about lodash fp
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]Module Count
Async chunks
History
To update your PR or re-run it, just comment with: |
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
Summary
Implements two new components:
SuggestedCurationsCallout, included on our Engine and Analytics pagesSuggestedDocumentsCallout, included on our Curation Detail page for manual curationsThese are powered by an underlying
SuggestionsCalloutcomponent that utilizes localstorage (through ouruseLocalStoragehook) to track whether the callout has been dismissed or not. The callout useslocation.pathnameto identify whether it has been dismissed already or not. This assumes that only oneSuggestionsCalloutis present per view/uniquelocation.pathname.Screenshots
Checklist