|
| 1 | +<h1><code ng:non-bindable=""></code> |
| 2 | +<span class="hint"></span> |
| 3 | +</h1> |
| 4 | +<div><p>The core grid rendering cycle is executed whenever the grid needs re-rendering. There are a number of core methods, |
| 5 | +with some of those methods able to be called individually.</p> |
| 6 | + |
| 7 | +<h3 id="current">Current</h4> |
| 8 | + |
| 9 | +<p>The key method is <code>grid.refresh</code>. This method updates the rows and columns in the grid, then redraws and resizes the grid.</p> |
| 10 | + |
| 11 | +<ul> |
| 12 | +<li>grid.refresh |
| 13 | +<ul><li>rowsProcessors</li> |
| 14 | +<li>setVisibleRows</li> |
| 15 | +<li>columnsProcessors</li> |
| 16 | +<li>setVisibleColumns</li> |
| 17 | +<li>redrawInPlace</li> |
| 18 | +<li>refreshCanvas</li></ul></li> |
| 19 | +</ul> |
| 20 | + |
| 21 | +<p>By preference grid.refresh is called through a debounce function - grid.queueGridRefresh. If you use this method you are |
| 22 | +telling the grid that you want a refresh, but you're allowing the grid to consolidate all refreshes from the current digest cycle |
| 23 | +and process just once.</p> |
| 24 | + |
| 25 | +<p>A similar method, <code>grid.refreshRows</code> also exists, this is the same as grid.refresh except that it doesn't run <code>columnsProcessors</code> |
| 26 | +or <code>setVisibleColumns</code>.</p> |
| 27 | + |
| 28 | +<p>The rows and columns processors are focused on ordering and determining the visibility of columns and rows. They include functions |
| 29 | +such as sorting and filtering (impacting order and visibility of rows), grouping rows (which adds extra rows, and changes the ordering |
| 30 | +and widths of columns), and pinning, which changes which render container particular columns are in.</p> |
| 31 | + |
| 32 | +<p><code>redrawInPlace</code> determines the correct scroll percentage in the grid, and therefore which of the rows and columns should currently |
| 33 | +be visible in the viewport.</p> |
| 34 | + |
| 35 | +<p><code>refreshCanvas</code> is a complicated method that determines the sizing of each of the grid elements. In some cases it is currently iterative, |
| 36 | +for example it determines header height by rendering each of the column headers, and determining the maximum rendered height. This largely |
| 37 | +appears to be to accomodate filters.</p> |
| 38 | + |
| 39 | +<ul> |
| 40 | +<li>refreshCanvas |
| 41 | +<ul><li>buildStyles</li> |
| 42 | +<li>$timeout - calcHeaders (this is inline - should it be a style computation? It isn't a promise, and doesn't wait on the buildStyles |
| 43 | +promise, but it does run in a timeout. Conversely, it creates a promise that it resolves - but it doesn't wait for the header calc to |
| 44 | +complete before resolving the promise) |
| 45 | +<ul><li>may call buildStyles again if it decides headerHeight has changed</li></ul></li></ul></li> |
| 46 | +</ul> |
| 47 | + |
| 48 | +<h3 id="vision">Vision</h4> |
| 49 | + |
| 50 | +<p>The vision is to make the style calculations more deterministic, and remove any iteration or other dependencies. A single pass through |
| 51 | +refreshCanvas should return a correctly sized grid.</p> |
| 52 | + |
| 53 | +<p>To achieve this, we really need to:</p> |
| 54 | + |
| 55 | +<ul> |
| 56 | +<li>calculate all sizing in code, without reference to the sizing of rendered grid elements. We already do most of this for rows |
| 57 | +and columns, the main gap seems to be grid header</li> |
| 58 | +<li>we could reference rendered size to determine the grid's available size (if we want to), which could allow the grid to be more responsive</li> |
| 59 | +<li>layout all the columns first - what render container they're in etc, before we start any sizing</li> |
| 60 | +<li>calculate the column widths and element heights</li> |
| 61 | +<li>calculate the overall grid sizing based on all the elements (headerHeight, footerHeight, container widths etc)</li> |
| 62 | +<li>render</li> |
| 63 | +</ul> |
| 64 | + |
| 65 | +<p>Thinking only at this stage!!</p></div> |
0 commit comments