-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
[Labs] Suggest component #1499
[Labs] Suggest component #1499
Conversation
Update docsPreview: documentation |
const { handleKeyDown, handleKeyUp } = listProps; | ||
const inputValue: string = isTyping | ||
? query : selectedItem | ||
? inputValueRenderer(selectedItem) : ""; |
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.
alignment to clarify double-ternary
const inputValue: string = isTyping
? query
: (selectedItem ? inputValueRenderer(selectedItem) : "");
onChange={this.handleQueryChange} | ||
/> | ||
</div> | ||
<div onKeyDown={handleKeyDown} onKeyUp={handleKeyUp}> |
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.
why can't these handlers go on Menu
? shouldn't need an extra wrapper element.
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.
We can have Menu
support ul
HTML props in a separate PR (and then refactor all the labs components to use that)
<div | ||
onKeyDown={this.getTargetKeyDownHandler(handleKeyDown)} | ||
onKeyUp={this.state.isOpen ? handleKeyUp : undefined} | ||
onClick={this.handleInputClick} |
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.
can these handlers go on InputGroup
? you'll need to invoke corresponding inputProps.on*
in each handler.
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'll try and report back
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.
Done
this.input.blur(); | ||
this.setState({ isOpen: false }); | ||
} else { | ||
this.setState({ isOpen: closeOnSelect ? nextOpenState : true }); |
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.
prefer else if (closeOnSelect) { setState( true ) }
instead of the no-op nextOpenState
in ternary
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.
✅ wait, i think i get it and this code is actually ok. nextOpenState
is param so it needs to make it into state somehow, which my suggestion does not allow.
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'm not sure what you mean by no-op, but your suggestion is not equivalent to what I have.
This logic is messed up anyway, I'm gonna handle closeOnSelect
stuff where it belongs: handleItemSelect
|
||
if (this.input !== document.activeElement) { | ||
// the input is no longer focused so we can close the popover | ||
this.input.blur(); |
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.
why blur if we already know it's not focused?
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.
Good question, it's because handleItemSelect
always refocuses the input. Now it only does with closeOnSelect={false}
✅
private handlePopoverWillClose = () => { | ||
const { popoverProps = {} } = this.props; | ||
|
||
// resetting the query when the popover close |
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.
no resetOnClose
?
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.
We always reset on close here. If we don't, you can end up with the filtered list desynced from what's shown in the input (because we don't show query
in the input at all times)
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.
gotcha, cool. please update comment to clarify why it always resets.
Neat. Will this support |
@dmackerman you bet |
Fix errorsPreview: documentation |
Not sure why this commit broke the build... The change is literally one word 🤔 - `Suggest` behaves similarly to `Select`, except it renders a text input as Popover target instead of arbitrary children.
+ `Suggest` behaves similarly to `Select`, except it renders a text input as the `Popover` target instead of arbitrary children. |
yeah not sure about the build... looks suspiciously like a test flake cuz it's about focus. 😕 |
Flaking test:
@giladgray how can I fix that? The underlying |
Well that test actually fails on |
Update docsPreview: documentation |
@llorca the "Open popover on key down" option doesn't appear to work: |
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.
Bug: openOnKeyDown
doesn't appear to work.
Set proper state and fix keyDown handlerPreview: documentation |
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.
Looks good overall! Left some questions for future reference.
|
||
// reset the query when the popover close, make sure that the list | ||
// isn't filtered on when the popover opens next | ||
this.setState({ query: "" }); | ||
this.setState({ | ||
activeItem: selectedItem ? selectedItem : this.props.items[0], |
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.
nit: Prefer explicit selectedItem != null
. I like to avoid loose falsy checks.
...restProps, | ||
} = this.props; | ||
|
||
return <this.TypedQueryList |
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.
nit: typical format for us is:
return (
// indented component
);
const { isTyping, selectedItem, query } = this.state; | ||
const { ref, ...htmlInputProps } = inputProps; | ||
const { handleKeyDown, handleKeyUp } = listProps; | ||
const inputValue: string = isTyping |
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.
Can we do away with the explicit : string
type here?
private handleInputFocus = (event: React.SyntheticEvent<HTMLInputElement>) => { | ||
const { openOnKeyDown, inputProps = {} } = this.props; | ||
|
||
this.selectText(); |
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.
Worth adding a selectAllOnFocus: boolean
prop like we do for NumericInput
?
|
||
if (!closeOnSelect) { | ||
this.input.focus(); | ||
this.selectText(); |
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.
Is this line necessary even though focus
'ing will trigger handleInputFocus
and subsequently invoke this.selectText()
? (Per the requestAnimationFrame
comment above, I'm assuming focus doesn't happen synchronously here?)
All comments appear to be addressed
@giladgray etc. I'm gonna merge this and then do an audit to make sure controlled mode works as expected before we release. Might even... (••) EDIT: Eh, actually, I'll just do that here before merging. There are also a couple other things I want to fix that I noticed in a second pass. |
Fix param namePreview: documentation | table |
Brought test coverage up to 90%. |
If I understand this component correctly, it fulfills #1407 (please feel free to close the issue if I'm right). |
Checklist
Changes proposed in this pull request:
Suggest
component composesPopover
,InputGroup
andQueryList
Screenshot