Maintaining invariants the most painful way possible.
A handy design pattern stolen from Objective-C and Swift for designing nicely usable APIs.
Faster, more reliable builds, with better error reporting – please come test it in your apps and addons!
Maybe helpers for safe object lookup and
Result helpers for exception-throwing code.
Today—just shy of two years since I started adding types to our Ember app—it fully type-checks.
A bunch of neat new utility functions on Maybe for arrays and tuples.
Revisiting our app in TypeScript’s strict mode has me thinking about what we’d do different if we had this input in the first place.
An important set of corrections about the behavior of class properties in Ember.js.
Or, making TypeScript into a terrible ML because I can’t use Elm in my day job.
Components as arguments! Components getting yielded! Components everywhere!
If your consumers have to use compiler options, they will be very sad.
A thing I didn't even realize I could do until after I published it.
Doubling Down on Documentation
A couple nice ergonomic updates and some breaking changes for consuming the library.
Finishing What We've Started
Now with generators, support for addons, and incremental compilation!
Using Ember Data, and service and controller injections improvements.
Computed properties, actions, mixins, and class methods.
Class properties—some notes on how things differ from the
How do things look in early 2018? Pretty good, actually!
Elm taught me something important about how to handle my APIs.
Result types, and supporting both a functional style and a more traditional method-call style.
Example: using Ember for view and lifecycle but plain-old TypeScript otherwise.
How to actually use types effectively in Ember today.
Adding TypeScript to an existing Ember.js project.
Set your Ember.js project up to use TypeScript.
Or, yet another long comment in Slack turned into a blog post.
Autocomplete all the things in all the ways!