Persisting Edits about lightning-data-grid HOT 5 OPEN

with 10000 rows i'm seeing 3-5ms on chrome....so maybe this is a moot point:

whosDirty : function(cmp){
        console.time('test');
        cmp.find('tableBody').get("v.body").forEach(function(item){
            _.each(item.get('v.rowData'), function(rd, key){
                if(rd.isDirty){
                    console.log("I'm dirty:" + key);
                }
                
            });
        });
        console.timeEnd('test');
    }

(about the tablebody.find stuff....I'm constructing the rows dynamically without an iteration, so a straight cmp.get('v.data') is giving me a different object than what ends up being on the row...ugh)

from lightning-data-grid.

I have been giving saving a lot of thought, but I've been heads down on the searching, filtering and sorting when I've had free time for this.

At the very least, I think the grid should be providing something like whosDirty in an invocable manner so we don't need to re-implement it on every new grid.

from lightning-data-grid.

Also, how is constructing the rows dynamically going for you? I experimented with that for a bit, and still think it could buy performance savings when the view is updated, especially if some caching mechanism is added for rows that already been seen before. A lot more code overhead to keep track of the bits and bobs though.

from lightning-data-grid.

I tried a few things, the ultimate goal being when you get close to the bottom scroll wise, it loads the next 'page' of records. I've tried 5 implementations of helper.addRows for this, adding 50 rows to the bottom each time:

(ps - my c:row body for this was just a hardcoded TR, no dynamic cells)

1. looping over next 50 data items and producing an array of configs to pass to A.createComponents
2. looking over the next 50 items calling A.createComponent inside the loop
3. raw HTML fragment.appendChild
4. Using aura:iteration and just increasing the items is v.items
5. Using a 'component store' so I call createComponents doing init, and create say 1000 components, then, in the addRows method, I can pull from the 'store' and append to the tableBody.v.body

In the chrome performance tab you can clearly see the bottle neck is the THOUSANDS of function calls in the createComponent spiderweb. My not scientific benchmarks were approx:

1. 1300ms
2. 3000ms
3. <400ms
4. 2000ms
5. 700ms (WAY longer on init)

Method 5 is very intriguing, if you could find a way to fill the store during user interaction lulls, a few pieces at a time. Or do something with WebWorkers. Still, HTML Tables? this is web 101.

I've spent a good amount of time in the source for ui:virtualDataGrid in the aura framework and force:inlineEditGrid, but they take advantage of APIs that are blocked with locker service. I keep wondering if just doing something on top of lighting, like baking in slickgrid or equivalent would be better than this hassle. That or just deal with less than ideal performance and see what the next 6 months brings.

I'm not actually using your source for this, or I'd send you a branch. I had developed something pretty similar on my own when I found this, and thought maybe we could synergize a bit. That said, I do have the code in a DX repo, so if you're interested, I can share.

from lightning-data-grid.

Yeah, I think doing something with slickgrid is probably the path of least resistance right now. But my original goal with this was to make it as natively lightning as possible to force myself to use the framework. That and lightning:treegrid still being Spring '18 at the earliest were the motivations for this project.

Thank you for sharing!

from lightning-data-grid.