# Limitations ## Use with the Legacy Loader API The dgrid package was designed primarily with AMD in mind; as such, it has been tested primarily using the `require` and `define` APIs available in Dojo 1.7+. When using the legacy `dojo.require` method instead, loading `dgrid/List` will not work without first loading `dgrid.css`. This is because otherwise the `xstyle/css` plugin will resolve asynchronously, which is not suported by the legacy loader. To use `dgrid/List` with `dojo.require`, make sure you have `` in your `` before loading `dgrid/List`. This also applies for stylesheets loaded by specific mixins (such as `dgrid/ColumnSet`) or extensions (such as `dgrid/extensions/ColumnResizer`). ## Reuse of Column Definitions Reusing a single column definition object between multiple grids (e.g. `var cols = {...}, gridA = new Grid({ columns: cols }), gridB = new Grid({ columns: cols })`) is *not* supported, and will not function properly. Always create a fresh `columns` object for every grid you instantiate. If multiple grids in a single page are likely to use the same column structure, in order to avoid code repetition, you can create a function which returns the structure, but creates it every time it is called. For example: ```js function getColumns () { return { col1: { label: 'Column 1', editor: 'text', editOn: 'dblclick' }, col2: { label: 'Column 2', sortable: false }, // ... }; } var grid = new Grid({ columns: getColumns(), // ... }, 'grid'); var secondGrid = new Grid({ columns: getColumns(), // ... }, 'secondGrid'); ``` ## Column Definitions: Coexistence of formatter and renderCell The default `renderCell` logic is specifically written in such a way as to honor any `formatter` that is defined on the column definition. If a custom `renderCell` function is specified, however, it will override the default logic which is responsible for honoring `formatter`, and thus the custom `renderCell` logic will take precedence. ## Tree: Duplicate items at multiple levels not supported In rare cases it may be possible for hierarchical store structures to contain references to the same item under multiple distinct parents. dgrid 0.3 had partial support for this since version 0.3.2, but it was never complete support in that some operations became limited to the top level. Fully supporting this would require adding complexity to both implementation and public APIs, so instead we have elected to remove it in dgrid 0.4. All store items should always contain unique IDs - if necessary, unique IDs can be generated by composing several other fields together (e.g. parent and child IDs).