search

avh4 / elm-color

Standard representation of colors, encouraging sharing between packages. (This replaces elm-lang/core#Color from Elm 0.18.)
BSD 3-Clause "New" or "Revised" License
23 stars 6 forks source link

Expose toHex and fromHex functions. #24

Open AsbjornOlling opened 4 years ago

AsbjornOlling commented 4 years ago

These can be useful, and are already implemented. Let's expose them.

I understand that the have been hidden before the release of 1.0.0, but I don't see any good reason to not expose them. In contrary, I think these functions will often be useful.

There are open issues where a handful of users are dissatisfied with this decision

20

The only code change is exposing these two functions, and adding @docs tags in the appropriate places.

avh4 commented 4 years ago

Sorry for the slow reply.

The reason I didn't expose them was because there were some API decisions that needed to be made that didn't seem to have a clear answer. Specifically, a lot of uses would prefer to have a fromHex : String -> Color instead of String -> Maybe Color. I'll take another look at the other discussion thread, though.

tortis commented 4 years ago

FWIW, It doesn't seem crazy to me for the user to add a Maybe.withDefault to handle the Maybe Color. They could even write their own wrapper function that uses their preferred fall back color.

jmpressman commented 3 years ago

Just figured I'd check in here. Is this likely to be merged in or should I just go ahead and create my own functions?

AsbjornOlling commented 3 years ago

I went ahead implemented my own functions (basically an exact copy of those in this module).

Would still love to see this merged though.

Pinging @avh4

loicknuchel commented 3 years ago

Hi, If I could add my voice here, I agree that String -> Maybe Color is totally reasonable as we expect some safety in Elm. It would be awesome to have them merged, but for now, I will just copy the implementation in my own files :man_facepalming:

ChristophP commented 2 years ago

Hi there,

@avh4 what would be the API design concerns regarding the use cases that would prefer fromHex to be String -> Color instead of String -> Maybe Color?

As far as I'm concerned I would appreciate that safety I get from the Maybe and that would be expected for me as other libraries handles a string to x conversion similarly with a Maybe. Some examples here:

I think there are two places those hex strings would most likely come from:

  1. From the API -> in that case they would be handled in a decoder, where it is easy to let the decoder fail
  2. from user input -> in that case I might handle the maybe case in my update function and display and error if the input was wrong.

Would it be an option that avh4/elm-color exposes the fromHex function as String -> Maybe Color and users who need it without the Maybe can just wrap it in their own code like this according to their needs? 

fromHexWithDefault : String  -> Color
fromHexWithDefault = fromHex >> Maybe.withDefault Color.black
kimtore commented 2 years ago

Please merge this, it would be a quality of life improvement (and I wouldn't have to fork it into my own repo.)

escherlies commented 1 year ago

Hi all 👋

since this package seems to be stale, I created a library that shares the same API and thus could be used as a drop-in replacement, if anyone is interested!

It also exposes fromHex, fromHexUnsafe and many more functions to work with colors in elm.

📦 https://package.elm-lang.org/packages/escherlies/elm-color/latest/

Would love to hear some feedback! (Feel free to open an issue for that)

Peace ✌️

kutyel commented 1 year ago

Hi @avh4 I also stumbled upon this and would find those functions useful, actually had to copy the code from your lib which is not ideal, thanks in advance! 🙏🏻