Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose Msg with Msg(...) #4

Closed
gabrielperales opened this issue Sep 30, 2017 · 3 comments
Closed

Expose Msg with Msg(...) #4

gabrielperales opened this issue Sep 30, 2017 · 3 comments

Comments

@gabrielperales
Copy link

I'm writing a component based on your component and I need that your component expose Msg as Msg(..) as is explained in this issue elm/error-message-catalog#215

@pablen
Copy link
Owner

pablen commented Oct 2, 2017

Hello Gabriel! I'm a bit reluctant about exposing the whole Msg subtypes because then any internal change in the Msg implementation would imply a major version bump when publishing the package as explained here: https://medium.com/@ghivert/designing-api-in-elm-opaque-types-ce9d5f113033.

Maybe I can expose some helper functions like isTransitioning : Toasty.Msg -> Bool to let you extract the internal message.

Would that help with what you are trying to achieve?

@gabrielperales
Copy link
Author

gabrielperales commented Oct 2, 2017

Hi @pablen!, I ended creating those helpers functions, and I think it is ok. I was trying to create my own toast component which was just exactly as yours but without having to pass the config record to each function. Here you can see the code and how I exposed those helper functions.

If you think there is an approach better to achieve the same thing, please let me know it :)

@pablen
Copy link
Owner

pablen commented Oct 2, 2017

Oh, so I think I misunderstood what you were trying to do here.

In your case I think those helper functions are a bit redundant because you can use the Success, Warning and Error types as constructor functions without the need of defining new helper functions.

You can take a look at the demo code, you'll notice I'm using those types in such a way:

case Char.fromCode keycode of
's' ->
(model ! [])
|> addToast (Toasty.Defaults.Success "Allright!" "Thing successfully updated")
'w' ->
(model ! [])
|> addToast (Toasty.Defaults.Warning "Warning!" "Please check this and that.")
'e' ->
(model ! [])
|> addToast (Toasty.Defaults.Error "Error" "Sorry, something went wrong...")

Also, look a few lines above how I defined a single addToast helper function to avoid having to pass the config record around every time:

addToast : Toasty.Defaults.Toast -> ( Model, Cmd Msg ) -> ( Model, Cmd Msg )
addToast toast ( model, cmd ) =
Toasty.addToast myConfig ToastyMsg toast ( model, cmd )

I think you'll be good to go with this!

@pablen pablen closed this as completed Oct 2, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants