It's 2024. You should use tsup instead of this.
🔥 Blazing fast builds
😇 CommonJS bundle
🌲 .mjs
bundle
✨ .d.ts
bundle + type-checking
import Foundation | |
// https://github.com/apple/swift/blob/main/include/swift/ABI/MetadataKind.def | |
struct MetadataKind: Equatable { | |
var rawValue: UInt | |
/// A class type. | |
static var `class`: Self { | |
.init(rawValue: 0) } | |
/// A struct type. |
It's 2024. You should use tsup instead of this.
🔥 Blazing fast builds
😇 CommonJS bundle
🌲 .mjs
bundle
✨ .d.ts
bundle + type-checking
Once upon a time, there was a developer that had an issue using the TypeScript language. He wanted to share his issue with the community to get help, but he didn't know how to properly write the title that would best describe his problem. He struggled to find the appropriate words as he didn't know how to name "this behavior" or "that kind of type mechanism".
This story encouraged me to start writing a glossary of TypeScript. Hopefully it will help you if you have to look for an issue, write an issue, or communicate with other TypeScript developers.
Disclaimer: it was me, I was the developer that struggled. I still struggle though, but this means I still have things to learn, which is great!
I've been working through the exercises in the excellent iOS Unit Testing by Example book by Jon Reid, which I highly recommend. However, the book is in beta at the moment and there are some curveballs thrown by iOS 13 that aren't handled in the text yet. Specifically, when I hit the section about using a testing AppDelegate
class I thought "This is very good. But what about the SceneDelegate
?"
In Chapter 4 the recommendation is to remove the @UIApplicationMain
decoration and make a manual top-level call to UIApplicationMain
. To wit:
import UIKit
The libdispatch is one of the most misused API due to the way it was presented to us when it was introduced and for many years after that, and due to the confusing documentation and API. This page is a compilation of important things to know if you're going to use this library. Many references are available at the end of this document pointing to comments from Apple's very own libdispatch maintainer (Pierre Habouzit).
My take-aways are:
You should create very few, long-lived, well-defined queues. These queues should be seen as execution contexts in your program (gui, background work, ...) that benefit from executing in parallel. An important thing to note is that if these queues are all active at once, you will get as many threads running. In most apps, you probably do not need to create more than 3 or 4 queues.
Go serial first, and as you find performance bottle necks, measure why, and if concurrency helps, apply with care, always validating under system pressure. Reuse
I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.
I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.
Chrome 51 has some pretty wild behaviour related to console.log
in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.
Hi Zach :D
Modals are funny beasts, usually they are a design cop-out, but that's okay, designers have to make trade-offs too, give 'em a break.
First things first, I'm not sure there is such thing as a "simple" modal that is production ready. Certainly there have been times in my career I tossed out other people's "overly complex solutions" because I simply didn't understand the scope of the problem, and I have always loved it when people who have a branch of experience that I don't take the time