Skip to content

Instantly share code, notes, and snippets.

View chriskrycho's full-sized avatar
🚀
Hire me! https://v5.chriskrycho.com/journal/next/role/

Chris Krycho chriskrycho

🚀
Hire me! https://v5.chriskrycho.com/journal/next/role/
View GitHub Profile
@chriskrycho
chriskrycho / danluu.css
Created October 20, 2023 16:43
My custom style sheet for danluu.com
html {
font: 17px/1.4 Palatino;
}
body {
max-width: 36rem;
margin-left: clamp(1rem, 20%, calc(50% - 21rem));
margin-right: clamp(1rem, 20%, calc(50% - 21rem));
}
@chriskrycho
chriskrycho / a_question.md
Last active May 5, 2023 14:53
Ember block content enforcement (relevant to Vue/Svelte slots and React children, too!)

I was wondering if there's currently any way in TS to enforce the child types passed into a yield block? I looked into the component signature and it seems like Blocks specifies the things that are yielded out but doesn't impose any restrictions on what's passed in.

For example, if I have some component Foo:

<div class="foo">
  {{yield}}
</div>
@chriskrycho
chriskrycho / lockfiles.md
Created October 31, 2022 15:25
Node package managers and dependency updates

Yarn will avoid updating transitive dependencies if you’re not actively updating the source of the transitive dependency.

This is reasonably well-motivated: say you depend on package A which depends on "B": "^1.0.0", and Yarn resolves B at 1.0.1 and you later install package C which depends on "B": "^1.0.2"A says it’s compatible with that version, but it’s still possible for A to be relying on broken behavior in B 1.0.1 which got fixed in 1.0.2, so Yarn leaves the original in place instead of updating it, and you just end up with two copies of B in your dependency graph; A uses the original and C uses a new one.

That is broadly preferable for Node-side applications, because it means you can control it by explicitly upgrading A or even A’s version of B, but it never happens implicitly.

To work around it in cases like this, you can volta install yarn-deduplicate and then run yarn-deduplicate in your repo, and that will usually clear out issues like this as long as

import Controller from '@ember/controller';
import EmberObject from '@ember/object';
import { getOwner } from '@ember/application';
let lol = EmberObject.create({ we: 'are very smart' });
export default class ApplicationController extends Controller {
hasOwner = JSON.stringify(getOwner(lol));
}
{{log @theArg}}
import Component from '@glimmer/component';
import MyService from '../services/my-service';
export default class Example extends Component {
myService = MyService.create();
}
import Controller from '@ember/controller';
export default class ApplicationController extends Controller {
appName = 'Ember Twiddle';
}
import Controller from '@ember/controller';
import { action } from '@ember/object';
class AC extends Controller {
appName = 'Native';
// Uncomment this and the app will fail at runtime, because @action
// sets up a trap which means that attempting to override it in the
// subclasses errors!
// @action
@chriskrycho
chriskrycho / instructions.md
Last active November 24, 2021 16:16
self-recursive ES modules 🤯
  1. Create a new Node package (an empty folder with a package.json will do), and set "type": "module" in it.

  2. Create an index.js file with this content:

    export function amaze() {
      console.log("modules importing themselves? wow");
    }

import { amaze as wow } from './index.js';

import Controller from '@ember/controller';
import { tracked } from '@glimmer/tracking';
export default class ApplicationController extends Controller {
@tracked value = "Hello";
get value() {
alert("Getting value!");
return this.value;
}