Tag: ember

Categories
Uncategorized

Setting up Coveralls for your Ember Addons

In this tutorial, we will see how to setup automated code coverage metrics collection for your Ember addons using Coveralls and Github Actions.

Why Code coverage?

In simple terms, code coverage is the fraction or percentage of code paths executed by some test or test suite of a program. It is generally measured by a tool which executes the test and logs the lines of code, the test “touches” while running. At its most basic, every conditional statement creates a “branch” defining two unique code paths, and theoretically, both “branches” of each condition must be executed by the test suite in order for the developer to be certain that the code works correctly in each condition.

Code coverage is often used as a metric to determine the effectiveness of Unit tests. Low coverage typically means that developers are not writing adequate unit tests. This signifies that there are many code paths in the application which may possibly behave incorrectly.

ember-cli-code-coverage

This addon provisions to gather Code coverage for your Ember apps and addons using Istanbul. Install this addon into your Ember app or addon with ember install;

The latest version published on npm is 0.4.2. This might be a very old version and not Octane compatible, you might run into some errors while running the tests. But there is a latest one in Github release with the tag v1.0.0-beta.9. If you are running into any problems with the npm package , you can directly install the 1.x beta version using yarn or npm.

Or using yarn

Coverage will only be generated when an environment variable is true (by default COVERAGE) and running your test command like normal.

Coveralls

Coveralls is a language-agnostic and CI-agnostic web service to help you track your code coverage over time, and ensure that all your new code is fully covered.

Add your github repo for the app/addon to Coveralls using Add Repos option in the website.

After adding the repo, Coveralls will provide you with a repo token, which we need to identify the repo with Coveralls. You need to add a Github Secret with the value of this token in your repo. This will be later used in our Github actions to set up the COVERALLS_REPO_TOKEN environment variable before sending coverage information to Coveralls.

Install the coveralls node package.

Configure your test script to include coverage information.

Add a separate coveralls script to upload the coverage information to Coveralls service.

This will upload the coverage statistics generated while running tests in a folder called coverage in a file known as lcov.info

Generating coverage statistics in CI

If you want to generate coverage information and upload it to Coveralls while running your tests in CI whenever you push your code to the repo or whenever a pull request is raised, you can go for some automated CI setup using Travis or Github Actions. In this tutorial we are going to look at how we can achieve this using Github Actions.

Github actions for Coveralls

This GitHub Action posts your test suite’s LCOV coverage data to coveralls.io for analysis, change tracking, and notifications. You don’t need to add the repo to Coveralls first, it will be created when receiving the post.

When running on pull_request events, a comment will be added to the PR with details about how coverage will be affected if merged.

Create a new job for your Github Actions or add it part of the existing one.

If you want to see the above setup in action, please take a look at my ember-chance addon repo.

Optional Goodies: README Badge

And finally if you want to add the coverage statistics as a badge in your README, you can do so by adding the following snippet at the top of your README file, which will show how much the coverge % is for your addon.

Please ensure to replace the above snippet with the appropriate values for the placeholders like <github-user-name> and <repo-name>

Recap

  1. Install ember-cli-code-coverage
  2. Install coveralls from npm
  3. Modify the test script in package.json to include COVERAGE=true
  4. Add a new script for coveralls to upload the coverage info
  5. Add your repo to Coveralls.io and get the repo_token
  6. Add a Github secret with the value of the repo_token in the repository
  7. Setup automated coverage collection in CI using Coveralls Github Actions

References:

Categories
Articles EmberJS

Creating runtime assisted Codemods using Telemetry helpers

In this article, we are going to take a glimpse at the ember-codemods-telemetry-helpers package and how it helps to create more advanced codemods for Ember.js.

If you want a more in-depth introduction to codemods, you can checkout this post detailing the why’s and how’s of codemods.

Telemetry for layman

First we will take a look at what Telemetry is all about. According to Wikipedia,

Telemetry is the collection of measurements or other data at remote or inaccessible points and their automatic transmission to receiving equipment for monitoring.

Software Telemetry

In software, telemetry is used to gather data on the use and performance of applications and its components, e.g. how often certain features are used, measurements of start-up time and processing time, hardware, application crashes and general usage statistics and/or user behavior. In some cases, very detailed data is reported like individual window metrics, counts of used features and individual function timings.

This kind of telemetry can be essential to software developers to receive data from a wide variety of endpoints that can’t possibly all be tested in-house.

Privacy concerns

Due to concerns about privacy, since software telemetry can easily be used to profile users, telemetry in user software is often an user choice, commonly presented as an opt-in feature (requiring explicit user action to enable it) or during the software installation process.

We had enough look about what really Telemetry is about. Now it’s time to look at the more specific use-case of creating codemods using telemetry helpers.

Telemetry helpers for Codemods

Telemetry helpers runs the app, grabs basic info about all of the modules at runtime. This allows the codemod to know the names of every helper, component, route, controller, etc. in the app without guessing / relying on static analysis. They basically help you to create “runtime assisted codemods”.

Below you can find the package composition of the ember-codemods-telemetry-helpers package.

The goal of this project is to enable each codemod to manage its own type of data gathering and to provide the harness to run that custom gathering function.

This package exports six functions for gathering telemetry information which can be used in the codemods.

Using the telemetry helpers for codemods

Assuming you are authoring a codemod with codemod-cli, ember-codemods-telemetry-helpers allows you the freedom to assign your own “telemetry gathering” function while provide one of its own out of the box.

All invocations of gatherTelemetryForUrl internally returns an object enumerated with properties named after all possible entries within window.require.entries. The values of each property is the value returned from within the gathering function. Using the example above, the output might be:

This package provides one gathering function: analyzeEmberObject. This function does a “best effort” analysis of the app runtime, returning such things as Components, Helpers, Routes, etc. and their particular properties.

It parses Ember meta data object, collects the runtime information and returns the following list of properties :

Gathering runtime data

Let’s see how the codemods use the telemetry helpers to gather data at runtime. For that, let’s take an example to see how the ember-native-class-codemod is invoked.

The first argument that you must pass to the codemod is the URL of a running instance of your application. The codemod opens up your application using the URL passed as the argument and analyzes the classes directly in order to transform them. Any classes that were not analyzed will not be transformed. This includes classes that are private to a module and never exported.

If you have any lazily loaded modules, such as modules from Ember Engines, you need to ensure that the URL you provide loads these modules as well. Otherwise, the codemod will not be able to detect or analyze them.

Origins of the Telemetry helpers

This project was extracted from ember-native-class-codemod. That codemod uses Puppeteer through this package to visit the Ember app and gather telemetry necessary to convert to native classes.

The idea for the extraction was to put the harness in this package (extracted from the native class codemod), but have the actual “telemetry gathering” live in each individual codemod project because the things that they need are quite different, for example, for implicit this codemod and angle brackets codemod all we need to know is an array of the helpers and components in the app, but for native class codemod it needs much more information such as names and types of methods, properties, etc on each default export.

Codemods already using the helpers

Currently there are two codemods : ember-native-class-codemod and ember-no-implicit-this-codemod, which are already making use of the telemetry helpers to gather information from the app during runtime. And there is an open pull request by Ryan Mark for the ember-angle-brackets-codemod to make use of the telemetry helpers.

References

Categories
Articles EmberJS

Ember into Futurity

Nobody can predict the future, but everybody can wish for something in it. It could be for the benefit and interest of one person or a community as a whole. I am putting down my thoughts and wishes for Ember.js as both a consumer of the framework itself and producer of the supporting tools and addons for the same.

The best way to predict the future is to invent it.

This post is my answer to the call for blog posts for #EmberJS2019. I haven’t had the slightest idea to write a post for the blog post call, but my colleagues and friends insisted me to write one. Because honestly I really don’t know where to start and how to give a conclusive ending to my post. But my creative Muse never ceases to amaze me. So here it goes.

The Framework

As a framework, we need to fully achieve conceptual integrity on what we want to accomplish and how we want to move forward with it. Because instead of trying to become one “All Purpose Tool Kit”, we should focus on one thing and do it well.

