Ember & Electron for Desktop Apps
Recently at Nimbo X we realised our end users would greatly benefit from having a “Desktop-like experience” when using our app, so we set ourselves to produce a first version of it. In this post we’ll explain our experience from a technical point of view.
Download it now for OS X & Windows
Publishing it to the “App Stores” distribution channels is still a work in progress, which deserves a post for itself, where we’ll narrate the bureaucratic experience while submitting the app.
Meet Electron ⚛
Electron is a runtime environment based on Node.js & Chromium. It allows creating desktop applications using regular web technologies, giving them access to the filesystem, hardware, OS notifications, etc.
Ember + Electron
The awesome ember-electron addon by Felix Rieseberg allowed us to quickly build app executables for major platforms by simply running:
ember electron:package
It wraps other amazing tools, like ember-packager and electron-osx-sign, into a single easy-to-use package. Other tools we relied on were:
- electron-windows-store: a tool for creating AppX containers for Universal Windows Apps, by Felix Rieseberg too
- Various tutorials from the Electron repo
- awesome-electron list by Sindre Sorhus
- among others…
Getting rid of browser modals, once and for all
Our biggest headache turned out to be good ol’ browser popups. We had several window.confirm, window.prompt and window.alert modals throughout our application that we needed to get rid of, since these are not available in Electron.
At first glance this seemed to be rather easy, but as it turns out the modal window abstraction doesn’t play well with a component-based app like ours.
We had already been using ember-modal-dialog for some modals, and since it’s still the first result in ember observer it was our natural choice.
Specially tricky were the modals which needed to hold some kind of state and pass data from/to the underlying route or component, such as a window.prompt and window.confirm.
This got even more complicated when having several levels of nested components while following DDAU (data down, actions up), thus data-related actions reside in the parent routes, and actions are bubbled up from nested components. This created a situation where we ended up polluting many components with modal’s logic/markup, ugly!!!!
We also considered ember-remodal, the second-best rated addon in ember observer, but it felt over-engineered and having to install yet another modal addon was not a particularly attractive choice.
In the end we decided to stick with ember-modal-dialog and get our hands dirty by crafting a solution of our own. Following this awesome screencast (suggested by Esteban Lara) was a great starting point for cleaning-up our code.
First we decided to encapsulate all the three modal-variants in a single component called modal-message, which reused ember-modal-dialog and would be rendered only once at top application-level:
The tricky part was to consume the logic from other controllers/components and passing data, while keeping the context, using closure actions:
This kinda breaks DDAU pattern!!!! But in the end is a tradeoff we’re willing to take, since modals themselves break component-based paradigm too, being more like a necessary evil in modern single-page applications UX metaphors.
Next Steps: Automating the process
If reception is good for our desktop apps we’ll keep iterating and improving the Electron builds. The next logical step would be to automate the process via auto-updates (hint: using Gitbook’s Nuts server), but that’s material for another post.
