-
Notifications
You must be signed in to change notification settings - Fork 238
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 visual editor #1128
base: dev
Are you sure you want to change the base?
feat: add visual editor #1128
Conversation
Added translations
Fixed not able to add entity in a new card Added option whether to use color thresholds
Added headers to sub pages Css adjustments Added more settings Entity form now uses grid for selectors positioning
Added clear button to color selector Color thresholds are in expansion panels now Added support for entity as value
Added subpage header and subpage link elements Organized files Added few default values Added bounds and value factor options Color selector small css tweak
Empty color selector is now indicated by a checkerboard
Removed support for color rgb array
Removed the other button for removing entity
Just a small remark: |
Another remark is about selecting entities.
Means - using same "common ways" just "contaminate" more cards in HA ))). |
Good, very useful & makes a picture clear. And what about this common issue? |
Yeah I have that issue, the only solution I think is to make custom selector or wait until they fix it in entity selector. |
This should help identify selected entity as the friendly_name is not unique and the default entity selector does not correctly highlight selected entity
I would choose this way for time-saving. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I finally got around to dig into some of the details of your (still impressive!) PR. Thanks for hanging on. I might have more feedback later, but I thought I'd better share it sooner than later.
To sum up my thoughts up front in a few points: I found one or two minor glitches. And I think we can improve some of the code by re-using common patterns and facilities provided by hass itself, which may also help to increase similarity to other cards' config editors.
Please have a look and let me know what you think. I might also not have grasped the full picture yet.
src/editor/editor.js
Outdated
align_state: 'left', | ||
smoothing: true, | ||
...this._config, | ||
show: { ...DEFAULT_SHOW, ...this._config.show }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed, the generated config is somehow more involved than the minimal config I started with. I suspect, it has to do with merging the defaults into the generated configuration.
I also noticed that I cannot clear fields such as the show.points = hover
option. This could be related.
I propose that default options should not be added explicitly to the configuration, if they are not selected explicitly by the user. (That is, DEFAULT_SHOW
and also the other options above.)
src/editor/editor.js
Outdated
|
||
if (this.subElementEditorConfig !== undefined) { | ||
return this.renderSubElement(); | ||
// return html` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this comment is a left-over that should be removed?
src/editor/editor.js
Outdated
], | ||
}, | ||
{ | ||
name: 'tap_action', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add this to the "Appearance" group? It appears a bit lost in the editor.
src/editor/editor.js
Outdated
const SCHEMA = [ | ||
{ | ||
name: '', | ||
type: 'expandable', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At first, I struggled a bit with the sub-page editor, because I had never seen it in HA before. Whereas I have seen these expandable groups before. But I understand now that the expandble groups can't meanigfully be added to the entity list. So, I agree with the sub-pages solution.
Maybe it will help tidying up the UI, if we also move this group to a sub-page? Possibly even move all groups to sub-pages to keep it consistent?
src/editor/editor.js
Outdated
import { DEFAULT_SHOW } from '../const'; | ||
import { localize } from '../localize/localize'; | ||
|
||
const SCHEMA = [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to put these long jsons in an editor/const.js
?
.hass=${this.hass} | ||
.data=${data} | ||
.schema=${SCHEMA} | ||
.computeLabel=${this.computeLabel} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to directly pass localize
here? And move all the logic to localize()
?
This would then allow to also fill .localizeValue
, in order to localize the values, too.
src/editor/editor.js
Outdated
|
||
computeLabel(schema) { | ||
const localized = this.hass.localize(`ui.panel.lovelace.editor.card.generic.${schema.name}`); | ||
if (localized === '') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any downside in just returning this.hass.localize(...) || localize(...)
?
If not, it seems to be common to omit the else
and do
if (localized !== '') {
return localized;
}
return localize(...);
hex_color: {}, | ||
}; | ||
|
||
export class CustomColorSelector extends LitElement { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason not to use the color picker provided by hass itself?
If it is the "clearable" feature, it could be handled in the usual hass way by having an enable/disable toggle in front of the color picker.
If it is the hex format, could it be converted "output-only" in the main valueChanged
function? I am not familiar enough with the way these things work...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mainly it was the hex format. I've tried to do the convertion on output but this resulted in warnings in console about supplied color value to hass color picker but the selecter was rendering just fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see... I'd guess, we'd have to convert back and forth to not loose colours on each startup of the editor... At least in setConfig
, configChanged
and entitiesChanged
... Then use [r,g,b]
internally in the editor and hex outside...
Another idea: How about we allow [r,g,b]
as a new colour input format for the mini-graph-card itself? Better suited for a follow-up PR then, maybe... We'd still loose non-hex colours on first startup of the editor, I assume...
I shall test, if losing colours is actually an issue...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did a test, and yes, loosing colours is an issue. Try this:
- Edit card
- Switch to YAML
- Set colour to "yellow" on an entity
- Switch to UI mode and edit entity
- Observe the colour to be black now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've addressed this issue in the latest commit
src/editor/editor.js
Outdated
if (!this._config || !this.hass) { | ||
return; | ||
} | ||
// this._config = { config, ...this._entities }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a left-over comment?
src/main.js
Outdated
return { | ||
entities: [], | ||
color_thresholds: [], | ||
show: DEFAULT_SHOW, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not understand, when this is used. If it automatically adds the default show options to each new card, we should not do this, I think. If it just can be used by the user to get a sensible template to fill in, I think it is a good idea to return all these otions here...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was needed because things like adding new entity on a new card was now working properly but I sorted it out internally so it is not needed anymore and will be deleted.
Color thresholds and state map now use the new `ha-form-mgc-list` Removed old unused components Moved schemas to `editorConst.js` Translations are now handled through `hass.localize` Color selector should now display proper color when supplied with color name Fixed inability to clear few options Removed leftover comments
Added missing translations
#773