Render on visible for better performance

[t9md]

Description of the Change

[Updated]

Aiming to solve #80
Depends on atom/atom-select-list#22

This PR use new atom select-list's initiallyVisibleItemCount(not merged yet) option.
When this option was passed, new visible option passed to elementForItem reflect visibility state in viewport.

We can use this information to skip heavy computation for faster response.
Here I just return empty li element when invisible.

Here is behavioral changes in command-palette.

• Old:
  • All items are equally rendered with command name, keymap shortcut.
• New:
  • First 10 items are always rendered with full info, others are just rendered with empty li.
  • When item become visible, render with full information(command name, shortcut)

Alternate Designs

#81
#98
#97

Benefits

Performance improve.
command-palette launch faster.

Perf comparison is at atom/atom-select-list#22.

Plus, user can easily notice perf improvement especially for initial launch, and user have many commands(like installing vim-mode-plus or nuculide).

Possible Drawbacks

When mouse scroll very quickly, user can see blank fake item.

Applicable Issues

#80

[leroix]

@t9md I checked out your branch and linked your atom-select-list branch. It works well, and the timeline tab definitely shows it to be faster in loading the command palette (<100ms vs 250ms). Nice work!

I think the behaviors you mentioned would be more appropriately tested in atom/atom-select-list#22.

[t9md]

@leroix Thanks you for feedback.
I worked on different issue in a few days.
But I'll continue to add some spec at select-list repo(but I still have difficulty how to do it)

[leroix]

@t9md is this PR ready to be merged?

[t9md]

Yes

[winstliu]

@t9md I was wondering if you think this will be useful to implement in all other Atom core packages that use atom-select-list?

[t9md]

Not sure if it's always good to introduce this new render-on-visible feature.
Theoretically, it improve perf by reducing amount of initial rendering item.
But if perf is not currently issue in that package, keeping it as-is is OK.
One minor caveat of this render-on-visible(enabled by passing initiallyVisibleItemCount) feature is "when user really scroll fast, user can see blank item on the list" since IntersectionObserver works in async, having delay to replace to real item element after it become visible.