# What's new in Grid v5.0.0
## New JavaScript bundles for combining products
Each product now has a new ES module based JavaScript bundle that only contains the product specific code, called a
`thin` bundle. They are intended to be used when combining multiple products on page, to avoid having shared code loaded
multiple times. Previously if you combined for example `Grid` and `TaskBoard` on a single page you would import from
these bundles (minified size):
* `grid.module.min.js` (~993 kB)
* `taskboard.module.min.js` (~1100 kB)
Both products are built upon Bryntum's core library and hence both of them include the core JavaScript (buttons,
toolbars, helpers etc.). With `thin` bundles you would instead import what you need from each product in the hierarchy
separately:
* `core.module.thin.min.js` (~643 kB)
* `grid.module.thin.min.js` (~268 kB)
* `taskboard.module.thin.min.js` (~88 kB)
This way the shared code (from core) is only included once. With the old approach, about 2 MB of JavaScript was loaded,
with the new about 1 MB.
The gain (loss actually) will be greater if you combine products that share even more code, like `Gantt` and
`Calendar`. `Calendar` builds upon `Scheduler > Grid > Core`, while `Gantt` builds upon `Scheduler Pro > Scheduler >
Grid > Core`. When not using `thin` bundles:
* `gantt.module.min.js` (~1978 kB)
* `calendar.module.min.js` (~1833 kB)
With `thin` bundles (many since these products build upon others):
* `core.module.thin.min.js` (~643 kB)
* `grid.module.thin.min.js` (~268 kB)
* `scheduler.module.thin.min.js` (~466 kB)
* `schedulerpro.module.thin.min.js` (~119 kB)
* `engine.module.thin.min.js` (~266 kB)
* `gantt.module.thin.min.js` (~122 kB)
* `calendar.module.thin.min.js` (~164 kB)
Total ~ 3811 kB vs 2048 kB (1763 kB less).
You import from the thin bundles in the same way as with any other ES modules bundle. The difference compared to using
the full bundles is that you have to import from the correct bundle. For example to use the `StringHelper` class from
Core and `GridRowModel` from Grid, previously you would have something similar to this:
```javascript
import { StringHelper, GridRowModel } from 'grid.module.js';
```
Now you have to import them separately (since they are from different bundles):
```javascript
import { StringHelper } from 'core.module.thin.js';
import { GridRowModel } from 'grid.module.thin.js';
```
## New CSS bundles for combining products
Each theme now has a new CSS bundle that only contains product specific styling, called a `thin` bundle. They are
intended to be used when combining multiple products on page, to avoid having shared styling loaded multiple times.
Previously if you combined for example `Grid` and `TaskBoard` on a single page, using the Stockholm theme, you would
load:
* `grid.stockholm.css` (~244 kB)
* `taskboard.stockholm.css` (~243 kB)
Both products are built upon Bryntum's core library and hence both of them include the core CSS (buttons, toolbars,
icons etc.). With `thin` bundles you would instead load each product in the hierarchy separately:
* `core.stockholm.thin.css` (~203 kB)
* `grid.stockholm.thin.css` (~40 kB)
* `taskboard.stockholm.thin.css` (~40 kB)
This way the shared CSS (from core) is only included once. With the old approach, about 487 kB of CSS was loaded, with
the new about 283 kB (204 kB less).
The gain (loss actually) will be greater if you combine products that share even more styling, like `Gantt` and
`Calendar`. `Calendar` builds upon `Scheduler > Grid > Core`, while `Gantt` builds upon `Scheduler Pro > Scheduler >
Grid > Core`. When not using `thin` bundles:
* `gantt.stockholm.css` (~659 kB)
* `calendar.stockholm.css` (~655 kB)
With `thin` bundles (many since these products build upon others):
* `core.stockholm.thin.css` (~203 kB)
* `grid.stockholm.thin.css` (~40 kB)
* `scheduler.stockholm.thin.css` (~363 kB)
* `schedulerpro.stockholm.thin.css` (~10 kB)
* `gantt.stockholm.thin.css` (~27 kB)
* `calendar.stockholm.thin.css` (~47 kB)
Total ~ 1314 kB vs 690 kB (624 kB less).
In your html file, you would for the `Gantt` + `Calendar` scenario have something similar to:
```html
```
Note the usage of the data-bryntum-theme attribute above, it is required if the app will be switching theme
at runtime using DomHelper.setTheme().
## Grid navigation and accessibility
In keeping with ARIA guidelines, the individual cells of a grid are now focused when navigating
cell-to-cell in a grid.
Previously, the outermost element was focused and navigation was purely programmatic. The focused
cell was tracked and a class added to it.
Now, a roving focus is used. Cells are not focusable by default, but are assigned a `tabIndex` when
they are required to be focused.
The `focusedCell` and the events emanating from cell navigation are now *driven by* focus motion, however
that is instigated, rather than as a result of an API request to navigate.
Tabbing onto a grid for the first time focuses the first column leaf header.
Tabbing into a grid that has previously contained focus returns focus to the previously focued cell.
### Keyboard navigation
The grid header row is treated as row 1 of the grid, and leaf column headers are the cells in that row.
When a header cell is focused:
* SPACE invokes the column header menu.
* ENTER sorts that column if it is sortable.
* DOWN moves to the first fully visible cell below the header.
Navigation cell-to-cell within the grid proceeds as per ARIA guidelines.
If a cell contains focusable components, they are focused upon entry to that cell by default.
For example in an `ActionColumn`, when its cells are navigated to, the first `button` within that cell
is focused. `TAB` works within the cell. `ESC` pops focus back up onto the encapsulating cell. Arrow keys navigate out
to other cells as usual.
### Cell editing
Cell editors are now inserted into a cell's DOM so that navigation remains within the edited cell.
## Tree grouping
Grid has a new [TreeGroup](#Grid/feature/TreeGroup) feature that can transform a tree structure at runtime, letting you
reconstruct the tree on the fly. It accepts an array of field names or functions that output a value, which it uses to
create the parents in the tree. Comes with a new demo,
[tree-grouping](https://bryntum.com/products/grid/examples/tree-grouping/).
Try it out in the live demo here:
### TextAreaField split into two classes
TextAreaField was split into two classes, `TextAreaPickerField` for use as column cell editor and `TextAreaField`
for use in a form type context.
## Simplified test case creation
When reporting a hard to reproduce issue on Bryntum's support forum we often request a test case showing the issue.
Getting a good test case greatly reduces the time it takes from reporting the bug until a fix can be released. Worst
case we won't be able to find and fix the bug at all without one.
We understand that for complex apps it is not always trivial to produce a standalone test case. The app might be using
a lot of different configs and the issue might only appear with a certain dataset etc. To simplify the process of
creating a test case we have added a new function called `downloadTestCase()` to all Bryntum products. Running it
collects the current value for the configs your app is using, inlines the current dataset and compiles configs and data
into a JavaScript app that is then downloaded.
The app will most likely require manual tweaking before you can submit it to us, but we are hoping it will make creating
a test case easier for you. Run `grid.downloadTestCase()` on the console in a demo to try it. Any feedback on how
this could be improved further is welcome on the forums!
## Auto-saving state
Grid allows persisting state changes automatically. See updated
[state](https://bryntum.com/products/grid/examples/state/) demo.
Resize columns, rearrange them, sort or filter the store and after refresh application state will be restored, no
special action is required.