TypeScript part3

**デフォルトの名無しさん** · 2018/04/26(木) 21:48:23.07

http://www.typescriptlang.org/

JavaScript that scales.
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
Any browser. Any host. Any OS. Open Source.

part1
https://peace.5ch.net/test/read.cgi/tech/1349187527/
part2
https://mevius.5ch.net/test/read.cgi/tech/1430386649/

**デフォルトの名無しさん** · 2019/02/17(日) 16:04:02.49

>>188
> 型の有用性
だから動的型言語にも型はあるし型の有用性を享受してんだけど…何度言っても分からない奴は分からないんだな

**デフォルトの名無しさん** · 2019/02/17(日) 16:11:02.99

そんな誰でもわかってることで得意げになってるのが恥ずかしい
一合目で山に登ったつもりになってる感じ
みんなもっと上にいるから！

**デフォルトの名無しさん** · 2019/02/18(月) 11:46:04.18

動的型と静的型では型の目的が違うことを理解していないらしいな

**デフォルトの名無しさん** · 2019/02/18(月) 23:46:52.94

昔は動的型付け言語と静的型付け言語って対義語みたいに思ってたけど、
TypeScriptやってみたら単純な二元論じゃないって気付かされた。

**デフォルトの名無しさん** · 2019/02/19(火) 21:50:14.71

そう対義語じゃない、分かりやすい表現だなぁ
本当に型が無いのはアセンブリ言語で、全てが整数になっててそれをどう解釈するかは本当に人間次第だからな

**デフォルトの名無しさん** · 2019/02/20(水) 19:06:49.04

Cのunionもそういう意味では何でもあり

**デフォルトの名無しさん** · 2019/02/20(水) 19:08:18.41

そういうのを昔の人は「型あって型なし」と言ったのだ

**デフォルトの名無しさん** · 2019/02/21(木) 14:36:31.18

同じファイルの書き込み処理なんかをRubyが5行で書けて、Javaが15行とかで書いて、いかにJavaが駄目かってブログ記事がはてなブックマークとかでよくバズってたな
声のでかい人はいつでもいる

**デフォルトの名無しさん** · 2019/02/22(金) 14:01:01.67

るｂｙなら一行で描かないと負け

**デフォルトの名無しさん** · 2019/02/23(土) 02:18:28.49

Javascriptのthisというか変数スコープが厄介でHaxeやってるけど
Typescriptはその辺の問題点引き継いでる？

**デフォルトの名無しさん** · 2019/02/23(土) 03:19:51.50

「thisというか変数スコープ」？
分かってないことは分かった。
お前はどの言語やっても大成しない。

**デフォルトの名無しさん** · 2019/02/23(土) 08:32:08.65

JavaScript(JS)/TypeScript(TS) のthis は、おかしい！
一方、jQuery, Haxe は、それを修正してる

また、JS/TS の== は危険だから、使っちゃいけない！
厳密等価演算子=== を使うべき！
一方、Haxe, Ruby は、== でOK

Haxe には、マクロ、引数つき列挙(enum)、代数的データ型、パターンマッチ、マルチプラットフォームがあるけど、TS には無い。

特に、switch 文での、enum が強力！
引数の型で分岐できるから、インタフェースと同等！

このサイトで、ブラウザでプログラミングして、実行できる
Try Haxe !
try.haxe.org/

Haxeプログラミング入門、尾野政樹、2015

Haxe は、Elixir に似てね？
プログラミングElixir、2016

**デフォルトの名無しさん** · 2019/02/23(土) 10:27:04.01

thisや==は今ならeslint/tslint任せでほとんど問題ないね。
引数付きenumはようはUnion Typeだし、代数的データ型はTagged Union Typeかな。
パターンマッチそのものはないけどType Guardで似たようなことができる。
マクロとマルチプラットフォームはさすがにないな。

**デフォルトの名無しさん** · 2019/02/23(土) 11:20:14.57

haxe？ああtsに負けて滅んだ言語かｗ

**デフォルトの名無しさん** · 2019/02/23(土) 11:24:28.53

