rm sdmxjs dep from visions
visions should not contain sdmx related code to remain as much as possible agnostic to any business.
visions should be considered as a UI lib on top of material ui.
material ui offers buttons and panels, visions offers siscc components but not sdmx related components.
the main reason is to be able to keep using visions for different versions of sdmx in the time or concurrently.
it allows to have a stable ui despite having different data API behind.
todo:
- rm dep in code and package.json, yarn.lock & package-lock.json (npm install --legacy-peer-deps)
- mv the sdmx related code to host(s) (DE, DV?) and defines an attribute to know when to apply special class
Edited by Nicolas Briemant