[Bug]: ColorPicker does not accept empty color

[cpiber]

Blazorise Version

1.7

What Blazorise provider are you running on?

None

Link to minimal reproduction or a simple code snippet

<ColorPicker Color="null" />

Steps to reproduce & bug description

Set Color property to null

What is expected?

The item should be set to no color, same as when the "Clear" button is used

What is actually happening?

Black is selected

What browsers do you see the problem on?

No response

Any additional comments?

I have a strong suspicion it is because of this line:

Blazorise/Source/Blazorise/wwwroot/colorPicker.js

Line 19 in 314d97e

default: options.default || "#000000",

The JS part has a fallback again; the blazor part already sets this default, so this should not be there

[stsrki]

There seem to be two problems here.

1. As you have assumed the default: options.default || "#000000" is more corrected to be defined as default: options.default || "#00000000". Which will set the color as transparent, same as it is in preview.
2. The <ColorPicker Color="null" /> is not correct to define it as null. Remember, the Color parameter is a string type, so in this case, you have defined it as string "null" value. The expected value format should be a HEX. That means to really to define it as a null, it needs to be defined as <ColorPicker Color="@((string)null)" />.

---

We will fix the first issue.

[cpiber]

is more corrected to be defined as default: options.default || "#00000000"

That still is not correct, is it? Clicking "Clear" sets Color to null, so giving null should also work without changing the value

The is not correct to define it as null. Remember, the Color parameter is a string type, so in this case, you have defined it as string "null" value. The expected value format should be a HEX. That means to really to define it as a null, it needs to be defined as .

null is equivalent to @((string)null) because string is nullable

[stsrki]

null is equivalent to @((string)null) because string is nullable

No. The .razor engine is kinda to blame here. When it tries to solve what you define for the string parameter it takes it as it is written. In your case, the actual value for Color="null" when inspected in the debugger would be the "null", not the null.

[stsrki]

That still is not correct, is it? Clicking "Clear" sets Color to null, so giving null should also work without changing the value

This problem is from the original library. The real color cannot be undefined. So we try to have default color that makes some sense.

See simonwep/pickr#178

[cpiber]

Interesting, good to know. In my actual test I have a variable that is null and it behaves the same, so I did not notice, thanks for the info.
Still, the input should not change the color to anything without the user selecting something, and both "#000000" and "#00000000" are different from null

[cpiber]

This problem is from the original library. The real color cannot be undefined. So we try to have default color that makes some sense.

I see. The author provides a workaround in simonwep/pickr#178 (comment), would that be acceptable? I can look into implementing it

[stsrki]

That might work. Working on it.

[cpiber]

Thank you for the fast work!