弊社、ガイジが導入したhaxeが完全な負の遺産化しててうんざりするわ
死ねとまでは思わないけど、産まれてこなければよかったのに

**デフォルトの名無しさん** · 2019/02/23(土) 11:27:21.05

thisはそもそも使う必要がない
jQueryとか昔のライブラリを使うとthisを使わざるを得なくなって混乱する
変数スコープの問題は多分変数の巻き上げの事だと思うけど、TypeScriptは変数を宣言する前にアクセスはエラーだから変数スコープの問題は無い

**デフォルトの名無しさん** · 2019/02/23(土) 12:07:09.04

言語でマルチプラットフォームってどゆこと？

**デフォルトの名無しさん** · 2019/02/24(日) 19:32:04.72

一般にバイナリ互換のこと。
スクリプト言語はソースコード=バイナリ扱いだが。

Qtとかのライブラリはソース互換やね。
そのライブラリと標準ライブラリ使う分にはマルチプラットフォーム。

**デフォルトの名無しさん** · 2019/03/27(水) 22:29:10.88

TypeScriptのリテラル型を知って目から鱗だったんだけど、元ネタってどこなのかな？
TypeScript以前に採用していた言語とかある？

**デフォルトの名無しさん** · 2019/03/28(木) 08:22:20.68

https://www.infoq.com/jp/news/2019/03/typescript-3-3-release

Flowは，少なくともこの分析を実施した1年前には，Facebookによって極めて閉鎖的な方法で進められていた言語です。
開発はまったく透過的ではなく，ロードマップも公開されていませんでした。
プロジェクトへのコントリビューションは，Facebook以外からはほとんどありませんでした。
対照的にTypeScriptは，数年前にGitHubに移動して以降はオープンソース開発を採用しています。
最新のロードマップを公開し，外部からのコントリビューションを受け入れ，全般的にコミュニティとの密接な関係を維持しています。

Flowオープンソースはほぼ放置されているので，現時点ではTypeScriptに切り替えた方がよいと思います。

このような懸念に対してFlowチームは，現在の進捗状況と2019年計画の見直しによる対処を始めている。
この概要の中で，FacebookのソフトウェアエンジニアであるAvik Chaudhuri氏は，FlowからTypeScriptへの移行について取り上げている。

　最近，Facebookを起源とするオープンソースプロジェクトの多くが，TypeScriptでのリライト計画を発表しています。
　Facebookでは個々のチームの独立性を強く尊重しており，各チームがロードマップを作成し，
　開発中のプロダクトに対して最大限の努力を払っています。TypeScriptへの切り替えを決定したプロジェクトは，
　この切り替えによって外部コントリビュータによる支援をより多く受けられるようになります。私たちはこの決定を尊重します。

**デフォルトの名無しさん** · 2019/03/31(日) 08:32:04.33

Announcing TypeScript 3.4
https://devblogs.microsoft.com/typescript/announcing-typescript-3-4/

**デフォルトの名無しさん** · 2019/04/27(土) 22:21:18.33

export default Vue;
export as namespace Vue;

型定義が↑だとjsのスクリプトモード(import なし)で↓のようにvscode認識してしまって悲しい
new Vue(); 　　　　　// NG
new Vue.default(); // OK

export default Vue じゃなくて export = Vue なら大丈夫っぽいんだが

**デフォルトの名無しさん** · 2019/04/27(土) 23:00:39.62

Vueなんてゴミ使ってるのが悪い

**デフォルトの名無しさん** · 2019/05/07(火) 14:32:47.27

質問なんですが、

interface TypeMap<T> {
　a: number
　b: string
　c: T
}

declare function test<T, K extends keyof TypeMap<T>>(arg: K): TypeMap<T>[K]

test("b")
test<number, "c">("c")
↑
これをtest<number>("c")って書けるfunction testの定義の仕方ってあります？

**デフォルトの名無しさん** · 2019/05/10(金) 03:36:53.56

ついにunion distributionを理解してしまった

**デフォルトの名無しさん** · 2019/05/20(月) 18:15:00.44

TS3のunknown型いいな。
てかany入れずに最初からこれにしとけや。

**デフォルトの名無しさん** · 2019/05/20(月) 23:15:37.00

