∞
Setting a Request ID in SvelteKit
I have been working on a full-stack application in SvelteKit recently. As the complexity of the application grew, it started getting harder to understand what was happening during each page render. I knew I needed something to help track down what was happening in my application during each request. The solution to my problem was a familiar one: request IDs!
∞
Print GitHub CLI Pull Requests Without Paging
I am a big fan of the GitHub Command Line tool, gh. In particular, it’s a great way to list the pull-requests for a repository and then check one out locally for review.
By default, this workflow is a little tricky. When you list your PRs you get a list that is passed automatically through your $PAGER program (probably less). By default, regardless of how much content there is, you have to actively dismiss less to go back to the command line.
∞
Managing Specificity with CSS Variables
A recent project at work had me defining some shared button styles for us to use in conjunction with Tailwind CSS. The styling is much like you might expect; a base button class with some specific “types” of buttons in different styles. For the purpose of illustration, imagine something like this:
.button { color: black; } .button.type-plain { color: blue; } To render a “plain” button, you use the classes together on an element:
∞
Converging on a Condition in QUnit
While writing some acceptance tests recently I kept running into slight race conditions between the state my application and an assertion I wanted to make. For example, one of the tests looked something like this:
test("creating a comment", async function (assert) { assert.equal(Task.comments.messages.length, 5, "Starts with correct number of comments"); await Task.comments.input.fillIn("A new comment"); await Task.comments.send(); assert.equal(Task.comments.message.length, 6, "Adds a new comment"); }); How does the test know that the right number of messages should be visible at the point that send() resolves?
∞
Writing JS in Vim
This post was originally published on Medium. You can view that here.
These days, the experience of writing JavaScript is influenced as much by the tools used during development as those used at runtime. Projects exist that can drastically improve your code quality, from basic help like spotting typos to adding full-blown type checking to a dynamically typed language. As great as these tools are on their own, they’re made even more useful when they can be brought directly into your editor.