(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.