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

initialContent now shows up for Omnibars; arrow keys work on initial items #2633

Closed
wants to merge 3 commits into from

Conversation

jkillian
Copy link
Contributor

@jkillian jkillian commented Jun 28, 2018

Changes proposed in this pull request:

When initialContent was null, it was still getting improperly returned by renderFilteredItems. This led to bugs in some of the list components and omnibar where the regular list of items wouldn't be displayed when first opened.

Also fixed a related bug where the arrow keys wouldn't work in an omnibar for the initial content.

@jkillian jkillian requested a review from giladgray June 28, 2018 17:59
@blueprint-bot
Copy link

don't try to render initialContent when it's null

Preview: documentation | landing | table

@jkillian
Copy link
Contributor Author

I did notice that even with this fix, initialContent doesn't seem to be navigable by arrow keys. Didn't get to look into why though

@jkillian jkillian changed the title Don't try to render initialContent when it's null initialContent now shows up for Omnibars; arrow keys work on initial items Jul 18, 2018
@jkillian jkillian changed the title initialContent now shows up for Omnibars; arrow keys work on initial items initialContent now shows up for Omnibars; arrow keys work on initial items Jul 18, 2018
@jkillian
Copy link
Contributor Author

Pushed an update with an additional fix; is there anything else this needs @giladgray?

@blueprint-bot
Copy link

make arrow keys work on initial render

Preview: documentation | landing | table

@giladgray
Copy link
Contributor

why no arrow keys? initialContent is a renderer escape hatch: it has no relation to items or itemRenderer so it is completely separate from the QueryList arrow key logic.

@jkillian
Copy link
Contributor Author

When the omnibar shows its list of items when first opened (which it failed to do until the initialContent bug was fixed in this PR), it should be navigable by the arrow keys. Prior to this PR, the arrow keys wouldn't work on that list of items because there was logic to disable them w/o a query.

However, if you provided initialContent to the omnibar, your initial content, like you said, is unrelated to items. Thus we shouldn't handle arrow key presses if you have custom initialContent

@giladgray
Copy link
Contributor

@jkillian i don't think this is a bug. omnibar is supposed to be empty on first open. see Alfred or Mac OS Spotlight.

see this line in the docs:

    /**
     * React content to render when query is empty.
     * If omitted, all items will be rendered (or result of `itemListPredicate` with empty query).
==>  * If explicit `null`, nothing will be rendered when query is empty.   // <== expected behavior
     *
     * This prop is ignored if a custom `itemListRenderer` is supplied.
     */
    initialContent?: React.ReactNode | null;

@jkillian
Copy link
Contributor Author

@giladgray, the line above the one that you mentioned is the behavior that should happen:

If omitted, all items will be rendered (or result of itemListPredicate with empty query).

Only if a user specifically says initialContent={null} should nothing pop up:

If explicit null, nothing will be rendered when query is empty.

@jkillian
Copy link
Contributor Author

In a lot of use cases, I believe users will want to customize itemListPredicate so that recently selected omnibar items show up before any query is entered. This is the typical behavior in IDEs and other places that use omnibar-like functionality I believe

const handlers = isOpen && !this.isQueryEmpty() ? { onKeyDown: handleKeyDown, onKeyUp: handleKeyUp } : {};
// handle arrow key presses once we have a query or w/ no query if we're not displaying custom initial content
const shouldHandleKeys = isOpen && (initialContent == null || !this.isQueryEmpty());
const handlers = shouldHandleKeys ? { onKeyDown: handleKeyDown, onKeyUp: handleKeyUp } : {};
Copy link
Contributor

Choose a reason for hiding this comment

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

i think this was fixed in #3130

@@ -57,7 +57,7 @@ export function renderFilteredItems(
noResults?: React.ReactNode,
initialContent?: React.ReactNode | null,
): React.ReactNode {
if (props.query.length === 0 && initialContent !== undefined) {
if (props.query.length === 0 && initialContent != null) {
Copy link
Contributor

Choose a reason for hiding this comment

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

this change feels wrong -- the explicit undefined check is supported by the docs.

@giladgray giladgray closed this Nov 16, 2018
@giladgray giladgray deleted the jk/fixInitialContentCheck branch November 16, 2018 16:47
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