fix: remove d2

[edoardo]

Implements DHIS2-19197

---

Key features

1. get rid of d2 entirely

---

Description

This branch has changes to remove the need for d2.

---

TODO

• figure out how to use the user data store without d2
• lots of regression testing
• fix tests, particularly the App.js tests, but before touching them we should figure out how we want to test, what should
  be tested in Cypress and what in unit tests
• look for and clean up more code not needed
• see if it's possible to avoid fetching all user authorities to check for the ALL, do we really need the isSuperuser flag?
• fix DimensionsPanel.spec.js: figure out how to mock the cachedDataQuery / provider (tests are skipped)

---

Known issues

• the user data store is used to store the visualization object when switching visualization from DV to Maps. Currently it relies on d2 as it's using some classes defined in that package.
• now that with this PR DV uses the app service data for getting/setting the current AO in the user data store, Maps should be updated in order to read the AO from the same key, since the app service stores the key under settings. Fixed here.

---

Screenshots

Not very meaningful but this is the app running on this branch:

[dhis2-bot]

🚀 Deployed on https://pr-3023.data-visualizer.netlify.dhis2.org

[HendrikThePendric]

These changes all look great, the bundle size will have decreased and I think the code is a lot easier to follow in many places now. The changes we discussed when you walked me through the changed have all been implemented, so I think this is ready for KFMT now 🚀 .

[HendrikThePendric]

Just one additional note after my approval. If fixing the SonarCube issue is easy to do then it would be good to address it.

But on the other hand:

• The level of complexity was already present, you actually simplified this code.
• It's a bit of a false positive anyway, the code is indeed 4 levels but that's just because there are two nested describe scopes and one it, so the "brain overload" tag here is not really applicable.

[edoardo]

Just one additional note after my approval. If fixing the SonarCube issue is easy to do then it would be good to address it.

But on the other hand:

• The level of complexity was already present, you actually simplified this code.
• It's a bit of a false positive anyway, the code is indeed 4 levels but that's just because there are two nested describe scopes and one it, so the "brain overload" tag here is not really applicable.

I refactored the test and extracted the intercept function.

[jenniferarnesen]

Cypress testing best practices would suggest that the whole describe should be in a single test:
https://docs.cypress.io/app/core-concepts/best-practices#Having-Tests-Rely-On-The-State-Of-Previous-Tests
https://docs.cypress.io/app/core-concepts/best-practices#Creating-Tiny-Tests-With-A-Single-Assertion

You can leave the old titles as comments if you feel that is informative

[edoardo]

Refactored.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
21.2% Duplication on New Code

See analysis details on SonarQube Cloud