Hi Oliver, Your code sample looks very similar to https://github.com/eirslett/elm-task-port-example/blob/master/example/Main.elm
That's a repo related to proposal on adding `Task-based ports`. They were proposed more than once already, but I'm not aware of any opinion on the subject in the core team. Having a tool like that would solve lots of issues with 3rd-party libraries interop. This feature might be even better if we could get these new two-way ports with `Result err val` for sync operations and `Task err ok` for async operations. > You're using a shared library now though so whenever you replace a javascript implementation with a safe Elm version everyone benefits. I'm not sure that it's true if we take Firebase client as an example. You can find *three *Firebase-related libraries on the graveyard of http://package.elm-lang.org/ I'd prefer to use the original JS library via ports. Having some kind of a wrapper library or even a pure Elm version of Firebase client that lacks support from the Google\Firebase company itself, might be abandoned by the author(s), lacks some features that I need... that's just much worse than wiring things up with ports, imho. On Monday, March 13, 2017 at 11:06:44 AM UTC+2, Oliver Searle-Barnes wrote: > > (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 [email protected]. For more options, visit https://groups.google.com/d/optout.
