A great advantage of using Ember Data with JSONAPI-compliant adapters/serializers is that there is almost nothing extra needed to work with the data layer - just create the models with names matching the types of the resources returned by the API and you are good to go! However, sometimes you may need to customize the naming which means that the names of the models in the Ember application will be different than the ones expected by the API and their corresponding types. What are the steps required to make it work in Ember Data?
Ember.js is a web frontend framework and it’s no surprise that majority of the applications deal with a lot of HTTP requests. But such fact has a lot of implications on the process of development of the Ember apps, especially when it comes to testing. For basic GET requests which don’t include any query params or don’t deal with pagination it’s quite straight-forward - for those we just want to fetch some data, so we can check if proper objects are present as a side-effect of these requests. What about POST, PATCH or DELETE requests, where we can’t easily test the side effects?
Timeouts and delays are quite extensively used in many applications when deferring execution of some action via Ember.run.later or debouncing via Ember.run.debounce. Having small amounts of tests executing such methods might not be a problem initially, but obviously, as the application grows, this can easily lead to slow test suite which takes minutes to finish due to the waiting for all the timeouts and delays in many places. Let’s try to find the best solution to solve this problem.
Thanks to the awesome tools in Ember ecosystem such as ember-cli-mirage, ember-qunit or ember-test-helpers writing majority of the tests is pretty straight-forward. Nevertheless, there are quite a few cases where simulating user’s interaction is not that simple. An example of such use case would be holding a button for particular period of time triggering some side effect.
Arrow function expressions were definitely a great addition in ES6 and thanks to tools like babel the new syntax has been quite widely adopted. Besides more concise syntax, an interesting thing about arrow function expressions is that they preserve the context, i.e. they don't define their own this, which was sometimes annoying and resulted in assigning that or self variables to keep the outer context that could be referred inside functions. As great as it sounds, arrow function expressions cannot be used in all cases. One example would be Ember computed properties.
In my recent post I mentioned some strategies of handling non-strictly CRUD / RESTful actions in API. One of them was adding extra actions beyond creating, updating and deleting resources. As it's not a standard solution and some data layers on client side (like Ember Data) don't handle it out-of-box, I was asked by some developers what's the best way to handle such actions. So let's see how can we hack into Ember Data and make it smooth.
In the previous blog post we were exploring a new wonderful feature coming with ECMAScript 7: decorators. This time we are going to learn about async / await, which is at this moment at Stage 3 in TC39 process, which means it's already a release candidate that passed Proposal and Draft stages. Just like decorators, it's already available in Babel. Let's see what kind of benefits does it offer.
Recently I've been repeatedly asked how to get started with programming, especially Ruby and Rails. To keep things DRY and make sure I always include all great resources for learning, I decided to write this blog post. Most of people who asked me had never programmed before or had done some coding before in other languages, but are not (yet) proficient developers, so if you are a total beginner or just started learning Ruby / Rails and you are not sure what the next step is then you came to the right place.