typeof の implementation-defined を削除 歴史的経緯から typeof の結果に implementation-defined が含まれていました。 Type of val Result

ECMAScript のモジュール ECMAScript にはもともとモジュール1つをカプセル化して表現した Abstract Module Records という抽象クラスと、それを継承した Source Text Module Records 具象クラスのみが定義されていました。 Source Text Module Records がいわゆる JavaScript モジュールを表しており、ざっくり以下のような特徴を持ちます。 JavaScript のソースコードを持つ 他のモジュールと(循環可能な)依存関係を持ち、有向グラフを作る モジュールグラフから、それぞれのモジュールの実行順が定められる Cyclic Module Records の策定 WebAssembly の登場により JavaScript のソースコードを持たないが、依存グラフに参加出来るモジュールが仕様に必要となりま
Reflect.ownKeys のプロパティ列挙順 ES2015 Reflect.ownKeys は対象オブジェクトが持つ [[OwnPropertyKeys]] 内部メソッドを呼び出します。Proxy や Module Namespace オブジェクトのような Exotic Object にはそれぞれ定義された [[OwnPropertyKeys]] 内部メソッドで順番が定義されますが、普通のオブジェクトは OrdinaryOwnPropertyKeys で定義された順に列挙されます。 OrdinaryOwnPropertyKeys は以下の順で列挙します。 配列のインデックスとなりうる整数(文字列)プロパティ(array index)をその数の順番で列挙する 1 以外の文字列プロパティを作成順に列挙する Symbol プロパティを作成順に列挙する const obj = { [3]:
イテレーターの next メソッドをキャッシュする JavaScript エンジンに ES2015 の機能が入り始め、Web ディベロッパーたちがその便利さに感動していた頃の話。配列で for...of やスプレッド構文を使うのは確かに便利な一方で、単純な for 文の方が高速に実行できることが問題視されました。 原因は明白で for 文の場合は値を取り出すのにプロパティアクセスするだけですみますが、for...of やスプレッド構文の場合は値を取り出すのに毎回イテレーターの next メソッドを呼び出す必要があります。そこでパフォーマンスを改善するため、互換性の問題が起きない範囲で破壊的変更を入れる案が2つ出ました。 %ArrayIteratorPrototype%.next といったビルトインイテレーターの next メソッドを変更不可能にし、それらから値を取り出す際にエンジンの最適化
皆さんは新しく実装が進む Node.prototype.moveBefore というメソッドをご存知でしょうか、この記事ではこの新しいメソッドについて簡単な解説を行おうと思います。 新しく実装が進む Node.prototype.moveBefore メソッド Node.prototype.moveBefore() とは新しく Node インターフェースに追加されるメソッドで Node.prototype.insertBefore() と同様のシグネチャーで要素の状態を維持しつつノードの移動ができる API です。 「要素の状態を維持しつつノードの移動ができる」という表現が想像できない人もいるかもしれませんが具体的な例としては、X のこのポストに付随している動画を見ていただけるとわかりやすいかと思います。 注目していただきたい点としては、要素が左右に移動した際にアニメーションの状態が保持さ
非同期イテラブル(非同期反復可能)とは ES2018 から仕様の中に非同期イテラブルインターフェースと非同期イテレーターインターフェースが定義されています。非同期イテラブルインターフェースを実装したオブジェクト[1]のことを単に非同期イテラブル(非同期反復可能)と呼びます。 ざっくり TypeScript の型で表現すると以下のようになります(実際の TypeScript での型はジェネリクスになっています)。 interface AsyncIterable { [Symbol.asyncIerator](): AsyncIterator; } interface AsyncIterator { next(value?: any): Promise<IteratorResult>; return?(value?: any): Promise<IteratorResult>; throw?(
概要 文章をコピペしてエクセルに張り付けたときに、画面のスタイルもコピーされてしまって困ったことはありますか?ありますよね! (↓こんな感じ) 私もよくやってしまうのですが、実際にどのような処理が行われているのかよく分かっていませんでした。理解を深めるためにも、自分で実装して謎を解いていきたいと思います。 3つパターンの処理を実装 比較のため、プレーンテキスト・HTMLテキスト・リッチテキストのコピー機能をサンプルプログラムを実装してみました。 (リッチテキストのコピーが、範囲選択してコピペしたときと同じ機能を想定しています。) HTMLファイル 画面表示されるHTMLは下記のような感じです。各コピー処理でid="message"の部分を固定でコピーするようにします。 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"
イテラブル(反復可能)とは ES2015 から仕様の中にイテラブルインターフェースとイテレーターインターフェースが定義されています。イテラブルインターフェースを実装したオブジェクトやプリミティブのことを単にイテラブル(反復可能)と呼びます。 ざっくり TypeScript の型で表現すると以下のようになります(実際の TypeScript での型はジェネリクスになっています)。 interface Iterable { [Symbol.iterator](): Iterator; } interface Iterator { next(value?: any): IteratorResult; return?(value?: any): IteratorResult; throw?(error?: any): IteratorResult; } interface IteratorResu
単なる自分のやらかしの共有です。この記事は事実をもとにしたフィクションです。 消し忘れたclose()関数 あるときモーダルコンポーネントを閉じる、close()関数というのを作りました。後日、リファクタリングをするときこの呼び出されているclose()関数がとあるコンポーネントから取り除かれることになりました。しかし誤って1つ削除し忘れてしまい、close()関数が取り残されてしまいます。 このとき、import文なども取り除かれたのですが、何故か未定義エラーなどは出ずに見過ごされてしまいました。(察しの良い人はピンとくるかも) 何故か消えるウィンドウ そんな中、消し忘れたコンポーネントを含む画面で特定の手順を踏むと開いたブラウザウィンドウが閉じてしまう現象が確認されるようになりました。 どうやら発生源は先程のリファクタリング作業らしい… window.closeというJavaScrip
AuthorsNameDarcy ClarkeX (Formerly Twitter)@darcyNameRuy AdornoBluesky@ruyadorno.comNameIsaac SchlueterX (Formerly Twitter)@izsNameLuke KarrysBluesky@lukekarrys.com After spending the past six months heads-down, we’re excited to share our foundational Package Manager Client & Serverless Registry.A New JavaScript Package Manager:First up, we're introducing vlt, a brand new, free, and open-source Ja
Programmatically assemble prompts for LLMs using JavaScript. Orchestrate LLMs, tools, and data in a single script. JavaScript toolbox to work with prompts Abstraction to make it easy and productive Seamless Visual Studio Code integration or flexible command line Built-in support for GitHub Copilot and GitHub Models, OpenAI, Azure OpenAI, Anthropic, and more
Intro ここまで解説した仕様を踏まえ、いくつかの代表的なユースケースの実装について考えていく。 あくまで仕様の組み合わせ方についての解説であり、実装そのものの推奨ではない。 また、ここで紹介する仕様はまだ変更の可能性があり、かつ実装も揃っていないものがある点に注意 Toast 次は、Popover の源流にもなった、画面端にメッセージを表示するいわゆる Toast UI について考えてみる。想定するのは以下のようなものだ。 メッセージの性質によって、色やアイコンのスタイルを変えられ、同時に複数積み上げて表示できるといった仕様が一般的だ。 HTML 基本は <div popover> となる。また、複数のメッセージがあった場合に、他のが表示されても消えないよう、manual を指定する。 <div popover="manual"> </div> もし内容のレイアウトで Flex や G
5つのECMAScript ProposalがStage4になど: Cybozu Frontend Weekly (2024-10-15号) こんにちは! サイボウズ株式会社フロントエンドエンジニアの Saji (@sajikix) です。 はじめに サイボウズでは毎週火曜日に Frontend Weekly という「一週間にあったフロントエンドニュースを共有する会」を社内で開催しています。 今回は、2024/10/15 の Frontend Weekly で取り上げた記事や話題を紹介します。 取り上げた記事・話題 PR TIMES フロントエンドの CI パイプラインを改善して、CI 処理時間と Billable Time を 50%を削減した話 | PR TIMES 開発者ブログ changed-files という github action 使って、変更があった特定のディレクトリのみ
Wasmerは、clangを実行することで可能になるユースケースの例として、以下を挙げている。 Wasmer CLI(コマンドラインインタフェース)を使用するだけで、CコードをWebAssemblyに簡単にコンパイルできる。ツールチェーンや複雑なインストールは不要で、Wasmerをインストールするだけで準備が完了する 「WASIX」がセルフホストされるようになり、WASIX自身と任意のCプログラムをコンパイルできる。WASIXは、WebAssemblyでネットワークやファイル、メモリなどのシステムリソースを抽象化するAPI仕様である「WASI」を拡張し、POSIX(Portable Operating System Interface)に対応させたものだ JavaScriptから直接Cプロジェクトをコンパイルできる(Wasmer JS SDKでclangを使用する方法については後述) ビル
Intro ここまで解説した仕様を踏まえ、いくつかの代表的なユースケースの実装について考えていく。 あくまで仕様の組み合わせ方についての解説であり、実装そのものの推奨ではない。 また、ここで紹介する仕様はまだ変更の可能性があり、かつ実装も揃っていないものがある点に注意 Cookie バナー 次は、「Cookie 利用への同意」、いわゆる Cookie バナーの UI について考えてみる。想定するのは以下のようなものだ。 前回の規約への同意と異なり、このバナーは画面表示時から右下に表示され、同意か拒否を選択するまで表示し続ける。つまり、表示中は他の操作をブロックしたりはしない。 つまり Dialog ではあるが Modal ではないため、show() する前提で実装を考えていく。 HTML HTML の注意点は、前回の規約と大きくは変わらない。 まず、最初から表示しておくために open 属
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く