イベントループとプロミスチェーンで学ぶJavaScriptの非同期処理
JavaScript の非同期処理は非常に難しく、その難しさの原因は「制御の流れ」が掴みづらいことにあります。 この本では非同期処理を理解するために必要な概念であり、仕組みでもあるイベントループでプロミスチェーンの処理がどのように行われるかをクイズ形式で学ぶことによって、非同期処理の「制御の流れ」を掴めるように訓練します。 知識面については中枢となるイベントループの機構から、実行環境と API、async/await や Promise.all などの一通りの範囲を学習し、最終的には並列化や順序づけて反復処理を行うための制御方法と TypeScript での型注釈までを網羅します。
Chrome の console.log でハマらないために
JavaScript を書いたことがある人ならば一度は使うであろう console.log ですが、この関数は思ったよりも厄介な性質を持っています。その性質を知らずに console.log を使うと、デバッグ時に大ハマリしてしまうことがあります。この記事では console.log の落とし穴についてお話します。 今回は Chrome に特化して解説しますが、Firefox や Safari でも同じ落とし穴があります。 console.log とは まずはさらっと基本をおさらいしましょう。 大前提なのですが、console.log は JavaScript の言語仕様（ECMAScript）で定義されていません。ブラウザ向けには whatwg の仕様がありますが、あくまでもそれはブラウザ向けの仕様であり、Node.js を含むほぼ全ての JavaScript 環境で使えるのは cons
JavaScriptを大きく変えうる Dataflow Proposals の概要と論点(Call-this, Pipe Operator)
Dataflow Proposals とは 以下の5つのプロポーザルをまとめて Dataflow Proposals と呼んでいる。 Stage 2: Pipe operator Stage 1: Call-this operator Stage 1: Partial application(PFA) Stage 1: Extensions Stage 0: Function.pipe and flow 例えば Pipe operator, Call-this operator, Partial application を組み合わせると、以下のように書けるようになる。（提案段階なので変わる可能性アリ） import { getAuth, getIdToken } from "firebase/auth"; function isPublic(article) { return articl
TypeScriptのError Handling - mrsekut-p
TypeScript/JavaScriptの言語思想的にはtry/catchを使ってerror handlingをするのが普通
Navigation API による「JS での画面遷移」と SPA の改善 | blog.jxck.io
Intro 従来の History API を改善する Navigation API の仕様策定と実装が進んでいる。 これは、 History API の使いにくかった部分を補うだけではなく、「JS で画面遷移をする」という現状のミッシングピースに取り組み、 SPA が抱える多くの問題だけでなく MPA すら改善する可能性がある。 この API の目的と仕様を解説しつつ、実装のメモを残す。 画面遷移と SPA の軌跡 Web は HTML の取得と描画を繰り返す、画面遷移(Navigation)を前提としたアーキテクチャ(のちに SPA からの逆算で MPA と呼ばれる)が基本であり、ブラウザなどの実装もそれに最適化されている。 一方「アプリケーション」の設計手法をそのまま Web に持ち込んだ SPA は、この Navigation によってもたらされる UX の低下を防ぐ部分がある一方
イベントループと TypeScript の型から理解する非同期処理
この本は、ブルーベリー本の 8 章からインスパイアされて、 TS の型が示す情報から Promise というものを理解してみる、というアプローチで書いたJSの非同期処理の解説です。 これらの資料と合わせて読むことを推奨します。 JSのイベントループのイメージを掴む JSでは中々意識することが少ないですが、正しく理解するには OS レベルのスレッドの視点で考え始める必要があります。 ブラウザや Node.js では一つのスクリプト実行単位を1つのスレッドに割り当てます。それをメインスレッドと呼んだり、ブラウザだったら UI スレッドと呼んだりします。 例えばブラウザでは、これは秒間60回、つまり 16.6ms ごとにループを呼び出します。(node だったらこれがもっと短いです) 仮に setTimeout の実装がなかったとして、それ相当の擬似コードを書くのを試みます。 let handl
「たかがJavaScript」のその先 #TECHPLAY
フロントエンドと自分のキャリア形成について。このスキルツリーとセットで見るといいかもです。 https://whimsical.com/oPYtoDPyho6uWK1gDmD9e
Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか
Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか https://d.potato4d.me/entry/20220405-nodejs/ へのアンサーソング。 プログラミング言語としての JavaScript の話をする。 2010年頃、Python 2 でプログラミングを学習した自分にとっては Node.js + CoffeeScript が Better Python だった。 CoffeeScript は当時の JS(ES3~5) に足りない機能を補ってくれて、Python と同じく空白制御のオフサイドルールなのが気に入った。見た目が少しだけ Ruby っぽいので当時全盛だった Rails の人間に訴求するにも有利だった。 Node.js のモジュールシステムである Commonjs は Pytho
Aspidaに感動しちゃった件について - Qiita
/* eslint-disable */ import { AspidaClient, BasicHeaders, dataToURLString } from 'aspida' import { Methods as Methods0 } from './pet' import { Methods as Methods1 } from './pet/_petId@number' import { Methods as Methods2 } from './pet/_petId@number/uploadImage' import { Methods as Methods3 } from './pet/findByStatus' import { Methods as Methods4 } from './store/inventory' import { Methods as Metho
クリエイティブコーディングの教科書
ゲームエンジンや3Dソフトウェアを利用して高度な表現ができるこの時代でも、プリミティブな描画や動き、アルゴリズムから学べることは多い。それらをJavaScriptで書くクリエイティブコーディングという形で学べる手引書が本書となる。
JavaScriptの非同期処理をじっくり理解する (1) 実行モデルとタスクキュー
対象読者と目的 非同期処理の実装方法は知っているが、仕組みを詳しく知らないのでベストプラクティスがわからないときがある 実行順序の保証がよくわからないので自信をもってデプロイできない変更がある より詳しい仕組みを理解することでより計画的な実装をできるようになりたい という動機で書かれた記事です。同様の課題を抱える人を対象読者として想定しています。 目次 実行モデルとタスクキュー Promise async/await AbortSignal, Event, Async Context WHATWG Streams / Node.js Streams (執筆中) 未定 入門記事へのリンク プロミスの使用 - JavaScript | MDN Promise, async/await (現代の JavaScript チュートリアル) JSの初心者にPromiseとasync/awaitの使い方
yarn v3 の独自機能を避けつつ yarn v1 から v3 へのアップグレードをする
yarn v3 が出ました。詳しい解説は譲るとして、esbuild integration や パフォーマンス向上が目玉です。 Yarn 3.0 🚀🤖 Performances, ESBuild, Better Patches, ... - DEV Community 流石に v1 はもう古いが、 v2 からの独自路線は受け付けがたい…という立場なのですが(yarn オリジナル作者の sebmck も難色を示しています)、今回は yarn 特有の機能をできるだけ避けて、できるだけ npm や pnpm 等と互換な部分だけで yarn v3 を使います。なので pnp も使いません。eslint や vscode の typescript 等でハマりどころが多すぎます。 ゼロインストールも否定派です。git blob objects のサイズが爆発して仕事にならなくなったことがあります。
Yarn 3.0 🚀🤖 Performances, ESBuild, Better Patches, ...
Yarn 3.0 🚀🤖 Performances, ESBuild, Better Patches, ... Hello! Long time no see! Back in December, we decided to start working on our next major release, the 3.0. It took a bit of time to do everything we intended to do, but here we are! So let's talk a bit about what it changes, and what it brings. Note that these are only the highlights, the full changelog is much more comprehensive. And if you
木構造の DnD に適した処理を考える
DnD は考えることが多い。大抵のライブラリは特定のユースケースにべったりで、毎回自分で書く羽目になる。 とくに、木構造の DnD をどう表現するかが難しい。特にWeb上でファイラーのようなUIを実装する頻度が高く、その求められる実装が毎回違うので、自分が考えていることを一般化してみる。 この記事はコードをコピペしたら使えるものではなく、あくまで考え方をコードに落としたもの、ということに注意。 今回は前提として、こういうものを作っていた。 DnD の要件 DOM ベースの sortable ライブラリはいっぱいあるが、DOMをマスターデータとして扱うタイプが多く、現代のフレームワークと噛み合わない。可能な限りデータを元に表現して、最後に変更したデータを render するだけとする。 フレームワーク非依存な処理を切り出して、UIを通さずにテストを書いたり、ポータブルに扱えるようにしたい。
【Next.js 11】next/script には JavaScript の基本がつまっていた
修正(2021/06/17) ツイッターでご指摘をいただき、一部修正を加えました🙇 はじめに 2021/06/16 未明に Next.js の新メジャーバージョン v11 がリリースされました。 ほぼ同じタイミングで Next.js Conf (Next.js のカンファレンス)が開催されており、Zenn ユーザの中にはリアルタイムで見ていた人も多いのではないでしょうか。 Core Web Vitals をはじめとした 、パフォーマンス改善に関する話題や新機能が多く、Google のチームが Next.js で最適化のトライを行いながら、Nuxt や Angular に反映していくというのが印象的でした。最先端の取り組みが、普段メインで使用している Next.js で行われているということで、非常に嬉しい限りです。 Next.jd 11 全体のまとめは今後誰かが書いてくれると思いますので
サービスワーカー API - Web API | MDN
サービスワーカーは、基本的にウェブアプリケーション、ブラウザー、そして（もし繋がっていれば）ネットワークの間に介在するプロキシーサーバーのように振る舞います。これは、よりよいオフラインの操作性を可能にするように意図されており、ネットワークのリクエストに介在してネットワークの使用可否の状況に基づいて適切な対応を取ったり、サーバー上にある資産を更新したりします。また、プッシュ通知やバックグラウンド同期の API 群へのアクセスもできるようになります。 サービスワーカーは、あるオリジンとパスに対して登録されたイベント駆動型のワーカーです。 JavaScript ファイルの形を取り、ナビゲーションやリソースへのリクエストを横取りや改変したり細かい粒度でリソースをキャッシュすることで関連付けられたウェブページやサイトを制御し、それぞれの状況（もっとも顕著な例は、ネットワークが利用できないとき）にアプ
JavaScript にイミュータブルな配列操作メソッドを導入するプロポーザルについて
この記事では、現在 Stage 1 のプロポーザル Change Array by copy について解説する。 プロポーザルの詳細については、https://github.com/tc39/proposal-change-array-by-copy を参照してほしい。 また、ここで紹介した仕様に関しては今後更新されていく可能性がある。 概要 Change Array by copy は、簡単にいえばイミュータブルな配列操作メソッドを導入するプロポーザルである。 JavaScript の配列には多くのインスタンスメソッドがあり、それらを使って配列を操作できる。 配列のインスタンスメソッドには、ミュータブルなもの、つまりもとの配列を変更することによって配列を操作するタイプのものがいくつかある。 たとえば、Array.prototype.push や Array.prototype.pop、A
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
外部に依存したコードもテストで駆動する / Test-Driven Architecture - AWS Dev Day Tokyo 2018 - Speaker Deck
Fetch VS Axios | Make Https Requests like a pro.
GitHub - escomplex/escomplex: Software complexity analysis of JavaScript-family abstract syntax trees.
