Table Embedded View Naming Inconsistencies

Ignition
1

I just wanted to make this call, as I am not sure its considered a bug, or just weirdly designed naming.

However it is very confusing that based on how you are using an embedded view in a table, it can change the names of the parameters provided to that view.
For Example:

  1. In a column as an embedded view, to access a rows data you use rowData and to access the cell value you use value (makes sense)
  2. In a subview you would access the rows data using value (which inherently means you can’t easily use the same setup for a column and a subview, since that keyword is already used for the cell)
  3. If you are using the {style:{}, value:{}} functionality of the table to change cell/row highlights, in a subview you must now access the rows data with value.value and for a column it is rowData.value, so if you want to use that functionality you need a third and fourth methodology for getting row data

A great example of why this being the same would be helpful:
If you have a table that is responsive, and on a larger format you want to show an embedded view as a large column. However on a smaller format you want to turn it into a subview, so that you can save screen real estate. In order to do this, and avoid all of the styling and location areas, you have to create a custom property that analyses params.rowData and params.value then decides if it should use the .value on each of those to decide what the rowData is in the first place. Just to show the data from the row the embedded view is on

I feel like in the case of a subview, the property should just be called rowData to mimic the column. However for backwards compatibility sake at this point I could see rowData and value both doing the same thing. That way you could at least consistently use rowData everywhere

In regards to the styling, I feel like it should not pass the object {style, value} syntax down into the embedded view, or at least if it does than it should maybe put it somewhere else so that you can always access the rowData in a consistent way.

All in all, these have been a nuisance when working on projects with heavy table use that also use a lot of embedded content, especially with the performance issues around binding execution order right now. Having to add in an extra binding just to figure out which parameters you should be using in the first place feels unnecessarily complicated.

Thank you for coming to my TED talk, hopefully there is an easy solution for this in the long term.

TLDR: Table embedded view parameter naming is inconsistent, rowData should always come from rowData, not value for a subview. And the {style, value} syntax should not follow all the way down to that rowData property.

4 Likes