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

Custom Lovelace View Layouts #6557

Merged
merged 19 commits into from
Sep 30, 2020
Merged

Custom Lovelace View Layouts #6557

merged 19 commits into from
Sep 30, 2020

Conversation

zsarnett
Copy link
Contributor

@zsarnett zsarnett commented Aug 7, 2020

Proposed change

I was talking to @balloob and @bramkragten about my Drag and Drop layout for core when the idea came about for allowing others to create Lovelace View Layouts. Basically, you register your layout via custom elements and we load it in if the view is configured for it. Cards will have a layout configuration variable that will house the layout configuration (position, width, height, etc).

Example configuration (Potential)

View Configuration:

title: Dashboard
icon: mdi:home
type: grid

Card Configuration:

type: entities
entities:
    - light.bedroom
layout:
    key: 1234
    posX: 3
    posY: 5
    height: 10
    width: 3

@zsarnett zsarnett marked this pull request as draft August 7, 2020 04:03
@balloob
Copy link
Member

balloob commented Aug 7, 2020

This should be at the view level. The dashboard level would be another component.

@zsarnett
Copy link
Contributor Author

zsarnett commented Aug 9, 2020

Just a thought I had: I think we should send the Parent height down to the view instead of the amount of columns. Or just let the view itself use a resize observer so we don't send an update to the view every pixel.

@zsarnett zsarnett marked this pull request as ready for review August 24, 2020 21:22
Comment on lines 98 to 100
viewConfig.panel
? PANEL_VIEW_LAYOUT
: viewConfig.layout || DEFAULT_VIEW_LAYOUT
Copy link
Member

Choose a reason for hiding this comment

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

We still need to be backwards compatible with the old panel config format?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is compatible. It checks if the flag is set and runs the panel view instead

editModeChanged =
!oldLovelace || lovelace.editMode !== oldLovelace.editMode;
}
this._createCard();
Copy link
Member

Choose a reason for hiding this comment

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

We are now recreating the card on every state change?

Copy link
Member

Choose a reason for hiding this comment

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

And we no longer set the theme

Copy link
Member

Choose a reason for hiding this comment

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

And we need to update hass if it is changed on the card.

this._card.hass = this.hass;

Copy link
Contributor Author

@zsarnett zsarnett Sep 25, 2020

Choose a reason for hiding this comment

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

Updating hass happens in the hui-view. Where the cards are created.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The theme is currently being applied in hui-view as well. Do we need to apply it in each separate view instead?

Copy link
Member

Choose a reason for hiding this comment

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

We still call this function on every state change? Should then only be called when edit mode is changed and the first time?

@bramkragten
Copy link
Member

We should write a dev blog post about this change, both for the new functionality for devs, and because it will probably break some custom cards?

@zsarnett
Copy link
Contributor Author

zsarnett commented Sep 25, 2020

Yea we should also see what does break off the bat when this is merged. @iantrich or @thomasloven maybe one of you could test a few custom cards on this branch and see if it immediately breaks anything?

I did test with the Button Card (Custom) and the basic config doesn't seem to be broken

Comment on lines 118 to 129
if (changedProperties.has("hass") && changedProperties.size === 1) {
return;
}

const oldHass = changedProperties.get("hass") as HomeAssistant;

if (
(oldHass && this.hass!.dockedSidebar !== oldHass.dockedSidebar) ||
(!oldHass && this.hass)
) {
this._updateColumns();
}
Copy link
Member

Choose a reason for hiding this comment

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

We don't check the sidebar anymore because we return if just hass is changed.

@bramkragten bramkragten merged commit 771c751 into dev Sep 30, 2020
@bramkragten bramkragten deleted the custom-view branch September 30, 2020 09:06
@bramkragten bramkragten mentioned this pull request Sep 30, 2020
@github-actions github-actions bot locked and limited conversation to collaborators Jul 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants