The Ember Times

👋 Emberistas! 🐹

Destroyables RFC in final comment period 💬, Ember Engines documentation rewrite ⚙️, Ember Octane at Square 💻, check out the new Ember CLI documentation 📚, introducing qunit-wait-for ⏰, and last, but not least, power up your Ember app with ember-glue ✨!

Destroyables RFC in final comment period 💬

The Destroyables RFC entered its final comment period today. That means you have 7 days (until April 17) to provide feedback.

The Destroyables RFC proposes an API that the Ember community can follow so that Ember's built-in constructs, which include components, services, routes, controllers, helpers, and modifiers, can clean up after themselves when destroyed. For example, a request in a data-fetching component would be cancelled if the parent is destroyed.

Please visit the RFC page to learn more. Be sure to provide your feedback on time!

Ember Engines documentation rewrite ⚙️

Michael Villander (@villander) announced a rewrite to the documentation for the Ember Engines Guides to improve the user experience for the community!

Updates include detailed explanations that range from what Ember Engines are and why should you use them, to differentiating the behaviour between standard and in-repo addons for Engines. The guide also goes through routable vs route-less Engines as well as how to “mount” them into your application. Finally, it also covers how to test code within Engines.

Huge thanks to Dan Gebhardt (@dgeb) and Gabriel Csapo (@gabrielcsapo)! Check out the new Ember Engines docs today and help contribute to make them better!

Ember Octane at Square 💻

Here at The Ember Times, we've been highlighting projects and teams who are using Ember Octane in their apps. This week, Dean Papastrat (@deanpapastrat) shares his experience as an engineer at Square! Dean writes:

Square enables businesses of all shapes and sizes to manage almost every aspect of their business - from payments to inventory to payroll - in one place. The Developers Experience team at Square builds products and tooling for external developers that build on Square's APIs, such as our Developer Dashboard, Developer Documentation site, API Reference, and API Explorer.

Our team recently released a new API Reference and API Explorer built on the Octane beta and Fastboot (don't worry, we're running production-grade Ember 3.17 now!). Despite being in beta, the choice to pick Octane was a no-brainer for us due to 3 major factors: performance, accessibility, and learning curve.

Since our team’s primary customers are developers, we knew we'd need the site to be snappy. In Octane, we're able to render much larger lists without virtualization because of the performance gains from Glimmer components, which spares us a lot of complexity and accessibility issues that come with virtual lists. The biggest example of this is our objects index page and enum lists for properties, which render hundreds of list items with markdown and other rich content.

The new API Reference is a completely accessible site, much in thanks to the improvements in Octane. It made it much easier for us to add ARIA attributes than past versions of Ember, where we had to bind lots of attributes explicitly or manually forward properties to elements inside of components. Specifically, the ability to apply "splattributes" to a given element in a component meant we could work with the HTML properties we were familiar with instead of working around the framework. The way angle bracket components use "@" symbols to delineate arguments on a component from HTML attributes made this easier for us as well, since it disambiguated how arguments and attributes would be handled on the component.

Lastly, the lower learning curve of Octane became the strongest selling point for our team. With half our team being engineers that had never touched Ember before, we were wary of how long it would take people to pick up the concepts in Octane that weren't well-documented at the time. Instead, we were blown away at how quickly people were able to pick it up. The engineers new to Ember picked up Glimmer components with tracked properties in under a day, because they "just worked like classes". Using modifiers directly within the templates themselves felt much more straightforward for new engineers. In fact, there were no "Emberisms" they needed to learn to be productive. Angle bracket components felt more natural to our engineers coming from a React background, and the disambiguation of arguments / component state / attributes made it much easier to understand how data flowed from one component to another.

The only regret we have is that we haven't been able to port the rest of our apps to Octane yet, and going back to computed properties feels like such a massive step backward, that it makes you realize how important Octane is for improving the Ember developer experience long term. We're excited to see how the Ember community approaches the challenge of modernizing the build system with Embroider, and can't wait to adopt it later this year.

Check out the new Ember CLI documentation 📚

In case you might not have known, the Ember.js website has documentation dedicated to Ember CLI. It covers both everyday and advanced uses that you will encounter when you write Ember apps or addons.

In the past two weeks, Mehul Kar (@mehulkar) dedicated his time to keep the documentation up to date and introduced 2 new sections: how to debug when CLI commands fail and how to create custom CLI commands.

We encourage you to check out the Ember CLI documentation to understand your toolset better. Don't forget to thank Mehul for his work!

Introducing qunit-wait-for ⏰

There's an awesome new test helper by Alex LaFroscia (@alexlafroscia) that rethinks the approach on how we wait for asynchronous behavior to resolve in our tests! 🎉

Typically in Ember tests you'd use one of the several available test helpers that wait until a promise resolves before making some kind of assertion against the state of your application. However, using wait test helpers in this way can add complexity to your tests and couple ⛓ your tests to your implementation code.

With qunit-wait-for the idea is to let assertions run immediately and fail gracefully until they pass or a timeout is reached. This allows you to wait ⏳ for async behavior to complete without your test code knowing any more than it needs to know about your app code. All you have to do is wrap your assertion with a waitFor assertion provided by qunit-wait-for, it's very cool!

qunit-wait-for can be used not only in Ember.js, but in any JavaScript applications that use QUnit. Give it a spin today!

A UI component library for ambitious Ember developers ✨

UI component libraries have become a popular, if not even essential part of a frontend developer's toolset.
Libraries such as ember-paper and semantic-ui-ember allow us to create beautiful, seamless and intuitive user interfaces.
And who doesn't want to feel empowered to build applications that their users will find compelling to use and love?

Now a brand-new component collection might improve our Ember applications even further: ember-glue is a
modern UI component library, that takes the latest best practices of frontend development into account. The components are accessible, responsive and themeable, allowing design updates with little effort.

Want to learn more about what ember-glue can do for your app? Check out the blog post describing the feature set and the motivation behind this addon. And if you're curious, to explore the ecosystem of UI libraries for Ember apps further, be sure to consult Ember Observer!