feat: Dynamic most recent date filter

[bprusinowski]

This PR:

• changes the configurator temporal filters to use date pickers instead of select elements (to be consistent with interactive filters where this is already the case),
• introduces a "pin to most recent date" feature to configurator temporal filters, to make a published chart always show the maximum available date as default.

TODO

• 🎨 UI of the feature will need to be adjusted once we have design ready

Context

For the description of the technical approach see this Notion document.

How to test

⚠️ Part of testing is only possible if you have a control over a test cube in Cube Creator!

1. Start making a chart using the cube you own that contains a temporal dimension. Use deployment preview link.
2. See that the application now uses date picker instead of select element to select the filter value.
3. See that it's possible to pin the temporal dimension filter to most recent value.

4. Publish the chart.
5. Update the cube to contain more recent date.
6. See that the published chart updated to this date.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
visualization-tool	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 8, 2023 3:48pm

[KerstinFaye]

@bprusinowski Could we adjust a little bit on the margins and paddings: https://www.figma.com/file/Hn9wvuEYLUmdJtg4KwZYUx/visualize.admin.ch---design?type=design&node-id=2151-136045&mode=design&t=eufhsDZ6QmDsMILm-4

[bprusinowski]

Sure, will do! :)

[ptbrowne]

Not sure I understand this 😓 Can you give me an example, or add a test 😁 ?

[bprusinowski]

I'll add a test, but just to explain: possible filters coming from the backend do not return VISUALIZE_MAX_VALUE, but rather an actual date (e.g. 2023), so if we didn't replace it back with VISUALIZE_MAX_VALUE, we would potentially trigger an update that shouldn't happen (as in fact, the pinned date didn't change, but is still equal to VISUALIZE_MAX_VALUE). Maybe it would make sense to already do this replacement on the backend side? 🤔

[ptbrowne]

LGTM 👏 One unit test on buildFilters could be good ?

[ptbrowne]

Nit: Instead of relying on the state usesMOstRecentDate, I think it is preferrable to rely on the checked value coming in the 2nd argument of the callback. This way the function could be stable, and I think it'd be clearer since here you have to think "ok usesMostRecentDate is true, so when it is clicked it shuold be false, and the max date should be used". IN the callback, the checked parameter is already right, so I think it's clearer.

[ptbrowne]

Function could be extracted for clarity ? It could aso be memoized ?

It made me think that if we'd use react-query, we could cache the sparql client results. Then I remember that we are using urql for it's graphql abilities 🤷

[bprusinowski]

Yup, it can be extracted 👍 But for memoization I am not sure how would you memoize it, I guess when it's extracted it's already "memoized"? (as we are not in the useMemo world here in the backend 😅)

[bprusinowski]

Thanks for the review @ptbrowne 🙇‍♂️ I'll try to tackle the changes this week, otherwise I'll make a note to myself to do it in the new year 😅