Hi Kris, I've faced the same problem with firebase too a couple of weeks ago. My solution was having 3 ports per fb subscription like so:
port subscribeGuests : String -> Cmd msg port unsubscribeGuests : String -> Cmd msg port guests : (List Guest -> msg) -> Sub msg Where subscribeGuests instructs the js using npm.org/package/firebase to listen on the path /guests/uid and sends the current data through guests, unsubscribeGuests stops listening, and guests is the subscription where changes come through. Then in update I return the Cmd from subscribeGuests or unsubscribeGuests when necessary to keep in sync the JS side subscriptions. I'm not 100% happy about it, but it got the job done. Regarding reusing the thing on other projects needing firebase, my (newbie-not-sure-if-possible) plan is to generalize the port interface by sending the paths on the port, and getting Json Value back from the subscriptions, so that I can have a single triplet of reusable ports (something like addListener, onData, removeListener for example). I have to dig into it more. I would've liked working on a wrapper over the official library given how awesome firebase is right now, but after digging and reading threads about native code in package, I don't think that's going to happen in the near future. One way to share code between projects, if you are using npm + webpack for your JS needs in the elm project, could be to publish your library to npm with the JS and Elm sources, then you can consume the JS using webpack, and include the elm source manually elm-package.json. (I still have to try this out, but it is on my plans). You miss on the good things of elm-package though, and it becomes more like manual semver (node style), but at least there is a way to do share the code. On Friday, June 10, 2016 at 10:42:30 AM UTC+2, Kris Jenkins wrote: > > Hey folks, > > I've hit a dead-end trying to integrate Elm 0.17 with Firebase. (This > isn't actually a Firebase-specific problem, but it's my concrete example.) > > Firebase has a feature where you can subscribe to changes at a particular > database path. So I can subscribe to "/votes", and any new votes made by > other people will be pushed to my client. You can also unsubscribe at any > time. > > I started doing this with a port. Subscribing to a path works as neatly as > you might hope. It's unsubscribing that gets hairy. I have this code: > > port listenForVotes : (List Vote -> msg) -> Sub msg > > subscriptions : Model -> Sub Msg > subscriptions model = > if model.authenticated then > listenForVotes NewVotes > else > Sub.none > > Once we're authenticated, it triggers code on the other side of the port > to start listening to that path. But if we log out, we just ignore them. No > new message is sent to the Firebase API to say, "Stop listening." That's > the problem I want to solve. > > > This seems to me like something effect managers were built for - tracking > which subscriptions are live and dealing with their appearance & > disappearance. So I started writing one of those. > > And technically it seems like the right solution. It's shaping up well. > But practically I can see it's going to fail. If I write an effect manager, > the native part of the code will be tied to the name of the project that > uses it. I can't reuse my effect manager across projects, even privately. > As far as I can tell, the only way to make an effect manager reusable is to > get it published to packages.elm-lang.org. And I'm deeply pessimistic > about that ever being approved. > > Can anyone see a way forward? > > Cheers, > Kris > -- 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.
