タグ

ブックマーク / zenn.dev/qnighy (7)

  • 主なNode.js独自API

    // CommonJS Modules の場合 const fs = require("fs"); const fs = require("node:fs"); // ES Modules の場合 import fs from "fs"; import fs from "node:fs"; process のように、グローバル変数としても組み込みモジュールとしても提供されているAPIもあります。 global globalThisの別名です。Webブラウザでは window と self がglobalThisの別名として定義されていますが、Node.jsには window や self はなく、かわりに global が定義されています。 Buffer ArrayBuffer, TypedArray (Uint8Arrayなど), DataView はJavaScriptの標準機能です。

    主なNode.js独自API
  • JavaScriptの参照レコードとthisバインディング

    JavaScriptの仕様には「参照レコード」という概念があります。参照を意識することで、JavaScriptにおけるメソッド呼び出しの理解と左辺式の評価順序の理解を同時に深めることができます。稿ではこの「参照レコード」の動機と詳細の説明を試みます。 ※ 記事ではECMAScriptの規格で「参照レコード」と呼ばれている概念を説明します。JavaScriptのオブジェクトは参照渡しのような使い方ができますが、これは稿で説明する「参照」とは少しだけ異なります。 参照レコードの目的 JavaScriptにおける参照レコードは以下の2つの目的で存在しています。 左辺式の中間評価結果を表現するため。 メソッドのレシーバーを決定するため。 左辺式の中間評価結果とは たとえば a[f()] += 2; というコードを考えます。 function f() { console.log("f()");

    JavaScriptの参照レコードとthisバインディング
  • Native ESM + TypeScript 拡張子問題: 歯にものが挟まったようなスッキリしない書き流し

    Node.jsのNative ESM対応は夢の機能ですが、夢を詰め込みすぎたせいかCJSからの移行を難しくしているポイントが依然として存在します。そのひとつが拡張子問題で、Node.jsのNative ESMではモジュールの拡張子を明示しなければいけなくなりました。 (これはWebブラウザの挙動に近づけるための判断だと考えられます。) 特にTypeScriptと他のツール (JestやWebpack) と組み合わせて利用している状態でのNative ESM化は実質的に未解決の状態だと言えます。稿ではこの現状についてできる範囲で状況説明を試みます。 Node.jsの拡張子の扱い Node.jsはCJSとESMの2つのモジュールフォーマットをサポートしていますが、これらは単にパーサーが異なるだけではなく、実質的には「2種類の異なるモジュールシステムがFFIで繋がっている」程度には隔たりがあり

    Native ESM + TypeScript 拡張子問題: 歯にものが挟まったようなスッキリしない書き流し
  • 「Rustでやると知らないうちに詰む設計」を避けるためのTipsを集めてみる

    とりあえず、よく言われてるやつから埋めていこうと思う。 構造体にライフタイムを持たせない 構造体にライフタイムを持たせるのは「基的に」避けよ、というのが重要なのは間違いないのだけど、これをもう少し実践的な内容にしたい。ちょっと考えてみたけど、こういうのはどうだろうか。 ある関数呼び出しの中でしか絶対に使わない。returnするまでにその構造体のデータは全て破棄される。static変数に退避させることもできない。アロケーションもその関数が面倒を見る。そういう一蓮托生できる関数呼び出しに心当たりはあるか? ある→ 構造体にライフタイムを持たせてもよい。 ない→ ライフタイム禁止。 そう考えてみると、DIとかReduxとかとも通じるところがあるかもしれない。「つべこべ言ってないで全部の責務を一番外側に持っていく」という決断ができるときは構造体ライフタイムが選択肢に入る。

    「Rustでやると知らないうちに詰む設計」を避けるためのTipsを集めてみる
  • TypeScriptのdeclareやinterface Windowを勘で書くのをやめる2022

    おことわり 個々の関数や変数に正しい型をつける話はしません。TypeScript HandbookのDeclarationの章などを読むことをおすすめします。 かわりに、稿では関数や変数の型宣言をどこにどう置くべきかの指針を与えます。 モジュールとスクリプト declareを正しく使うにはまずモジュールとスクリプトの区別を理解し、意識することが大切です。 ブラウザやNode.jsは外部からの指定でモジュールとスクリプトを区別しますが、TypeScriptでは原則としてファイルの内容でモジュールとスクリプトを区別します。 import 宣言または export 宣言が1つ以上あればモジュール。 CommonJSモジュールの場合はTypeScript専用構文である import = 宣言、 export = 宣言を使う。 それ以外の場合はスクリプト。 ただし、JavaScriptファイル (

    TypeScriptのdeclareやinterface Windowを勘で書くのをやめる2022
    ko-ya-ma
    ko-ya-ma 2022/01/01
    かなり詳細な説明
  • JavaScriptの非同期処理をじっくり理解する (3) async/await

    対象読者と目的 非同期処理の実装方法は知っているが、仕組みを詳しく知らないのでベストプラクティスがわからないときがある 実行順序の保証がよくわからないので自信をもってデプロイできない変更がある より詳しい仕組みを理解することでより計画的な実装をできるようになりたい という動機で書かれた記事です。同様の課題を抱える人を対象読者として想定しています。 目次 実行モデルとタスクキュー Promise async/await AbortSignal, Event, Async Context WHATWG Streams / Node.js Streams (執筆中) 未定 用語に関する注意 前々回定義した以下の用語を今回も使います。 1 tick ... タスクキューが1周すること。 1 microtick ... マイクロタスクキューが1周すること。 これらの単位は非同期処理の間の相対的な優先

    JavaScriptの非同期処理をじっくり理解する (3) async/await
  • JavaScriptの非同期処理をじっくり理解する (2) Promise

    対象読者と目的 非同期処理の実装方法は知っているが、仕組みを詳しく知らないのでベストプラクティスがわからないときがある 実行順序の保証がよくわからないので自信をもってデプロイできない変更がある より詳しい仕組みを理解することでより計画的な実装をできるようになりたい という動機で書かれた記事です。同様の課題を抱える人を対象読者として想定しています。 目次 実行モデルとタスクキュー Promise async/await AbortSignal, Event, Async Context WHATWG Streams / Node.js Streams (執筆中) 未定 用語に関する注意 前回定義した以下の用語を今回も使います。 1 tick ... タスクキューが1周すること。 1 microtick ... マイクロタスクキューが1周すること。 これらの単位は非同期処理の間の相対的な優先順

    JavaScriptの非同期処理をじっくり理解する (2) Promise
  • 1