In a React application written in TypeScript, the language’s type system is the first line of defense against type errors in component props. In Markdoc, where content is decoupled from rendering logic and can’t take advantage of TypeScript types, the schema-based validation system plays an important role in bridging the gap between declarative tag definitions and typed React components. The Markdoc validator ensures that tag attribute values in a document match the types declared in the corresponding schema.

A recent Markdoc release introduced a new feature that makes it possible for validation functions to access the parents of the current node. This feature is useful for writing custom validation logic that analyzes document structure or enforces rules based on a node’s position in the hierarchy. For example, you might want to impose restrictions on where an image can be nested in a document, prohibiting the use of images in specific tags like callouts and asides.

Chrome 63, released in December, included async iterators and the associated for-await-of syntax. As the feature is now official in V8 6.3, it’s also likely to land in the upcoming Node.js 10 release this April. In light of its imminent availability in Node.js, I figured that it was time to start exploring the real-world potential of async iterators on the backend. Combining the async and await keywords with generator functions provides an elegant way to express streaming operations in modern JavaScript applications.

Microsoft’s TypeScript programming language brings many of the advantages of static typing to JavaScript. Although it doesn’t enforce types at runtime, it enables richer static analysis, encourages more safety, and opens the door for better IDE integration. TypeScript code is typically transpiled to standards-based JavaScript so that it can run natively in browsers and Node.js. Given the attractiveness of TypeScript’s benefits, it is unsurprising that adoption is growing at a rapid pace.

OS X comes with a framework called SearchKit that applications can use to index content and support full-text searches. I occasionally run into situations where I want to take advantage of an application’s existing SearchKit index so that I can perform my own full-text searches programmatically. The most recent case arose this weekend while I was attempting to build an Alfred workflow for searching Quiver notes. Quiver uses SearchKit internally to expose full-text search through its own user interface, but it doesn’t have native Spotlight integration yet.