Decouple insights components from URL

[paolodamico]

Currently we store the state of analytics on the URL. Each individual component (e.g. date range filter, interval filter, ...) fetches the state from the URL and updates it there. By now, we've realized this presents quite a few complications:

• Backward-compatibility issues with URLs when we change parameter definitions.
• Code gets quite messy, hard to track down where changes are happening.
  • Some repeated logic across insights.
• Long URLs that are hard to share.
• Screws up the intuitive back button of behavior of the browser, as going back will undo the previous action that affected the filters instead of actually going back.

We need to think about how best to handle this, but ideally we would store the state someplace else. We might need to store states in the backend too to create reusable URLs.

Additional context

• We probably want to introduce Make saved reports a top-level feature #3408 first.
• @timgl worked on this at some point, he may have some useful insights on this.

[mariusandra]

Finally had a chance to make progress towards this. First step, #4966 fixes the final of the 4 points:

• Screws up the intuitive back button of behavior of the browser, as going back will undo the previous action that affected the filters instead of actually going back.

The other points are still valid:

• Backward-compatibility issues with URLs when we change parameter definitions.
• Code gets quite messy, hard to track down where changes are happening.
  • Some repeated logic across insights.
• Long URLs that are hard to share.

[paolodamico]

Is this important to prioritize for next sprint (1.31.0 2/2)?

[mariusandra]

There are two things still to do with this task:

1. Change view mode /insights/123?insight=TRENDS&bla=asd&date_from=-7d to /insights/123, only add filters if overridden (e.g. changed date filter)
2. Put filters into hashParams: /insights/123/edit?insight=TRENDS&bla=asd&date_from=-7d --> /insights/123/edit#q={insight:'TRENDS',bla:'asd',date_from:'-7d'}

Regarding priorities, I think we have worse offenders to fix. This should still get done, and should be in the list, but probably low.

[paolodamico]

@mariusandra I believe all your recent work and particularly the huge PR merged today addresses this, so closing. But please reopen if I'm missing something.