esの上位互換である以上anyは無きゃいかんだろう。

**デフォルトの名無しさん** · 2019/05/22(水) 08:13:28.81

unknownからの簡単にキャストできるような値ばかりなら、確かにanyはいらんかったろうな

**デフォルトの名無しさん** · 2019/05/30(木) 08:25:00.89

Announcing TypeScript 3.5
https://devblogs.microsoft.com/typescript/announcing-typescript-3-5/

**デフォルトの名無しさん** · 2019/05/31(金) 23:01:09.01

TSも知らんフロントエンドエンジニアとか死んでほしいわ

**デフォルトの名無しさん** · 2019/06/01(土) 00:45:31.22

知ってるだけでデカい顔してるフロントエンドエンジニアも死んで欲しいわ

**デフォルトの名無しさん** · 2019/06/01(土) 16:36:48.07

ts知ってるだけででかい面できるってどんな現場だよ

**デフォルトの名無しさん** · 2019/06/01(土) 19:04:47.55

それくらい世界はまだJSの悲しみに満ちているってことさ
救ってあげようよ、僕らで

**デフォルトの名無しさん** · 2019/06/01(土) 19:52:58.38

お前だれだよ

**デフォルトの名無しさん** · 2019/06/01(土) 20:56:08.22

strictNullChecksをtureにしてる人いる？？

ロジックではnull禁止できるけどさ、
dbからgetしたデータに混じるんだよね。
未入力状態のデータって奴。

null撲滅マスターの方は、どう解決してるの？？

**デフォルトの名無しさん** · 2019/06/01(土) 20:58:48.44

それはDBの設計が腐ってるし、unknown | null型なんだろ
ロジックが間違ってる

**デフォルトの名無しさん** · 2019/06/02(日) 11:14:24.16

そもそも、実行時にnullやundefinedが混じるという話とstrictNullChecksに直接の関係はないだろ。
その中間のどこかで困っているんだろうけど、それがわからないとなんとも。

**デフォルトの名無しさん** · 2019/06/02(日) 11:38:18.31

nullableなfieldをgetしたらそりゃnullableでしょ

**デフォルトの名無しさん** · 2019/06/05(水) 02:53:11.94

Visual Studio Code でAngularの勉強をしているのですが、
TypeScriptのthisがどこのコードを参照しているのかイマイチ理解できていません。
このthisをマウスオーバーしたら参照先のコードを表示してくれる拡張機能はありませんか・・・？
現状ですとthisにマウスオーバーをすると this:this と表示されます

**デフォルトの名無しさん** · 2019/06/05(水) 08:05:19.27

Angular自体糞だからやめとけ

**デフォルトの名無しさん** · 2019/06/05(水) 08:30:28.74

vueをやるんだ

**デフォルトの名無しさん** · 2019/06/07(金) 22:14:26.23

みんな、質問。

TSって公式のスタイルガイド無いけど、
みんな何使ってる？
正直googleのは末尾カンマが受け付けない。。

**デフォルトの名無しさん** · 2019/06/07(金) 22:21:16.75

prettierで終わり
受け付けないもクソもない
おまえのスタイルは全てクソで、prettierを信じろ

**デフォルトの名無しさん** · 2019/06/10(月) 00:34:38.75

>>231
設定は？？
信じていいprettierはデフォ設定でOKなの？

**デフォルトの名無しさん** · 2019/06/10(月) 07:11:15.54

>>232
デフォと言いたいが

arrowParens: "always",
semi: false,
trailingComma: "es5",

のみ付けるのが多い（気がする）

**デフォルトの名無しさん** · 2019/06/10(月) 07:12:37.13

semi: false,
だけは本当に極稀に問題になるから、設定しなくてもいい
目障りだから俺は設定するけどね

**デフォルトの名無しさん** · 2019/06/13(木) 17:34:43.34

>>233, 234
ありがとう！試してみる！

**デフォルトの名無しさん** · 2019/06/15(土) 19:57:13.61

const x = { a: 'b' };

この x の型は { a: string } になってしまうみたいだけど、 { a: 'b' } 型にする方法ってないんでしたっけ？
TypeScript 3.5です。

