Here’s a collection of tips and changes I had to consider while converting a large ember-data (“ED”) project over to ember-orbit (“EO”) and Orbit.js. I’m hoping this helps you to at least estimate the size of effort it might be to do the same on your own project. Our motivation was to leverage almost all of the abilities that Orbit enables (offline cache, transaction logs, background sync strategies) but the first priority was for providing an Undo/Redo feature in the application with otherwise existing behaviour. At this point, our conversion is still in progress and I’m still learning new things.
I’m not going to introduce Orbit, as others have already done a decent job of that. …
Orbit.js advertises a reversible transaction history as a feature. I was attracted to this because I needed to implement an Undo stack in my application, as well as a transaction log, and thought offline support might be a nice side-benefit. The documentation got me as far as rolling back one change, but with some help from the OrbitJS Gitter channel, I put together an example.
I started by forking the existing todomvc-ember-orbit on GitHub. This starts off with just a simple in-memory store. The README.md describes the steps to take to progressively add more data sources and synchronization/offline support. …
ember generate http-proxy foofor a new debug-time proxy server, what’s next for having your socket.io connections pass through here with support for the transport upgrade?
From an old helpful thread on this subject, we need to pass an
option object to the proxy routes to have the http server available for modification later. Edit
(I’m on a really old, 3.1.x version of ember here, this might look slightly different nowadays.)
Because we debug against different backend setups with different ports, we also take the port number from the commandline (i.e.
My project’s demo was nearly crippled recently when the number of JSON-API CRUD operations to the server was outstripping the database connection pool and creating total havoc on the consistency of the data on the client. Here’s a quick fix trick to throttling the AJAX requests that Ember-Data makes.
We were using stock Ember-Data Store CRUD and had not addressed the lack of “bulk” operations. In the application we were doing lots of duplication and/or deletion of many records at once (or rather, in very quick succession.) …
My goal was to run my Ember tests in our (in-house, private) GitLab pipeline, but without duplicating the setup steps already encapsulated in our Dockerfile for building the production app. There were a number pieces I had to puzzle over to get this running, this being my first attempt while learning how GitLab CI works. I’m no expert here, so please comment if you have similar experience to share. Here’s the high-level steps I wanted to cover:
Updated/Edited 2019-Jan-6: Found a few moments to submit a PR to ember-sinon-qunit, which has since been accepted. Added this info and an example.
I do prefer to use the ember-sinon-qunit addon because of the automatic cleanup on each test. This means you also reference
this.stub() rather than an imported
sinon.stub(). Well, at v3.3.0, I tried using the
fake functions this way … but they were undefined! Instead you must reference them instead via
The addon has been around much longer than Sinon v5 has, so there were no references to
fake in the README. (There is also another project, https://github.com/scalvert/ember-sinon-sandbox, where you use
this.sandbox.* for everything. …
Update [Oct 29, 2018]: I’ve added Ember 3.x-style code snippets.
As much as I love Ember.js, coming back to it after a couple years, I found testing (and maybe this is just testing web-apps in general) extremely taxing and confusing (in Ember 2.x — things are a lot nicer in 3.x). Part of it was that the project I was taking over had thousands of useful integration tests, but was very short on fully isolated unit tests. This was mostly due to some ill-advised architecture choices that I could not immediately remedy. Here is a quick example of using the Sinon.js mocking library to better isolate a service test. (Ember 2.x, and 3.x …