Ember has the right ideas, but the wrong atomic structure.

Component Paradigm

While Ember was ruling the MVC realms, there came a knight known as “React“, armed with a simple yet profound idea, who taught us how we can build web applications using components. The Components Model may be a new one for Web development, but it wasn’t for programmers and system application developers like me who have been dealing with objects and classes for a very long time. Yet this new Knight conquered the world with his deep and extensive conceptual integrity. Ember failed to realize this threat for a very long time, even though Ember had components in it’s arsenal, but it was no match for React.

Octane

Octane is the one thing I eagerly waited for in Ember a year ago when Tom Dale published his Ember 2018 Roadmap RFC. I even remember that I explored the RFC in detail in my blog here. But still we are yet to see a full-blown Octane Edition landing in Ember. And it would be a disgrace if I fail to appreciate the effort put by the Team to make the necessary provisions for the Octane release by making the guides ready with great care and great tact.

More Flexible CLI

One of the best things I love about Ember is the CLI. No other Javascript Framework has got it right till date. While all of the other frameworks use CLI as just an application scaffolding tool to bootstrap a project, Ember-CLI goes beyond them with generators and blueprints. And it gets even better by giving us the flexibility to define and generate a custom blueprint.

But the CLI is not very flexible in-terms of choosing tools and libraries for various tasks other than the standard packages shipped as part of the CLI. The Convention over Configuration is holding us back in some aspects on this front. The Web is evolving with more new tools and libraries day by day, and I think we should open up more and make provisions to allow developers to choose their own tools and libraries best suited for their projects.

We should adopt the ideas from projects like ember-cli-create which will allow the developers to choose their own tools and technologies for their projects based on the requirements, platform and other external factors.

Unified Documentation

This is one thing I really wanted to emphasize here. Because we have so many ideas being implemented in Ember such as Server-Side Rendering (Fastboot), Ember Engines and Glimmer.js. But all of them are scattered and fragmented. I wish all the above things should branch out from our main guides for Ember instead of having separate websites.

I am not concerned more on the technical implementation rather on the conceptual mapping to give developers an overall idea of different technologies that can be used along with the framework. It could be a simple page for each one of the above within guides itself and guide the users to take them to the main website if they want to explore more on this or a more prominent place where we can have links to these projects within the guides itself.

Functional Components (Hooks)

When hooks landed in React, it made a real fuzz. More of my fellow React developers were singing praises for the same, such as how it changed the way they write code and mutated their minds on how you could bring about solutions for complex problems using components. And again underneath all the fuzz, it’s just a conceptual modification that the React framework brought in for writing components, which can be adapted to any framework that supports the component model for creating user interfaces for the web.

I wish Ember could have adopted it much earlier, but it’s better late than never. I am very much relieved to see this has seen the light of the day, when I saw ember-functional-component  created by our beloved rwjblue.

Fail Fast

As a community we value “Stability without Stagnation”, but that proved expensive for the framework in the long run. I personally urge that we should fail fast, because by failing fast we come to value the lessons and insights we learnt from our failures and move forward with much greater pace. We need to get out there, try out new things and find out what works and what doesn’t.

Why do we fall? So we can learn to pick ourselves up.

– Alfred, Batman

Embroider

Using broccoli as a build tool, have been a huge impediment for Ember, in adopting the best and the latest conventions from other frameworks in terms of build pipeline and tooling. Since other frameworks like React, Angular and Vue are heavily betting on cutting edge packaging technologies like Webpack, Rollup and Parcel, while Ember still fixating on broccoli proved to be a costly mistake for the community. I think Embroider will not suffer from the same fate, by adopting Webpack as a tool in the build pipeline.

Conclusion

So instead of asking “Why didn’t Ember succeed?”, actually the right question to ask will be Why is there a perception that Ember didn’t “succeed”? And I would like to conclude this post with words from my favorite author, Henry David Thoreau.

Read your fate, see what is before you and walk on into futurity.

Categories
Uncategorized

