Revision code Ext JS / GridView

At one time I arrived in the confidence that the code
js usually do not need to write so that it is
the most optimal. "Client part" - I said, - "the server does not
will affect, and therefore, you can score. " Unfortunately, it turned out that it is not quite
So.

This article contains technical information. If you do not understand what is written here, please do not minus.


It all started with the use of the library
EXT JS on our project, but
specifically the EditableGrid widget. Originally
I really liked the library. First of all, its object-oriented
structure. Problems began later. Looking ahead I will say that I am still
I remain a fan of EXTJS. Another library that would be the same
logical and offered such opportunities I do not know. In addition, should
note that obvious performance problems started either with
a large number of columns in the table, or with a large number of rows (about
This is the library developers, however, warned).
')
You can read some common js problems here.




CSS - Cascading Style Sheets - “what's the word for
cascading? ”



In fact, this problem was pointed out to me by our
html coder (Zhenya, hello!
J)

Take a look at the css file,
which is used.

Yes, sometimes styles are specified cascade, but in
overwhelmingly - NO. “What is the problem?” You ask. For me,
as for a java programmer, the problems are not
existed until I implemented the grid on the open page. AND…
I have all the styles floated. Grid looked awful. What's the matter? The fact is that on
page used common css styles for everything
of the project and they had a higher priority than the styles that are described in
grid.css. Why
so - I will not explain to you. I understand this as “the more accurate the path, the higher
style’s priority ”, at least such an explanation works for me. there is
another modifier "! important", but as I was told, it is better not
abuse. I hope, considering the number of professional designers
here in the comments will be an explanation.

So, for myself, I concluded - use the word
"Cascading" in the definition of CSS.



Update CSS rules or first brakes



It turned out that according to the requirements in one of the grids you need
It was display 20 columns. “Small number” - as I thought. It turned out that
not.

Ext.grid.GridView uses a fun mechanism to specify the width of the columns. When drawing
creates a <style> node in which
empty view styles are written:



# [grid ID]
.x-grid-col- [number
columns] {

2}



For example:



# grid-example .x-grid-col-0 {

2}





When the html code is ready,
these dynamically generated styles are modified and indicated
width of each column. For each such style is performed



Ext.util.CSS.updateRule



I must say that this is not a cheap operation. And for 20
speakers observed significant brakes. Thus had to optimize
this mechanism to remove the tangible pause that occurred since
downloads, until the moment when the user could really do something.
In addition, the processor load was 100%.

I initially generated not empty styles, but immediately
created filled with set widths
(width). Rolled, but then it had to
clean up (see below).

So, for myself, I concluded - do not use
dynamic update of CSS tables.



A large number of elements or "well, how much can
shove?"



You will see approximately this code for each cell in
gridou:



<td class = "x-grid-x-grid-td-1
x-grid-cell-5-1 "tabindex =" 0 ">

<div class = "x-grid-col-1
x-grid-cell-inner ">

<div class = "x-grid-cell-text" unselectable = "on"> $ 31.61 </ div>

</ div>

</ td>



This is just ONE cell. It turns out that except
td, the hapless browser will need to keep more
at least two DOM objects. It takes memory
and resources.

In my opinion, this should be avoided.



Working with a DOM table or "well, that's dead"

It should be noted that in the forums, developers honestly
warn that working with a large number of lines will slow down and
should use pagination. But ... users are always right and
did not want to see the pages. In fact, there is a simple way
optimize the grid to work with quite a large number of rows (I have
Works with 500 no brakes).



What was the problem? The fact is that
GridView uses table view.
Delete / insert / edit operations were very slow, if
the number of lines was more than 20 (with the number of columns more than 15). It and
clearly, the table is not just an array, but the whole object that is needed
recount / redraw. In addition, when all values ​​change in any
column (for example, a calculated column that depends on an external parameter)
the browser just died and never came to itself.



How was this decided? From the profile I realized that working with
large tables (> 20-30 rows) takes an order of magnitude longer than
with small (<20 lines). After that, I looked at the implementation
Google Spreadsheet. Here is
what I found there: they don't use one big table, but break into
many small, which are located one under one. In addition, the width
columns are not specified by styles, but, more logically, through the width of the first row
using style
table-layout:
fixed



Result

Thus, GridView has been rewritten with the following rules:

- Use CASCADE styles

- Do not add extra items in
Dom

- Do not use dynamic style update

- Split large tables into several
little ones

As a result, I received
EditableGrid that can work with large
number of lines.