Plugin preferences not persisted with correct key

[joelamb]

Plugin preferences should be saved with the key defined in the name property of the class

references: API documentation Plugin Interface

The two failing tests in this PR, point to plugin preferences being saved with the Class name (klass.name) as a key, rather than the value of the name property defined on the Class.

This is an issue, because this key is minified in production code, so the preference keys end up being persisted with minified, single-character keys.

This is brittle, since we cannot guarantee the value of the minified Class name, and hence any previously saved user preferences will be lost, if the key changes.

The test output is not particularly helpful in the Checks

But what it's trying to say is:

Expected:  
"plugins": {     "column-reordering": {       "columns": {},       "table": {         "order": {           "A": 3,           "B": 2,           "C": 1,           "D": 0         }       }     },     "column-visibility": {       "columns": {         "A": {},         "B": {},         "C": {},         "D": {}       },       "table": {}     }   } }
-- | --
Result
{   "plugins": {     "ColumnReordering": {       "columns": {},       "table": {         "order": {           "A": 3,           "B": 2,           "C": 1,           "D": 0         }       }     },     "ColumnVisibility": {       "columns": {         "A": {},         "B": {},         "C": {},         "D": {}       },       "table": {}     }   } }

The expected plugin keys are defined with the name property for 'Column Reordering' here

and for 'Column Visibility' here

[joelamb]

@NullVoxPopuli was the intention to move to use class name eg ColumnReordering.name ("ColumnReordering") rather than the name property ("column-reordering")? If so, how do we avoid having the keys minified in production?

[NullVoxPopuli]

rather than the name property ("column-reordering")?

nay, the manually specified string name was intended to be used exactly to protect against minified class names in production

[joelamb]

Any thoughts on where / how it might have come unstuck, or maybe it was never using the manually-specified name property string?

[johanrd]

@joelamb thanks. I'm a bit confused about the status of this compared to https://github.com/CrowdStrike/ember-headless-table/pull/237 and https://github.com/CrowdStrike/ember-headless-table/pull/239

What are you doing with this in crowdstrike, applying as a patch? It would be useful to pull this over the line, but I feel I might provide more mess than help!

[NullVoxPopuli]

Could have the universal-ember org adopt this addon to have more vis / attention https://github.com/universal-ember/

[johanrd]

ohh, that would be very positive, I think!

[johanrd]

@joelamb what do you think? I think the repository would benefit greatly if it could be adopted by e.g. universal-ember