**デフォルトの名無しさん** · 2019/06/15(土) 20:04:24.55

const x: { a:'b' } = { a: 'b' };

**デフォルトの名無しさん** · 2019/06/15(土) 20:10:32.39

const x = { a: 'b' as 'b' }; もいけるみたいだけど冗長だなぁ。

**デフォルトの名無しさん** · 2019/06/15(土) 20:14:03.78

as const

**デフォルトの名無しさん** · 2019/06/15(土) 20:32:57.50

>>239
ありがとう！これだ。

**デフォルトの名無しさん** · 2019/06/15(土) 22:08:42.82

デフォルトで全部 as const にするオプションとかあればいいのに

**デフォルトの名無しさん** · 2019/06/21(金) 19:39:39.40

今日の疲れやばい

**デフォルトの名無しさん** · 2019/06/21(金) 19:42:13.96

anyを許すルールにするっつったら
「でもapiからくる値なら全て型定義できますよね？」
って言われたことにものすごい疲れた
完璧なappなんかねーんだよ！！！ってキレそうだったわ

**デフォルトの名無しさん** · 2019/06/21(金) 19:42:54.97

一生インターフェース書いてろ！

**デフォルトの名無しさん** · 2019/06/22(土) 13:59:29.40

そこでunkownですよ

**デフォルトの名無しさん** · 2019/06/22(土) 14:09:53.49

unknown確か途中で足されたよな。最初から入れとけおもた。

**デフォルトの名無しさん** · 2019/06/22(土) 15:50:14.82

みんあなはallow any 派？

**デフォルトの名無しさん** · 2019/06/22(土) 18:02:27.27

>>247
許容派です。
再帰処理とかをまともに型付してたら、辛すぎる。。

ちなみに
const arr = []
で、never[]型になるのがしんどい。

設定でany[]型にならないでしょうか・・？

**デフォルトの名無しさん** · 2019/06/22(土) 20:42:33.24

明示的に型を書けばいいじゃん

**デフォルトの名無しさん** · 2019/06/22(土) 22:04:34.45

てかリテラルの [] が never[] になんかなる？

**デフォルトの名無しさん** · 2019/06/23(日) 13:58:34.11

eslint が v6.0.0 になったら @typescript-eslint/parser が読み込めなくなった
とりあえず issue をみて ./node_modules/@typescript-eslint/parser/dist/parser.js で

require("eslint/lib/util/traverser")
↓
require("eslint/lib/shared/traverser")

でやり過ごしてる

**デフォルトの名無しさん** · 2019/06/24(月) 11:41:32.01

この研究によるとTypeScriptは最もバグ発生率が低い言語なんだけどその理由とか体感とかありますか？
https://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf
>TypeScript －1.32 (0.40)∗∗ －2.15 (0.98)∗ －1.34 (0.41)∗∗ －0.34 (0.07)∗∗∗

**デフォルトの名無しさん** · 2019/06/24(月) 11:46:37.72

コンパイラにバグが無い
コンパイル中にコードのバグは発見出来る
アルゴリズムのバグは知らんがな

**デフォルトの名無しさん** · 2019/06/24(月) 21:38:49.72

TypeScriptで書いたプロダクトにバグが少ないのか、TypeScriptコンパイラにバグが少ないのか、どっちよ？

**デフォルトの名無しさん** · 2019/06/24(月) 21:39:48.85

あと今土器pdfなんかで出すなよボケカス
日本語翻訳使えないだろが

**デフォルトの名無しさん** · 2019/06/24(月) 21:52:09.72

TS >>> JS
という話なら圧倒的同意しかないのだが
https://www.reddit.com/r/typescript/comments/aofcik/38_of_bugs_at_airbnb_could_have_been_prevented_by/
他の言語と比べてどうこうはわからん

あと動的型無し糞言語がゴミというのも同意

**デフォルトの名無しさん** · 2019/06/25(火) 18:21:53.19

>>254
TSで書かれたソフトウェアにバグが少ない
そのPDFによれば調査対象のメジャーな10種くらいの言語の中で最も少ない

