During the conference I noticed a lot of neat ways to demonstrate and focus on code on slides. I didn't do well at this during my talk, but wanted to provide a place where I track updates to the slides in case anyone wants to reference them. I know that I'll be referencing them as I try to flesh out some ideas in more details. 30 minutes is not a lot of time with such a broad topic!

Link to slides from the Presentation: Comparing Patterns in React and Ember

• 2019-03-19: Talk / Presented
• 2019-03-21: Add code focus/highlight boxes and split up presenter notes to match focus/highlight boxes

* I've technically given talks at local meetups before.
one was on a ruby gem for bringing the ideas behind ember's module unification efforts to rails, Drawers, and the other was on a topic similar to what I spoke about at emberconf, but much higher level.

** My first conference was gencon 2018. That event takes over the entire downtown Indianapolis area.

Since I didn't yet have a domain, I figured it would take a bit longer.

Here are the steps I took to create this blog / site:

• buy domain at namecheap.com

• create blog:

  • ember new website --yarn
  • cd website
  • ember install empress-blog empress-blog-casper-template
  • create repo on github
  • push code to github

    git remote add origin <url from github>
    git add .
    git commit -m "first commit"
    git push -u origin master

• visit netlify and setup a new netlify app

  • connect netlify to the repo I created on github

  • tell netlify about the domain I bought on namecheap

  • configure namecheap to use different Nameservers so that netlify can manage DNS for my domain.

  • wait for those changes to propagate the internet (~20 minutes)

  • notice that netlify says that I need to add a redirect from the netlify default domain to my domain

    • I created this file in config/_redirects

    # Redirect default Netlify subdomain to primary domain
    https://nullvoxpopuli-website.netlify.com/* https://nullvoxpopuli.com/:splat 301!

    • add a deploy script to my package.json:

    ember build -e production && cp ./config/_redirects dist/

    • update my netlify build command under the deploy settings to use yarn deploy

• after committing and pushing the _redirects update, I got a build error about one of my dependencies not supporting node 10. I had to create an .nvmrc file that specifies node 8, as I found out during my research that netlify will read the .nvmrc file to determine which node version to use during build and deployment.

• after waiting for the automated deploy to finish after pushing the .nvmrc file, the blog was finally up and running!

Compared to other blogs I've setup in the past, this was very easy, and most of my time was spent on DNS configuration.

the ideal structure is the one that allows you to move around your code with the least amount of effort.

--- The 100% correct way to structure a React app…

Why worry about folder/file structure at all? It seems like a difficult problem to solve. When there are no restrictions, almost everyone has a different idea of how 'things' should be named, and where they should live. In order to get everyone on the same page to achieve maximum project consistency, a structure should be agreed upon beforehand.

There are many topics on file structure. None of them agree. Some may have some similar concepts. Some may be too relaxed to be worthwhile. Ultimately, when faced with the choice of where to put a file, everyone's preference seems to be a little different.

So, how is this article going to be any different? My goal is to define a set of criteria for which we can assess a folder/file structure, and then to describe a reasonable start to a structure that can work as a base for any single-page-app in any ecosystem -- React, Vue, Angular, or Ember.

Firstly, let's define the criteria that we'll assess structures with.

1. Users should be able to maintain their apps without worrying about the structure of their imports inhibiting them from making changes.
2. Related files should be discoverable, such that a user does not need to hunt for a file should they not be using TypeScript (where you'd be able to use "Go to definition")
3. Related files should be accessible, such that a user can easily locate a related file without having any IDE features (i.e.: browsing on github).
4. Users should have reasonable context at any level within their project hierarchy. Flattening out too much is overwhelming and reduces the ability to maintain, discover, and access.
5. Refactoring sections of the project should be easy. When moving a directory to a new location, the internal behavior should remain functional.
6. The right way and place to add a new thing should be obvious and a structure should not allow for unnecessary decisions.
7. Tests and styles should be co-located along side components.
8. Avoid the infamous "titlebar problem", where a bunch of files all named the same can't be differentiated in the editor (though, a lot of this is editor-based)
9. The structure should not impose limitations that would prevent technical advancement -- such as the addition of code-splitting to a project that does not yet have it.

The general-enough-to-work-for-all-apps-layout:

Note that any combination of {folder-name}/component.js,template.hbs should be synonymous with:

• React: {folder-name}/index.jsx,display.jsx
• Vue: {folder-name}/index.vue,display.vue
• Angular: {folder-name}/component.js,template.html
• Ember: {folder-name}/component.js,template.hbs
• etc

Also, note in these examples are shorthand, and some projects (particularly Angular projects), like to be very explicit with naming, such as ComponentName/ComponentName.Component.js.

src
├── data
├── redux-store
├── ui
│   ├── components
│   │   └── list-paginator
│   │       ├── paginator-control
│   │       │   ├── component.js
│   │       │   └── template.hbs
│   │       ├── component.js
│   │       ├── integration-test.js
│   │       └── template.hbs
│   ├── routes
│   │   ├── login
│   │   │   ├── acceptance-test.js
│   │   │   ├── route.js
│   │   │   └── template.hbs
│   │   └── post
│   │       ├── -components
│   │       │   └── post-viewer
│   │       │       ├── component.js
│   │       │       └── template.hbs
│   │       ├── edit
│   │       │   ├── -components
│   │       │   │   ├── post-editor
│   │       │   │   │   ├── calculate-post-title.js
│   │       │   │   │   ├── component.js
│   │       │   │   │   └── template.hbs
│   │       │   │   ├── route.js
│   │       │   │   └── template.hbs
│   │       │   ├── route.js
│   │       │   └── template.hbs
│   │       ├── route.js
│   │       └── template.hbs
│   ├── styles
│   │   └── app.scss
│   └── index.html
└── utils
    └── md5.js

Going though the folders from top to bottom, because dev.to doesn't allow inline links without code fences… (a great feature of one of prism.js' plugins).

src

Most of this will focus on the src directory, as any other top-level folder or file tends to be more project or ecosystem specific, and may not generally translate to projects cross-ecosystem. Some examples of those folders that may not translate due to project-specific or build-configuration-specific reasons are: app/, tests/, vendor/, public/, config/, translations/, etc.

src/data

This directory is intended for all api-related data interactions and representations. In an app where you have the model-adapter-serializer pattern, you may want additional folders within src/data such as models or transforms, depending on how much normalization you desire within your application. This is why it doesn't necessarily make sense to have anything named more specific or vague.

src/redux-store

If using redux, most guides and tutorials just use the same store, which can be ambiguous, since store is a construct used by any library that maintains a cache of data. So not only in Redux, but also in Orbit.js, and ember-data.

For more info on app-level state management, See this article comparing state mangement in both React and Ember

src/ui

The entirety of anything that directly affects the display should go in the ui folder. This includes styles, components, and routes. The user interface can exist independent of data, application state, and utilities.

src/ui/routes

Most single page apps are using some sort of router, and therefor the UI is entirely route based. What components display are determined by what routes are active. Due to this coupling of display, and consequently, behavior with the browser URL, it should only be natural to divide up your app by the natural route boundaries. Splitting the UI by route also lends itself to straight-forward code-splitting on the route boundaries.

src/ui/routes/{route-name}/-components

In a recent React project, I've tried to omit the route-level private components directory, but it's lead to confusion between what is intended for the route, and what is there to support what is rendered on the route. I had originally omitted the -components directory thinking that if I/my team just use the right folders, things wouldn't be so bad.

An example of a page where you'd want nested routes separate from your components is tabbed navigation:

posts/post
├── view/
├── comment-moderation/
├── publishing-options/
│   ├── -components/
│   │    ├── confirm-publish-modal.jsx
│   │    └── social-media-blast-options.jsx
│   └── index.jsx
└── edit/
    ├── -components/
    └── index.jsx

This structure, unlike the above link (things wouldn't be so bad), this has a clear, explicit separation of components and route-specific components. In the linked react app, I've also been playing with keeping local-only higher-order components (HoCs) at the top route-level due to their one-time use nature -- though, in this particular app, commonly-used HoCs are moved to the data directory. I'm still kind of playing around with the idea, but the HoC locations are more specific to the functional single-page-apps such as those that would be react-based.

One criteria to use to know if your structure is heading in the right direction is how often you end up using ../ or ../../ in your import paths. Using upwards reverse relative paths violates our Goal #5 stating that any subtree can change location and the functionality of the contents should remain in a working state. The above example should not inherently have any reverse-relative pathing.

An example violating Goal #5:

posts/post
├── view/
├── comment-moderation/
├── publishing-options/
│   └── index.jsx
├── confirm-publish-modal.jsx
├── social-media-blast-options.jsx
└── edit/
    └── index.jsx

Here, publishing-options files must use ../ to access the components defined at the parent level.

src/utils

Any functions, classes, or utilities should live in src/utils. These files should be purely unit testable, as they should have no app dependencies. This includes things like string format conversion, auth0 wrappers, fetch abstractions, etc.

Overall

Let's revisit our goals, and look out how this proposed layout meets each one:

1) Users should be able to maintain their apps without worrying about the structure of their imports inhibiting them from making changes.

Achieving this goal is mostly through simply having any documented convention that can be referenced later. There are currently no general static analysis tools to help out with enforcing a structure -- though, there is one tool for one of the major frameworks that dictates structure. (See Implementation below)

2) Related files should be discoverable, such that a user does not need to hunt for a file should they not be using TypeScript (where you'd be able to use "Go to definition"

By having related files next to each other in this layout, everything is contextual by nature. If someone is a heavy file-tree/project-tree browser, they'll have an easy time navigating and discovering what they're working on and what is involved.

3) Related files should be accessible, such that a user can easily locate a related file without having any IDE features (i.e.: browsing on github).

This is related to (2), but more enforces co-location. When browsing files quickly online, without editor or typescript features, it's convenient to be able to click through as few web pages as possible to view related components.

4) Users should see have reasonable context at any level within their project hierarchy. Flattening out too much _is overwhelming and reduces the ability to maintain, discover, and access._

By having a nested structure by route, any component that is only used in one place will by contextually co-located to its usage. This keeps the amount of large flat folders to a minimum, and allows for understand the greater design of the app without having to follow references everywhere. Sibling folders are to be treated as complete unrelated (adopted?).

5) Refactoring sections of the project should be easy. When moving a directory to a new location, the internal behavior should remain functional.

I hope this one is self-explanatory, but this folder/file structure allows for drag-and-drop refactoring where any folder moved should have all of its internal tests still passing.

6) The right way and place to add a new thing should be obvious and a structure should not allow for unnecessary decisions.

This, in part, relies on both documentation and programmatic enforcement. The structure follows a strict set of rules that can be easily learned. For example, when using this folder/file stricture, by default, things should be going in -components folders as you build out a route. For more inspiration on what kind of rules there could be, read about The Octane layout (formally Module Unification)

7) Tests and styles should be co-located along side components.

Instead of in a top-level tests/ directory, tests can be contextually located with the thing that they are testing. This works for unit, integration, and acceptance tests. There will, of course, be exceptions to this, where you may be testing something app-wide and it has no specific context -- for those situations, I tend to just put tests in tests/acceptance/ (if they are acceptance tests).

8) Avoid the infamous "titlebar problem", where a bunch of files all named the same can't be differentiated in the editor (though, a lot of this is editor-based)

The tab problem shouldn't be a thing in modern editors

(neo)Vim:
VSCode:
Atom:

9) The structure should not impose limitations that would prevent technical advancement -- such as the addition of code-splitting to a project that does not yet have it.

Because the files locations can be fitted to a rule, (i.e: src/${collection}/${namespace}/${name}/${type}), we can programatically crawl across the project and experiment with 'conventions', or compile scss without importing into the javascript, or invoke some transform on a particular sub-tree of the project.

A more concrete / real-world example (in user-space), by having the files split apart by route, we allow the file system to know our natural route/code-splitting boundaries -- which makes for a much easier implementation of code-splitting.

Implementation

1. How do you get everyone on the same page when anything can go?
2. How do you achieve consistency between developers?
3. How do you remember where something should go?
4. How do you manage imports with all these file trees?

For 1 through 3, the only answer for most projects is in-depth code reviews. After the first few established routes, it'll get easier to maintain. But it is inevitably a manual process, as most ecosystems do not have a way to programatically enforce conventions.

For managing imports, the best thing to do is to set up absolute aliases to common entry points.

