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

feat: Add new props for search, keyboard navigation, and scrolling #589

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

gandhis1
Copy link
Contributor

@gandhis1 gandhis1 commented Aug 6, 2022

What does it do?

  • The new prop searchTerm can be used to set the initial search term or fully control the search semantics for a higher-order component.
  • The new prop onSearchChange allows specification of a callback for when the search term changes or the search mode is activated or deactivated.
  • The new prop disableKeyboardNavigation allows disabling all actions associated with a key down event in the search input box. This is important if you need an input box to behave normally. For instance, when I press SHIFT+HOME, it should select the entire line, so I can press BACKSPACE to clear it.
  • The new prop pageSize can be used to control the size of the scroll view before scrolling to near the bottom is required to show more nodes.

Fixes # (issue)

Fixes #581
Requested #463
Fixes #576

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • Updated documentation (if applicable)
  • Added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • My changes generate no new warnings

@gandhis1 gandhis1 changed the title feat: Add new props for search and keyboard navigation feat: Add new props for search, keyboard navigation, and scrolling Aug 7, 2022
@gandhis1 gandhis1 force-pushed the search_state branch 3 times, most recently from 49430a8 to 29d1fd7 Compare August 10, 2022 14:05
The new prop searchTerm can be used to set the initial search term or fully control the search semantics for a higher-order component. The new prop onSearchChange allows specification of a callback for when the search term changes or the search mode is activated or deactivated. The new prop disableKeyboardNavigation allows disabling all actions associated with a key down event in the search input box. The new prop pageSize can be used to control the size of the scroll view before scrolling to near the bottom is required to show more nodes.
}

static defaultProps = {
onAction: () => {},
onFocus: () => {},
onBlur: () => {},
onChange: () => {},
onSearchChange: (_) => {},
Copy link
Contributor Author

Choose a reason for hiding this comment

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

There is an incompatibility between the prettier pre-commit hook and the codeclimate checks on GitHub with regard to this line. One tool insists on parentheses being present, the other insists it it on being absent. Is there any way we can use the same linter on both so that one tool does not conflict with the other like this?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Hmm, not sure. Will have to check with CC docs to see if they support a lint rc.

Copy link
Collaborator

Choose a reason for hiding this comment

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

We can ignore the warning manually in CC dashboard as a last resort

@github-actions
Copy link

github-actions bot commented Oct 2, 2022

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label Oct 2, 2022
@gandhis1
Copy link
Contributor Author

gandhis1 commented Oct 2, 2022

Bump

@stale stale bot removed the stale label Oct 2, 2022
@mrchief mrchief added the wip Work In Progress label Oct 9, 2022
Comment on lines +113 to +114
/** dsiableKeyboardNavigation will disable keyboard navigation of the tree */
dsiableKeyboardNavigation?: boolean
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
/** dsiableKeyboardNavigation will disable keyboard navigation of the tree */
dsiableKeyboardNavigation?: boolean
/** disableKeyboardNavigation will disable keyboard navigation of the tree */
disableKeyboardNavigation?: boolean

mode: PropTypes.oneOf(['multiSelect', 'simpleSelect', 'radioSelect', 'hierarchical']),
pageSize: PropTypes.number,
Copy link
Collaborator

Choose a reason for hiding this comment

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

@gandhis1 I did think about it during the infinite scroll implementation but ultimately decided against it. Reasons being

  • an arbitrary pageSize doesn't help with the overall intent of optimization - e.g, setting a lower number is actually counter productive and setting a higher number will slow down the rendering. This gets exacerbated if you have multiple dropdowns on the page. Furthermore, unless you've a really big screen, you can't see more than 100 anyway so why hold it in DOM?

@@ -50,18 +53,21 @@ class DropdownTreeSelect extends Component {
inlineSearchInput: PropTypes.bool,
tabIndex: PropTypes.number,
disablePoppingOnBackspace: PropTypes.bool,
disableKeyboardNavigation: PropTypes.bool,
Copy link
Collaborator

Choose a reason for hiding this comment

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

What's the use case for this? At a glance it seems like an a11y blocker but people don't have to use the keyboard if they don't want to so curios as to why this is needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

From my PR description above:

The new prop disableKeyboardNavigation allows disabling all actions associated with a key down event in the search input box. This is important if you need an input box to behave normally. For instance, when I press SHIFT+HOME, it should select the entire line, so I can press BACKSPACE to clear it.

I can't use arrow keys either on the search box right now.

Copy link
Collaborator

Choose a reason for hiding this comment

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

an input box to behave normally

I hear you but it's not really a regular input box - hence the special treatment.

when I press SHIFT+HOME, it should select the entire line, so I can press BACKSPACE to clear it.

Can this handled by adding additional functionality to the keyboard navigation logic? So that we don't have to choose between having it or not at all?

@charleslee94
Copy link

Hello! Curious on the status of this pr, this change would help out my use case of not clearing the search term on selection.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wip Work In Progress
Projects
None yet
Development

Successfully merging this pull request may close these issues.

control the search field Single click to clear search field
3 participants