Flatten ?filters=(...)&labels=(...) to ?f=...&f=...&l=...&l=...

[apata]

Changes

• Moves current URL params parsing logic to legacy-jsonurl-url-search-params.ts
• Adds custom serialization logic for labels and filters in url-search-params.ts and encodeURIComponent based logic for other simple params.
• Adds redirect logic from jsonurl search params to new search params.

Tests

• Automated tests have been added

Changelog

• Entry has been added to changelog

Documentation

• This change does not need a documentation update

Dark mode

• This PR does not change the UI

[github-actions]

Preview environment👷🏼‍♀️🏗️
PR-4810

[ruslandoga]

👋

Sorry for a drive-by comment on a draft PR, but if you set the attribute key to f[]= then it would get automatically decoded into a list in Plug / Phoenix. Otherwise a custom decoder for query strings would need to be implemented.

More info: https://hexdocs.pm/plug/Plug.Conn.Query.html

[apata]

👋

Sorry for a drive-by comment on a draft PR, but if you set the attribute key to f[]= then it would get automatically decoded into a list in Plug / Phoenix. Otherwise a custom decoder for query strings would need to be implemented.

More info: https://hexdocs.pm/plug/Plug.Conn.Query.html

Thanks for bringing it up @ruslandoga ! At the moment, this format must be recognizable only to the FE and ideally humans, though. I think of it as URL-stored dashboard state.

Currently, the BE receives applied dashboard filters in URL-encoded stringified JSON, and there's an extra transform taking place https://github.com/plausible/analytics/blob/master/assets/js/dashboard/util/filters.js#L231 before that, which we're not planning to get rid of (in the interest of readable URLs).

[ukutaht]

The idea with the new filters format was to also support nesting in case we need it in the future. Stuff like:

[
  ["or", [
    ["and", [
      ["is", "visit:source",  "Google", {case_sensitive: false}],
      ["is", "visit:utm_medium", "is", "cpc"]
    ]],
    ["and", [
      ["is", "visit:source", "Facebook", {case_sensitive: false}],
      ["is", "visit:utm_medium", "paid_social"]
    ]]
  ]]
]

This format seems to make that a bit harder. Did you consider that as well @apata ?

[apata]

Good question, @ukutaht! I expect there to be a bunch of ways to do this because we know the key words: and, or, not, all operators and all operator options.

[
  [
    "or",
    [
      [
        "and",
        [
          [
            "is",
            "visit:source",
            ["Google", "Bing"],
            { "case_sensitive": false }
          ],
          ["is", "visit:utm_medium", "is", ["cpc"]]
        ]
      ],
      [
        "and",
        [
          ["is", "visit:source", ["Facebook"], { "case_sensitive": false }],
          ["is", "visit:utm_medium", ["paid_social"]]
        ]
      ]
    ]
  ],
  ["not", ["is", "visit:country", ["Estonia"]]],
  ["contains", "event:goal", ["trial"], { "case_sensitive": false }]
]

For this edgy filter tree, an URL in the new style might be

?f=or/2&f=and/2&f=is/i,source,Google,Bing&f=is,utm_medium,cpc&f=and/2&f=is/i,source,Facebook&f=is,utm_medium,paid_social&f=not/1&f=is,country,Estonia&f=contains/i,goal,trial

This would be reconstructable thanks to fixed order of f= in the URL and known group lengths.

// url.split("&").map(i => i.split("=")).filter(i => i[0] === "f").map(i => i[1]) -->
[
  "or/2",
  "and/2",
  "is/i,source,Google,Bing",
  "is,utm_medium,cpc",
  "and/2",
  "is/i,source,Facebook",
  "is,utm_medium,paid_social",
  "not/1",
  "is,country,Estonia",
  "contains/i,goal,trial",
]
// reconstruct recursively