Reduce dashboard position_json data size

[graceguo-supercat]

this is to fix issue #5532.

This PR covers following things:

• remove DASHBOARD_ and _TYPE prefix/suffix in component ids (and db migration for saved data).
• remove leading and trailing white spaces in stored position_json data
• when user tries to save dashboard, check the size of position_json:
  • if larger than threshold, show error message and user can't save it
  • if size is larger than 90% of threshold, show warning message and user still can save it.
  • add dashboard config for dashboard position threshold, default is 65535.

@john-bodley @michellethomas @mistercrunch

[kristw]

The first 3 lines seem to provide redundant information.

ROOT_ID: { // << key
  type: 'ROOT',  // same information that can be parsed from key
  id: 'ROOT_ID', // always same with key
  children: ['GRID_ID']
}

If we were to keep type as part of the ID, can we make id = ${type}_${identifier} a convention and get rid of type field in the object?

The id field value (e.g. ROOT_ID) is always equal to the key. Could we construct that if needed when parsing?

ROOT_ID: {
  children: ['GRID_ID']
},
GRID_ID: {
  children: ['CHART_123']
}.
CHART_123: {
  children: [] // this field seems redundant for leaf nodes. 
} 

or if these are stored as an array instead and converted to hash after parsing.

[
  { id: 'ROOT_ID', children: ['GRID_ID'] },
  { id: 'GRID_ID', children: ['CHART_123']},
  'CHART_123' // plain string when no children or other metadata
]

p.s. I haven't read the dashboard engine code so not sure how much change this will affect that code or are there other constraints? Just think that these approaches may save more space.

[graceguo-supercat]

@kristw Thank you for all the good comments! Here are my explanations:

• Keep an id: [key] property is a good practice for normalized redux state: https://redux.js.org/recipes/structuringreducers/normalizingstateshape. It did duplicate the entry key, but it gives us a lot of convenience when access/traverse the data itself.

• Encode type information in id property is optional, i still want type as a mandatory property. Currently id has type information, but it is optional (for easier debug). In the worst case we can remove type from id. But most of code won't affected since we have type mandatory property.

• remove children:[] from leave node is a good idea, but it also involved both frontend JS and more complicated migration code. I also feel in our code base we assume children property is required for all nodes. it required a lot tests before we can remove it.

[williaster]

lgtm! thanks for making this more concise!

[williaster]

do you need the print? seems potentially useful

[graceguo-supercat]

yeah. i can see results from deployment log, kind of reduced 50% spaces...