ExtJS: Performance Best Practices

[mitchellsimoens]

If your grid needs to display data a different way than what is given, isn't that a view thing not a data thing?

[Jangla]

If your grid needs to display data a different way than what is given, isn't that a view thing not a data thing?

Well, standard aside, my question really comes down to performance? Rearrange the data a dozen different ways in the store and use a templatecolumn or have the minimum neccessary fields in the store and use a rendered on the column which call a function to arrange data for you and apply it to a tpl?

[vadimv]

If your grid needs to display data a different way than what is given, isn't that a view thing not a data thing?

Yes. I missed to write that depends on the case. An example to what I said is: I have one model with a 'name' field, and I can't control how server data is returned, and is one store per view.

            { name: 'name', type: 'string', convert: function(v,record){
                switch(record.raw.evtype){
                    case "MOTION":
                    case "DISCONNECT":
                    case "RECONNECT": {
                        return record.raw.camera_name;
                    }
                    case "ACCESS_CONTROL" : {
                        return record.raw.ac_dev_name + ':' + record.raw.ac_user_name;
                    }
                    case "PARTITION-CHANGED-STATUS" :
                    case "ZONE-CHANGED-STATUS" :{
                        return record.raw["orig.name"]
                    }
                    case "SMS":
                    case "MMS":
                    case "MAIL": {
                        return record.raw.dest;
                    }
                }
            }}

[mitchellsimoens]

Best performance is to get the data exactly how you want from the server. After that it's best to do it in the model. Lastly the view.

Just depends on what you are going to be doing with the data as there isn't a silver bullet to work with all use cases. For example, say you have 15 views using the same store (yes, I've done it and more for enterprise needs) but not all of them may display; maybe 7 of them get displayed for a particular user session, the other 8 aren't used very much. Are you going to bloat your data to fit all 15 views or should each view handle itself. If you used a convert function and added extra fields to the model then you have a large up-front performance hit where as if you did it in the views it would be smaller performance hits as the application is used. Sure the smaller hits may add up to more than the up-front hit but since it's spread out over the application usage it isn't felt by the user as much as the up-front hit is.

[vadimv]

Best performance is to get the data exactly how you want from the server. After that it's best to do it in the model. Lastly the view.

very well said

[logn]

We have noticed that using the compiled version of Sencha is 10-15x faster. Also storing html locally v/s loading it from the server is obviously much faster

[natedsaint]

mitchellsimoens originally offered up the concept of removing tabs or cards that were not visible.

Our team is interested in this concept, as we are in the process of moving from a "desktop" layout with individual windows to one that uses a card layout to swap between the views. To make for a better UX, we are considering not forcing the user to "close" the cards they aren't looking at, so they can just focus on the task at hand rather than managing a slew of windows/cards/tabs/whatever. This could potentially mean a big memory footprint, but in testing it seems to be well within the thresholds we can handle. The real problem is the hugely cluttered DOM, which is now full of hidden elements, and I imagine the event listeners that are polling with no results (though I'm not as familiar with those types of optimizations so I could just be stretching there).

When you mention "deleting" the views not visible, are you talking about creating an override or modification to the card layout that removes the dom nodes and caches them somewhere for re-entry? If so, how can you re-add event listeners and cache references/etc after an Ext.removeNode has occurred? Or are you more specifically saying that you completely delete everything and force a re-load if they re-visit those tabs/cards later? Or are you talking about something completely different? Can we see a code example?

Thanks for your ideas, this thread is pretty great.