ListGrid's scrollbar is not working for my wide record component

[nitroamos]

Here's some sample code with a problem verified on the latest Smartclient. The DynamicForm component is wider than 250. The ListGrid's horizontal scrollbar seems to realize this, but if I try to scroll right it flickers back to the left immediately.

I could change DynamicForm.numCols or ListGridField.width to avoid the problem, but I'd prefer a way for me to let the width be fit dynamically.

isc.ClassFactory.defineClass("MixedLabResultViewer", isc.ListGrid);
isc.MixedLabResultViewer.addProperties({
    height: 100,
    width:500,
    autoFitWidth: false,
    autoFitData: "vertical",
    showRecordComponents: true,
    showRecordComponentsByCell: true,
    virtualScrolling: false,
    fields:[
        {name:"measurementType", title: "Test"},
        {name:"values", title: "Result"}
    ]
});
isc.MixedLabResultViewer.addMethods({
    createRecordComponent : function (record, colNum) {
        var fieldName = this.getFieldName(colNum);
        if(fieldName == "values"){
            var df = isc.DynamicForm.create({
                width:"*",
                numCols:6,
                wrapItemTitles: false,
                fields: [
                    {name:"field1", title: "Field 1 Title",
                        defaultValue: "Field 1 Value"},
                    {name:"field2", title: "Field 2 Title",
                        defaultValue: "Field 2 Value"},
                    {name:"field3", title: "Field 3 Title",
                        defaultValue: "Field 3 Value"},
                ]
            });
            return df;
        }
        return null;
    }
});
var lg = isc.MixedLabResultViewer.create({
});
lg.addData({});
lg.addData({});

[nitroamos]

I should add that the problem is observed in both Chrome 56 and Safari 10.

[nitroamos]

After a lot of messing around, I finally figured out that overriding getDefaultFieldWidth like this seems to be what I'm looking for (needs some cleanup):

getDefaultFieldWidth: function(field){
    if(field.name != "values"){
        return 50;
    }
    var minWidth = 0;
    for(var r=0; r<this.getTotalRows(); r++){
        var comp = this.getRecordComponent(r);
        if(!comp){continue;}
        minWidth = Math.max(minWidth, comp.getScrollWidth());
    }
    return minWidth;
},

Is there a reason logic like this isn't included in super's getDefaultFieldWidth?

[Isomorphic]

Your approach above defeats incremental rendering (see recordComponentPoolingMode:"recycle"). If you don't need scalability to more than 50-ish rows, this is OK, but that's not really the main point of recordComponents, which is designed to scale to huge data sets.

Note, if your recordComponents are all the same size, or all less than a max, just set that as the field width - no need for a getDefaultFieldWidth override.

[nitroamos]

Good point.

In my case, the problem I'm trying to solve is that each row has a variable number of columns, so I'm putting all the extra columns into one cell. Therefore, each record component has a different size. In another widget I've been developing, I am creating record components that themselves are ListGrids which had the same problem if too many columns are visible. Given these situations, the flickering scrollbar is a disaster and I was afraid I'd have to tell my users to live with wider browser windows.

You might consider adding a field to a ListGrid or ListGridField called "autoFitRecordComponents" which does this.

[Isomorphic]

But again, that could only work by breaking the main use of recordComponents, so we don't plan to do this..

If you have varying numbers of extra fields, and there's a large degree of variance, you probably aren't really going to end up with a nice UI with this approach, no matter what. You'll just end up with a lot of awkward horizontal scrolling to see the additional fields.

You might consider something like a fixed-size column with an icon that opens a window to view/edit the rest of the fields, or other variations of this interaction. This would have the benefit of allowing the main grid to scale to large numbers of records as well.