Tidy demo apps and `examples` folder

huong-li-nguyen commented 7 months ago

Description

Create 3 separate demo apps: demo: Dashboard with gapminder data (pydantic + yaml + notebook) features: Dashboard with all our relevant features (pydantic + yaml) _dev: Simple Dashboard that we can use for dev purposes (pydantic only)
Update integration tests to test for demo, features and dev dashboard
Remove dict and json examples from demo dashboard
Update hatch commands, you can now run the relevant demos as follows:
- hatch run example : Runs the dev dashboard
- hatch run example-demo: Runs the demo dashboard
- hatch run example-feat: Runs the features compendium dashboard
Minor fixes to docs
Update notebook and yaml for demo dashboard

Screenshot

Dev - Dashboard

Features - Dashboard

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 / or (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.

petar-qb commented 7 months ago

I'm just curious..

What did we decide about adding dict and json examples?
Why is the _dev example underscored if it is the default run with the hatch run example?
Do we also need to add hatch run example-dev (and still keep this shortcut hatch run example)?

huong-li-nguyen commented 7 months ago

I'm just curious..

What did we decide about adding dict and json examples?

Why is the _dev example underscored if it is the default run with the hatch run example?

Do we also need to add hatch run example-dev (and still keep this shortcut hatch run example)?

We decided to remove dict and json as the json example can be easily retrieved by using a yaml to json converter and the dict version we initially had due to legacy reasons (not relevant anymore). All of the 4 methods are still shown in the docs for the Dashboard.
I've kept _dev underscored because this is not supposed to be a public-facing demo, it's basically our playground. There will probably be another demo coming, which is a more basic example and will be public-facing. It won't be part of this PR though
I am actually fine just having one short-cut for it. Reduces confusion as there is only one way to call it 😄

huong-li-nguyen commented 7 months ago

@antonymilne - any idea why the linting fails on the json inside the devcontainer? I didn't change it and somehow the pre-commit hook cannot fix it automatically? I can't fix it locally either 😅

Do we even need that file if we don't have a code tour anymore?

antonymilne commented 7 months ago

@antonymilne - any idea why the linting fails on the json inside the devcontainer? I didn't change it and somehow the pre-commit hook cannot fix it automatically? I can't fix it locally either 😅

Do we even need that file if we don't have a code tour anymore?

We should keep this file because it's useful for codespaces in general even without code tour, and actually it's something I'd like to work on more in future.

No idea why it would fail linting all of a sudden, especially because it passes the pre-commit.ci checks on commit [pre-commit.ci] auto fixes from pre-commit.com hooks, which I trust more than our own checks.

The only things I can think of are:

make sure you're using Python 3.11 to do hatch run lint locally to try and reproduce what CI does
downgrade the version from v4.0.0-alpha.8 to something non-alpha
put in

maxschulz-COL commented 7 months ago

While working on the AG Grid yaml docs, I have realised that I think the yaml dev version would also be good. It's also something we do not need to keep in sync, so it is a one time effort. It would be great if you could add that one too.

Like that we can all set our PyCHarm/VSCode run configurations to both scripts, and its super quick to test either implementation and test the examples

huong-li-nguyen commented 7 months ago

While working on the AG Grid yaml docs, I have realised that I think the yaml dev version would also be good. It's also something we do not need to keep in sync, so it is a one time effort. It would be great if you could add that one too.

Like that we can all set our PyCHarm/VSCode run configurations to both scripts, and its super quick to test either implementation and test the examples

The AG-Grid I would expect to be added to the examples-feat dashboard? And then we should have a yaml version there? I can also add a yaml version to dev though. The reason why I initially just added the pydantic version in there was to show how the structure of a basic app would be (so not extra path for assets for example).

But I guess we're mixing dev and basic app again 😅

maxschulz-COL commented 7 months ago

While working on the AG Grid yaml docs, I have realised that I think the yaml dev version would also be good. It's also something we do not need to keep in sync, so it is a one time effort. It would be great if you could add that one too. Like that we can all set our PyCHarm/VSCode run configurations to both scripts, and its super quick to test either implementation and test the examples

The AG-Grid I would expect to be added to the examples-feat dashboard? And then we should have a yaml version there? I can also add a yaml version to dev though. The reason why I initially just added the pydantic version in there was to show how the structure of a basic app would be (so not extra path for assets for example).

But I guess we're mixing dev and basic app again 😅

Hm yh, so for me it was independent of the AGGrid. Just as a place to paste a quick yaml config that is based on one registered dataframe (potentially gapminder). Ideally we should have in the python part of that yaml version all datasets registered that are used throughout our examples. Like that a developer can immediately paste any yaml config, and test an isolated example.

wdyt?

huong-li-nguyen commented 7 months ago

While working on the AG Grid yaml docs, I have realised that I think the yaml dev version would also be good. It's also something we do not need to keep in sync, so it is a one time effort. It would be great if you could add that one too. Like that we can all set our PyCHarm/VSCode run configurations to both scripts, and its super quick to test either implementation and test the examples

The AG-Grid I would expect to be added to the examples-feat dashboard? And then we should have a yaml version there? I can also add a yaml version to dev though. The reason why I initially just added the pydantic version in there was to show how the structure of a basic app would be (so not extra path for assets for example). But I guess we're mixing dev and basic app again 😅

Hm yh, so for me it was independent of the AGGrid. Just as a place to paste a quick yaml config that is based on one registered dataframe (potentially gapminder). Ideally we should have in the python part of that yaml version all datasets registered that are used throughout our examples. Like that a developer can immediately paste any yaml config, and test an isolated example.

wdyt?

I've added the yaml to the dev folder now

maxschulz-COL commented 7 months ago

I've added the yaml to the dev folder now

Which datasets are we registering? For now I guess only gapminder?

huong-li-nguyen commented 7 months ago

I've added the yaml to the dev folder now

Which datasets are we registering? For now I guess only gapminder?

iris for the dev example

huong-li-nguyen commented 7 months ago

I didn't look through the features dashboard in detail because others have already done so, but generally this looks great! Thanks very much for doing it.

I think we should try to simplify the directory structure slightly. Can we change the structure of demo to look like this?
demo
├── app.py
├── assets
│   └── ...
├── jupyter_version
│   └── app.ipynb
└── yaml_version
    ├── app.py
    └── dashboard.yaml
So the default folder no longer exists, and I've renamed some folders too. Same changes would apply to features. Then we can change the default app.py to not take user_assets_folder argument any more.

Is it possible to put the images that are top-level inside assets inside assets/images instead? Certainly with app.svg and logo.svg that should work (it's actually the main reason we rolled our own infer_images function rather than use Dash's own one), not sure about favicon though but I think probably not possible for that.

After that let's talk about the best way to make changes to hatch.toml and the tests, because I think the previous setup was tidier and we should still be able to achieve something very similar without such heavy changes.

Do we have a list somewhere of all the other various future ideas/TODOs for demo dashboards, like the stuff I mentioned on slack? Would be good to keep track of it :)

Can do - we can talk about the required changes to hatch.toml later in the call then. I think the separate folders with default / yaml_example made it easy to configure the hatch commands. Not sure how it will look like now?

1 ✅ 2 ✅ 3 - currently broken 4 ✅ https://github.com/McK-Internal/vizro-internal/issues/520

maxschulz-COL commented 7 months ago

I've added the yaml to the dev folder now

Which datasets are we registering? For now I guess only gapminder?

iris for the dev example

Awesome! Could we also register gapminder and gapminder_2007 just for ease of use?

mckinsey / vizro