[Feat] Add `Figure` model and introduce KPI card functions

[huong-li-nguyen]

Description

Why introduce the Figure model?

This PR was initially intended to enable reactive Cards as we needed them for the KPI Cards. Still, several iterations and prototypes clarified that a higher-level model was required to allow any dash component to be reactive.

We've been hesitant to introduce this model as we first wanted to see if it is needed, so we started with lower-level models such as Table, Graph, AgGrid, and Card as they are also more declarative. However, in the future, we could subclass the Table, Graph, and AgGrid from the Figure, see Antony's comment here: https://github.com/mckinsey/vizro/pull/493#pullrequestreview-2100342271

As you already see, the naming is not optimal, which was also one of the reasons why we didn't go with it straight away 😄 So if you strongly disagree with Figure as a name, please raise your opinion here, such that we can find a name that everyone can accept more or less: https://github.com/mckinsey/vizro/pull/493#discussion_r1627671410

I'll split docs in a separate PR as this model needs proper documentation and probably lots of explanation, as its purpose is unclear from the naming alone. @stichbury I would probably need your help on that 👍

What does this Figure solve for? Essentially, it will enable any dash component to be reactive to controls (not filter interactions, as this logic needs to live in any subclass implementation for now). This could have already been useful and a better approach when:

• We've included the dash-mermaid chart into Vizro
• We've included custom D3 charts into Vizro
• We've helped our users make components reactive to controls that are just a combination of HTML divs
• And now, when we wanted to include reactive Cards
• Essentially including any other dash component that doesn't fall into Table, Graph, AgGrid and doesn't qualify for another sub-category (can't think of any right now anyways)

How did we get here from the KPI Card?

Ultimately, the KPI Cards are just implementations of CapturedCallables that go into Figure. However, before we got here, I considered four different approaches and did prototypes for all of them.

• If you are curious how 1 and 2 would have looked like: https://github.com/mckinsey/vizro/pull/493/commits/a1b12288f795d1defc27e2f588173ead328bb790
• Approach 3 you can see if you take a look at the code at the time of this commit: https://github.com/mckinsey/vizro/pull/493/commits/90dfcb31d7e4713e2933d654c5f1a911209f28d2

1) Use a custom chart with go.Indicator and provide to vm.Graph ❌

• Most convenient way of creating a static and dynamic KPI card without any additional core core changes
• Several drawbacks when it came to resizing custom styling that we decided to create our custom component instead
• Suitable as a temporary solution only

2) Use a custom component ❌

• The best way to currently create a static KPI Card as it allows for complete flexibility in terms of styling
• The biggest drawback is that the KPI Card cannot be dynamic (reactive to controls) due to our constraint of components only being reactive to controls when they have a figure attribute and a CapturedCallable is provided
• Suitable as a temporary solution only

3) Extend the vm.Card model with a figure attribute ❌

• Possibility to create a static and dynamic KPI Card
• Full flexibility in terms of styling
• Full flexibility for the users in terms of extension by provision of CapturedCallable
• We stuck with this one for a while, but it got messy with the current API and combining it with the pre-existing arguments text and href. While it was possible, there were several drawbacks to this approach:
  • Because the text and nav card were now provided as CapturedCallable, they started loading as well, which just wasn't nice UX as these components are static
  • The build, in the end, was not connected to the Card, and any intention to do that meant having to move the dbc.Card outer container from the CapturedCallable, which led to several issues given classNames needing to be provided
  • Given that the build was not connected to the Card anymore but could have been the higher-level model for any dash component that we might want to be reactive to controls, approach 4 made more sense ⬇️

4) Create a new component with a figure attribute ✅

• Possibility to create a static and dynamic KPI Card
• Full flexibility in terms of styling
• Full flexibility for the users in terms of extension by provision of CapturedCallable
• Unlocks many other blockers, e.g., provision of custom d3 charts or other dash components that we want to react to controls without them having to fit into Table, AgGrid, or Graph

What will be our default KPI Cards? I've created designs for 3 KPI Cards and aligned with @Joseph-Perkins that these will be the ones we want to offer by default. Users can still create their own KPI Cards by providing their own CapturedCallable. Colors, etc., might still change, but the overall structure remains the same:

• Simple KPI Card (Only title + value)
• KPI Card with Icon (title + value + icon)
• KPI Card with reference value (title + value + reference value)
• KPI Card with the reference value and icon (could be potentially done based on the three above)

Notice

• [x] I acknowledge and agree that, by checking this box and clicking "Submit Pull Request":

  • I submit this contribution under the Apache 2.0 license and represent that I am entitled to do so on behalf of myself, my employer, or relevant third parties, as applicable.
  • I certify that (a) this contribution is my original creation and (b) to the extent it is not my original creation, I am authorized to submit this contribution on behalf of the original creator(s) or their licensees.
  • I certify that the use of this contribution as authorized by the Apache 2.0 license does not violate the intellectual property rights of anyone else.
  • I have not referenced individuals, products or companies in any commits, directly or indirectly.
  • I have not added data or restricted code in any commits, directly or indirectly.

[stichbury]

I'm not sure why the linkchecker in the RTD build is upset -- it could just be that it's expecting a page to exist that won't exist until after this PR merges?

[huong-li-nguyen]

I'm not sure why the linkchecker in the RTD build is upset -- it could just be that it's expecting a page to exist that won't exist until after this PR merges?

Yes, I think so too 👍 I'll create the PR to fill that docs page soon and then I'll just merge these subsequently 👍

[maxschulz-COL]

One more random thought: are we sure about having the kpi cards in our API, as opposed to just as examples? Would avoid API changes, and maintentance, etc.?

My feeling is that we probably do want them: I am actually quite happy with supporting this API e.g. as compared to custom charts, where the whole alignment (or lack thereof) with the plotly.express API is more of a burden.

Just thought I'd raise this as a discussion point, as when we have hosted examples very soon, there might be a little less need for things to be native.

Another big pro here is of course that we can then configure KPI cards via yaml! But yh, just thought I'd raise this to gauge your view.

[huong-li-nguyen]

Another big pro here is that we can then configure KPI cards via yaml! But yeah, I wanted to raise this to gauge your view.

I feel strongly about including the KPI cards in our public API, more than any of the custom charts we plan to bring from our internal library. Apart from your arguments, it's worth adding because it's such a widespread component used in any business dashboard. Since customizing the go.Indicator for our design needs wasn't easy, this further emphasizes the need to add this component to our library. It will also bring much value to the OS community, as I've seen similar struggles on the forums.

At some point, we discussed whether we should only have one KPI card function and combine the two here. But there were a few reasons why we decided not to do that. First, we wanted to avoid exposing someone who wants a simple KPI card to an API with all these extra arguments that are also not intuitive. Hence, all of these long docstrings 😄 The other point is the concept of CapturedCallables. One of the reasons why we've introduced this is precisely for this purpose. I don't mind adding more CapturedCallables and maintaining their API as long as they are generic enough and provide value to the OS community.

Any customizations of the current KPI cards (e.g., layout changes, including subtitles or any of that sort) should live in the docs. I think the current implementations can cover 80% of what people might want to do, as any customization can be done quickly based on the existing implementations. What we did not include are KPI cards with sparklines or KPI groups that flexibly rearrange themselves based on screen width/height. For me, this can all live in docs. However, the code that can cover 80% of all KPI Cards should be added by us 👍