**デフォルトの名無しさん** · 2019/06/25(火) 20:19:43.86

C#と大して変わらんのにバグが少なくなるって根拠がよく分からん
JavaScript上がりのプログラマが使うことが多いから良く訓練されているってのが考えられる根拠だなw

**デフォルトの名無しさん** · 2019/06/25(火) 23:32:40.42

ユーザのリテラシが高いが後押ししてるのはありえそうだな

phpあたりは言語もユーザもガイジだからかわいそう

**デフォルトの名無しさん** · 2019/06/26(水) 00:17:43.45

JavaScriptは初心者が触るには最悪の言語と言っても過言ではないないから、ありとあらゆるバグを出して大変な目に遭ったプログラマがTypeScriptを使うことになると、バグも少なくなるだろうなという意味だよ

**デフォルトの名無しさん** · 2019/06/26(水) 00:40:51.84

つか論文？の表の見方がわからんのだが

**デフォルトの名無しさん** · 2019/06/26(水) 00:41:37.75

よくよく読んだら、ほんとは一番バグが多かったとかいうオチ？？

**デフォルトの名無しさん** · 2019/06/26(水) 00:45:17.97

スレッドがないとかポインタがないとかでできないことがある分バグも減るでしょ

**デフォルトの名無しさん** · 2019/06/26(水) 00:49:58.46

>>263
できないことだらけにしたGoさんはどうなりましたか・・・？

**デフォルトの名無しさん** · 2019/06/26(水) 09:13:51.70

このスレの住人なら当然ターミナルはコレだよな！

Terminus - TypeScript製のターミナル
https://www.moongift.jp/2019/06/terminus-typescript%E8%A3%BD%E3%81%AE%E3%82%BF%E3%83%BC%E3%83%9F%E3%83%8A%E3%83%AB

**デフォルトの名無しさん** · 2019/06/26(水) 12:25:57.23

>>264
Ｗｅｂ画面なんて壊れてても気にしないからコミット取り消さないし
そもそも画面実装とかサーバに比べて問題の範囲が限定的でたいして難しくないだろ
最初から扱ってる問題が言語ごとにちがうんだ
この表ってか論文で一緒にしてるのおかしい

あ、型なし言語はあかんと思います

**デフォルトの名無しさん** · 2019/06/26(水) 16:21:39.07

確かにCとかC++は基礎的なソフトに使われるから
僅かなバグも絶対に許されないとこありそう
それ以外にポインタ使ってるからってのもあるだろうけど

**デフォルトの名無しさん** · 2019/06/29(土) 10:08:56.36

>>266
動画の新しいエンコーダ作るとか、プログラムじゃなくて数学のレベルを求められる仕事は置いといて、

webならフロントの方がよっぽど複雑じゃない？
バックなんて同期処理でお決まりのレールに乗ってダラダラ書いてくだけだし。

複雑でパフォーマンスが要求されるpwaとか、typescript無かったら絶対に完成する気しないわ。
カオス過ぎる

**デフォルトの名無しさん** · 2019/06/29(土) 10:25:06.32

js/tsだけどダイアログとか出すときに
モードレスにした方がユーザーには使い易いのに
バグが増えそうだからモードレス禁止ってことで
全部モーダルで造らされたことがある

**デフォルトの名無しさん** · 2019/06/29(土) 19:29:55.34

型の判定の正しい手順ってどうだっけ？5行目で引っかかってしまう。

function isMyType(o: unknown): o is MyType {
if (typeof o !== 'object') { return false; }
if (!o) { return false; }
if (!('key' in o)) { return false; }
if (!o.key) { return false; } // ts7053
return true;
}

**デフォルトの名無しさん** · 2019/06/29(土) 23:44:35.08

ひえっ…
typescript使う意味あるのこれ

**デフォルトの名無しさん** · 2019/06/30(日) 01:10:38.25

そりゃTypeScriptだって魔法じゃないんだから。
すごいのは外部から渡された得体の知れない値をこうやって動的に型判定して
それを静的な型の世界に持ち込めるところ。

**デフォルトの名無しさん** · 2019/06/30(日) 01:36:24.68

