table.View.onStoreRecordChange fields do not match selectedRecordField - bug and fix

george, you do have the following example on which i spent multiple hours just for you to see how it is working: https://neomjs.com/examples/table/nestedRecordFields/index.html

looking at your desired change: if (field.name === me.selectedRecordField.split('.')[0]) {

it can only assume(!) that you are doing something like:

record.annotations = {selected: true};

i know max did that inside the trainings before we had change events for nested fields, but this is clearly not the way to go. we do not want to listen to changes of any possible annotations, but to the the "right" one.

meaning (as it is done inside the example):

record.annotations.selected = true;

the singleSelect part should indeed move somewhere else.

as I recall from a year and more back, the assignment

record.annotations.selected = true

failed, because Store couldn't handle the case where there was not (yet) a record.annotations field. Therefore I had used some some tricky dribbling to construct that object on the fly, without obliterating other potentially existing key:value pairs. The store model was simple:

model: {
                    fields: [{
                        name: 'annotation',
                        type: 'Object'
                    }, {

In training/workshop discussion, you had confirmed the store limitation, and had advised exactly the same solution. So that was the "right-enough" way at the time. Back then you mused about tradeoffs implementing subfield handling for store.

I used that model for various map, chart components, and of course, for table, such that the highlighting was determined by the data selected field value. This is the format of the json data input file, read using that model by store:

{
   "results":[
       {
         "annotation": {"selected": true},
         "timestamp":"2017-10-13T12:07:24.000Z",
         "latitude":63.976,
         "longitude":-21.949,
         "depth":1.1,
         "size":0.6,
         "quality":58.73,
         "humanReadableLocation":"6,1 km SV af Helgafelli"
      },
      {

Thus the annotation Object became {"selected": true}. Simple.

Because Table did not use data input to control highlighting, I added that feature so it would have parity with Map and Chart. Namely, I had modified View.mjs to use that record.annotation object, parsing out the selected subfield to control row highlighting. I put in a PR for that.

The nestedFields example introduced an enhanced store model with sub-fields:

class MainModel extends Model {
    static config = {
        className: 'Neo.examples.table.container.MainModel',

    fields: [{
        name: 'annotations',
        type: 'Object',

        fields: [{
            name        : 'annotations.selected',
            type        : 'Boolean',
            defaultValue: false
        }]
    }, {
        name: 'country',
        type: 'String'
    ...
    }, {
        name: 'user',
        type: 'Object',

        fields: [{
            name: 'user.firstname',
            type: 'String'
        }, {
            name: 'user.lastname',
            type: 'String'
        }]
    }]
}

}

The View.mjs re-factoring of last week, implemented my request to control highlighting via a selected data field. That refactoring used Neo.njs to parse out the select field, specified by a config parameter sting. That config string approach adds desirable flexibility. However, it also requires using the nested record model format, and a Neo.njs which is not documented sufficiently for regular use in component code by application developers.

Unfortunately a dearth of documentation meant it broke my table component code. My bug fix issue item duly reported that and fixed it.

Previously, I could use the same store model for all my components. Notably, no component imposed a model on the others.

It remains to be see if Store fully handles the new store/model, in all cases.