Sym·poly·mathesy

by Chris Krycho

topic: TypeScript

Everything I’ve written on the subject, from the beginning of this version of the site.

I may also have written on this on earlier versions of my website:

  1. 2006 – 2011 (link coming soon!)
  2. did not have a blog!
  3. 2012 – 2013 (link coming soon!)
  4. 2014 – 2019

  • 2019

  • 2020

    • Feb

      • 23

        • 17:25 ❈ — NOTES

          I’ve spent a good chunk of this afternoon working through and tweaking and fixing some things about this website, and as much as I like 11ty, at this point I would love to be doing this work in Elm instead. A tool like elm-pages seems very appealing.

          As for why: I just spend a lot of time sad about JS “sorry bro that’s undefined” stuff and templates being totally type-unaware. Even something like Gatsby + TS would probably be better here, but Elm’s rigor and top-to-bottom integration of types and rendered HTML and CSS would be a huge win for the way I build websites.

    • Apr

    • May

      • 12

        • 10:15 ❈ — NOTES

          TypeScript: it’s regularly absurd or weird, and I am frustrated regularly by so many things about the type system… but nearly all of them come down in practice to “this works this way because JavaScript and JavaScript developers.”

      • 13

        • 08:11 ❈ — NOTES

          Last night I threw away almost all the build config I’d been blinded by this spring while working on rewrite: webpack config, TypeScript integration, you name it. What I have left: a simple bunch of npm scripts that I can run in parallel in different terminal sessions:

          {
  "scripts": {
    "clean": "rm -rf dist/*",
    "build:static": "cp static/* dist",
    "build:css": "sass --load-path=./node_modules src/style.scss dist/style.css",
    "watch:css": "sass --watch --load-path=./node_modules src/style.scss dist/style.css",
    "build:elm": "elm make src/Main.elm --output dist/app.js",
    "watch:elm": "watchexec -w src 'elm make src/Main.elm --output dist/app.js'"
  }
}

          It’s not fancy, but it gets the job done just fine for the things I’m actually working on — rather than things I’ll need eventually — and that’s exacty the right balance at this point.

      • 25

    • Jun

    • Sep

    • Oct

    • Dec

      • 06

        • 13:28 ❈ — NOTES

          I built a tiny tool to delete all my old tweets, since previous passes via online apps weren’t doing the trick (something something Twitter API limitations). Was a fun little exercise!

      • 22

        • 16:25 ❈ — NOTES

          At long last — literally over a year late! — we just published our revised, Octane-ready docs for ember-cli-typescript. They’re far from perfect, but we’ll iterate from here. And keep your eyes open: lots more motion in this space over the next six months!

  • 2021

    • Jan

      • 08

        • 22:45 ❈ — NOTES

          Going to write up a deep dive blog post on this, but for tonight, a preview: Ember.get (or _.get or R.prop) with nested keys working correctly and robustly in TypeScript — play with a demo here.

      • 22

    • Mar

    • May

      • 21

        • 16:41 ❈ — NOTES

          The kind of day I’m having: I went searching for literature on semantic versioning for dependent types. As far as I can tell, there’s literally nothing1 — and as my friend Dan Freeman pointed out, it’d probably be a 🍾 moment if they were in broad enough use to have this literature. 😂

          In related news: conceptualizing type narrowing in TypeScript as write operations on types in the flow-control-based subset of dependent typing which TS enables has proven profitable for resolving a previously-intractable conceptual problem about SemVer for TS I was having. 😂

          1. The top hit on both DuckDuckGo and Google for the search query "semantic versioning" "dependent types" is… me. 😬 ↩︎

      • 26

        • 20:50 ❈ — NOTES

          Just published a small experiment I’ve been mulling on for the past week or so: ember-simple-track-helper. It’s basically the same idea as React’s useState hook, for Glimmer and Ember “template-only components” — places you don’t really need a backing class.

          (As with all my recent packages, this is following the spec for SemVer for TypeScript I have been working on. So far it’s working well! Hopefully-final revisions to that RFC inbound in the weeks ahead!)