おまえら禁じられたインデックスアクセスを平気で使ってんじゃねえか！わかってんのか？『ランタイムエラー』が生まれたのは人間がコンパイラオプションに甘えたせいだろうがよ！
おまえら禁じられたインデックスアクセスを平気で使ってんじゃねえか！わかってんのか？『ランタイムエラー』が生まれたのは人間がコンパイラオプションに甘えたせいだろうがよ！ 2022.06.25 TypeScript 4.1 から noUncheckedIndexedAccess オプションが追加されました。このオプションは上記のような配列のアクセスやオブジェクトのプロパティのアクセスをより厳密にします。 具体的には、配列に対するインデックスアクセスやインデックスシグネチャを通じたプロパティのアクセスは常に `undefined` とのユニオン型となります。
Typescript では !! と Boolean() が完全に同じ動作ではない
🌼 はじめに 皆さんは Javascript である値を boolean に変換するときどういう方法も使いますか？よく使われる方法は!!（二重否定・Double negation）か、Boolean()だと思います。 const hello = Boolean("hello"); // true const world = !!"world" // true Typescript のハンドブックでもその２つを紹介してます。 You can always coerce values to booleans by running them through the Boolean function, or by using the shorter double-Boolean negation. いちおう型の観点では、!!を使ったら型がtrueかfalseになり、Boolean()関数を使った
「ここにあるJavaScript、全部TypeScriptにして」案件が勃発したのですがどうすればいいですか？
よんてんごP @yontengoP 「ここにあるJavaScript、 全部TypeScriptにして、 何故ならその方がカッコいいから」案件が 先日から勃発したのですが 有識者各位、JS⇒TSの置き換えって 何から始めればいいですか (´・ω・`)<僕はまず技術書を買わないとアカンかと思っています 2022-05-29 23:05:19
Falsy値を比較せずにそのまま判定に使うことはやめよう
…という話を現場でしました。 こんにちは、クレスウェア株式会社の奥野賢太郎 ( @okunokentaro ) です。TypeScript をお使いのみなさんは、Falsy 値（フォルシーち）というものをご存知ですか。TypeScript や JavaScript を長年使っている読者であれば「そんなもの常識だろう」となるかもしれませんが、TypeScript からの入門者だったり、他言語から TypeScript へ移ってきたような「JavaScript 未経験の TypeScript 経験者」が近年現れ始めており、筆者には案外これが常識とも言い切れなくなっているという感覚があります。 この Falsy 値、もちろん知っているに越したことはないかもしれませんが、TypeScript 全盛となったこの時代にただでさえ他に覚えるべきことが多いなか、果たしてこれはずっと常識のままなのでしょうか
any、またお前か——配列とhomomorphic mapped typeの罠
TypeScriptは企業によって開発されてはいるもののなかなか大きなOSSの一つであり、openなissueの数はこの前5,000を超えました。日々いくつものissueが作られ、そして一部は閉じられていきます。TypeScriptはなかなか大きなOSSですから、issueが閉じられなかったとしても厳しい行く末を迎えるものは多くあります。TypeScriptチームが興味をそそられなかったならば、提案はSuggestionラベルとAwait More Feedbackラベルが与えられ、たとえ100を超える👍を得ようとも、奇跡でも起きなければ二度と掘り起こされることはありません（奇跡というのは、数年後にAndersさんが気まぐれにTypeScriptのおもしろい新機能を実装してそのついでに解決されるといったことを指します）。また、バグに関しても喫緊でないものはbugラベルをつけられてBack
TypeScript 4.2 と 4.3 で起こった“最弱の更新”
TypeScript 4.3 の RC が先日登場し、正式リリースが近づいてきていますね。そこで、この記事では TypeScript 4.2 から 4.3 にかけて発生した“最弱の更新”とも言える出来事、そしてそれによって起こったベストプラクティスの変化を紹介します。 TypeScript 4.2 でコンストラクトシグネチャの abstract 修飾子の追加 コンストラクトシグネチャ (construct signature) とは、コンストラクタ、すなわち「newできる関数」を表す型システム上の概念です。TypeScript 4.2 からは、コンストラクトシグネチャにabstract修飾子を付けることができるようになりました。 // 普通のコンストラクトシグネチャを持つ関数オブジェクト declare const foo: new (arg: number) => unknown; co
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するということ自体に焦点
TypeScript地獄の地図と幻の型たち - Qiita
初学者がTypeScriptを始めようとするのなら、おそらくはどこかしらの解説記事をみることになるだろう。ところがTypeScriptは迷宮の入り口なのである。知らずに進めば、GPSもコンパスも役に立たない永劫の樹海を彷徨うことになるだろう。 まずは入り口でこう問われることになる 『おぬしの進むべき道は、前か後ろか？』 大抵の人間はこう答えるだろう。 「もちろん前に進む、そのために来たのだ！」 その答えに対して、再び問われる。 『ふむ、まあ良いだろう。では次の問いだ。おぬしは環境を重んじるか？』 大半の人間にはその意味が分からない。しかし分からないままこう答える。 「環境は良い方がいいなぁ」 気がついたらフロントエンドでエコシステムをぶん回して、わけも分からずWebPackを設定する結果となる。この時点で、TypeScriptをまともに動かすための設定地獄が始まるのだ。 初学者がTypeS
Rubyの型定義ファイルを中央repoにしないほうがいい理由 - Islands in the byte stream
あるいは私がDefinitelyTyped (DT) が失敗だと思っている理由、です。 DefinitelyTypedは明確に失敗だと思っているので、あれを避けるのはそんなに難しくないかなと。まず (1) anyを認めて「型がなくてもいいや」という気持ちでいく (2) 中央repoは作らずそれぞれのgemに対して型定義パッチをおくりつける でなんとかなるっしょ。— FUJI Goro (@__gfx__) September 19, 2017 あたりが話の発端です。 DTについては以前いまいちイケてない理由を書いたことがあります。 TypeScriptのDefinitelyTypedは「ダメでもともと、うまく使えればラッキー」くらいの距離感がよい - Islands in the byte stream この時の話を一言でまとめると「ライブラリの作者ではない第三者がメンテしていることが多く
マイクロソフト、「TypeScript 2.3」をリリース。コメント付きJavaScriptをTypeScriptで型チェック可能に
マイクロソフト、「TypeScript 2.3」をリリース。コメント付きJavaScriptをTypeScriptで型チェック可能に マイクロソフトは「TypeScript 2.3」のリリースを発表しました。 TypeScript 2.3では、JavaScriptファイルにコメントを記述することでTypeScriptによる型チェックなどを行える機能が追加されました。これにより、明示的にTypeScriptのファイルを記述しなくともTypeScriptの利点をすぐに得られるようになったとマイクロソフトは説明しています。 具体的には、JavaScriptの先頭にコメントとして「@ts-check」と記入し、TypeScriptによるチェックを受け入れる旨を宣言。さらにJSDocの形式のコメントを記述することで型を宣言します。 // @ts-check /** * @param {string}
クラスライブラリ・プロジェクトでTypeScriptのコンパイルを行うようにする設定 - きよくらの備忘録
Visual Studio 2013にて、クラスライブラリ・プロジェクトに追加したTypeScriptファイルを、ファイル保存時やビルド時にコンパイルするために必要な設定についてのメモ。 クラスライブラリ・プロジェクトの場合、そのままではTypeScriptファイルを追加してもコンパイルを行ってくれません*1*2。保存時やプロジェクトのビルド時にTypeScriptもコンパイルするには、プロジェクトファイルを編集する等の対応が必要になります*3。 プロジェクトファイル（*.csproj）の編集箇所 プロパティーのImportを追記 該当のクラスライブラリプロジェクトのプロジェクトファイル（例：SampleClassLib.csproj）のProject要素の直下に、以下のImportを追加します。 <Import Project="$(MSBuildExtensionsPath32)\Mi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
