(prompted by discussion of firebase integration on elm-dev)

Given that it would be really helpful to have more integration libraries 
available for Elm (auth0, firebase, aws...) I've been wondering if the 
current state of affairs is ideal for achieving:

1) Maximum number of integration libraries available for Elm
2) All of those implemented in pure Elm

Currently the path to get there appears to be:

1) Use an existing javascript library and wrap it using ports
2) Reimplement the library in Elm

1 to 2 often represents a significant amount of development. Because ports 
preclude a library from being published in http://package.elm-lang.org/ and 
elm package doesn't support installing them from anywhere else there's a 
social pressure to not implement effect managers or release libraries that 
make use of ports. 

Another path get to pure Elm libraries might be

1) Use an existing javascript library and wrap it using ports or native 
functions
2) Release it as a library
3) Gradually migrate the library over to pure Elm with the help of any 
members of the community that need it

The concern here is obviously that your Elm code can now blow up and 
there's no way of knowing which code is unsafe. 

What if unsafe because a first class concept in Elm? You could mark 
functions as "unsafe". Any function that calls an unsafe function would 
also be required to be declared as unsafe  e.g.


    unsafe attemptAuth : LoginDetails -> Task String AuthStatus
    unsafe attemptAuth loginDetails =
        Native.WrappedLibrary.attemptAuth loginDetails




    type Msg
        = unsafe AuthResponse (Result String AuthStatus)



    unsafe update : Msg -> Model -> (Model, Cmd Msg)
    unsafe update msg model =
        case msg of
            AuthResponse status ->




This would make it possible to do a first pass on integration by just 
delegating to the javascript implementation. It's now very clear which of 
your Elm code is safe and unsafe. Having that unsafe keyword not only let's 
you know which code carries the Elm safety guarantees (if a function isn't 
marked unsafe) but you now also have this unsafe keyword stinking up your 
code encouraging you to reimplement it in pure Elm. You're using a shared 
library now though so whenever you replace a javascript implementation with 
a safe Elm version everyone benefits.

What do you think, does this offer a practical route to a greater number of 
pure Elm integration libraries?







-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to