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

Dot notation to crawl object hierarchy does not work with arrays #153

Closed
EdLeckert opened this issue Nov 22, 2024 · 0 comments · Fixed by #155
Closed

Dot notation to crawl object hierarchy does not work with arrays #153

EdLeckert opened this issue Nov 22, 2024 · 0 comments · Fixed by #155

Comments

@EdLeckert
Copy link
Contributor

This issue has been discussed in #76, #86 and #87, and probably elsewhere, but I'd like to add some clarity here.

Dot notation works fine for singletons. Take this example attribute structure from #87:

engine:
  engine_type: iV
  power_in_kw: 132
  battery_capacity_kwh: 62

This attribute's elements can be accessed using dot notation, without the need for the modify option, as in this card definition:

type: custom:flex-table-card
entities:
  include: sensor.enyaq_iv60_car_info
columns:
  - name: Model
    data: model
  - name: Engine Type
    data: engine.engine_type
  - name: Power
    data: engine.power_in_kw
    suffix: " kw"
  - name: Battery Capacity
    data: engine.battery_capacity_kwh
    suffix: " kwh"

The result is:

CarExample

However, dot notation does not fully work when the result is an array. Consider this JSON from #76:

{"my_data":[{"field_a":"a","field_b":"b"},{"field_a":"a","field_b":"b"}]}

If we attempt to use only dot notation to access the data as in this card definition, where prova is the name of the attribute:

type: custom:flex-table-card
entities:
  include: sensor.mydata
columns:
  - name: Field A
    data: prova.my_data.field_a
  - name: Field B
    data: prova.my_data.field_b

...then the result is:

FailedFieldExample

We have no choice but to use the modify option for the lowest level to get it to work:

type: custom:flex-table-card
entities:
  include: sensor.mydata
columns:
  - name: Field A
    data: prova.my_data
    modify: x.field_a
  - name: Field B
    data: prova.my_data
    modify: x.field_b

FieldExample

This need to use the modify option in combination with the data option not only confuses users and leads to numerous Issues and questions, it also has undesirable side effects. For example, modify often ends up having a dual purpose, one as an object selector, and also as a formatter. When trying to sort or sum (new feature) a column, we always need the selector, but often find that the formatting gets in the way of a proper sort or summation. The sort_unmodified option can be used to remove what is added by modify, but if modify is used as an object selector, this won't work. Using the modify option to both select and format data breaks a fundamental rule of data processing, and we can see the unfortunate results. The modify option is also somewhat risky.

Fortunately, a solution is available in an upcoming PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

1 participant