ts知らないけど処理系がロード済みの型一覧を取得できないの

**デフォルトの名無しさん** · 2019/06/30(日) 02:09:58.63

unknownじゃなくてanyでいいでしょ

**デフォルトの名無しさん** · 2019/07/01(月) 22:30:11.88

>>270
この返り値、なんていう記法？
というか、なぜこんな書き方が必要なの？

**デフォルトの名無しさん** · 2019/07/01(月) 23:18:57.13

user defined type guard function でググれ。

**デフォルトの名無しさん** · 2019/07/02(火) 04:58:55.57

>>269
jQuery, jQuery UI のダイアログを使えば？

モーダルが多いような気がする

**デフォルトの名無しさん** · 2019/07/03(水) 22:40:20.89

>>276
それだけで理解した
なるサンクス

**デフォルトの名無しさん** · 2019/07/07(日) 08:52:11.33

/* eslint-disable @typescript-eslint/explicit-function-return-type */
const mapDispatchToProps = (dispatch: TodoAsyncDispatch) => {
return {
fetchTodo: (id: TodoId) =>
dispatch(todoAsyncRequestActions.fetchTodoRequest({ id })),
}
}
/* eslint-enable */

type ReduxDispatchProps = ReturnType<typeof mapDispatchToProps>

---

これをeslint-disableなしで実装する方法ってないですか？
例えば、↓こんな感じで「any」の部分が「型推論させる型」みたいにできる、とか。
redux-thunkの型付けが難しいお・・・

---

type MDTP = (dispatch: TodoAsyncDispatch) => any

const mapDispatchToProps2: MDTP = (dispatch) => {
return {
fetchTodo: (id: TodoId) =>
dispatch(todoAsyncRequestActions.fetchTodoRequest({ id })),
}
}
type ReduxDispatchProps2 = ReturnType<typeof mapDispatchToProps2>

**デフォルトの名無しさん** · 2019/07/07(日) 09:34:19.15

その暗黙の推論を禁止するルールなんだから普通に考えたら無いよね。
型付けが難しい場合があるのはわかるけど、eslint-disableじゃだめな理由は？
全体として入れているチェックの例外を設けるなら後からその箇所がわかるように
しておかなきゃ困ると思うが。

**デフォルトの名無しさん** · 2019/07/07(日) 10:04:05.70

ジャネリック

**デフォルトの名無しさん** · 2019/07/07(日) 10:24:01.49

>>280
型付け自体はそう難しくはないんだが、この2重定義感がだるくて。
mapDispatchToPropsに型ちゃんと書いてそこに集約したいというか。

---

type ReduxDispatchProps = {
fetchTodo: (id: TodoId) => Promise<void>
}

const mapDispatchToProps = (
dispatch: TodoAsyncDispatch
): ReduxDispatchProps => {
return {
fetchTodo: (id) =>
dispatch(todoAsyncRequestActions.fetchTodoRequest({ id })),
}
}

---

> eslint-disableじゃだめな理由
mapDispatchToProps は書く頻度が高いから、あまり eslint-disable を撒き散らしたくない
とはいえ普通の function で explicit-function-return-type を false にしたくない
というお気持ち

やっぱ無理ッスかね

**デフォルトの名無しさん** · 2019/07/07(日) 10:37:01.72

>>281
どう書けばできそうですか？

**デフォルトの名無しさん** · 2019/07/07(日) 11:45:51.89

{ allowExpressions: true }

**デフォルトの名無しさん** · 2019/07/07(日) 13:32:44.90

>>284
既にこれで設定してます

---
"@typescript-eslint/explicit-function-return-type": [
"error",
{
allowExpressions: true,
allowTypedFunctionExpressions: true,
},
],
---

**デフォルトの名無しさん** · 2019/07/10(水) 01:53:27.81

Nest.js使ってサーバサイドもts使ってる人いる？

**デフォルトの名無しさん** · 2019/07/17(水) 21:56:07.81

むしろ整合性が求められるサーバーサイドでこそ活躍する

**デフォルトの名無しさん** · 2019/07/17(水) 23:22:52.24

TSerならdenoでない？