Ember Octane – everything one can expect in the next Ember edition

Everything one can expect in Ember Octane

A few days ago, Tom Dale opened the Ember 2018 Roadmap RFC that set the goals for Ember in 2018. The RFC consisted of three major goals like:

  • Improve communication and streamline decision-making, and empower new leaders.
  • Finish the major initiatives that have already been started.
  • Ship a new edition, Ember Octane, focused on performance and productivity.

In this article we will focus on Ember Octane which is primarily targeted to improve performance of Ember applications for low-end devices and the like.

Ember Octane will be a new edition of Ember, emphasizing its modern productivity and performance. The Core team promises to polish Ember’s compatibility with new JavaScript language features like native classes, decorators, and async functions. There is also some significant emphasis to continue efforts like optional jQuery and treeshaking that reduce file size. It is also expected that the Ember team will overhaul the Ember homepage to align with Octane and tell the story of modern Ember.

Some of the primary motivations for Ember Octane came from The 2018 Community Survey, #EmberJS2018 blog posts, Ember Discussion Forum and deliberations among the Ember core teams.

The homepage looks a bit outdated and does not a very compelling job at selling Ember to new users, IMHO. This needs to change.

— Simon Ihmig

When you generate a project with ember new, you get a project that is almost “legacy” by standards of the wider JavaScript community.

— Gaurav Munjal

Ember’s custom object model isn’t hard to learn, but it’s a big reason people are turned off before learning why Ember is such a great choce. I’d like to see ES classes support finished and adopted in the Guides ASAP, followed by decorators.

— Michael Kaiser-Nyman

ES6 syntax, the new file layout, new templating etc. — the new features will land in 3.x releases as non-breaking changes, but let’s prepare to show off the sum of all those amazing parts. Sell the vision, right now! A ‘relaunch’ of Ember in the minds of those who dismiss it.

— Will Viles

Ember releases a new, stable version every six weeks. For existing users, this reverberation of incremental improvement is easier to keep up with than splashy, big-bang releases.

However, for people not following Ember closely, it’s easy to miss the significant improvements that happen over time. As detailed in the forthcoming Ember Editions RFC (being worked on by Dave Wasmer), every year or so the team will release a new edition of the Ember, focused on a particular theme. The set of improvements related to that theme, taken together, mark a meaningful change to how people should think about Ember.

In 2018, the Ember team will release the first edition of Ember, called Ember Octane. Octane will focus on the themes of productivity and performance. Ember Octane will generally highlight how Ember excels in performance-constrained environments, particularly on mobile devices, as well as the productivity benefits of modern JavaScript features like classes, decorators, and asyncfunctions when paired with Ember’s strong conventions and community.

We can also expect the team to review the new application blueprint, to ensure that it is up-to-date with the latest Ember Octane idioms and includes the right set of addons to help new users achieve our goals of productivity and performance.

Ember Octane is about doing more with less. Not only does this make Ember simpler to learn, it makes the framework smaller and faster, too.

These are some of the highlights of Ember Octane as quoted by Tom Dale in the RFC:

1. No jQuery

Currently available as an optional feature, this will be enabled by default. The process of making jQuery optional started with the Make jQuery optional RFC by Robert Jackson in January this year. For the past Ember has been relying and depending on jQuery. This RFC proposes making jQuery optional and having a well defined way for users to opt-out of bundling jQuery.

Mathias Bynens has demonstrated the major drawback of having jQuery, the increased bundle size, which amounts to ~29KB (minified and gzipped).

2. Svelte builds

“svelte” builds of Ember, are where deprecated but unused code paths in the framework are removed during an application build. The team will get more aggressive about deprecating code that is not widely used. With the eventual introduction of Svelte builds, there will be a mechanism to say “strip out any code for deprecated features from 2.0 to 2.8”.

There is an issue in the official github repository regarding svelte builds with the title [Project Svelte] Deprecation Introduction Hitlist opened by Chad Hietala which highlights some of the ways and approaches to find deprecations and the list of deprecation IDs.

