Handle old dashboard configuration more gracefully

[mtheoryx]

We've run into this issue a few times on stream, and I'm sure some of you also have run into it locally.

Currently, all the state is stored but sometimes can drift when new features come rolling in. It's quite frustrating that we don't have an upgrade path or at least a way to let the user know there is a conflict.

I'm opening this just to get a dialogue started and get some thoughts out there!

Here are some initial ideas:

• A way to detect state drift
• A way to alert users of a state drift problem, and optionally remediation for them?
• Perhaps a second look at how we're storing state?

Toss in some other thoughts or ideas, we can do this together!

Cheers all! @mpaarating

[mtheoryx]

So I've been thinking some more about this, and wanted some feedback... Consider a tale of a few states

I don't have a dashboard built

Great! We all start with no dashboard, currently, but a default is proposed in #73 so that may change.

I have a default dashboard saved

Ah, I see you've been around here before. Here's where there may be dragons. We could compare object properties in the old vs the new that "wants" to be created, and inform the user they have a now-invalid dashboard config.

If it's pretty similar in structure to the default dashboard but the data shape has changed and we didn't handle that in code (add new object property, be responsible to fix this for objects missing the prop by adding a sane default and alerting the user).

I have a custom dashboard, and please do not mess with it!

Like above, but... please don't mess with my board! Now, what do we do?

Now, for use cases in my thought process that powered the above line of thought:

1. New user trying this out for the first time, wants to experiment
2. User likes the repo, wants to save the dashboard
3. User is literally using this for something important

I'd love to see this one fixed, and happy to help. There are a lot of unanswered questions and assumptions though, and I need some feedback :)

[mtheoryx]

As discussed on stream, imagine this is like when you have a Rails app. You write a feature that introduces a schema change.

You then would want to have a schema migration process for existing users to run. Should they not run it, we should handle that by alerting them that there is a pending migration that needs to be run.

It's like noop:db:migrate :)