feat(lib): Inherits the dark/light theme's mode management using css variables and an ODS Charts DEFAULT mode

[louismaximepiton]

Note: Please transform - [ ] into - (NA) in the description when things are not applicable

Related issues

NA

Description

TODO

Motivation & Context

Be able to use Boosted contextual dark mode to use ODS Charts dark mode. And handle the mode so it looks like Boosted v5.

Types of change

• New feature (non-breaking change which adds functionality)

Test checklist

Please check that the following tests projects are still working:

• docs/examples
• test/angular-ngx-echarts
• test/angular-echarts
• test/html
• test/react
• test/vue
• test/examples/bar-line-chart
• test/examples/single-line-chart
• test/examples/timeseries-chart

[jacques-lebourgeois]

Perhaps it would be possible to do as in the example https://www.w3schools.com/howto/howto_html_include.asp to mutualize header and footer code? This is optional, perhaps to be dealt with at a later date.

[netlify]

✅ Deploy Preview for ods-charts ready!

Name	Link
🔨 Latest commit	e00307f
🔍 Latest deploy log	https://app.netlify.com/sites/ods-charts/deploys/678a6693f5dace0008c53615
😎 Deploy Preview	https://deploy-preview-422--ods-charts.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[louismaximepiton]

Shouldn't we remove the fact that we can filll in a mode ?

[louismaximepiton]

Suggested change

	'var(--ods-blue-200, #80CEEF)',
	'var(--ods-blue-200)',

[jacques-lebourgeois]

Now, we should be able to remove fallback value.

Maybe it could help the maintenance.

but we also can do it in another PR after the last one of the series ?

[louismaximepiton]

shouldn't we have /$--[^:]*: ?([^;]*/g instead ? So if people change the CSS var, we keep their value ? If yes, same below.

[jacques-lebourgeois]

After reflexion, we are dealing only with constants from the library like

export const DEFAULT_COLORS_PURPLE = {
  color: [
    'var(--ods-purple-1, #492191)',
    'var(--ods-purple-2, #6E4AA7)',
    'var(--ods-purple-3, #9373BD)',
    'var(--ods-purple-4, #A885D8)',
    'var(--ods-purple-5, #C1A4E4)',
    'var(--ods-purple-6, #D9C2F0)',
  ],
};

so we know that any var definition has a fallback value as long as we decide to do it like that.

The fallback value should never be used but it is just a security.

We can decide that to simplify maintenance we remove the fallback value and then we will need to add the other case without fallback.

I push a commit to deal both cases. I test with :

• no default value 'var(--ods-purple-1)',
• some spaces 'var( --ods-purple-2 ,#6E4AA7 )',
• regular way 'var(--ods-purple-3, #9373BD)',