Some preliminary explorations on svelte builds have also taken place among Ember developers some of which can be found in this thread in the Ember Discussion Forum.

You can find some references to svelte builds in this official blog post by Matthew Beale on The Road to Ember 3.0.

3. Native JavaScript classes

Ember Octane will make use of native Javascript classes which perform better and require less code, and integrate better with tools like TypeScript and ESLint.

4. Glimmer Components

Glimmer is one of the fastest DOM rendering engines, delivering exceptional performance for initial renders as well as updates. Architected like a virtual machine (VM), Glimmer compiles your templates into low-level code so it can run as fast as possible—without sacrificing ease of use. With Ember Octane, Glimmer components offer a greatly simplified API and remove common slow paths.

Glimmer differentiates between static and dynamic components, thus reducing the number of elements that need to be checked when looking for changes. This differentiation can be achieved thanks to the expressiveness of Handlerbar’s templates.

Another key difference between Glimmer and other solutions lies in the way nodes are stored and compared. Glimmer stores nodes as simple stream-like objects (that is, simple queues of values) rather than full-fledged DOM-like nodes. To find out whether a real DOM node needs updating, the final value of a Glimmer node is compared to the last known real DOM value. If the value has not changed, no further actions are taken.

5. Incremental rendering and rehydration

Incremental rendering addresses problems like, to get high levels of animation performance you have to synchronize the DOM (tween stack across the entirety of the animation chain in order to minimize layout thrashing) and skipping style updating when updates would be visually imperceptible.

In React, Fiber takes charge of solving problems like it. Bringing a feature named “incremental rendering” which split rendering work into chunks and spread it out over multiple frames. The new rendering logic allows a better approximation of the principles of an animation.

In traditional way React uses Stack, which is synchronous and recursive. But can’t be split in chunks, have a heavyweight context and other issues. The goal of React Fiber is to increase its suitability for areas like animation, layout, and gestures. Other key features include the ability to pause, abort, or reuse work as new updates come in; the ability to assign priority to different types of updates; and new concurrency primitives.

Incremental rendering: the ability to split rendering work into chunks and spread it out over multiple frames.

Rehydration in the context of isomorphic JavaScript applications is the act of regenerating the state that was used to render the page response on the server. This could include instantiating controller and view objects, and creating an object or objects (e.g., models or POJOs) from the JSON that represents the data used to render the page. It could also include instantiating other objects, depending on your application architecture.

Rehydration is more common in frameworks like React where SSR is given an important consideration and with the advent of Ember Fastboot, the concept of rehydration is also becoming a buzzword in the framework arena.

6. Treeshaking

In computing, tree shaking is a dead code elimination technique that is applied when optimizing code written in ECMAScript dialects like Dart, JavaScript, or TypeScript into a single bundle that is loaded by a web browser. Rather than eliminating code that can never be executed, tree shaking starts from entry point and includes only the code that can ever be executed. It is succinctly described as “live code inclusion”.

In Ember, tree shaking has already been part of the JavaScript Module API RFC which was implemented in the recent versions of Ember.

To get deep insights about tree shaking, please read this article by Rich Harris, one of the contributors of Rollup giving a detailed explanation of how tree shaking is done in Rollup.

7. Eliminating the runloop

Ember Octane will also focus on eliminating the runloop from the programming model, replaced by async and await in tests.

Timeline

The final timeline and feature set of Ember Octane will be determined by the Core team and are not set in stone.

Ember Octane will mostly incorporate all features that are either finished or being implemented now, keeping with the commitment to finishing what has been started by the Ember Team. It is recommended that the team will not plan for Octane to have any features that are not already close to being done today, so that they have adequate time to make sure they all work well together as part a cohesive programming model.

The process of releasing a new edition also gives the developers and users an opportunity to evaluate what it’s like to use Ember end-to-end. It is highly likely that the team will overhaul the Ember homepage, focusing on Ember Octane and how it helps solve targeted use cases.

The Ember Team will perform a holistic review of the guides, making sure that examples use the latest idioms and set new learners on a good path.

References

Image Credits:

Photo by chuttersnap on Unsplash