Move towards more efficient DOM manipulation#900
Conversation
|
⚡ Great to see that big of a speed improvement! Code looks good to me, though I've never worked on this code before. |
lib/suggestion-list-element.js
Outdated
| } | ||
|
|
||
| getDisplayHTML (text, snippet, displayText, replacementPrefix) { | ||
| getDisplay (text, snippet, displayText, replacementPrefix) { |
There was a problem hiding this comment.
Minor nitpick: This name is a bit weird to me. getElement maybe?
There was a problem hiding this comment.
Oh, it's already called "element" in terms of element in the list, so my suggestion isn't good.
nathansobo
changed the title
nathansobo
left a comment
nathansobo
left a comment
There was a problem hiding this comment.
I like your approach to updating the tests. If the test coverage was good previously, then this should be fine. There was quite a bit of logic for constructing the elements and I'd be lying if I looked at each line super closely, but from a few minutes of inspection it all seems reasonable. I say we move forward with this. Nice work!
|
It's probably unrelated to the content of this PR, but What's up with the subsequence provider failing against beta on AppVeyor? Did we change the behavior? |
|
@nathansobo Yea, that's what I'm looking into today. I don't think we've changed the behavior that I know of. I'm a bit befuddled. Btw, I don't really like |
|
I just built 1.22.0-beta0 locally, ran the specs, and didn't get the failure that was present in Appveyor. 😕 |
lib/suggestion-list-element.js
Outdated
| } | ||
|
|
||
| getDisplay (text, snippet, displayText, replacementPrefix) { | ||
| getDisplayFrag (text, snippet, displayText, replacementPrefix) { |
There was a problem hiding this comment.
Sorry to be a pain, but we prefer to use whole words in all Atom code unless there's a very special case. (Like "id")
leroix
force-pushed
the
faster-rendering
branch
5 times, most recently
from
6cf0977 to
70e1cbd
Compare
|
We figured out that appveyor is failing because of an ambiguity in the sorting logic in https://github.com/atom/superstring/blob/master/src/core/text-buffer.cc#L525 If the scores are the same, the order is left up to the order the matches showed up in The fix for this is unrelated to this PR, so I think this PR is ready to go. |
3 participants
Description of the Change
This PR moves away from setting
.innerHTMLin.renderItemwhere possible. Though, when we receive HTML via the suggestion provider API, we still have to use it. Direct DOM manipulation tends to be faster when called in a loop:Here's an illustration of the improvement for the same autocomplete scenario before and after the changes in this PR:
Alternate Designs
n/a
Benefits
This is a step towards faster rendering of autocomplete suggestions making the typing experience feel more responsive.
Possible Drawbacks
Imperative dom manipulation can potentially be more complex than just setting
.innerHTMLin some cases.Applicable Issues
n/a