イベントループと TypeScript の型から理解する非同期処理
この本は、ブルーベリー本の 8 章からインスパイアされて、 TS の型が示す情報から Promise というものを理解してみる、というアプローチで書いたJSの非同期処理の解説です。 これらの資料と合わせて読むことを推奨します。 JSのイベントループのイメージを掴む JSでは中々意識することが少ないですが、正しく理解するには OS レベルのスレッドの視点で考え始める必要があります。 ブラウザや Node.js では一つのスクリプト実行単位を1つのスレッドに割り当てます。それをメインスレッドと呼んだり、ブラウザだったら UI スレッドと呼んだりします。 例えばブラウザでは、これは秒間60回、つまり 16.6ms ごとにループを呼び出します。(node だったらこれがもっと短いです) 仮に setTimeout の実装がなかったとして、それ相当の擬似コードを書くのを試みます。 let handl
急なTypeScript案件🔥最初の30日間に使い倒したい「コードリーディング支援ツール」 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この投稿では、「TypeScriptの文法や用語がよく分からない」という問題を解消してくれそうなツールを紹介します。 勉強しながらの見切り発車 最近はTypeScript未経験でも、TypeScript案件にアサインされることが増えてきているように思います。 運がいいと着手前にTypeScriptをじっくり学習する時間を与えられることがあります。しかし、多くのケースでは、見切り発車で開発に参加するのではないでしょうか。 コードリーディングから始まる TypeScript案件は、理解すべき既存のTypeScript/JavaScriptコ
TypeScript 4.5でますます便利に！ better-typescript-lib v2
今日リリースされた TypeScript 4.5 Beta の新機能として、標準ライブラリの差し替えが従来よりも簡単になるというものがあります。 筆者は TypeScript の標準ライブラリからanyを排除してより安全にしたbetter-typescript-libを開発していましたが、このたび TypeScript 4.5 に対応した v2.0.0 のベータ版を用意しました（2.0.0-beta）。 この記事では better-typescript-lib の簡単な紹介に加えて、TypeScript 4.5 の機能の解説やそれによって better-typescript-lib に起こった変化を紹介します。 better-typescript-lib について better-typescript-lib は、TypeScript の標準ライブラリをより型安全にしたものです。better
TypeScriptの導入にあたって考慮すべきメリットとコスト
皆さんこんにちは。京都開発室のLinです。仕事と個人的なプロジェクトでTypeScriptによる開発を始めて約2年が経ちましたので、 TypeScript導入時の経験を皆さんにお話ししたいと思います。 近年、TypeScriptはフロントエンド分野で最も注目を集める技術となっています。The State of JavaScriptの資料によれば、TypeScriptの使用を選択する開発者は増加を続けており、その評価も肯定的なものが多いようです。 「次のプロジェクトではTypeScriptにより開発を行うべきだ」「今あるJavaScriptプロジェクトをTypeScript仕様に変更すれば、プロジェクト品質の向上につながる」と考えているチームは数多くあるでしょう。 しかしながら、TypeScript導入のコストおよびメリットについては、極めて慎重に評価を行う必要があると、私は考えています。
Promiseをthrowするのはなぜ天才的デザインなのか - Qiita
ReactのConcurrent Modeが最初に発表されたのはもう1年近くも前のことです（記事執筆時点1）。Concurrent Modeはたいへん奥深い機能で正式版がたいへん待ち遠しいですが、Concurrent Modeの代名詞として多くのReactユーザーに知られているのはPromiseをthrowするというAPIデザインです。Concurrent Modeでは、コンポーネントがレンダリング時にPromiseをthrowすることで、レンダリングをサスペンドした（Promiseが解決されるまでレンダリングできない）ことを表します。 Concurrent Modeに関しては筆者の既存記事Concurrent Mode時代のReact設計論 (1) Concurrent Modeにおける非同期処理などをご参照いただきたいのですが、ここではPromiseをthrowするということ自体に焦点
大統一 Node ツールチェイン Rome の野望 現状の実装
つい先日 beta リリースされたフロントエンドのツールチェインの Rome について、その思想とコードを読んだ結果の現状について。 Rome Frontend Toolchain この記事は公式ドキュメント以外にもソースを読んで得られた undocumented な部分も含んでいるので、すぐ古くなる。その前提で読むように。 問題の認識とその解決手段 フロントエンドの最適化は実行前のプリプロセスに、エコシステムの開発リソースの多くが当てられている。Node のツールチェインが発達するにつれて、自前の パーサ+AST 定義を持つ実装が増えていった歴史がある。 acorn(estree) babel prettier typescript terser それぞれのツールの生成する AST はそのツールの都合で微妙に/もしくは大幅に定義がずれている。typescript に至っては完全に別物。こ
TypeScriptのenumを使わないほうがいい理由を、Tree-shakingの観点で紹介します
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog こんにちは。LINE Growth Technology UITチームの慶島(@pittanko_pta)です。 この記事では、TypeScriptのenumを使わないほうがいい理由を、Tree-shakingの観点で紹介します。 検証環境 TypeScriptからJavaScriptへのトランスパイルは https://www.typescriptlang.org/play (TypeScript 3.9.2 / targetはESNext) で行いました。 Tree-shaking の挙動については https://rollupjs.org/repl/ にトランスパイルしたJavaScriptコードを貼り付けて検証しました
なぜ default export を使うべきではないのか？
プロジェクトで使われている技術と ESModule の状況について UIT では、 SPA 開発のプロジェクトにおいて Vue.js と React が多く利用されており、既存の多くは Babel を利用した JavaScript で、新規のプロジェクトでは TypeScript を利用して開発が行われています。 FYI: 【LINE DEV DAY 2019 番外編】UIT Front-end Tooling Survey 2019 技術選定は勿論、プロジェクトにおける細かなコーディングルールについては、プロジェクトのコードオーナーに委ねられており、プロジェクトごとに裁量を持った意思決定を行っています。 その上で、私が携わるプロジェクトにおいては、 default export を可能な限り避けるように心がけています。 import 側の裁量で対象を自由に命名できてしまう 今回は「『Da
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
この TypeScript が Hello, world! のくせに慎重すぎる - Qiita