For example:

    "paths": {
      "project-name/*: ["."],
      "@data/*": ["src/data/*"],
      "@models/*": ["src/data/models/*"],
      "@ui/*": ["src/ui/*"],
      "@components/*": ["src/ui/components/*],
      "@env": ["src/env.ts"],
      "tests/*": [ "tests/*" ],
      "*": ["types/*"],

This does mean that if you have deeply nested components, your import paths may be long, but they are easy to grep for, and you'll have an easier time moving subtrees around since there are no relative paths to worry about breaking.

An example of a React app implementing most of the criteria outline in this post: Example React App

However, in Ember, there is a resolver. The resolver defines a set of rules for finding things and contextually discovering components, routes, data models, etc. There are a set of conventions that allow the resolver to find things in app-space, so that you don't need to worry about importing them. There is a reference, the resolver looks up the reference, and the thing stubbed in.

Something unique about ember, is that it has a bunch of build-time optimizations that the other ecosystems don't have. This is powered by broccoli, where you can transform parts of your app file tree during the build process. Ember uses this to swap out lookups with the actual reference to a component (for example, could be other things). Broccoli is also used to swap out simple helpers such as {{fa-icon}} with the rendered html during build so that the bundle can be smaller.

To read more about ember's resolver, feel free to checkout DockYard's article, "Understanding Ember's resolver"
To read more about Broccoli, Oli Griffith has an amazing guide / tutorial on it

An example of this structure can be found here:
emberclear at gitlab (this is the code for emberclear.io, one of my side projects).

The Octane Layout's folder structure satisfies nearly all use cases. And the majority of this post represents a subset of the ideas from the The Octane Layout's RFC.

Note that the Octane layout is not yet released. It's coming early 2019, along with the release Ember Octane

Would I say that this in the layout people should use? maybe. There is some breathing room between what I've outlined for all js ecosystems to use and what the Octane layout dictates for ember-specific apps. Ultimately, if you are in an ecosystem where you have to decide how to lay things out, just keep the guidelines in mind as your placing files around, or copy everything here -- but with some tweaks. Ultimately, you need to do what is best for your team. Personally, with React, I feel close. Maybe there is a tool that could be written for non-ember projects that helps guide structure. Like a linter, but for file locations.

This post is inspired by the call for blog posts to determine the Ember 2019 roadmap (and the one from last year) -- while, over the past years I have not worked with ember professionally, I've enjoyed being involved in the community and being involved with the framework as whole as a hobby, there is no greater feeling than taking long breaks from a side project, and knowing exactly where you left off without any catchup/recall cost (I know this is hyperbole.. shhh). However, as I've been trying to stay up to date with the other ecosystems, mainly React, as that's been what I've professionally been doing the past almost three years, I've made note of things that are high on the hype train that I think will allow for ember's adoption to soar.

Octane

This is the edition that was started as a result of last years community blogging efforts. Ember, over the years, and especially with Module Unification, has kind of had a reputation for over-promising and under-delivering -- so it would be totally stellar to see this released soon. As far as I'm aware, there is only one major feature flag still on canary that has yet to make it to enabled by default, EMBER_METAL_TRACKED_PROPERTIES. Then the only remaining things are documentation. Which, I'll be helping with at the end of May as I'll be between jobs for a couple weeks. Exciting!

Website Redesign

The Website Redesign RFC was merged at the beginning of April of this year. It looks amazing! With the upcoming Octane changes, and entire paradigm shift in how ember is to be developed, implementing the redesign shortly after the release of Octane would be amazing. I mean, look at these pictures. (I'm very excited about this, but I have no idea on progress or timeline). With ember becoming more and more modern as time progresses, it's time we get the site up to date as well. It could hurt ember's growth otherwise.

Project Structure

Module Unification was originally planned to ship with Octane but as people were playing with it, it become clear that it was uncovering more questions about ergonomics than answers. Most notably (that I dealt with anyway) are local-lookup rules for tests, helpers, modifiers, everything. With the current state of Module Unification there are a lot of implicit rules that the developer needs to know about in order to use it effectively. Through bugging a bunch of people on the ember discord early on in 2018, I learned all the tips and tricks when implementing emberclear (source) -- but expecting everyone, especially those not comfortable with ember to begin with, to learn all that is asking too much.

There are a couple new~ish RFCs to help with part of this problem, SFC & Template Import Primitives and Component Templates Co-location. The SFC and Template Import Primitives one will allow addon authors to experiment with different project structures, as components could be imported from wherever, eliminating the need to memorize implicit local lookup rules and building on existing knowledge in how JavaScript module imports work. This RFC would also allow for Single-File Components which would be super handy for little things like buttons, links, etc. The Component Template Co-Location RFC will bring pods-like co-location of component and template files to the classic layout, which will be a huge improvement to project-browseability. I'm violently against the classic layout, so this would be a very welcomed change.

Query Params

Query Params are something that everyone agrees needs to be better. ember-parachute has taken a stab at making query params better. I've submitted an RFC and implemented a prototype addon that uses decorators to totally abstract away the boilerplate atd awkward APIs that the query params documentation currently instructs us to use -- bringing query param usage up to date with the rest of the modern world.

All I want is something like this:

import Route from '@ember/routing/route';
import { queryParam } from 'ember-query-params-service';

export default class ApplicationRoute extends Route {
  @queryParam('r') isSpeakerNotes;
  @queryParams('slide') slideNumber;

  model() {
    return {
      isSpeakerNotes: this.isSpeakerNotes,
      slideNumber: this.slideNumber
    }
  }
}

where the @queryParam decorator can be used anywhere -- components, routes, etc.

Better Error and Loading state handling

According to the routing guides on error and loading substates, for both errors and loading state, we need a template in various locations depending on our route structure and, for loading, which routes we think are slow enough to warrant a loading indicator (whether that be a spinner, or fake cards or other elements on the page). Additionally, there is a loading action fired per route that can optionally be customized in order to set parameters on the route's controller. I think this is needlessly complicated, and we can do better.

Maybe something we could do to make things less configuration-based and also be more explicit is to set properties on routes.

import Route from '@ember/routing/route';
import ErrorComponent from 'my-app/components/error-handler';
import LoadingComponent from 'my-app/components/loading-spinner';

export default class MyRoute extends Route {
  onError = ErrorComponent;
  onLoading = LoadingComponent;

  async model() {
    const myData = await this.store.findAll('slow-data');

    return { myData };
  }
}

This is just spit-balling here, but setting components to use as the error and loading state render contexts allows us to more intuitively tie in to the dependency injection system as well as have very clear shared resources for this common things. The actions that are called on error and loading could still exist, as those may be useful for maybe redirecting to different places in case of a 401 Unauthorized / 403 Forbidden error, but the main thing that I want, specifically for error states is that for any error that occurs within a route's subtree, the onError component should be rendered. This would catch errors that currently break the UI entirely, or are only printed to the console. Not only should network errors that occurs within the beforeModel, model, and afterModel hooks, but also during rendering. With component centric development, errors can happen anywhere, and it would be fantastic to have a centralized placed to handle those errors.

This is somewhat inspired by some React work I've done recently, where instead of directly using the react-router Routes, I wrapped them in an ErrorBoundary, which does exactly as I describe above. Any error that occurs, whether during rendering or otherwise is caught be the ErrorBoundary, and then an error-parsing component is rendered that can display the error in a meaningful way to the whomever is looking at the screen -- all without having to have the console open. It's great for that added insight into what's going on when the UI doesn't have as expected.

Route Splitting & Svelte Builds

In a world where most online devices are low-powered pocket-computers, to reach the broadest possible audience, it's important now, more than ever, that we pay attention to how our apps are shipped to each device. embroider is kinda beta~ish atm and enables route-splitting. I've done route-splitting in React, and other webpack-using projects… and it feels very manual. With ember I expect things to just work without having to configure things, and as I read the embroider readme right now, there is a splitAtRoutes option to enable, to make things "just work", no need to await import('file'), no need to come up with a loading scheme for your router to wait for the route subtree to load -- embroider does that all for you, which is super exciting! (Seriously, I can't express how excited I am for embroider to become the main build system for ember apps -- I've been in the React community so long, and hearing everyone make an excessive big deal over tiny apps needing route splitting and then watching all the hoops they have to jump through to implement it is exhausting… it's so relieving to to see a proper implementation). I would like to see embroider as a default sooner, rather than later, especially as Octane brings in a new wave of fresh blood, people are going to be wondering where the features are that embroider provides.

Additionally, along the same lines of shrinking bundle size, Svelte builds are to strip out unused features in ember. I don't know if this work has started, and I'm still a little fuzzy on the details, but it seems like for the crowd that are targeting PWAs and very low powered devices, where JS parse time is a serious issue, this would be a huge improvement -- for everyone.

Data

The changes I want to see in the data space may not exactly be ember-data related, but I know that there is a bunch of incremental progress to make the ember-data experience both more flexible and more friendly. The biggest things I want to see from data as a whole is for the { json:api } Operations Spec to land, so that we can have worry-free implementations. Operations is really exciting to me, because it brings parity to GraphQL while still having strong semantic correctness with relational data. Operations allow for easier websocket implementations while still using the { json:api } format -- and maybe more importantly, allows for sanctioned bulk behavior without hacks. Operations, generally, can be used today, but not with ember-data -- I'm very excited with the direction ember-data has been going lately, and I'll be even more excited as operations start to solidify.

Those are my main focuses this year, and I'll probably try to find a way to help progress each of them, as I'll actually be working with ember for the better half of this year. I'm very excited about all of this, and want it all now. :)

Partially due to the fact that I find coming up with things to write about somewhat difficult, I've been seeking articles from the React community to rewrite for Ember (primarily on twitter). This'll help the searchability of common patterns people may be familiar with when coming from React, or any other ecosystem which also has a similar nomenclature.

My hope for this series is only two things:

• Improve the perception of Ember with respect to modern features and behavior
• Show how conventions and architectural patterns can make everyone's lives easier.

In response to Setting Up Webpack for React and Hot Module Replacement (by thoughtbot), as proposed by @j_mcnally, I'll be going through the article in chunks as there are correlations with how all of what is explained could be done in an ember project.
The article is broken out into a few short sections:

1. Initializing a project

2. Setting up webpack

   a. Basic configuration

   b. Adding loaders

   3. Writing React components

   a. Adding an index page

   4. Setting up the webpack dev server

   a. Hot module replacement

It's a short article, and the first half is setting up the project -- so, if you have a terminal shell ready and are all setup for javascript development, feel free to run the following command to instantiate your project, and we can skip parts 1, 2, 2a, 2b, 3a and 4 (we'll get to 4a shortly).

Note: if all you care about is how to do Hot module replacement, feel free to skip ahead

npx ember-cli new hmr-demo -b @ember/octane-app-blueprint

Depending on your familiarity with ember, it may seem like this isn't enough to set up a project. Well, my friends, with the power of conventions and agreed upon tooling, the above command bundles all the above setup steps so that you don't need to care about them when making apps. Sure, if you enjoy tweaking webpack configs to try to squeeze out more loading performance or reduce bundle size in a variety of ways, that's fine -- but for being productive in feature development, it's not something that needs to be repeated for every project -- even in the React world, and especially at my previous company DeveloperTown (a consultancy), configuration files were copied and pasted between projects.

Next up, let's look at writing components in Ember -- by rewriting the "Greeting" component from the thoughtbot article.

yarn ember g component greeting

This creates 3 files as shown in this screenshot of the terminal output:

While the generate component command gives you 3 files, you don't need each of them. The generate command gives you those files so that, for most components, you have the availability to quickly open and edit, without having to create the files yourselves and implement the boilerplate.

in app/templates/components/greeting.hbs, we'll type out a little template that says Hello to whatever name we pass in. We can ignore the greeting.js and greeting-test.js files for now.

<div class='greeting'>
  Hello, {{@name}}!
</div>

Inside of app/templates/application.hbs, the entrypoint to rendering our application, we need to render our Greeting component.

<Greeting @name="Kerrigan" />

{{outlet}}

A note about the syntax used here, if coming from React, or any other ecosystem, the @ used when invoking a component signifies that the key-value pair is an argument, and not an attribute, such as class or data-test would be. This allows for some nice API design when building UI components where you want to give control of attribute values to the caller. For more information on this, see @pzuraq's blog post on Angle Brackets and Named Arguments

Hot module replacement

There is a package called ember-ast-hot-load which will do all of the hot module replacement for us. This enables us to maintain the greater application state while we work on individual components. We don't need to wait for the entire app to rebuild, or the page to refresh. This greatly benefits our development feedback loop by reducing wait time.

To install the package, we can run:

yarn ember install ember-ast-hot-load

Now we'll want to start our development server with

yarn start

To see the speed that hot module replacement gives you, let's modify the greeting component by wrapping the text in an h1 tag.

in app/templates/components/greeting.hbs:

<div class='greeting'>
  <h1>Hello, {{@name}}!</h1>
</div>

When you save the file you'll see the page update automatically without a page reload. If you don't believe it, feel free to remove the ember-ast-hot-load package from package.json and restart the dev server.

That's it!

tl;dr:

yarn ember install ember-ast-hot-load

done.

Want More Information?

• Getting started (general)
• Templates in Ember
• Components
• Addons and Dependencies
• The Ember Atlas
  • Ember for React Developers

In user interface development, there are many intermediate states that must be accounted for.
A user may click a button that triggers something that will take a while, such as an API request.
Maybe a websocket connection needs to be established,
or there is a page with search or autocomplete capabilities.
ember-concurrency solves a number of problems
with dealing with intermediate state in both user interaction and background async behavior.
Let's take a look at what ways that ember-concurrency makes things easier,
and what ways it's not needed.

Note: this post will be kept up to date with the latest decorators and
concurrency documentation as the decorators proposal and
babel transform support changes / improves.

Packages Versions at the time of writing:

• ember-cli-babel: 7.11.0
• ember-concurrency: 1.0.0
• ember-source: 3.14.0-canary

As a disclaimer: this post is not comprehensive, and there are likely additional use cases for both using and not using ember-concurrency.

Table Of Contents

• Submitting a Form
• Examples
  • Async Button
  • Text Search
• Further Reading

Submitting a form

Forms can be used for creating and updating data. Given that we have the following form:

<form {{on 'submit' this.onSubmit}}>
  <button type='submit'>Save</button>
</form>

Every time the user triggers the form's submit, this.onSubmit will be invoked. That sounds exactly what we want right? Well, not necessarily. Maybe onSubmit is defined as:

import Component from '@glimmer/component';
import { action } from '@ember/object';

export default class MyForm extends Component {
  @action
  async onSubmit() {
    await fetch('https://my.api/resource', { method: 'POST' });
  }
}

if the network is laggy, or if the user's browser hangs for whatever reason,
the user may get impatient and trigger the submit action again.
If this API endpoint is creating a new record on every request,
we now have duplicate data.
To protect against duplicating data,
we'll need to track state inside the submit action,
and represent that state on the form.

import Component from '@glimmer/component';
import { tracked } from '@glimmer/tracking';
import { action } from '@ember/object';

export default class MyForm extends Component {
  @tracked isSubmitting = false;

  @action
  async onSubmit() {
    if (this.isSubmitting) {
      return;
    }

    this.isSubmitting = true;

    await fetch('https://my.api/resource', { method: 'POST' });

    this.isSubmitting = false;
  }
}

<form {{on 'submit' this.onSubmit}}>
  <button type='submit' disabled={{this.isSubmitting}}>Save</button>
</form>

We've now doubled the amount of code in this example.

Unfortunately, assuming we're writing tests for our code, we may accidentally discover an error during our tests.

Called set on destroyed object

To resolve this, after every await, we need to check to see if our component has been destroyed.
Our action now becomes:

  async onSubmit() {
    if (this.isSubmitting) {
      return;
    }

    this.isSubmitting = true;

    await fetch('https://my.api/resource', { method: 'POST' });

    if (!this.isDestroyed && !this.isDestroying) {
      this.isSubmitting = false;
    }
  }

This problem is exacerbated if our action has multiple awaited function calls. There is a possibility of our context becoming destroyed after every await!

If there are many forms for dealing with various resources,
this becomes a lot of boilerplate --
which will grow in to a lot of difficult to maintain code as your project teams grow.
Inconsistencies will be introduced due to varying implementations or
people's perspectives on what state should be managed,
and what actions need to be protected. So what do we do?
How do we ensure a consistent implementation for all of this type of behavior?

ember-concurrency.

The above example, could be re-written as:

import Component from '@glimmer/component';
import { task } from 'ember-concurrency';

export default class MyForm extends Component {
  @(task(function*() {
    yield fetch('https://my.api/resource', { method: 'POST' });
  }).drop())
  onSubmit;
}

<form {{on 'submit' (perform this.onSubmit)}}>
  <button type='submit' disabled={{this.onSubmit.isRunning}}>Save</button>
</form>

We're back to having minimal code.
Not only do we no longer need to track the running state,
but the destroyed state is handled for us.

Notes on the new APIs introduced:

• task

  The task function handles all the "state" of the async behavior.
  This'll include running, not running, errored, how many concurrent task there are,
  what the last result or error was. For more information on task,
  see the task documentation.

• yield

  This is a keyword used in generators to yield control back to the calling context.
  In this case, the calling context is more or less abstracted away from us.
  It enables the function passed to task to be cancelled, or restarted,
  which get to the importance of shortly.

• drop

  This is an ember-concurrency api on the Task Property.
  It signifies the type of behavior we want. In this example,
  we want subsequent requests to be dropped or ignored,
  as we want to wait for the first request to be completed before allowing a subsequent request.
  This is important, because maybe the form won't even be on the page when the task finishes.
  A common pattern for CRUD is to redirect to a newly created resource for viewing,
  and this would enable that behavior to safely be performed.

• perform

  A template helper that returns a function that invokes perform on the task.
  The value returned by task isn't a function itself,
  but a Task that has a perform method.
  The Task encapsulates the state of the async behavior,
  and perform is how an instance of that behavior is created / started.

When wouldn't you use ember-concurrency?

ember-concurrency is not a replacement for async/await behaviors. It's a supplement. The rule of thumb is:

Use async/await when your function has no side-effects on the calling context.
Use ember-concurrency when there are side-effects, or limiting concurrent executions of a function.

Where a side-effect is:

• the setting of a variable in the invocation context (such as a service or component)
• the triggering of another task

For example, a side-effect-free function may look like this:

import Component from '@glimmer/component';
import ENV from 'app-name/config/environment';

export default class MyComponent extends Component {
  async getPosts() {
    let response = await fetch(`${ENV.host}/api/posts`);
    let json = await response.json();
    let data = JSON.parse(json);

    return data.posts;
  }
}

It does not set any properties on the class. If the component is destroyed while the fetch request is in-flight -- nothing will go wrong, as there is no set / assignment on a destroyed component.

If we desire to trigger getPosts from a user interaction, there will need to be an ember-concurrency task somewhere.

@action
async refresh() {
  let posts = await this.getPosts();

  this.posts = posts;
}

If we were to add an action invokes getPosts, we would run into two problems:

1. An error will occur "called set on destroyed object", if the component is destroyed before refresh finishes.
2. There is no way to prevent concurrent requests.

Both of these are solved with a Task

@(task(function*() {
  let posts = yield this.getPosts();

  this.posts = posts;
}).drop())
refresh;

It looks almost the same, except the task is cancelled when the component is destroyed, and all subsequent calls to refresh will be ignored, until the first running invocation finishes. But while refresh must be a task. getPosts can remain a vanilla JavaScript async/await function.

Examples

Async Button

Async buttons, or buttons that can be aware of the rejected or resolved states of a promise,
are a common pattern for one-click triggers of async behavior --
but that API calls, waiting for something processing-intensive, etc.

Going forward with this post, there will be minimal prose,
and mostly just before/after examples of pre/after ember-concurrency --
there will be some explanation of why someone wouldn't want to use ember-concurrency,
where appropriate.

Additionally, all examples will be using TypeScript to describe the API of the components.

Before

import Component from '@glimmer/component';
import { tracked } from '@glimmer/tracked';
import { action } from '@ember/object';

interface Args {
  promise: <ReturnType>() => Promise<ReturnType>;
  disabled?: boolean;
  label: string;
}

const SHOW_SUCCESS_FOR_MS = 2000;

export default class AsyncButton extends Component<Args> {
  @tracked isSuccess = false;
  @tracked isRunning = false;
  @tracked isError = false;

  @tracked error?: string;

  get isIdle() {
    return !this.isRunning;
  }

  @action
  async onClick() {
    if (this.isRunning) {
      return;
    }

    this.reset();

    try {
      await this.args.promise();

      if (!this.isDestroying && !this.isDestroyed) {

        this.isSuccess = true;

        await new Promise((resolve) => {
          setTimeout(
            () => this.reset(),
            SHOW_SUCCESS_FOR_MS
          );
        });
      }


      return;
    } catch (e) {
      if (!this.isDestroying && !this.isDestroyed) {
        this.error = e.message;
        this.isError = true;
      }
    }


    if (!this.isDestroying && !this.isDestroyed) {
      this.isRunning = false;
    }
  }

  reset() {
    this.isSuccess = false;
    this.isError = false;
    this.isRunning = true;
    this.error = undefined;
  }
}

<button
  {{on 'click' this.onClick}}
  ...attributes
  disabled={{or this.isRunning @disabled}}
>
  {{#if this.isIdle}}
    {{@label}}
  {{else if this.isRunning}}
    Running...
  {{else if this.isSuccess}}
    Success!
  {{else if this.isError}}
    Error: {{this.error}}
  {{/if}}
</button>

After

import Component from '@glimmer/component';
import { tracked } from '@glimmer/tracking';
import { task, timeout } from 'ember-concurrency';

interface Args {
  promise: <ReturnType>() => Promise<ReturnType>;
  disabled?: boolean;
  label: string;
}

const SHOW_SUCCESS_FOR_MS = 2000;

export default class AsyncButton extends Component<Args> {
  @tracked isSuccess = false;

  @(task(function*() {
    yield this.args.promise();
    this.isSuccess = true;

    yield timeout(SHOW_SUCCESS_FOR_MS);

    this.isSuccess = false;
  }).drop())
  promiseRunner;
}

<button
  {{on 'click' (perform this.promiseRunner)}}
  ...attributes
  disabled={{or this.promiseRunner.isRunning @disabled}}
>
  {{#if this.promiseRunner.isIdle}}
    {{@label}}
  {{else if this.promiseRunner.isRunning}}
    Running...
  {{else if this.isSuccess}}
    Success!
  {{else if this.promiseRunner.isError}}
    Error: {{this.promiseRunner.error}}
  {{/if}}
</button>

Text Search

Before

import Component from '@glimmer/component';
import { tracked } from '@glimmer/tracking';

const DEBOUNCE_MS = 250;

interface Args {
  onSearch: <ResultType>(text: string) => Promise<ResultType>
}

function waitMs(ms) {
  return new Promise((resolve) => {
    setTimeout(resolve, ms);
  });
}

export default class TextSearch extends Component<Args> {
  @tracked text = '';

  lastInvocation = undefined;

  async search() {
    this.lastInvocation = new Date();

    await waitMs(DEBOUNCE_MS);

    if (this.isDestroying || this.isDestroyed) {
      return;
    }

    let waitEndedAt = new Date();

    // did we search again while waiting?
    let didSearchAgain = this.lastInvocation - waitEndedAt < DEBOUNCE_MS;

    if (didSearchAgain) {
      return; /* do not invoke search */
    }

    await this.args.onSearch(this.text);
  }
}

<form {{on 'submit' this.search}}>
  <Input @value={{this.text}} />

  <!-- submit on press of enter key-->
  <button type='submit'>Search</button>
</form>

After

import Component from '@glimmer/component';
import { tracked } from '@glimmer/tracking';
import { task, timeout } from 'ember-concurrency';

const DEBOUNCE_MS = 250;

interface Args {
  onSearch: <ResultType>(text: string) => Promise<ResultType>
}

export default class TextSearch extends Component<Args> {
  @tracked text = '';

  @(task(function*(){
    yield timeout(DEBOUNCE_MS);

    yield this.args.onSearch(this.text);
  }).restartable())
  search;
}

<form {{on 'submit' (perform this.search)}}>
  <Input @value={{this.text}} />

  <!-- submit on press of enter key-->
  <button type='submit'>Search</button>
</form>

Further Reading

The ember-concurrency docs have a very thorough explanation of a single example of before and after applying ember-concurrency to a problem.

Series Intro feel free to skip

Partially due to the fact that I find coming up with things to write about somewhat difficult, I've been seeking articles from the React community to rewrite for Ember (primarily on twitter). This'll help the searchability of common patterns people may be familiar with when coming from React, or any other ecosystem which also has a similar nomenclature.

My hope for this series is only two things:

• Improve the perception of Ember with respect to modern features and behavior
• Show how conventions and architectural patterns can make everyone's lives easier.

Rather than a response to a particular blog featuring React, this is more of a demonstration of correlating design patterns between the two ecosystems. Thanks to @vlascik for the suggestion to cover React's render props pattern.

First, let's clarify what a render prop is for those who may not be familiar with the term. According to the React Documentation:

The term “render prop” refers to a technique for sharing code between React components using a prop whose value is a function.

In React, components are just functions™, so any prop passed to a component whos value is a function that returns JSX is considered a "render prop".

Some examples:

<Header
  {/* profileImage is the render prop */}
  profileImage={profileProps => {
    return (
      <LargeProfileImage {...profileProps} />
    )
  }
}>
  <AppNavigation />
</Header>

<Header>
  <AppNavigation />
  {/* children, an implicit render prop passed to Header when there is block content */}
  <LargeProfileImage />
</Header>

where Header could be defined as:

export function Header({ profileImage, children }) {
  return (
    <header>
      <HomeLink />

      {children}

      {profileImage &&
        profileImage({ className: 'header-image' })
      }
    </header>
  )
}

When would someone want to use render props in React?

When a part of a component's template needs to be different between usages of that component. Rather than using conditionals in the component (in this case Header), render props allow yielding control to the calling context.

Ember has the exact same capabilities, but under a different name: "Yieldable Named Blocks". Which we'll get to after we talk about the default / easy thing to do with both ecosystems.

{children}

For {children}, however, there is an exact corollary in Ember: {{yield}}.

Both words have great semantic meaning as well.

A parent component yields the rendering context to its children.

The default template generated for a component contains a single line: {{yield}}.
Let's change that to mimic the React example:

<header>
  <HomeLink />

  {{yield}}
</header>

aside from not having the profileImage render prop, these templates are the exact same, but with {children} replaced with {{yield}}

Any other render prop

In Ember, we'd still use yield, but with a parameter to create named 'blocks' that the calling context can use. These yields with the to argument are "Yieldable Named Blocks" (available in Ember 3.20+)

Example using Header, from above:

<header>
  <HomeLink />

  {{yield}}

  {{yield to='image'}}
</header>

and then the calling context would look like:

<Header>
  <AppNavigation />

  <:image>
    <LargeProfileImage />
  </:image>
</Header>

Passing Arguments

For both of these examples, assume there is a UI Library which provides a bunch of component primivites for constructing the common UI pattern / "Card".

in React:

export function SomeComponent({ header, content, children, footer }) {
  return (
    <Card>
      {header && (
        <CardHeader>
          {header({
            Image: CardHeaderImage,
            Icon: CardHeaderIcon
          })}
      </CardHeader>
      )}

      <CardContent>
        {children}
        {content && content()}
      </CardContent>

      {footer && (
        <CardFooter>
          {footer()}
        </CardFooter>
      )}
    </Card>
  )
}

and then in the calling context

export function App() {
  return (
    <SomeComponent
      header={({ Image }) => {
        return (
          <>
            <Image src='path/to-image.png' />

            My Header!
          </>
        );
      }}

      footer={() => {
        return (
          <button>Call to Action</button>
        );
      }}
    >
      freely yielded content
    </SomeComponent>
  );
}

in Ember:

{{!-- some-component --}}
<Card>
  {{#if (has-block 'header')}}
    <CardHeader>
      {{yield
        hash=(
          image=(component 'card-header-image')
          icon=(component 'card-header-icon')
        )
        to='header'
      }}
    </CardHeader>
  {{/if}}

  <CardContent>
    {{yield}}
    {{yield to='content'}}
  </CardContent>

  {{#if (has-block 'footer')}}
    <CardFooter>
      {{yield to='footer'}}
    </CardFooter>
  {{/if}}
</CardModal>

{{!-- the calling context --}}
<SomeComponent>
  <:header as |headerComponents|>
    <headerComponents.image src='path/to-image.png' />

    My Header!
  </:header>

  <:footer>
    <button>Call to Action</button>
  </:footer>

  <:default>
    freely yielded content
  </:default>
</SomeComponent>

What's cool about named blocks is that, as a component author, you are in control of the order the components are rendered.
So in the above example where header is first and footer is second, those could be flipped, but still rendered in the same locations,
because the content is placed where the corresponding {{yield to="name"}} block is. I like that a lot, and it's something I always
wanted when I was writing React components.

Want More Information?

• The RFC for Yieldable Named Blocks
• The Ember Atlas
  • Ember for React Developers

One of the most common things I hear from people who are new to Ember,
new to programming in general, or coming from another frontend ecosystem
(especially React and Vue), is that they think Ember's dependency injection
system is too complicated and magical --
too hard to reason about or know where the injected services come from.
I, too, was in that boat -- until I really dove into how it works -- it was
then that I began to understand why dependency injection even exists, and
how it's actually simpler than not having it at all.

What is Dependency Injection?

According to Wikipedia

dependency injection is a technique in which an object receives other
objects that it depends on.

That's it.

So… this is dependency injection?

let foo = new Foo()

let bar = new Bar(foo);

yes!.

The big deal with dependency injection usually comes from managing how an object
receives those other objects.

Why use Dependency Injection?

For me personally, there are two reasons:

1. Application State (data and functions) can be easily shared between components
2. Testing is much easier and can be done in isolation

For #1, there are many ways to share state between components, but I like that
dependency injection provides a centralized pattern and location for that state
as well as an ergonomic and light way to interact with that state.

For #2, this is a little harder to boil down to a sentence or two, and ultimately
comes down overall architecture of your app, how big your app is, and what sorts of
things provide value when tested. For example, let's say you have some behavior
for interacting with an external API, maybe it's the Star Wars JSON api,
or maybe it's interacting with a game that you're building a bot for -- you could
build all that functionality into your component(s) -- because why prematurely abstract?
But you could also build that functionality into a Service, or "just another
class that your component will end up using", like this:

class MyComponent {
  constructor() {
    this.api = new StarWarsApi();
  }
}

let myComponent = new MyComponent();

This is a great first step! as the StarWarsApi can be tested by itself without
needing to be tied to your component. However, your component has the opposite
problem, it is dependent on the StarWarsApi, and there is no way to test
the behaviors of MyComponent without using the real implementation of StarWarsApi.
The solution to this is dependency injection, where the coupling between the
specific implementation of StarWarsApi is reduced to just the interface
(the list of methods that we care about), and during testing, we can swap out
the StarWarsApi with a fake one that has all the same methods.

class MyComponent {
  constructor(api) {
    this.api = api;
  }
}

let fakeApi = { /* fake stuff here */ }
let myComponent = new MyComponent(fakeApi);

There is a lot of information on this topic, and I think this StackOverflow Answer
summarizes it well:

So, to cut a long story short: Dependency injection is one of two ways of how
to remove dependencies in your code. It is very useful for configuration
changes after compile-time, and it is a great thing for unit testing
(as it makes it very easy to inject stubs and / or mocks).

Which reminds me of the whole point of software engineering and architecture in
general: to make testing easier.

If we do not learn from the mistakes of those before us and allow ourselves to make
testing hard for both our coworkers as well as our future selves, we are doing
our coworkers (and ourselves!) a disservice.

This could easily go on a tangent about the important and philosophy of testing
and testing-driven architecture, but that's a topic for another time.

How does Dependency Injection work in Ember?

I think the best way to describe this is to first demonstrate how we would create
our own dependency injection system from scratch.

This is a bottom-up approach, meaning that we start with the bare minimum, and the
gradually add more behavior as we move forward. First, we'll need to define some
terms and set goals, so we're on the same page:

Nomenclature:

• Service: a named bucket of state and/or behavior (usually a class instance);
• Injection: the act of defining a reference to a Service
• Container: the object that holds references to each Service

Goals:

1. A Service can be referenced from anywhere, regardless of where it is accessed
2. A Service is a singleton
3. Services can reference each other (circular dependencies are valid)
4. Access to the global namespace is not allowed

This could be considered an ancestor to dependency injection, where there exists
a shared container object in the module scope, still allowing for us to
achieve the first three goals.

// app.js
let container = {};

function bootApp() {
  initializeServices();

  container.bot.begin();
}

class Bot {
  begin() {
    let nextMove = container.ai.getMove();

    container.ui.sendKeyPress(nextMove);
  }
}

function initalizeServices() {
  container.ai = new AI();
  container.bot = new Bot();
  container.ui = new UI();
}


bootApp();

To see this code in action, view this CodeSandBox

In a multi-file environment we don't have access to the same module scope between files,

// app.js
import Bot from './bot';
import AI from './ai';
import UI from './ui';

let container = {};

function bootApp() {
  initializeServices();

  container.bot.begin();
}

function initializeServices() {
  container.ai = new AI(container);
  container.bot = new Bot(container);
  container.ui = new UI(container);
}

// bot.js
export default class Bot {
  constructor(container) {
    this.container = container;
  }

  begin() {
    let nextMove = this.container.ai.getMove();

    this.container.ui.sendKeyPress(nextMove);
  }
}

To see this code in action, view this CodeSandBox

However, as a framework or library developer, forcing users / application developers
to remember to assign the container each time isn't very ergonomic.

// app.js
// same as before

// service.js
export default class Service {
  constructor(container) {
    this.container = container;
  }
}

// bot.js
import Service from './service';

export default class Bot extends Service {
  begin() {
    let nextMove = this.container.ai.getMove();

    this.container.ui.sendKeyPress(nextMove);
  }
}

This is a little better, we have abstracted away a bit of boilerplate, but there is still
a "magic property", container -- this is generally where object oriented programming
can get a negative reputation for -- a lack of proper or incomplete abstraction.

A bad abstraction is worse than no abstraction

So, let's clean that up a bit using a decorator

// app.js
// same as before

// service.js
let CONTAINER = Symbol('container');

export default class Service {
  constructor(container) {
    // the container is now set on a symbol-property so that app-devs don't
    // directly access the container. We want app-devs to use the abstraction,
    // which we're aiming to be more ergonamic
    this[CONTAINER] = container;
  }
}

// this is a decorator, and would be used like `@injectService propertyName`
// where target is the class, name would be "propertyName", and descriptor is the
// property descriptor describing the existing "propertyName" on the class that is
// being decorated
//
// For more information on decorators, checkout the above linked decorator plugin
// for babel.
export function injectService(target, name, descriptor) {
  return {
    configurable: false,
    enumerable: true,
    get: function() {
      if (!this[CONTAINER]) {
        throw new Error(`${target.name} does not have a container. Did it extend from Service?`);
      }

      return this[CONTAINER][name];
    }
  }
}

// bot.js
import Service { injectService } from './service';

export default class Bot extends Service {
  @injectService ai;
  @injectService ui;

  begin() {
    let nextMove = this.ai.getMove();

    this.ui.sendKeyPress(nextMove);
  }
}

To see this code in action, view this CodeSandBox

With this approach we can reference each service by name -- but we have a new problem now:
as a framework developer, how do we ensure that service properties match up to the service classes?

In the current implementation, we've been arbitrarily assigning values on the container object,
ui, ai, and bot. Since this has been in user-space, we've always known what those properties
are on the container.

This is where convention steps in.

As framework / library authors, we can say that services are required to be in the
services/ folder of your project.

let container = {};

function bootApp() {
  initializeServices();

  container.bot.begin();
}

function initializeServices() {
  for (let [name, AppSpecificService] of detectedServices) {
   container[name]  = new AppSpecificService(container);
  }
}

However, if you're familiar with module-based javascript, you'll noticed that detectedServices
needs to somehow be aware of the services in the services/ folder and know their names.

This is where a CLI, at build-time, can help out our framework at run-time.

In Ember, this step is handled be the ember-resolver
which then defers to requirejs,
which defines modules in the AMD
format -- which, for now, we don't need to worry about.

For demonstration purposes, we'll "say" that our bundler and CLI are configured
together to produce a map of relative file paths to modules:

let containerRegistry = {
  'services/bot': await import('./services/bot'),
  'services/ai': await import('./services/ai'),
  'services/ui': await import('./services/ui'),
}

so then our app.js may look like this:

let knownServices = Object.entries(containerRegistry);
let container = {};

function bootApp() {
  initializeServices();

  container.bot.begin();
}

function initializeServices() {
  for (let [fullName, ServiceModule] of knownServices) {
    let name = fullName.replace('services/', '');
    let DefaultExport = ServiceModule.default;

    container[name]  = new DefaultExport(container);
  }
}

So now in our documentation, we can write that whatever the file name of the service is
will be the name of the property pointing to an instance of that service within
the container.

Now, what if we wanted our services to be lazily instantiated, so that we don't negatively
impact the time to interactive benchmark if we don't have to?

So far our container has been a plain old object. We can utilize a Proxy

let knownServices = Object.entries(containerRegistry);
let registry = {};

let container = new Proxy(registry, {
  get: function(target, propertyName) {
    if (target[propertyName]) {
      return target[propertyName];
    }

    let FoundService = lookupService(propertyName);

    target[propertyName] = new FoundService(container);

    return target[propertyName];
  }
});

function lookupService(serviceName) {
  let fullPath = `services/${serviceName}`;
  let doesServiceExist = Object.keys(containerRegistry).includes(fullPath);

  if (!doesServiceExist) {
    throw new Error(`The Service, ${serviceName}, was not found.`);
  }

  // We establish a convention that the service is defined on the default export
  return containerRegistry[fullPath].default;
}

function bootApp() {
  // initialization now happens on-demand
  container.bot.begin();
}

To see the final implementation, view this CodeSandBox

What does Ember do behind the scenes?

Ember abstracts nearly all of the above from you and provides conventions for
building out the map of service names to service instances, accessing those
services, and creating any container aware-object.

The most important thing to know about the container, is that it'll
provide the contained, known internally-to-ember as the "owner", as
the first argument to each of your classes.

So, if you want to have your own "kind" of object, maybe it's a bunch of custom
objects that interact with something external, such as an API, or a Canvas, or WebGL,
or .. really anything!, it's possible to register your objects with Ember's
container.

Ember does this internally for Services, Routes, Controllers, Components, Helpers,
and Modifiers, but to do what ember is doing, have this somewhere in your app

// maybe in a Route's beforeModel hook
let owner = getOwner(this);
owner.register(
  /*
    full name in the format:
    namespace:name
  */
  'webgl:renderer',
  /* class */
  Renderer
);

Now, how would you access that from your component? It's not a service, so the
service decorator wouldn't work. First, let's look at what the service decorator does look like

// abridged version of the @service decorator
//
//
// NOTE: ember convention is:
//   import { inject as service } from '@ember/service';
export function inject(target, name, descriptor) {
  return {
    configurable: false,
    enumerable: true,
    get: function() {
      let owner = getOwner(this);

      return owner.lookup(`service:${name}`);
    }
  }
}

So that way, when you have @service api, the namespace gets prepending for
you, and the service:api full name is looked up in the container.

Knowing the above, we can make our own decorator so that we may access the our
"foo" singleton

export function webgl(target, name, descriptor) {
  return {
    configurable: false,
    enumerable: true,
    get: function() {
      let owner = getOwner(this);

      return owner.lookup(`webgl:${name}`);
    }
  }
}

So then anywhere in our app, we could have a component with the following:

class MyComponent extends Component {
  @webgl renderer;
}

"That's all, folks!"

Once I realized the implementation of ember's dependency injection, it felt
simple. It's pretty much a global store where instances of classes are
stored on that global store and referenced from other places within your app.
If something here doesn't feel simple, let me know!, and hopefully I can tweak
this blog post until it does feel simple.

I like the pattern a lot, because it avoids the need to explicitly pass references
to every object you want to use throughout your entire app. Instead, Ember abstracts
away the passing of the container object to all objects created through that container
(mostly components and services, but custom classes can be used as well).

Disclaimers

Dependency injection can be a big topic and have a lot of features implemented.
This demonstration has narrow scope and is not intended to be a "fully featured"
dependency injection implementation.

About

Professionally, I had my start to frontend development in React, and at the time
there was really only Redux and MobX for state management -- but I only had the
privilege of working with Redux and eventually React's Context Provider/Consumer
pattern. There is a little bit of overlap between React's Contexts and Ember's
Services, but they differ in fundamental ways -- which could be a topic for
another time.

Now that I'm getting paid to work with Ember almost every day I've only
gotten more excited about the programming patterns introduced by the framework and
am eager to share them with the world.

This was inspired from some conversations on Twitter as well as trying not to use a web framework for building an Artificatial Intelligence to play a game

References

• TC39 Decorator Proposal
• Ember Documentation on Dependency Injection

Ever been curious about how much space your node_modules directories are taking up across every project on your file system?

From the root of your project directory, run:

find . -name "node_modules" -type d -exec du -bc {} + \
  | grep total$ \
  | cut -f1 \
  | awk '{ total += $1 }; END { print total }' \
  | numfmt --to=iec

Explanation: https://unix.stackexchange.com/a/589060

This will search for every node_modules directory, find the size, and add all the sizes together before showing you a number.

For me (on an overworked computer), this was:

40G
>> took 6m37s

I don't use WebStorm, but common feedback I get from people who use WebStorm is that they don't have all the features and niceties that you'd get with neovim or VSCode even.

The main features missing from WebStorm (by default) are:

• hbs tagged template literal highlighting in JavaScript and TypeScript. This is useful for tests, single-file components, as well as multi-component files.
• Ember Language Server support. This provides a bunch of hints, go-to-definition from templates, and a bunch of nice features.
• Integration with ember-template-lint. This is normally provided by the language server… but without the language server, there are no lint hints.
• Correct template parsing. WebStorm uses handlebars parsing, which isn't correct for ember and glimmer projects as the language of templates used is only handlebars-esque and is actually much richer than handlebars while also eliminating many features of handlebars that people don't like (like implicit context scoping). It also seems that components and named blocks are incorrectly identified as custom html tags, giving you a yellow squiggly under them.
  

hbs template string higlighting

So far, I've been able to solve the hbs tagged template literal highlighting in JavaScript and Typescript, and here is how you can set that up yourself,

In WebStorm 2021.2.2,

1. Open the File Menu > Settings

2. Search for "Injection"

3. Click on "Language Injections"

4. Click on "HTML in JS strings"

5. Click the "Duplicate" button

6. Double Click on your duplicated "HTML in JS strings"

7. Change the settings to look like this

   • Name: HBS in JS strings
   • ID: Handlebars
   • Places Patterns: + taggedString("hbs")

   

8. End Result gets you hbs tagged template literal highlighting in both tests and non-test code:
   

Other editor experiences

There are two plugins at the moment for working with Ember in IntelliJ editors:

• Ember.JS

• and Ember Experimental.JS

  According to the author, this adds (in addition to the previous plugin):

  • Handlebars references for tags/mustache paths and tag attributes
  • Handlebars autocompletion for tags and mustache paths
  • Handlebars parameter hints for helpers/modifiers and components
  • Handlebars renaming for mustache ids and html tags

  For all the other problems, I'll be periodically checking in with the folks who work on the Ember plugins for the IntelliJ family of editors, and see if it's feasible to get things moving sooner or later (scale of timeline unknown, obvs).

Note that at the time of writing, I only have these plugins installed

• Ember.JS
• One Dark theme
• Rider UI Theme Pack

MSW

• Using MSW for tests only
• Using MSW for development

CSS / Styles

• tailwind, postcss, embroider

Component/Template Demos / Concepts

• In this other post
  • Effects
  • Loading Remote Data
  • Forms / Inputs
  • Resources
  • Modifiers via the ember-modifier README -- probably the most comprehensive introduction to modifiers atm.

Patterns / Concepts

• "Keep it Local" by @chriskrycho / EmberConf 2021 (Video)
• re-thinking lifecycles
  • avoiding @ember/render-modifiers
• Authenticated Routes

Starter Repos / Apps (needs READMEs / instructions for tooling setup)

• Polaris
• Polaris + Toucan (Polaris + tailwind, using the Toucan design system tailwind preset)
• Vite - lightning fast boot and rebuild times, at the cost of compatibility with existing projects
• Tauri - example of how to use Tauri with Ember.

Custom Blueprints

• vitest - since vitest only runs in node, this is only useful for testing non-browser things
• complex blueprint - the v2 addon blueprint -- lots of flags / behaviors, generates multiple packages/projects

Example Apps

• Octane: TodoMVC - deployed here - guide on MDN

Originally posted here on the Ember Forums -- there is some additional discussion there as well.

This post will be a collection of demos I've used in response to questions from various community members -- for the purpose of finding these again easily, and maybe other folks will f ind them useful as well.

Loading Remote Data

• shows how to use loading state
• keeps the UI stable while new data is loaded / refresh

Demos:

• using Resources - uses resources in the template
• using a keepLatest Resource - uses resources in JS - and keepLatest from ember-resources
• exposing the implementation of keepLatest - uses resources in JS

Forms / Inputs

• automatic binding of inputs (better than both two-way binding and one-way binding)
• checkboxes
  • controlled input (explicit binding)
  • uncontrolled input (automatic binding)

Polling

• Using 0 libraries (as of 4.10.0)
• Using ember-resources

Resources

• Clock - encapsulated state and providing a single reactive value.

Rendering

• elsewhere / with portals via in-element
• conditional modifiers
• dynamically rendering components, statically

Effects

Note that effects should be avoided (in any ecosystem, not just ember). They are an easy thing to grab for, but often a symptom of a bigger problem. Most effects I've seen (whether implemented as helpers (as in the demos below) or as modifiers (like @ember/render-modifiers) should actually just be a @cached getter. Derived data patterns are much easier to debug and provide much nicer stack traces, whereas effects are "pretty much" observers, which can suffer from "spooky action at a distance" or "weird stacktrace".

• calling a function once
• calling a function in response to arg changes
• an effect that relies on auto-tracking to re-run

demos

Originally posted here on the Ember Forums -- there is some additional discussion there as well.

The RFC that concluded the research in to this new file format is
RFC#779 First-Class Component Templates

For all projects

1. For syntax highlighting:

   • in neovim and VSCode, see here
   • on the web,
     • highlight.js via highlightjs-glimmer
     • shiki has gjs support built in

2. For type checking gts, you'll use glint instead of tsc.
   Ember Glint documentation is here on the Glint docs site.
   
   
   Ensure that your tsconfig.json has

   {
     "compilerOptions": { /* ... */ },
     "glint": {
       "environment": [
         "ember-loose",
         "ember-template-imports"
       ]
     }
   }

   
   
   Note that in Glint projects, you'll want to disable tsserver, so you don't have double-reported errors.

3. For linting, there are two paths:

   • Quickest:
     
     use configs.ember() from @nullvoxpopuli/eslint-configs
   • Modifying you're existing lint command:
     

     eslint . --ext js,ts,gjs,gts

   if you otherwise don't specify extensions, having a sufficiently new enough lint config from the app blueprint should "just work"

   • make sure you have at least eslint-plugin-ember@12.0.2
   • use the ember eslint parser in your eslint config, (mentioned in the eslint-plugin-ember README)

      module.exports = {
         // ...
         overrides: [
           // ...
           {
             files: ['**/*.gts'],
             plugins: ['ember'],
             parser: 'ember-eslint-parser',
           },
           {
             files: ['**/*.gjs'],
             plugins: ['ember'],
             parser: 'ember-eslint-parser',
           },
         ],
      };

   To get linting working in VSCode, you'll need to modify your settings (and be sure to include the defaults as well for both of these settings):

   "eslint.probe": [
    // ...
    "glimmer-js", 
    "glimmer-ts"
   ],
   "eslint.validate": [
     // ...
     "glimmer-js",
     "glimmer-ts"
   ],
   // ...
   "prettier.documentSelectors": ["**/*.gjs", "**/*.gts"],

   For neovim,

   local lsp = require('lspconfig')
   
   -- ✂️ 
   
   local eslint = lsp['eslint']
   
   eslint.setup({
     filetypes = { 
       "javascript", "typescript", 
       "typescript.glimmer", "javascript.glimmer", 
       "json", 
       "markdown" 
     },
     on_attach = function(client, bufnr)
       vim.api.nvim_create_autocmd("BufWritePre", {
         buffer = bufnr,
         command = "EslintFixAll",
       })
     end,
   })

   neovim has support for typescript.glimmer and javascript.glimmer built in. vim-polyglot breaks neovim's built-in syntax resolving, so uninstall that if you have it (neovim ships with treesitter which has very extensive language support).

4. For prettier/formatting, you'll need prettier-plugin-ember-template-tag
   And for the best experience / workflow, run eslint and prettier separately (without the popular eslint-plugin-prettier)

In an App

1. Install ember-template-imports.

2. If you use TypeScript,

   1. update your babel config to have:

       "plugins": [
         [
           "@babel/plugin-transform-typescript",
           { "allExtensions": true, "onlyRemoveTypeImports": true, "allowDeclareFields": true }
         ],
         // ...

   3. update your tsconfig.json to have (in compilerOptions)

     "verbatimModuleSyntax": true,

In a v1 Addon

1. Install ember-template-imports.

   npm add ember-template-imports

   it is important that this library be in dependencies, not devDependencies

2. If you use TypeScript,

   1. update your babel config to have:

       "plugins": [
         [
           "@babel/plugin-transform-typescript",
           { "allExtensions": true, "onlyRemoveTypeImports": true, "allowDeclareFields": true }
         ],
         // ...

   2. update your tsconfig.json to have (in compilerOptions)

     "verbatimModuleSyntax": true,
     "allowImportingTsExtensions": true,

In a v2 Addon

1. @embroider/addon-dev provides a addon.gjs() plugin.

Usage and Patterns

See the interactive glimmer tutorial: https://tutorial.glimdown.com

Notes

ember-template-imports easily provides a prototype of the features described by RFC#779, but embber-template-imports is not the final form of the <template> feature -- it as an easy way to set up the support today, but future techniques for enabling <template> will be easier. When reviewing the README for ember-template-imports, ignore everything about hbs, it will not be supported.

Example Projects using gjs/gts

Each of these projects is setup with linting, typechecking, etc

Hopefully they can be a reference for when issues are encountered upon setup

• The Limber Project (REPL and Tutorial)

• ember-resources

• ember-primitives

• ember-headless-form

• ember-headless-table

  See also

  • Glint and <template>

I had given a brief look at null_ls a while back, and didn't really comprehend what it wanted of me. I didn't understand how my neovim config applied, and how I setup my language servers would be applicable or not.

It wasn't until yesterday when I was playing around with custom root_dir functions on tsserver and glint language server.

Normal language servers are set up by requiring lspconfig and calling the appropriate server's setup method:

local lsp = require('lspconfig')

lsp[serverName].setup({   
  -- config here
})

and null_ls is similar:

local null_ls = require('null-ls')

null_ls.setup({
 -- config here
})

and that's the whole gist 🎉.

Of course, just being able to call setup isn't enough, I wanted the following features:

• eslint
  • diagnostics and code-actions
  • run on save
• prettier
  • diagnostics and code-actions
  • run on save
• spell check diagnostics and actions
  • a single machine-global file to store my custom words
  • I had lost this when I switched away from CoC

It turns out that all of these integrations are built-in to null_ls!!

As I was browsing for which built-in configs would work best for me, I learned that both prettier and eslint have daemon versions, eslint_d and prettierd. This is important to me because I want my editor to be as fast and as responsive as possible, and in order to accomplish that with node's boot time, daemonizing just makes sense to help out with time and memory and block the main thread for the least amount of time possible while performing "format on save". Both README's for these two tools explain the philosophy behind their approaches.

To make null_ls as obvious and as isolated as possible, I did all configuration in a separate file that I require from my main lsp-config lua file.

To set up all null_ls stuff, I do this "somewhere":

require('plugin-config.lsp.integrations')

where I have a plugin-config/lsp/integrations.lua file where all the null_ls code lives.

The Code / config

In my file where I configure what plugins I want, I have this:

use {
  'jose-elias-alvarez/null-ls.nvim',
  requires = { "nvim-lua/plenary.nvim" }
}

I use packer for package management.

The official docs are really good, and I really just needed to have read them.

Then my plugin-config/lsp/integration.lua file has these contents, below -- this is the combination of a bunch of docs, example code, and other people's solution to problems. I'll explain in comments in the snippet in case things may not be clear.

---------------------------------------------------------
--
-- NULL LS is for hooking up non-LSP tools to the LSP UX
--
--
-- Be sure to :checkhealth to see if any underlying tools are missing
--
-- pnpm add --global @fsouza/prettierd cspell typescript
--
---------------------------------------------------------
local null_ls = require('null-ls')
local augroup = vim.api.nvim_create_augroup("LspFormatting", {})

-- TODO: figure out how to wire up ember-template-lint
local lsp_formatting = function(buffer)
  vim.lsp.buf.format({
    filter = function(client)
      -- By default, ignore any formatters provider by other LSPs 
      -- (such as those managed via lspconfig or mason)
      -- Also "eslint as a formatter" doesn't work :(
      return client.name == "null-ls"
    end,
    bufnr = buffer,
  })
end

-- Format on save
-- https://github.com/jose-elias-alvarez/null-ls.nvim/wiki/Avoiding-LSP-formatting-conflicts#neovim-08
local on_attach = function(client, buffer)
  -- the Buffer will be null in buffers like nvim-tree or new unsaved files
  if (not buffer) then
    return
  end

  if client.supports_method("textDocument/formatting") then
    vim.api.nvim_clear_autocmds({ group = augroup, buffer = buffer })
    vim.api.nvim_create_autocmd("BufWritePre", {
      group = augroup,
      buffer = buffer,
      callback = function()
        lsp_formatting(buffer)
      end,
    })
  end
end

null_ls.setup({
  sources = {
    -- Prettier, but faster (daemonized)
    null_ls.builtins.formatting.prettierd.with({
      filetypes = { 
        "css", "json", "jsonc","javascript", "typescript",
        "javascript.glimmer", "typescript.glimmer",
        "handlebars"
      }
    }),

    -- Code actions for staging hunks, blame, etc 
    null_ls.builtins.code_actions.gitsigns,
    null_ls.builtins.completion.luasnip,

    -- Spell check that has better tooling
    -- all stored locally
    -- https://github.com/streetsidesoftware/cspell
    null_ls.builtins.diagnostics.cspell.with({
      -- This file is symlinked from my dotfiles repo
      extra_args = { "--config", "~/.cspell.json" }
    }),
    null_ls.builtins.code_actions.cspell.with({
      -- This file is symlinked from my dotfiles repo
      extra_args = { "--config", "~/.cspell.json" }
    })
    -- null_ls.builtins.completion.spell,
  },
  on_attach = on_attach
})

ESLint

The native ESLint LSP is similar to prettierd, in that it has a long-running process from within which to invoke eslint from.
I did this in a separate commit.
You can see that I tried out eslint_d (and I've since removed it from the above code snippets in this post),
but I ran in to an issue where the way eslint_d manages processes caused a lot of zombie processes when I'd eventually exit neovim.
Since node tends to be memory heavy, having so many zombie processes just would not be acceptable.

The thing missing from the ESLint LSP is formatting with the LSP formatting integration.

The main things to have when using ESLint with "--fix on save", are:

local eslint = require('lspconfig').eslint

eslint.setup({
  on_attach = function(client, bufnr)
    vim.api.nvim_create_autocmd("BufWritePre", {
      buffer = bufnr,
      command = "EslintFixAll",
    })
  end,
})

And then I could remove the entries for diagnostics.eslint_d and formatting.eslint_d in my null_ls.setup.

Here is how to set up passwordless authentication with a Yubikey:

sudo apt install libpam-u2f
mkdir ~/.config/Yubico # do not commit this directory to a dotfiles repo or anything like that
pamu2fcfg > ~/.config/Yubico/u2f_keys # once the light blinks on your yubikey, press the button

Lastly, configure the type of auth that the Yubikey will be used for by editing /etc/pam.d/sudo:

  # Set up user limits from /etc/security/limits.conf.
  session    required   pam_limits.so

  session    required   pam_env.so readenv=1 user_readenv=0
  session    required   pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0
+
+ auth sufficient pam_u2f.so

  @include common-auth
  @include common-account
  @include common-session-noninteractive

Docs for the pamu2fcfg util can be found here.

For reference, my versions at the time of writing:

❯ lsb_release -rd
Description:    Ubuntu 22.04.2 LTS
Release:    22.04

❯ uname -r
5.15.0-43-generic

What happens if you don't have your Yubikey nearby?
You'll be asked for your sudo password, as you would have been previously.

What happens if the Yubikey is not plugged in?
You'll be asked for your sudo password, as you would have been previously.
Passwordless auth is only enabled when the Yubikey is plugged in.

If you're using:
ember-auto-import:

// ember-cli-build.js
let app = new EmberApp(defaults, {
  autoImport: {
    webpack: {
      devtool: 'source-map',
    }
  }
  /* ... */
});

embroider:

// ember-cli-build.js
return require('@embroider/compat').compatBuild(app, Webpack, {
  /* ... */
  packagerOptions: {
    webpackConfig: {
      devtool: 'source-map',
      /* ... */
    },
  },
});

A simple component

with the defaults

__webpack_require__.r(__webpack_exports__);
/* harmony export */ __webpack_require__.d(__webpack_exports__, {
/* harmony export */   Header: () => (/* binding */ Header)
/* harmony export */ });
/* harmony import */ var _header_css__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__(/*! ./header.css */ "./components/header.css");
/* harmony import */ var ember_primitives__WEBPACK_IMPORTED_MODULE_6__ = __webpack_require__(/*! ember-primitives */ "../../.pnpm/ember-primitives@0.10.1_@babel+core@7.23.3_@ember+test-helpers@3.2.1_@glimmer+component@1.1.2_2udfmchmj4htznuxtzf4ynvf4y/node_modules/ember-primitives/dist/components/external-link.js");
/* harmony import */ var _icons_fa_external_link__WEBPACK_IMPORTED_MODULE_1__ = __webpack_require__(/*! ./icons/fa/external-link */ "./components/icons/fa/external-link.ts");
/* harmony import */ var _universal_ember_preem__WEBPACK_IMPORTED_MODULE_2__ = __webpack_require__(/*! @universal-ember/preem */ "../../.pnpm/@universal-ember+preem@0.1.7_@babel+core@7.23.3_@ember+test-helpers@3.2.1_@glimmer+component@_orczibosv232nhi52ufgg3bjky/node_modules/@universal-ember/preem/dist/index.js");
/* harmony import */ var _ember_template_factory__WEBPACK_IMPORTED_MODULE_3__ = __webpack_require__(/*! @ember/template-factory */ "../rewritten-packages/ember-source.848c2a54/node_modules/ember-source/@ember/template-factory/index.js");
/* harmony import */ var _ember_component__WEBPACK_IMPORTED_MODULE_4__ = __webpack_require__(/*! @ember/component */ "../rewritten-packages/ember-source.848c2a54/node_modules/ember-source/@ember/component/index.js");
/* harmony import */ var _ember_component_template_only__WEBPACK_IMPORTED_MODULE_5__ = __webpack_require__(/*! @ember/component/template-only */ "../rewritten-packages/ember-source.848c2a54/node_modules/ember-source/@ember/component/template-only.js");







const Header = (0,_ember_component__WEBPACK_IMPORTED_MODULE_4__.setComponentTemplate)((0,_ember_template_factory__WEBPACK_IMPORTED_MODULE_3__.createTemplateFactory)(
/*

  <header>
    <div>
      <ExternalLink class="github" href="https://github.com/NullVoxPopuli/package-majors">
        <img alt="" src="/images/github-logo.png" />
        GitHub
        <Arrow />
      </ExternalLink>
    </div>

    <div>
      <ThemeToggle />
    </div>
  </header>

*/
{
  "id": "YMACeO+O",
  "block": "[[[1,\"\\n  \"],[10,\"header\"],[12],[1,\"\\n    \"],[10,0],[12],[1,\"\\n      \"],[8,[32,0],[[24,0,\"github\"],[24,6,\"https://github.com/NullVoxPopuli/package-majors\"]],null,[[\"default\"],[[[[1,\"\\n        \"],[10,\"img\"],[14,\"alt\",\"\"],[14,\"src\",\"/images/github-logo.png\"],[12],[13],[1,\"\\n        GitHub\\n        \"],[8,[32,1],null,null,null],[1,\"\\n      \"]],[]]]]],[1,\"\\n    \"],[13],[1,\"\\n\\n    \"],[10,0],[12],[1,\"\\n      \"],[8,[32,2],null,null,null],[1,\"\\n    \"],[13],[1,\"\\n  \"],[13],[1,\"\\n\"]],[],false,[]]",
  "moduleName": "/home/nvp/Development/NullVoxPopuli/package-majors/node_modules/.embroider/rewritten-app/components/header.ts",
  "scope": () => [ember_primitives__WEBPACK_IMPORTED_MODULE_6__.ExternalLink, _icons_fa_external_link__WEBPACK_IMPORTED_MODULE_1__.Arrow, _universal_ember_preem__WEBPACK_IMPORTED_MODULE_2__.ThemeToggle],
  "isStrictMode": true
}), (0,_ember_component_template_only__WEBPACK_IMPORTED_MODULE_5__["default"])());

//# sourceURL=webpack://package-majors/./components/header.ts?

with devtool: 'source-map'

import { template } from "@ember/template-compiler";
import './header.css';
import { ThemeToggle } from '@universal-ember/preem';
import { ExternalLink } from 'ember-primitives';
import { Arrow } from './icons/fa/external-link';
export const Header = template(`
  <header>
    <div>
      <ExternalLink class="github" href="https://github.com/NullVoxPopuli/package-majors">
        <img alt="" src="/images/github-logo.png" />
        GitHub
        <Arrow />
      </ExternalLink>
    </div>

    <div>
      <ThemeToggle />
    </div>
  </header>
`, {
    eval () {
        return eval(arguments[0]);
    }
});

Debugging

Using devtool: 'source-map' also enables in-browser breakpoints that more closely match the code in the source. With gjs/gts it's not original source, as browsers don't know what gjs/gts is, but it's "pretty close".

with the defaults

With the default, a bunch of paths end up emitted in the source.

__webpack_require__.r(__webpack_exports__);
/* harmony export */ __webpack_require__.d(__webpack_exports__, {
/* harmony export */   Search: () => (/* binding */ Search)
/* harmony export */ });
/* harmony import */ var _glimmer_component__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__(/*! @glimmer/component */ "../rewritten-packages/@glimmer/component.dac0f4a2/node_modules/@glimmer/component/index.js");
/* harmony import */ var _ember_service__WEBPACK_IMPORTED_MODULE_1__ = __webpack_require__(/*! @ember/service */ "../rewritten-packages/ember-source.848c2a54/node_modules/ember-source/@ember/service/index.js");
/* harmony import */ var ember_primitives__WEBPACK_IMPORTED_MODULE_9__ = __webpack_require__(/*! ember-primitives */ "../../.pnpm/ember-primitives@0.10.1_@babel+core@7.23.3_@ember+test-helpers@3.2.1_@glimmer+component@1.1.2_2udfmchmj4htznuxtzf4ynvf4y/node_modules/ember-primitives/dist/components/form.js");
/* harmony import */ var _ember_helper__WEBPACK_IMPORTED_MODULE_2__ = __webpack_require__(/*! @ember/helper */ "../rewritten-packages/ember-source.848c2a54/node_modules/ember-source/@ember/helper/index.js");
/* harmony import */ var _name_input__WEBPACK_IMPORTED_MODULE_3__ = __webpack_require__(/*! ./name-input */ "./components/name-input.ts");
/* harmony import */ var _show_minors__WEBPACK_IMPORTED_MODULE_4__ = __webpack_require__(/*! ./show-minors */ "./components/show-minors.ts");
/* harmony import */ var _show_old__WEBPACK_IMPORTED_MODULE_5__ = __webpack_require__(/*! ./show-old */ "./components/show-old.ts");
/* harmony import */ var _ember_template_factory__WEBPACK_IMPORTED_MODULE_6__ = __webpack_require__(/*! @ember/template-factory */ "../rewritten-packages/ember-source.848c2a54/node_modules/ember-source/@ember/template-factory/index.js");
/* harmony import */ var _ember_component__WEBPACK_IMPORTED_MODULE_7__ = __webpack_require__(/*! @ember/component */ "../rewritten-packages/ember-source.848c2a54/node_modules/ember-source/@ember/component/index.js");
/* harmony import */ var _home_nvp_Development_NullVoxPopuli_package_majors_node_modules_pnpm_decorator_transforms_1_0_1_babel_core_7_23_3_node_modules_decorator_transforms_dist_runtime_cjs__WEBPACK_IMPORTED_MODULE_8__ = __webpack_require__(/*! ../../.pnpm/decorator-transforms@1.0.1_@babel+core@7.23.3/node_modules/decorator-transforms/dist/runtime.cjs */ "../../.pnpm/decorator-transforms@1.0.1_@babel+core@7.23.3/node_modules/decorator-transforms/dist/runtime.cjs");
/* harmony import */ var _home_nvp_Development_NullVoxPopuli_package_majors_node_modules_pnpm_decorator_transforms_1_0_1_babel_core_7_23_3_node_modules_decorator_transforms_dist_runtime_cjs__WEBPACK_IMPORTED_MODULE_8___default = /*#__PURE__*/__webpack_require__.n(_home_nvp_Development_NullVoxPopuli_package_majors_node_modules_pnpm_decorator_transforms_1_0_1_babel_core_7_23_3_node_modules_decorator_transforms_dist_runtime_cjs__WEBPACK_IMPORTED_MODULE_8__);










/**
 * This is triggered on every value change,
 * which we don't need for this app.
 * The early return makes it a normal submit,
 * so the <Form> abstraction is basically just doing the
 * `FormData` conversion for us.
 */
function handleSubmit(onChange1, data1, eventType1) {
  if (eventType1 !== 'submit') return;
  onChange1(data1);
}
class Search extends _glimmer_component__WEBPACK_IMPORTED_MODULE_0__["default"] {
  static {
    (0,_ember_component__WEBPACK_IMPORTED_MODULE_7__.setComponentTemplate)((0,_ember_template_factory__WEBPACK_IMPORTED_MODULE_6__.createTemplateFactory)(
    /*

        <Form @onChange={{fn handleSubmit this.updateSearch}}>
          <NameInput @value={{this.last.packages}} />

          <ShowMinors checked={{this.last.minors}} />
          <ShowOld checked={{this.last.old}} />
        </Form>

    */
    {
      "id": "q4ddJ3hO",
      "block": "[[[1,\"\\n    \"],[8,[32,0],null,[[\"@onChange\"],[[28,[32,1],[[32,2],[30,0,[\"updateSearch\"]]],null]]],[[\"default\"],[[[[1,\"\\n      \"],[8,[32,3],null,[[\"@value\"],[[30,0,[\"last\",\"packages\"]]]],null],[1,\"\\n\\n      \"],[8,[32,4],[[16,\"checked\",[30,0,[\"last\",\"minors\"]]]],null,null],[1,\"\\n      \"],[8,[32,5],[[16,\"checked\",[30,0,[\"last\",\"old\"]]]],null,null],[1,\"\\n    \"]],[]]]]],[1,\"\\n  \"]],[],false,[]]",
      "moduleName": "/home/nvp/Development/NullVoxPopuli/package-majors/node_modules/.embroider/rewritten-app/components/search.ts",
      "scope": () => [ember_primitives__WEBPACK_IMPORTED_MODULE_9__.Form, _ember_helper__WEBPACK_IMPORTED_MODULE_2__.fn, handleSubmit, _name_input__WEBPACK_IMPORTED_MODULE_3__.NameInput, _show_minors__WEBPACK_IMPORTED_MODULE_4__.ShowMinors, _show_old__WEBPACK_IMPORTED_MODULE_5__.ShowOld],
      "isStrictMode": true
    }), this);
  }
  static {
    (0,_home_nvp_Development_NullVoxPopuli_package_majors_node_modules_pnpm_decorator_transforms_1_0_1_babel_core_7_23_3_node_modules_decorator_transforms_dist_runtime_cjs__WEBPACK_IMPORTED_MODULE_8__.f)(this, "router", [_ember_service__WEBPACK_IMPORTED_MODULE_1__.service]);
  }
  #router = ((0,_home_nvp_Development_NullVoxPopuli_package_majors_node_modules_pnpm_decorator_transforms_1_0_1_babel_core_7_23_3_node_modules_decorator_transforms_dist_runtime_cjs__WEBPACK_IMPORTED_MODULE_8__.i)(this, "router"), void 0);
  get last() {
    let qps1 = this.router.currentRoute?.queryParams;
    let minors1 = qps1?.['minors'];
    let packages1 = qps1?.['packages'];
    let old1 = qps1?.['old'];
    return {
      packages: packages1 ? `${packages1}` : '',
      minors: minors1 ? `${minors1}` : undefined,
      old: old1 ? `${old1}` : undefined
    };
  }
  updateSearch = data1 => {
    let {
      packageName: packages1,
      showMinors: minors1,
      showOld: old1
    } = data1;
    this.router.transitionTo('query', {
      queryParams: {
        packages: packages1,
        minors: minors1,
        old: old1
      }
    });
  };
}

//# sourceURL=webpack://package-majors/./components/search.ts?

with devtool: 'source-map'

All the TypeScript that was authored is very close to original source, with the main differences being minor line breaks and spacing changes.

import { template } from "@ember/template-compiler";
import Component from '@glimmer/component';
import { fn } from '@ember/helper';
import { service } from '@ember/service';
import { Form } from 'ember-primitives';
import { NameInput } from './name-input';
import { ShowMinors } from './show-minors';
import { ShowOld } from './show-old';
import type RouterService from '@ember/routing/router-service';
import type { DownloadsResponse } from 'package-majors/types';
/**
 * This is triggered on every value change,
 * which we don't need for this app.
 * The early return makes it a normal submit,
 * so the <Form> abstraction is basically just doing the
 * `FormData` conversion for us.
 */ function handleSubmit(onChange1: (data: SearchFormData) => void, data1: unknown, eventType1: string) {
    if (eventType1 !== 'submit') return;
    onChange1(data1 as SearchFormData);
}
interface SearchFormData {
    packageName: string;
    showMinors?: 'on';
    showOld?: 'on';
}
export class Search extends Component<{
    Blocks: {
        default: [data: DownloadsResponse];
    };
}> {
    static{
        template(`
    <Form @onChange={{fn handleSubmit this.updateSearch}}>
      <NameInput @value={{this.last.packages}} />

      <ShowMinors checked={{this.last.minors}} />
      <ShowOld checked={{this.last.old}} />
    </Form>
  `, {
            component: this,
            eval () {
                return eval(arguments[0]);
            }
        });
    }
    @service
    router: RouterService;
    get last() {
        let qps1 = this.router.currentRoute?.queryParams;
        let minors1 = qps1?.['minors'];
        let packages1 = qps1?.['packages'];
        let old1 = qps1?.['old'];
        return {
            packages: packages1 ? `${packages1}` : '',
            minors: minors1 ? `${minors1}` : undefined,
            old: old1 ? `${old1}` : undefined
        };
    }
    updateSearch = (data1: SearchFormData)=>{
        let { packageName: packages1, showMinors: minors1, showOld: old1 } = data1;
        this.router.transitionTo('query', {
            queryParams: {
                packages: packages1,
                minors: minors1,
                old: old1
            }
        });
    };
}

Here is the setup,

• the js-framework-benchmark app.

  • this benchmark focuses on testing the rendering of large tables, measuring CPU, Memory, etc while also measuring time to first render as well as time to update across certain common behaviors of these large tables.
    Normally, Large tables aren't something you want in a real app -- almost always you want pagination, and/or virtualized content.
    However, this is a decent stress test for "large amount of data rendered at once".

• two copies of the code with the "row" content extracted to its own component.

  • the template-only version of the component looks like this

     const Row =
       <template>
         <tr class={{if @isSelected 'danger'}}>
           <td class='col-md-1'>{{@item.id}}</td>
           <td class='col-md-4'><a {{on 'click' @select}}>{{@item.label}}</a></td>
           <td class='col-md-1'><a {{on 'click' @remove}}><span
                 class='glyphicon glyphicon-remove'
                 aria-hidden='true'
               ></span></a></td>
           <td class='col-md-6'></td>
         </tr>
       </template>;

  • the class-version of the component looks like this:

     class Row extends Component {
       <template>
         <tr class={{if @isSelected 'danger'}}>
           <td class='col-md-1'>{{@item.id}}</td>
           <td class='col-md-4'><a {{on 'click' @select}}>{{@item.label}}</a></td>
           <td class='col-md-1'><a {{on 'click' @remove}}><span
                 class='glyphicon glyphicon-remove'
                 aria-hidden='true'
               ></span></a></td>
           <td class='col-md-6'></td>
         </tr>
       </template>
     }

The delta between the two components is this:

-  const Row =
+  class Row extends Component {
    <template>
      <tr class={{if @isSelected 'danger'}}>
        <td class='col-md-1'>{{@item.id}}</td>
        <td class='col-md-4'><a {{on 'click' @select}}>{{@item.label}}</a></td>
        <td class='col-md-1'><a {{on 'click' @remove}}><span
              class='glyphicon glyphicon-remove'
              aria-hidden='true'
            ></span></a></td>
        <td class='col-md-6'></td>
      </tr>
-    </template>;
+    </template>
+  }

Why?

When using TypeScript a question came up about the ergonomics of typing either of these components.

Here is what typing the template-only component looks like:

import { TOC } from '@ember/component/template-only';

interface Signature {
  Args: {
    item: { id: string; label: string };
    select: () => void;
    remove: () => void;
  }
}

const Row: TOC<Signature> = <template> ... </template>;

And here is what typing the class component looks like

interface Signature {
  Args: {
    item: { id: string; label: string };
    select: () => void;
    remove: () => void;
  }
}

// The Component was already imported from `@glimmer/component`
class Row extends Component<Signature> { ... };

This post isn't about the ergonomics of each of these, or which I prefer, but this is why I wanted to get actual hard data about the claims we've been hearing for years about template-only vs class-based.

But! having to make make a const for the default-export case, is extra work, as you must make a const. However, in a fully gjs/gts-using app, there does not need to be any default exports at as, as there would be no loose mode (classic, hbs files).
Using gjs / gts in routes, your regular component files with one export could look like:

// app/components/my-component.gts
export const MyComponent: TOC<Signature> = <template>...</template>;

and then imported:

import Route from 'ember-route-template';
import { MyComponent } from 'my-app/components/my-component';

export default Route(
  <template>
      <MyComponent>
          {{outlet}}
      </MyComponent>
  </template>
);

But anyway, getting back to answering the question I've yet to mention,

if someone prefers empty class components (which are linted against) for usage in TypeScript, is there anything they're missing out on by not using template-only components?

The tl;dr: is yes. But actual results will vary based on your actual app and use cases.

template-only components are 7-26% faster

(for this particular benchmark and depending on which thing you're measuring).

As always, please test in your own apps.
Tracerbench is a statistically sound tool that uses the built in performance.mark() apis.

This does not mean that this is always going to be the case. There has been increased activity in work happening in the VM to speed things up. For example, one such option that is being investigated is avoiding destruction callbacks on class components if the class didn't implement a destruction method (as well as removing the parent node before runnig destruction on child nodes (this would improve rendering brand new content or navigating to a new page)). Also at the time of writing, there already exists a good number of perf-related PRs, if anyone is interested: on the glimmer-vm repo

For the js-framework-benchmark, here are the actual results.

And the table of the results here:

My system at the time of running the benchmark(s):

❯ google-chrome --version
Google Chrome 120.0.6099.109 

❯ uname -srp
Linux 6.2.0-39-generic x86_64


❯ lsb_release -csd
Ubuntu 23.04
lunar

info from screenfetch:

CPU: AMD Ryzen 9 7900X 12-Core @ 24x 4.7GHz
GPU: NVIDIA GeForce RTX 4080
RAM: <in use> / 63438MiB

Quick Links:

• JSBin to play around. 🥳
• The Proposal
• The Polyfill
• Library using the polyfill
• Interactive Tutorial

tl;dr:

• Signals enables many ecosystems to start interoping together, even if they are completely isolated today.

What you can do?

• Get involved, try out the polyfill, try to integrate it in to you framework (in abranch) ✨

Signals have been proposed to TC39 to be built in to JavaScript as a language native feature.

But what does this actually mean for you and your daily work?

1. Who is this for?
2. Why am I talking about this?
3. What even are Signals?
4. Why should I care?
5. What are the requirements?
6. Seems like there are missing features 🤔
7. How this affects you
   1. library authoring
   2. framework maintenance
   3. application dev
8. How you can get involved

Who is this for?

There are generally three types of roles a person can play when it comes to programming -- and these may seem obvious, but it's important that we be on the same page, because it's easy (especially for me!) to forget which audience we're talking about in which situations -- feel free to skip to the next section:

Framework authors

These are the people who will jump through any hoop in the name of ergonomics, performance, compatibility, you name it. These people work directly on projects like Angular, Ember, Preact, Solid, Svelte, Vue, and many more.

Library authors

These are people who may want their library to be usable in multiple / all frameworks that are supporting Signals -- traditionally in order to have broad reach across every framework, libraries would need to either have no reactivity, or private reactivity -- which isn't integrated into the host application, and in either case, if these libraries render anything, the host framework must be hands off, as the library "takes over" the dom element that it is given and multiple renderers cannot control the same subtree of the DOM -- this is common in Charting libraries, or older jQuery based libraries. Some libraries could provide an abstraction over reactivity and then adapters for each reactivity system -- Vue, Svelte, Angular, etc.

Application developers

These people could use the TC39 Signals directly, but more likely that their framework or ecosystem used for their application will provide wrapper utilities that align with the framework/ecosystem's existing nomenclature and mental models. For example, Svelte has runes, and Vue has ref, and Ember has tracked -- all of these can wrap the TC39 Signals, and in a minor, non-breaking, version upgrade of your framework's core library, could suddenly have support for Signals and the broader reactive ecosystem -- and you wouldn't even know without reading the changelog! 🎉

Why am I talking about this?

I, @NullVoxPopuli, am very excited about Reactivity[^my-writing].

There has been a problem in JavaScript since the dawn of time (1995): as ecosystems develop (and specifically what I am presently concerned about: web apps (which, kind of, moves our dawn of time to the mid 2000s)), they cannot share code between each other. React can't share code with Vue, nor can Svelte share code with Vue, or Ember, Angular, Solid, etc.

Billions of lines of code have been duplicated across these ecosystems solely[^solely-duplication] because the reactive systems are separate.

There are 3 major categories for which I can place my excitements:

1. Interoperability, solving the above-described problem
2. Technically, the way the reactive algorithm works (even as the TC39 proposal changes over time) is super exciting, and something I've been using myself for years in Ember.
3. Adoption - Non-breaking, non-major change^[editions] to introduce Signal compatibility to a framework.

It's intended for framework and library authors to swap out their internals with the proposal's primitives (shedding tons of kb, and beginning the Epic Quest of aligning on all the similarities between our frameworks - eliminating (probably) Petabytes of network transfer of (basically) duplicate code each year).

What even are Signals?

Signals are a means to enable efficient computation of state for a particular viewer. The viewer in many cases is the DOM, but could extend to any observable[^observable] boundary, a WebSocket, Database Connection, etc.

The exact way in which this works isn't important right now (and also the exact details will probably change over time as the proposal is still in Stage 1) -- perhaps a topic for another time!

Some helpful terminology and definitions that various folks use

As people talk about Signals, auto-tracking, Runes, or other forms of reactivity, it may be heplful to have everything defined / so we can all be on the same page / reduce any potential ambiguity or uncertainty. Not all of these will be used here, in this post, but… more for your (and my own) information[^terms].

To continue the quantum physics analogy:

A signal graph is in a superposition of states, but you can't tell because the second you try to observe them the wave collapses

but you can create double slit experiments.

wycats.

Why should I care?

From gbj in the Discord

the proposal is designed to be the greatest common factor of the existing mainstream framework signal approaches, not the least common denominator

It’s “how much could we share?” not “how little can we get away with?”

Imagine, a reactive library could be built in a such a way, using native Signals, that it works across UI Frameworks: Vue, Svete, Ember, (etc), Node CLI applications, databases, websocket implementations, etc. This proposal has the opportunity to dramatically reduce the amount of duplicate code we have between our different JavaScript ecosystems.

Some libraries that I think could greatly benefit from a shared signal implementation (provided target frameworks also natively integrate with native signals):

• TanStack family of projects.
• Charting libraries, such as D3.js.
• Any project using web components.

I don't have data, as this would be very hard to measure, but I like guessing, so I'm guessing: if we had standard / platform / native signals 6 years ago, we could have saved at least a trillion dollars in duplicate library development consts, research and development, etc. Now, none of this proposal would be possible without those 6+ years of research, exploration, collaboration, and trying to out-do one another 😉.

One thing that will be interesting longer term is how web components could maybe one day be ergonomic to author without the use of a wrapper library (Lit, for example (which helps fix some of web components' ergonomics issues)).

There are two places to watch for developments there:

• HTML Template Instantiation
• DOM Parts

What are the requirements?

• Autotracking - the main feature of the Signals proposal that makes it more than just values and functions.
• Memory allocations should be kept to a minimum.
• Signal.State should be extensible with fewer object allocations so that frameworks can add their own functionality on top.
• multiple types of effects and batching should be implementable by framework authors.
• Writes are synchronous, and immediately take effect. At no point in the reactive graph would reading a descendent, deriving from some ancestor, be out of sync.

What are the considerations?

This is just a snippet of a much bigger list of goals, considerations, and desires for the Signals proposal:

• The proposal is minimal, and intended to be added on to later -- Changes to a language take a lot of time, so like a pull request, the smaller it is, the higher the chance it will progress towards being accepted.
• Computation must be glitch-free, so no unnecessary calculations are ever performed.
• JS Frameworks have their own scheduling, and the native signals implementation should enable that. There is likely no way to write a "scheduler" that efficiently integrates with a framework's own dynamic tree better than the framework native scheduling.
• Enable composition of different codebases which use Signals -- aka / cross-framework library sharing.

There are many more of these, and if you want to learn more about this, check out the Design goals for Signals.

Seems like there are missing features 🤔

The proposal, at the time of writing, is still in Stage 1, so just about everything is subject to change and nothing is set in stone.

If you want to help out with the proposal, please open an issue or PR for collaboration 🎉

How this affects you

library authoring

Here is a demo of Signals in React and Svelte by Jack Herrington -- showing that we can make cross-framework libraries.

• reactive code using what's in the proposal
• no need for abstractions
• must subscribe to "derived" purism (no effects).

In universal code, we can't use effects, because an effect usually has framework-specific semantics that don't make sense in other frameworks -- for example, if you use React's effect, the whole library may as well be react-specific.
As a library author, you could circumvent this restriction by requiring your users to call a destructor at time that makes sense for your library, which calls the Watcher's unwatch method.

• you can use impure computeds, like the asyncFunction implementation does (mentioned above).

example usage:

import { Signal } from 'signal-polyfill';
import { signalFunction } from 'signal-utils/async-function';

const url = new Signal.State('...');
const signalResponse = signalFunction(async () => {
  const response = await fetch(url.get()); // entangles with `url`
  // after an away, you've detatched from the signal-auto-tracking
  return response.json(); 
});

// output: true
// after the async function completes
// output: false
<template>
  <output>{{signalResponse.isLoading}}</output>
</template>

Aonther util that enables more powerful fetch / AbortController management, is the Relay. (See Signal Relays by @pzuraq).

export const fetchJson = (url) => {
  return new Signal.Relay(
    { isLoading: false, value: undefined },
    (set, get) => {
      let controller;

      const loadData = async () => {
        controller?.abort();

        set({ ...get(), isLoading: true });

        controller = new AbortController();
        const response = await fetch(url.get(), { signal: controller.signal });
        const value = await response.json();

        set({ ...get(), value, isLoading: false });
      }

      loadData();

      return {
        update: () => loadData(),
        destroy:() => controller?.abort(),
      }
    }
  );
}

The Relay pattern provides a way to have more control over the behavior of things-with-lifetime, such as a fetch request. Definitely checkout pzuraq's blog post for more details.

For now, there is an exploratory signal-utils library with a bunch of reactive utilities and data structures -- pull requests are very encouraged here!! It'd be equally awesome to see other experiments people come up in their own libraries! (Noting that we don't want to accidentally make a new framework, but moreso want to test out the capabilities of the polyfill / current design of the proposal and validate ergonomics / problems / etc).

framework maintenance

The dream is that once frameworks integrate with native signals, whole ecosystems begin to start being able to share resources with one another.

Especially as it is still the early days, the most useful thing now with respect to the proposal is to try out the polyfill in your framework, replacing your own reactive primitives with those from the polyfill and open issues such as:

• Batch unsubscribe issue
• calling watch on computed signal can prevent getting correct latest value
• False positive in cycle detection
• and more!! folks are already doing a great job testing things out!

Here is an example of @lifeart's spike to add the signal polyfill to their renderer[^glimmer-next]: glimmer-next#114, and in doing so, a problem was found where unwatch performance worsened by ~ 3000% (oops).

Effects and fine-grained rendering can be implemented via a watched Computed like here in glimmer-next -- this whole PR is probably a good reference for the amount of work involved in swapping the core reactive primitives.

Higher level abstractions should also be possible, and some of these are explored in signal-utils. For example, in ecosystems that encourage classes, they may implement a decorator which allows "just regular property access" to continue working:

import { signal } from 'signal-utils';

class State {
    @signal accessor #value = 3;

    get doubled() {
        return this.#value * 2;
    }

    increment = () => this.#value++;
}

let state = new State();


// output: 6
// button clicked
// output: 8
<template>
  <output>{{state.doubled}}</output>
  <button onclick={{state.increment}}>+</button>
</template>

Another example, for reference, could be the reaction() utility from MobX.

application dev

For now there isn't much to do directly with the proposal, but you can work with your framework ecosystems to see how you can help test things out and provide feedback!
This isn't to say that you wouldn't be able to use native Signals in your application once everything ships, and is integrated, etc, -- on the contrary! -- but moreso that you'll likely want to stick with your framework's specific nomenclature, utilities, etc.

How you can get involved

On this call for participation on the proposal github, you'll find links to

• The Signals Discord Server
• Asking for help, and ways you can help

In summary, many / most contributions are welcome:

• fixing typos in the README
• adding tests
• playing with the polyfill (finding bugs, fixing them, etc)
• Document use cases for or against certain reactive programming patterns (and if the current design supports those use cases)
• Add to the interactive tutorial here
  • viewable here

and more! (see the linked issue)

You can also try out signals for yourself here at this JSBin.

There is a lot to do!, but we'll get there! Between finding alignment with the broadest group possible, time to implement and adopt, and then adding additional proposals that build on top of the Signals proposal, this is my favorite meme:

(from Dune: Part 2)

References

…and additional reading:

• The TC39 Process
• @pzuraq's How Autotracking Works
• @RyanCarniato's Derivation in Reactivity
• @eisenbergeffect's A TC39 Proposal for Signals
• Mat Hostetter's Reactivity Overview
• lord's GitHub Comment
• From @steve8708 :

In my experience, the more you use them, esp as your app scales, the more their DX shines

Signals are not just about perf
/1
from X/Twitter

• From @thdxr, an AMA on X/Twitter

^[observable]: this definition of observable is simply "noticeable" / "to be noticed" and in no way is intended to correlate to the the programming concept by the same name. Observables as a pattern (rx.js) invert the reactive graph from Signals, and have proven to be less efficient. They are a useful tool!, just not for everything (Angular has been moving to Signals from rx.js, for example).

[^my-writing]: But I haven't been the best at communicating -- written, spoken, or otherwise -- about my excitement for reactivity -- a lot of concepts are quite abstract, and a hard to find the right balance of distilling a problem to something digestible verses finding something complex enough where people don't immediately fall in to "but this other way is much easier, or could be done like 'this'".

[^solely-duplication]: maybe not solely, exactly. I'm sure there is a good amount of "I could do better" and "There are bugs, how hard could it be[^how-hard-could-it-be] to do myself"?

[^how-hard-could-it-be]: Anyone else have this genetic trait where they generously undeestimate effort of a task? (not just in programming) .

^[editions]: See also: Editions, an extension to SemVer.

^[terms]: This table alone, with examples in the wild could / should probably be its own post -- it's a lot of information.

[^glimmer-next]: this is an alternate DOM renderer for Ember focused on performance, and trying to incrementally gain as much compatibility as possible where it makes sense. I've opened an issue on Ember for a Swappable Renderer to help explore what this could be capable of, what compatibility is missing, etc -- it's still early, and the ideas still need to be proved out in big projects.

[^starbeam-note]: Starbeam is not 1.0 yet, and does not presently have a production ready release, so folks should hold off on trying it out. The docs even mismatch a little at this point, so learning it would be a smidge confusing without diving in to the code as the source-of-truth for learning.

@trusktr asks:

What’s the equivalent of Solid.js createEffect() (or React useEffect(), Meteor Tracker.autorun(), MobX autorun(), Vue watchEffect(), Svelte $effect(), Angular effect()) in Ember.js?

This is certainly shocking to folks new to ember, but ember deliberately doesn't have an any effect by default.

Now, as a framework author, the concept does sort of exist (at a high level) -- but I'll circle back around to this in a smidge.

In your Solid demo, if you want to log function calls, you'd do:

const a = () => 1;
const b = () => 2;
const c = () => 3;

<template>
  {{log (a) (b) (c)}}
</template>

Some notes on function invocation syntax, if needed

• Glimmer Tutorial: Transforming Data
• https://cheatsheet.glimmer.nullvoxpopuli.com/docs/templates#template__notation

We use templates as the sole entrypoint to reactivity, whereas solid's reactivity is more general purpose. With templates, and being DOM focused (for now), we can ask ourselves:

"If the user can't see the data rendered, does the data need to exist?"

Now, you're demo (with logging) is definitely effect-y. And if you had no other way (like the situation was somehow impossible to model in a derived data way), you can do this:

function myLog() {
  console.log(a(), b(), c());
}

<template>
  {{ (myLog) }}
</template>

This would auto-track, so as the consumed tracked data accessed from each of a, b, and c changed, myLog would get to re-run.
However, this has a caveat: data may not be set within myLog, else an infinite render loop would occur.

This is covered here

• Glimmer Tutorial: synchronizing state (to the console in this case)

There is a way around the above caveat, not being able to set during render, by making myLog invoke an async-IIFE, and waiting a tiny bit (i.e.: setting slightly after render):

// now we're passing in the args directly so that they
// are tracked (all args are auto-tracked in all
// function / helper / component / modifier execution
// coming from the template)
function myLog(...args) {
  async function run() {
    await 0;
    // causes a change in a's data
    // and because we awaited, we don't infinite loop 
    setA(); 
    // prints a pre-setA, because a was passed in
    console.log(...args);
  }
 // return nothing, render nothing 
 // (we have no result to show the user)
}

<template>
  {{myLog (a) (b) (c)}}
</template>

This is nuanced, and is why I made this tiny abstraction a whole thing over here https://reactive.nullvoxpopuli.com/functions/sync.sync.html
it's 95% documentation, 5% code 😅

So coming back to:

"We deliberately don't have effects"

Because of a couple current facts about our ecosystem:

• we want derived data to be preferred, because it is the most efficient way to have your render state settle
• calling a function from a template can only happen after the template is rendered, so doing so causes a second render (I believe this is true in React as well)
• there is a need to synchronize external state, and that has been part of the exploration of Resources, and Sync
  • Starbeam Docs on Sync
  • Starbeam Docs on Resources
  • Current ember implementation does not have sync capabilities: ember-resources (due to limitations of the private APIs implementing reactivity (ember-resources is public-API only))
  • Tutorial Chapters on Resources
• we think that effects are overused and a huge footgun (for app devs), so by documenting a story more around synchronizing external state, we can continue to guide devs in to a pit of success.

Note: Starbeam is where we're extracting our reactivity primitives, and are planning to swap to Starbeam entirely at some point once we work out some composition ergonomics for serial Resources (the coloring problem).

Hope this helps!
If anything is unclear or if you have more questions, let me know!

Ember has historically allowed access to everything in a global scope, like web-components. This proved confusing for developers, and Ember has moved to a more explicit, import-what-you-need approach, called "template-tag" -- more information on that here, in the official guides.

A common thing I hear from folks is that they don't know where to import a component/modifier/helper from a particular addon, or maybe assume that because something isn't documented, they can't import the component/modifier/helper.

Good news:
if it works in loose mode (the globals way), the import is public API.

Here is how you find them:

1. open node_modules/${libraryName}

   • if it doesn't exist, install libraryName / add to your package.json

2. open the package.json of libraryName

   • does it have exports?

     • This could look like this for types-providing projects:

       "exports": {
         ".": {
           "types": "./declarations/index.d.ts",
           "default": "./dist/index.js"
         },
         "./*": {
           "types": "./declarations/*.d.ts",
           "default": "./dist/*.js"
         },
         "./addon-main.js": "./addon-main.cjs"
       },

     • or it could look like this for non-types-providing projects

       "exports": {
         ".": "./dist/index.js",
         "./*": "./dist/*.js",
         "./addon-main.js": "./addon-main.cjs"
       },

     Exports say if you import x from library-name/${sub path specifier}, the exports map will match to a file on disk. So you can look through the dist directory if ./* is specified and see what all you can import. See the docs for details.
     For example, if you see a file in dist/components/foo.js (and given the above exports), you can import it at library-name/components/foo.

     ---

     There is an intermediary step which may or may not ever be relevant, due to how strongly folks follow conventions in with the library blueprints, but if there is an ember-addon.app-js key in the package.json -- this is the mapping of what is dumped in to the globals resolver, and is what is exposed to you pre-gjs/gts/template-tag. This config will looks something like this:

     "ember-addon": {
       "version": 2,
       "type": "addon",
       "main": "addon-main.cjs",
       "app-js": {
         "./components/foo.js": "./dist/some-other-folder/foo.js"
       }
     },

     In this scenario, instead of importing from libraryName/components/foo, you'd import from libraryName/some-other-folder/foo.

     Once you find the file in dist, you're done.

   1. If the package.json you're looking at does not have an exports config, and the library is an ember-addon (has ember-addon listed in keywords), this likely the older "v1 addon" format, which was convention-based, and didn't follow broader standards (as they didn't exist yet). By convention, you'll need to check the app folder for your components/modifiers/helpers, and see what those files define or re-export. You can then import what those files use.

   For example, if you find app/components/foo.js contains

   export { default } from 'libraryName/some-other-folder/foo'

   you can import from that same location. e.g.:

   import theDefaultExport from 'libraryName/some-other-folder/foo';

This information is also available on the ember-template-imports README.

Don't know which library to start with?

you can find anything by searching in node_modules.

I like using the_silver_searcher, but any search tool will work.

❯ ag --unrestricted "<ResponsiveImage" --file-search-regex '.js$'

I use --unrestricted to search ignored files (node_modules), and --file-search-regex with .js$, because I want to exclude source-map files, .js.map$ (I haven't learned how to read those).

So if I want to search for "ResponsiveImage" (a component that's used on this site), I don't get results in node_modules, but in my dist folder (my app's output) -- this means I need to try one of the other forms of which components can be referenced.

These are the possibilities for the direct name reference:

• <PascalCase, hoping that the component's JSDoc exists

  ❯ ag --unrestricted "<ResponsiveImage" --file-search-regex '.js$'

• class PascalCase to find the file in JS

  ❯ ag --unrestricted "class ResponsiveImage" --file-search-regex '.js$'

But we can also search via file path:

• kebab-case

  ❯ ag --unrestricted --filename-pattern 'responsive-image'

  using --filename-pattern allows us to search for file paths, and not the contents of the file. We might not know what is in a particular file.

  • or, if too many results, you can search with the extensions:
  • kebab-case.js
  • kebab-case.ts
  • kebab-case.gjs
  • kebab-case.gts
  • kebab-case.hbs
  • kebab-case/index.js
  • kebab-case/index.ts
  • kebab-case/index.gjs
  • kebab-case/index.gts
  • kebab-case/index.hbs

  All can be searched for all at once with this (which can still be far fewer results than with no extension):

  ❯ ag --unrestricted --filename-pattern 'responsive-image(\/index)?\.(js|ts|hbs|gjs|gts)'

Feel like a lot of work to find which library something comes from? I think so, too.

This is why gjs/gts/template-tag is so nice, because you just know exactly where something is coming from.

To try out gjs / <template> in your browser, check out this interactive tutorial.

In any case, while this is useful, I have manually set up some DNS entries on my pi.hole (which I use for network-wide ad-blocking for all devices (phones!)).

The pi.hole has a default DNS request rate limit of 1000 requests in 60 seconds. And Ubuntu was regularly surpassing this by doing "Reverse DNS" PTR requests to in-addr.arpa. Now, every time I looked at the pi.hole logs, these were cache-hits, but the fact of exceeding 1000 requests in 60 seconds remained. When this limit is exceeded, I was no longer able to operate my computer where DNS requests were required (such as during git push).

Through some light investigation, I found that this built-in behavior bundled with the default Ubuntu install is caused by a program called avahi-daemon.

So, to fix my issue, I just uninstalled avahi-daemon

sudo apt remove avahi-daemon

And my problems were solved!

This StackOverflow/SuperUser post is a good resource for details

CSS frameworks a great way to start a project, but long-lived projects need interactivity to truly feel like an application.

This post is a curation of libraries to help you get started with bootstrapping your app, or creating your own design system, so you don't need to go looking for things!
(and I'll try to keep it up to date as new libraries are published).

NOTE: Some of what is in here is my opinion, and not necessarily representative of the opinions of others / groups I'm a member of.

As of 2025, these are a good few maintained design systems, and here I've broken them up into some categories:
The "Polaris" category can be used as a learning tool to see how folks should be writing ember today.
There is "Pre-Polaris", which means that the design system is nearly Polaris, but missing one or two modern patterns to be considered Polaris.
Lastly, there is the "Needs Work" category, which is to concisely say that the design systems has a number of migrations to do before I would recommend someone look at the code for learning how to write modern Ember.

Polaris

• Elastic EUI » Docs | npm

  

  npm add @ember-eui/core 

  This design system from Prysmex is a fully modern, thorough, up to date design system.
  There are enough components to build whole products without creating any additional components.

• Hokulea » Docs | npm

  

  npm add @hokulea/ember

  Hokulea is a fully modern whimsical design system from gossi that demonstrates Storybook integration and workflows for documenting each component. This design system supports themeing, is research driven, and has enough components to build a real product without needing to write more components!

• Frontile » Docs | npm

  

  npm add @frontile/buttons @frontile/overlays # ... 

  This design system from josemarluedke is a fully modern, thorough, up to date design system.
  There are enough components to build whole products without creating any additional components.

• Carbon » Docs | npm

  

  npm add carbon-components-ember

  This design system from IBM is one of the more modern codebases, though, in poking around their documentation, I found a few CSS bugs.
  They use TypeScript, gjs/gts, and the V2 Addon (native library) format.

• shadcn-ember » Docs | npm

  

  npx shadcn-ember@latest init

  This design system from Ignace Maes is an Ember port of shadcn/ui. It uses a CLI to copy beautifully designed, accessible components directly into your project for full customization. Built with TypeScript, gts, and Tailwind CSS v4.

• Helios » Docs | npm

  

  npm add @hashicorp/design-system-components

  Helios is a design system by Hashicorp, so it is well funded and maintained, as well as made with influence from accessibility experts.

Needs Work

These are also "V1 Addons" -- which are node programs that your app runs during your app's build, and the node programs happen to emit browser JavaScript.
This is different from normal browser libraries (sometimes call "V2 Addons"), which are compiled when the library is published.

• UI Kit » Docs | npm

  

  npm add ember-uikit

  This design system looks polished, but it provides no Types, is not a V2 Addon, and doesn't use any gjs or gts components -- however, this does not mean it's not a solid choice for bootstrapping a new project! If you're writing javascript, and don't want to read this design-system's code, this is a fine option.

• Bootstrap » Docs | npm

  

  npm add ember-bootstrap

  This library provides a good few interactive components where the Bootstrap CSS Framework would not be sufficient for building applications.
  This library is not a V2 Addon, does not use Types, and doesn't use any gjs or gts components.

• Material Design » Docs | npm

  

  npm add ember-paper

  Material design is starting to look a little dated these days, but maintenance of this design system is still on-going. It provides no types, is not a V2 Addon, and doesn't use any gjs or gts components.

Want to build your own?

Ember authors great ergonomics for creating design systems!

And to help build design systems even faster, there a number of libraries that abstract away a lot of the menial things that you'd have to implement anyway on top of the platform (while deferring to the platform as often as possible ( as we all know: the best code is the code that isn't needed in the first place ))

UI Primitives:

• ember-sortable - primitives for sorting, drag & drop
• ember-primitives - Styleless, Accessibility-focused primitives that help you build faster UIs. Not just components, but light/dark mode management, popover management, etc.
• @universal-ember/table - a plugin-based styleless way of building complex table UIs with sorting, column-reordering, etc
• ember-headless-form - an Accessibility-focused way of taking the boilerplate out of highly-managed form experiences, including local errors, server errors, etc -- giving you the primitives, to expose powerful design-system forms with a great pit of success .
• ember-focus-trap - element modifier for trapping focus within the element.

Utility Primitives:

• reactiveweb - low-level reactive utilities and reactive wrappers of common web APIs.
• ember-keyboard - easy key-combos.
• ember-concurrency - easy concurrent behaviors, prevent users from submitting forms multiple times.
• ember-statechart-component - Use XState statecharts as components, allowing easy drop-in diagram-based logic implementation.

Testing and Documentation:

• @ember/test-waiters - tie async-behaviors to the settled state system, so users have an easy time with tests (no wait-for, etc).
• ember-a11y-testing - Add AXE accessibility testing to your automated tests.
• @universal-ember/test-support - Additional common test utilities to use on top of those provided from @ember/test-helpers or testing-library
• Kolay - a runtime-rendered documentation framework allowing easy documentation of design systems, component libraries, all in a familiar markdown format.
  • This is pre-alpha right now, so unless you want to help fix bugs, you may be more interested in:
    • Docfy
    • field-guide

Build Tools:

• @responsive-image/ember automatically create responsive optimized images and fast page loads -- part of responsive-image
• svg-jar automatically <use> SVGs in rollup and vite

Other:

• Shepherd - guided walkthroughts for introducing users to things

tl;dr: install the pre-release version of the Glint extension and enable @builtin typescript.

We're using the pre-release version of Glint here because it provides a far superior editing than the currently released stable version of Glint. Glint V2 is powered by Volar and lines up nicely with the Polaris efforts to align with broader ecosystem tooling in a way that unblocks all experimentation while also still supporting older code so that large codebase have a path to the modern tooling and DX.

For neovim, I need to PR to the built in configs to make switching to the glint ts-plugin automatic, but here is what it looks like!

For questions / concerns / updates, feel free to ask in:

• The Official Ember Discord
• My Personal Discord

While you may use ember for your frontend application, most of the code you will encounter is non-ember aka “just javascript”. Learning ember will allow you to quickly get to shipping or debugging features for non-company-specific problems.

The goal is for the framework to stay out of your way. If you feel any resistance to doing your work, regardless of the cause, please let me know.

Where to get started

• Already know another framework?
  • Compare component-patterns between Ember Polaris and other frameworks
    • React, Solid,
    • Vue 3, Vue 2
    • Svelte 5, Svelte 4
    • Lit
    • Angular Renaissance, Angular
    • Ember Octane
• Tutorials
  • how-to and interactive guide
  • full and official tutorial and walkthrough, which guides you through building a real application
• AI Chat
  • There is a custom GPT in the ChatGPT marketplace trained on ember knowledge - it’s able to convert between frameworks, so if you don’t like tutorials or prefer to learn by trial and error, you may want to start here.
    (It’s important to use this over general trained AI, this custom GPT has been told to favor newer patterns instead of older patterns)
• Guided documentation:
  • Guides on many topics for developing apps on the official website

If you want to take a step back and learn things how the framework has organized, you may want to start on this page: The official Learn Ember page.

Once you have some familiarity

• Reference documentation

  • Runtime Framework APIs
  • Data / warp-drive APIs
    • Newer concepts

• Messin’ around

  • Online REPL - fast way to “just try stuff”
  • Stackblitz - a little slower due to running a whole dev environment in your browser, but most like the local dev experience for default ember apps.
    • Ember (JavaScript)
    • Ember (TypeScript)

Vocab

• vite - the build tool we use — which has many contributors and is leading the JavaScript ecosystem in local build performance
• embroider - the set of tools we use for adapting pre-spec JS to spec-compliant JavaScript
  This is what enables our > 10 year old, multi-million line project to run in vite without a major migration / rewrite, enabling parallel shipping and maintenance.
• tracked properties - what ember calls its wrapper around Signals.
• addon - alias for “library”
• webpack - older and slower build tool that we’re migrating away from (or will already have migrated away from by the time you read this)
• broccoli - older and slower build tool that we’re migrating away from (or will already have migrated away from by the time you read this)

If we don't have exact Indicators of Compromise, what do we need to check for?

Initially, when I found out about CVE-2025-54313 / GHSA-f29h-pxvx-f335, or any vulnerability, I have to decide if there is, beyond a shadow of a doubt, sufficient evidence to do nothing, else, I have to do a bunch of key-rolling -- which takes about 15 minutes on my personal hardware, and an hour and a half on work hardware (due to MacOS being way slower than linux).

In this case, the day prior, I was doing a lot of open source development for a library that my employer makes heavy use of, and noticed that my pull request was conflicting with main frequently due to renovate running very eagerly on dependency updates. I needed the repo's CI to run all the scenarios for me, because enumerating all the tested / supported scenarios without knowing where errors exist is time consuming and cumbersome -- and GitHub does not run CI for pull request if there is a conflict. So I was regularly rebasing.

Normally this isn't a big deal, but I just didn't know -- which is not an acceptable state to be in to "decide to do nothing".

At the time I decided I had to deal with the possibility of my two computers being infected with the malware, I didn't have sufficient knowledge for a targeted sweep / clean of my systems. All I knew was that the malware would steal credentials and upload them somewhere.

So I had to do the heavy-handed investigative process:

• Disable WiFi / all internet connections on both devices

• On my phone, review audit logs from GitHub.

  • Discover than NPM does not have an audit log.
  • Discover that GitHub doesn't have an auditlog of your SSH (git cli) activity…
  • Delete SSH Keys on GitHub

• Write a script now located here to help scan for suspicious copies of the libraries reported in the above-linked reports.

  • Through this process I realized that if I were trying to defend against myself, I would not win. Not knowing enough about the attack, I had to assume the worst:
    • I can't sufficiently trust:
      • checking for libraries installed on my desk under the name of the published package -- if I were trying to do an attack, I would have the code copy itself elsewhere
      • checking the library's version -- I would try to publish a malicious package with the version of a trusted copy of the package
      • checking for a package.json with the name of the affected packages -- I would change the name if I were trying to evade detection
    • So my script scans all directories node has access to -- which for all intents and purposes include every folder that doesn't require sudo to access (as I never install dev tools with sudo)

• The script didn't tell me I was compromised, but given that I kept thinking of ways to circumvent myself, I had to go further. I couldn't trust automated detection of an attack I didn't know the details of.

• I decided to delete all node_modules on my machines

  find . -name 'node_modules' -type d -prune -exec rm -rf '{}' +

  This took about 7 minutes for my hundreds of GB of JS projects an their dependencies.
  On the work MacOS it took about 45 minutes.

• I also deleted things that I knew could have node_modules, but potentially not have them kept in a node_modules directory

  • Uninstall and Delete caches of: Discord, Slack, Cursor, Windsurf, etc (All Electron-based applications)
  • Delete global cache directories: rm -rf ~/.pnpm-store, or pnpm store prune, for example.

• I suspected that if me as an attacker in the try-hardest mode I could think of potentially wouldn't even use node

• Rebooting the computer would ensure that anything that began running would be stopped (be that a node process or otherwise)

• However, if there is malicious code disguising itself, it's potentially possible it started up again at login

  • This is where code-signing comes in to play -- applications that are not signed by a central authority do not have permission to install themselves and start up.
    (But short of having a machine with signing, you'd then need to inspect your network activity… which is involved)

When I started the computers back up again, I was ready to investigate the signatures of all the running binaries -- but then I found out the attack was only for windows machines (after confirming with 10+ well known security sources) -- and… I just stopped -- I didn't need to do all this work.

But I'm glad I did. I solved my paranoia.

I also didn't re-install Cursor and Windsurf, which is a win.

This is mostly going to be about did-insert, did-update, etc, aka, the
@ember/render-modifiers.

If you know of a pattern that you use the render-modifiers for and it feels awkward and is not covered here, let me know

I'm writing about this, because I don't think there has been any guidance published
on what to do. A long time ago
(10 months ago),
a warning was added to the top of the @ember/render-modifiers README explaining:

The modifiers provided in this package are ideal for quickly migrating away from classic Ember components to Glimmer components, because they largely allow you to use the same lifecycle hook methods you've already written while attaching them to these modifiers. For example, a didInsertElement hook could be called by {{did-insert this.didInsertElement}} to ease your migration process.

However, we strongly encourage you to take this opportunity to rethink your functionality rather than use these modifiers as a crutch. In many cases, classic lifecycle hooks like didInsertElement can be rewritten as custom modifiers that internalize functionality manipulating or generating state from a DOM element. Other times, you may find that a modifier is not the right fit for that logic at all, in which case it's worth revisiting the design to find a better pattern.

Either way, we recommend using these modifiers with caution. They are very useful for quickly bridging the gap between classic components and Glimmer components, but they are still generally an anti-pattern. We recommend considering a custom modifier in most use-cases where you might want to reach for this package.

So yeah, there is kind of a lot to unpack there. Especially since we haven't really had an
alternative to the data-side / non-dom-related-side of things for a long while. Throughout this post, there will be
bulleted lists showing the benefits of each alternative -- because I usually skim long posts with code,
and I'm sure others do as well -- bulleted lists stad out ;)

Using a custom modifier

A custom modifier is good solution for when your behavior is tied to a particular DOM node
or DOM tree. It encapsulates the lifecycle of rendering in to one co-located space so that
it's easy to understand what code is responsible for what.

❌ Bad - setup and teardown are not grouped together

<div
  {{did-insert this.setupResize}}
  {{did-update this.updateResize}}
  {{will-destroy this.teardownResize}}></div>

In addition, this pattern also encourages components that have multiple responsibilities.
The component that contains this setup/update/down for resize may also have other responsibilities,
like maybe it's also managing a form, or a table, or something.

✔️ Good - behavior is grouped

<div {{resizable}}></div>

This pattern collects all the related behavior in to a semantically standalone thing, a custom modifier.
There are built in modifiers, and you may be familiar with them, as they're the only two modifiers
in ember right now (3.27 latest at the time of writing): {{on}} and {{action}}.

How would the JavaScript side of this look? In the first example, the code in a component may look something
like this:

// app/components/my-component.js
export default class MyComponent extends Component {
  // ... component stuff ...

  @action setupResize() { /* ... */ }

  @action updateResize() {/* ... */}

  @action teardownResize() { /* ... */ }

  // ... component stuff ...
}

which looks fine in isolation, and if this were all a component did, it would not be cause for too much alarm.
But as components grow, and folks add features to existing components, those 3 functions get crowded. Extracting
them to a custom modifier is a great way to focus on a component's core responsibilities.
That extracted JavaScript may look like this:

// app/modifiers/resizable.js
import Modifier from 'ember-modifier';

export default class Resizable extends Modifier {
  didInstall() { /* original setup code */ }
  didUpdateArguments() { /* original update code */ }
  willDestroy() { /* original teardown code */ }
}

Benefits of the custom modifier

• all element tied to a behavior is encapsulated in a single class
• easier to keep track of cleanup
• can be render-tested outside of the component where it is used
• shareable among other elements
• reads better when parsing the template with your eyes

Using a local modifier

Sometimes you are not sure if your modifier needs to be globally accessible or you want to keep it to yourself
while you work out the kinks before shareing it with your team. Since Ember 3.25, you can assign modifiers,
helpers, and components to class properties on components to reference locally in your component.

For example, say you decided that the above resizable modifier wasn't ready to be shared with folks,
you could rearrange your files like so:

-app/components/my-component.hbs
-app/components/my-component.js
+app/components/my-component/index.hbs
+app/components/my-component/index.js
-app/modifiers/resizable.js
+app/components/my-component/resizable.js

Also note: we moved my-component.{js,hbs} to my-component/index.{js,hbs}, not because we had to, but because
it (to me) feels nicer to have a folder contain our "private-to-the-component" stuff.

In the my-component/index.js, you'll need to import and assign the modifier

// app/components/my-component/index.js

import Resizable from './resizable';

export default class MyComponent extends Component {
  resizable = Resizable;

  // ... component stuff ...
}

<div {{this.resizable}}></div>

It'll work the exact same is the previously globally available version.

Benefits of a local modifier

• most of the benefits of a custom modifier
• additionally, modifiers that are "specific to a thing", can be kept private~ish (as private as JS allows anyway)
• allows for easier prototyping without interfering with the global pool of modifiers

More information on modifiers

Modifier abstractions aren't yet adopted into the framework, but you can learn more here

• ember-modifier
  Lots of information in here about the philosophy and thought process about when to use a modifier.
• RFC #757: Default Modifier Manager
  For using plain vanilla JavaScript functions as modifiers when used in the modifier position in template syntax.
• RFC #416: Render Element Modifiers
  Original RFC detailing a transition path from old ember component lifecycle hooks

Fetching data

❌ Bad - Modifier has nothing to do with the element.

<div {{did-insert this.fetchData}} {{did-update this.fetchData @someArg}}></div>

This also requires that your component have a template -- provider components, for example, do not need a template.
Additionally, this means that data is eagerly fetched, so even if your component doesn't need the data right away,
that data-fetching slows down your time-to-settled.

✔️ Good - Data is reactively and lazyily fetched as it is needed via a Resource.

import { trackedFunction } from 'ember-resources/util/function';
export default class MyComponent extends Component {
  data = trackedFunction(this, async () => {
    let response = await fetch(`url/${this.args.someArg}`);
    let json = await response.json();

    return json;
  });
}

{{!-- when ready for use --}}
{{this.data.value}} will be the fetch's json

With this approach, no modifier is used and no element is needed. data will call your function when the .value
property is accessed, and it will "eventually" resolve to the returned json in the inner function.

There are a number of utilities in ember-resources for dealing with "Reactive async~ish" data a little nicer.
See the README over there for more details.

Benefits of using a Resource:

• lazy, only runs when accessed
• reactive, changes to tracked data will re-invoke the resource
• everything is encapsulated, no need to worry about template <-> javascript communication
• easily unit testable
• can be used in vanilla JavaScript classes

✔️ Good - Data is lazily fetched after a user action

This is probably the best case scenario for data loading, even though it is non-reactive.

export default class MyComponent extends Component {
  @action
  async loadData() {
    let response = await fetch(`url/${this.args.someArg}`);
    let json = await response.json();

    return json;
  }

  @tracked data;

  @action 
  async handleClick() {
    this.data = await loadData();
    /* ... do something with data */
  }
}

{{!-- when ready for use --}}
{{this.data}} will be the fetch's json

This is the most optimized that you can make a network request, and aligns with ember-data's new request manager usage recommendations. Most notably, however, if this.args.someArg changes, the data will not update, because data fetching was triggered by the user, not the autotracking system.

Handling destruction

For this example, assume we have a class constructor that we've bound some events to the window.
Maybe beforeunload (to protect against accidental refreshes while editing a form).

❌ Bad - Modifier has nothing to do with the element.

<div {{will-destroy this.removeWindowListeners}}></div>

This sometimes has caused folks to add an invisible element just so that they can use the modifier hook.
We should not add more DOM than we absolutely need, and behavior setup in JS should be torn down in JS.

✔️ Good -- no modifiers needed

{{!-- No element --}}

import { registerDestructor } from '@ember/destroyable';

class MyComponent extends Component {
  constructor(owner, args) {
    super(owner, args);

    this.setupWindowListener();
    this.setupScrollListener();
  }

  @action setupWindowListener() {
    /* setup */
    window.addEventListener('beforeunload', this.handleUnload)

    registerDestructor(this, () => {
      /* teardown */
      window.removeEventListener('beforeunload', this.handleUnload)
    });
  }

  @action setupScrollListener() {
    /* setup */

    registerDestructor(this, () => { /* teardown */ });
  }
}

For @glimmer/component, there is also the willDestroy hook,
but I'd argue that co-locating setup and teardown is better long-term, because in each setup-teardown pair,
you know exactly what conditions are needed to safely teardown. Keeping that grouped together can make maintenance
easier if or when you need several teardown steps for various things (maybe you setup a few listeners, a Mutation
Observer, other stuff).

Benefits of @ember/destroyable

• co-locates setup+teardown
• can be used anywhere, not just in ember constructs
• eliminates the need for "willDestroy" hooks provided by a framework
• can easily share combined sets of setup+teardown functions

Docs on @ember/destroyable

Related, if you find the registerDestructor setup/teardown dance a bit tiring, there is a utility library,
ember-lifecycle-utils which provides a utility to
allow you to eventually create concise apis like:

class Hello {
  constructor() {
    useWindowEvent(this, 'click', this.handleClick);
    useWindowEvent(this, 'mouseenter', this.handleClick);
  }
}

More info on Resources

• Introducing @use by pzuraq

• ember-could-get-used-to-this

• ember-resources

  • note that ember-resources is inspired by pzuraq's work, and solves some of the common challenges
    that the ember-could-get-used-to-this' implementation faces:
  • Typescript support without wrapper no-op methods
    • No need for decorator (typescript can't augment types with decorators)
  • Custom Resources no longer need a magic 'value' property
  • Built in support for (async) functions and concurrency tasks

  Much thanks to pzuraq, because without ember-could-get-used-to-this, ember-resources would not have existed.

• RFC 567: @use and Resources

  • Discussion that lead to a bunch of smaller RFCs and the implementation of ember-could-get-used-to-this

Why even change how I write code at all?

You don't have to, that's up to you. One of the primary reasons @ember/render-modifiers was made as an
addon was so that it didn't have to be part of the framework, and that individual projects and teams
could decide if it was the right fit for them. It's a very small package, so if it's only used in a few places,
bundle size isn't that much of a concern for the average app.