Conversation
|
I pulled this branch and tried locally with I haven't examined the code yet, so I'll look at that and maybe put in some sort of timing mechanism |
donkawechico
left a comment
There was a problem hiding this comment.
As I was studying the code I realized a lot of this is going to change with the refactor PR. I think it would make more sense to review this once we merge the two and see how it all shakes out.
| this._commandTriggered = -1; | ||
| this._commandItems = undefined; | ||
| this._entities = undefined; | ||
| this._filteredItems = undefined; |
There was a problem hiding this comment.
I don't think this is possible (see further down), but it occurred to me there could be a perf opportunity here:
The idea being: remove these undefined assignments, change showDialog() to reuse existing list, then change updated to invalidate the cache if it notices a New, Removed, or Renamed entity.
So like:
public async showDialog(params: QuickBarParams) {
//...
this._entities = this._entities || Object.keys(this.hass.states).map<HassEntity>(
(entity_id) => this.hass.states[entity_id]
);
//...
public updated(changedProperties) {
if (
changedProperties.has(_propertyThatIndicatesANewEntity) ||
changedProperties.has(_propertyThatIndicatesARemovedEntity) ||
changedProperties.has(_propertyThatIndicatesARenamedEntity
) {
this._entities = undefined;
}
}
The reason I doubt this is feasible is that I'm not sure there's a simple property that indicates whether something was added... I think it's just a big list of existing states?
| this._itemFilter = ""; | ||
| this._filter = ""; | ||
| this._commandTriggered = -1; | ||
| this._commandItems = undefined; |
There was a problem hiding this comment.
Minor:
We could probably remove this line and let the command list stay cached for next launch since the command list will very rarely change in the middle of a session.
| import memoizeOne from "memoize-one"; | ||
| import "../../common/search/search-input"; | ||
| import { mdiConsoleLine } from "@mdi/js"; | ||
| import { scroll } from "lit-virtualizer"; | ||
| import { styleMap } from "lit-html/directives/style-map"; |
There was a problem hiding this comment.
I see you stopped using the VScode auto organize imports 😜
f9b4522 to
3f53143
Compare
| private _handleSelected(ev: SingleSelectedEvent) { | ||
| const index = ev.detail.index; | ||
| const item = (ev.target as any).items[index].item; | ||
| this.processItemAndCloseDialog(item, index); | ||
| } |
There was a problem hiding this comment.
Is the purpose of this function just to separate the concept of "handling a selection" and "how to execute quick bar commands"?
There was a problem hiding this comment.
it is to get the index and items from the event detail
There was a problem hiding this comment.
But that was already being done inside processItemAndCloseDialog. Seems like an unnecessary abstraction to me.
donkawechico
left a comment
There was a problem hiding this comment.
I just found a bug where command items aren't executing even if you click. Styling is off too.
|
|
||
| ha-icon { | ||
| color: var(--secondary-text-color); | ||
| } |
There was a problem hiding this comment.
@bramkragten Why is this ha-icon styling no longer in dev?
Current dev:
frontend/src/dialogs/quick-bar/ha-quick-bar.ts
Lines 338 to 358 in 07fc9b9
I looked through git blame and the commit history of ha-quick-bar and I don't see anything that removed it O_o
There was a problem hiding this comment.
It probably doesn't matter, icons look okay in dark mode.
But it does seem spooky that this code could vanish without a github trace.
There was a problem hiding this comment.
I made a general PR to make it general
| : fuzzySequentialMatch(filter, item.text); | ||
| return item; | ||
| }) | ||
| .filter((item) => item.score === undefined || item.score > 0) |
There was a problem hiding this comment.
Why is this in here? This would return all invalid items.
There was a problem hiding this comment.
lol, it is? 😆 Man I need to learn to read git history better. Sigh...
| value=${this._commandMode ? `>${this._itemFilter}` : this._itemFilter} | ||
| .filter=${this._commandMode ? `>${this._filter}` : this._filter} | ||
| @keydown=${this._handleInputKeyDown} | ||
| @focus=${this._resetActivatedIndex} |
There was a problem hiding this comment.
Why was all the activated index stuff (styling the topmost and highlighted row) removed in a PR about perf? And without a review?
To me, that was a pretty helpful visual styling and would've liked to discuss in review context.
There was a problem hiding this comment.
Because it didn't work anymore. Also it was using the wrong methods. If we would want to make the focus color different, we should change the css for that.
| ${this._commandTriggered === index | ||
| ? html`<ha-circular-progress | ||
| size="small" | ||
| active | ||
| slot="meta" | ||
| ></ha-circular-progress>` |
There was a problem hiding this comment.
Moving the circular progress bar inside this async renderItem breaks the progress bar. We never go back into this function after this._commandTriggered gets a value so the progress bar never appears.




Proposed change
I noticed the quick bar could be pretty sluggish, added virtualization and some more improvements for speed (and some style).
Type of change
Example configuration
Additional information
Checklist
If user exposed functionality or configuration variables are added/changed: