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/09/19(木) 17:24:02.70

ksk

**デフォルトの名無しさん** · 2019/09/19(木) 22:29:49.45

>>323
すでにTSはNull安全なんですがそれは

**デフォルトの名無しさん** · 2019/09/19(木) 22:33:00.75

TypeScript 3.7 Iteration Plan
ttps://github.com/microsoft/TypeScript/issues/33352

- Optional Chaining
- Nullish Coalescing
- Assertion Signatures
- Recursive Type References
- ECMAScript Private Fields
- Top-Level await

つよい

**デフォルトの名無しさん** · 2019/09/19(木) 22:50:14.26

>>326
Microsoftの本気

**デフォルトの名無しさん** · 2019/09/19(木) 23:08:15.80

TSあやうし！　　（笑）

**デフォルトの名無しさん** · 2019/09/29(日) 01:47:49.36

>>326
Recursive Type References
こんなん出来るのか？

再帰はanyで逃げてたわ。

**デフォルトの名無しさん** · 2019/10/04(金) 15:53:59.79

ktkr
https://forest.watch.impress.co.jp/docs/news/1210897.html

**デフォルトの名無しさん** · 2019/10/04(金) 21:06:33.10

>>330
いや、必要なのはパッチじゃなくて、明示的なdeprecatedだろ。

MSは全ての官公庁に対して、blinkのブラウザーを強制させるべき。

ゴミ政治家じゃ無理なので、MSがやれ。

黒船代行料として10兆払っても惜しくない。

**デフォルトの名無しさん** · 2019/10/06(日) 16:12:20.74

Object の OR を自動判別ってできないのかな？
下のURLは、TypeScript Playgroundで書いてみたもの
規制で書き込めなかったから、お手数だが concat して開いてほしい

https://
bit.ly
/30Pw8K3

**デフォルトの名無しさん** · 2019/10/06(日) 16:44:47.50

そういうのは、{ type: 'Succeeded'; result: string }と{ type: 'Failed'; message: string } みたいにして、typeで分岐させるのが普通だけど、
if ('result' in resp) {} でもいけるよ
typescriptの型はただの構造でしかないことがわかれば理解できると思う

**デフォルトの名無しさん** · 2019/10/06(日) 17:28:21.59

>>333
うおお、できた、ありがとう、感動、感謝、完璧です

**デフォルトの名無しさん** · 2019/10/09(水) 01:40:28.94

tsconfig.jsonでソースディレクトリの指定は

"include": [
"src/**/*"
]

と "compilerOptions":{
""rootDir": "./src",

のどっちが正しいのですか？

**デフォルトの名無しさん** · 2019/10/09(水) 07:36:48.39

コンパイルできる方

マジレスすると上
rootDir って要らなくね？

**デフォルトの名無しさん** · 2019/10/26(土) 16:09:48.89

もうeslintに移行しても大丈夫かな？

**デフォルトの名無しさん** · 2019/10/26(土) 16:20:08.49

もう3ヶ月前くらいに本番でeslint移行したが、全く問題なくてビビるぞ

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

Announcing TypeScript 3.7
https://devblogs.microsoft.com/typescript/announcing-typescript-3-7/

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

　( 　ﾟдﾟ)
＿(__つ/￣￣￣/＿
　　＼/　　　　/

きたか…！！

　　( ﾟдﾟ )　ｶﾞﾀｯ
　　.r　　ヾ
＿_l_l　/￣￣￣/＿
　　＼/　　　　/

　　( ﾟдﾟ )　ｽｯ
＿(__つ/￣￣￣/＿　
　　＼/　　　　/　

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

1歩進んで2歩さがる

**デフォルトの名無しさん** · 2019/11/08(金) 14:35:13.79

Microsoft、組み込みデバイスをターゲットとしたTypeScriptの高速サブセット”Static TypeScript”を発表
https://www.infoq.com/jp/news/2019/11/static-typescript-msft-paper/

**デフォルトの名無しさん** · 2019/11/08(金) 15:41:32.87

神ってる

**デフォルトの名無しさん** · 2019/11/08(金) 21:30:00.92

>さらにSTSは、TypeScriptの型規則からも逸脱している。TypeScriptがクラスに構造的型付け(structural typing)を
>使用するのに対して、Static TypeScriptでは名前的型付け(nominal typing)を使用しているのだ。

TypeScriptの人気にあやかった別言語じゃね？

**デフォルトの名無しさん** · 2019/11/09(土) 02:29:33.32

結局ただのC言語の亜種だろ
MSもそんな事をいちいちアピールしないといけないほど落ちぶれたか…

**デフォルトの名無しさん** · 2019/11/23(土) 10:38:33.96

TypeScriptはJSerへの強制型付けギプスだと思えばそこそこ優秀
いつまでもギプスつけた状態で満足するものではないのでそのうちRustなり別の静的型付けに移行する前提であれば賞賛できる

**デフォルトの名無しさん** · 2019/11/23(土) 10:47:34.10

TypeScriptはタイプ脳への強制補助輪だと思えばそこそこ優秀
いつまでも補助輪つけた状態で満足するものではないので
そのうち生JSなり別の動的型付けに移行する前提であれば賞賛できる

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

TypeScriptはタイプ脳への強制補助輪だと思え
ばそこそこ優秀いつまでも補助輪つけた状態で満足するものではないのでそのうち生JSなり別の動的
型付けに移行する前提であれば賞賛できる

**デフォルトの名無しさん** · 2019/11/23(土) 13:06:34.59

型無し糞言語は死ねだと思え
動的糞言語はいつまでも糞でそのうち糞
糞糞糞

**デフォルトの名無しさん** · 2019/11/30(土) 00:23:57.91

すみません
今までES5.1を使って来て、これから扱い易いと言われる
TypeScriptを学習しようと思うのですが
逆にTypeScriptの方がJavaScriptより
難易度高いと言う事はありませんでしょうか。

型は値に付く物で変数はそれへの参照、
prototypeはファンクションへの参照格納用プロパティ
Objectは可塑性のある便利な何かという感覚が身についています。

**デフォルトの名無しさん** · 2019/11/30(土) 05:04:50.08

vscodeといっしょに使えば、jsより楽
型エラーは全てTSが教えてくれる

**デフォルトの名無しさん** · 2019/11/30(土) 08:52:48.62

>>350
型は値に付くというその感覚はそのままでいいよ。TypeScriptはそれに加えて

- それぞれの変数にどんな型の値が入るかコンパイラが調べてくれる
- それぞれの変数にどんな型の値が入ってほしいかプログラマが指定できる
- その両者に食い違いがないかどうかコンパイラがチェックする

というだけ。

**デフォルトの名無しさん** · 2019/11/30(土) 09:04:25.09

TSの機能を余す事なく使おうと思うと難易度高いけど
其処を目指す必要はない

**350** · 2019/12/01(日) 22:23:36.97

ありがとうございます。
とりあえず tslint を緩めにしてやってみます。

**デフォルトの名無しさん** · 2019/12/02(月) 06:56:16.59

TS初心者ですがお勧めの書籍ありませんか？webpackとかも合わせて勉強したいです。

**デフォルトの名無しさん** · 2019/12/04(水) 22:44:25.30

interface A {
x: string;
}

a: A;

A.xの型(string)を取り出したい場合 typeof A.x じゃダメで typeof a.x ならいけたけど、
aみたいな変数を使わずに typeof A.x 相当のことってできないんだっけ？

**デフォルトの名無しさん** · 2019/12/05(木) 07:17:39.55

A['x']

**デフォルトの名無しさん** · 2019/12/05(木) 08:56:27.95

なるほど。ブラケット記法って最近とんと使わなくなったけど、こんなところに使い道残ってたんだ。

**デフォルトの名無しさん** · 2019/12/21(土) 15:23:23.21

実践TypeScript - BFFとNext.js&Nuxt.jsの型定義、吉井健文、2019/6/26

今まで、TS の本は、あまり無かったので買ってみた

入門者用の文法の説明が、130ページしかない。
残りの190ページが、各フレームワークへの対応

本屋で、他の本を見たら、
掌田津耶乃は、Node.js, Vue.js, React, Angular の本を出してるw
山田祥寛も、Vue.jsの本を出した

**デフォルトの名無しさん** · 2019/12/21(土) 15:40:03.75

vueは根本から型が腐ってるから使う必要なし

**デフォルトの名無しさん** · 2019/12/21(土) 19:32:06.97

やっぱ React か

**デフォルトの名無しさん** · 2019/12/21(土) 22:14:02.68

日本人は馬鹿だからしょうがない。
世界的にはreactなのに、世界と同じものでは戦えないからなのか、日本ではvueを使おうとする

**デフォルトの名無しさん** · 2019/12/24(火) 13:31:33.33

記述がスゲー長くなって見づらい
これって劣化javaみたいな記述にならない？
jsの良さが完全に死亡してる気が…

**359** · 2019/12/24(火) 13:53:39.03

実践TypeScript を読んでるけど、TS の細かい挙動の怪しい所が多いから、
その例外的なルールの数を覚えるのが大変。
つまり、ハマる箇所を避けるのが大変

TS を学ぶと、Haxe の偉大さが分かる！
JavaScript のおかしい部分を修正しているから、かなりやりやすい

**デフォルトの名無しさん** · 2019/12/24(火) 21:47:34.41

JSに良さなんてあったのか！？びっくりドンキー！

**デフォルトの名無しさん** · 2020/01/04(土) 19:44:33.72

3.7でECMA private field 使えないんだな。ガチのprivateはお預けかぁ

**デフォルトの名無しさん** · 2020/01/04(土) 19:55:56.50

ECMA private fieldの必要性、全く感じないわ

**デフォルトの名無しさん** · 2020/01/16(木) 00:04:23.72

ts拡張子のts動画との棲み分けってうまい方法あるかな？

**デフォルトの名無しさん** · 2020/01/17(金) 22:59:25.18

tsxにする

**デフォルトの名無しさん** · 2020/01/21(火) 10:46:46.65

ts-jestはテストのたびに*.test.tsをTypescriptからJavaScriptにコンパイルしてテストを実行しているのですか？
テストコードが変わらなくても、内部的にコンパイルしてるの？
それとも、tscコマンドでテストコードもコンパイルしてｊｓファイルに変換したら、それを利用してるの？

**デフォルトの名無しさん** · 2020/01/24(金) 09:42:02.04

プロパティでyield のやりかたわからん。
get hoge : Generator<number,void,boolean> {
　　　return (function* (){ yield 1; yield 2; yield 3; })();
}
とかでええの?
なんか get* hoge も *get hoge も get *hoge も怒られる。

**デフォルトの名無しさん** · 2020/01/24(金) 22:27:44.69

そもそも getter にジェネレータ記法はない

**デフォルトの名無しさん** · 2020/01/24(金) 23:21:56.15

getterでそんな複雑なことをするんじゃあない・・・

**デフォルトの名無しさん** · 2020/02/24(月) 18:47:37.01

<Ts extends Array>(...args: Ts)=>
でTsの全ての型の交差型を返したいんだけど可能？

**デフォルトの名無しさん** · 2020/02/24(月) 23:10:15.02

Typescript: Retrieve element type information from array type - Stack Overflow
https://stackoverflow.com/questions/41253310/typescript-retrieve-element-type-information-from-array-type

Creating types from values in array ・ Issue #28046 ・ microsoft/TypeScript
https://github.com/microsoft/TypeScript/issues/28046

keyof for arrays ・ Issue #20965 ・ microsoft/TypeScript
https://github.com/microsoft/TypeScript/issues/20965

この辺どうよ
できたら教えて

**デフォルトの名無しさん** · 2020/03/02(月) 20:34:14.12

締め付けはガチガチなのにガバガバな構文
トランスパイルのせいで起動は遅いし設定項目やハマりポイントはクソ増える
選択肢のないフロントはともかく、言語を選び放題なサーバーでts入れてまでjsを使う意味ってなに？

**デフォルトの名無しさん** · 2020/03/04(水) 19:31:12.74

>>376
キツマンなのに誰とでも寝るみたいなん感じか

**デフォルトの名無しさん** · 2020/03/05(木) 00:10:09.52

型無し言語というジャンルで見ると、一番マシ

**デフォルトの名無しさん** · 2020/03/07(土) 19:41:25.48

https://github.com/microsoft/vscode-textbuffer/blob/master/src/common/position.ts をC#に書き直してる。
44行目からのwithが分からん。

with(newLineNumber: number = this.lineNumber, newColumn: number = this.column): Position {
if (newLineNumber === this.lineNumber && newColumn === this.column) {
return this;
} else {
return new Position(newLineNumber, newColumn);
}

解説とC#に書き直して。"Create a new postion from this position."ってあるけど、
どう呼ばれるの？もしかしてwith文じゃなくて、with()ってメソッド？

**デフォルトの名無しさん** · 2020/03/07(土) 20:06:50.29

メソッドの定義以外の何に見えるのか

**デフォルトの名無しさん** · 2020/03/07(土) 21:33:39.02

そもそも JavaScript に with 文なんて・・・あるのかよ何だこの邪悪な臭いがプンプンするやべえやつは

**デフォルトの名無しさん** · 2020/03/08(日) 10:00:55.25

>>203
御社は今どういう状況になってる？

**デフォルトの名無しさん** · 2020/03/08(日) 13:25:25.06

>>382
何も変わっとらんよ
機能拡張もできないから、現状維持という名の放置

**デフォルトの名無しさん** · 2020/03/08(日) 13:39:52.36

サンクス

**デフォルトの名無しさん** · 2020/04/14(火) 00:16:42.49

違い何？

interface Dictionary<T> { [key: string]: T; }

type Dictionary<T> = { [key: string]: T; };

**デフォルトの名無しさん** · 2020/04/14(火) 00:52:31.86

そのコードに限っては、違いないかもな

interface は後から追加できる
これ playground にでも貼ってみ

```
interface DictionaryI {
a: string
b: string
}

type DictionaryT = {
a: string
b: string
};

interface DictionaryI {
wow: number
}

type DictionaryT {
wow: number
}

const di: DictionaryI = ({} as any)
console.log(di.wow)
```

だから、ライブラリの定義ではたまに使われる
プロダクトコードで使ってる奴は物知らないか、設計力のないやつ

**デフォルトの名無しさん** · 2020/04/14(火) 08:03:12.85

＞物知らないか、設計力のないやつ
どうして？

**デフォルトの名無しさん** · 2020/04/14(火) 08:24:49.93

>>386
ケツにIとかTを付けるのは設計力の無いやつ

**デフォルトの名無しさん** · 2020/04/14(火) 08:34:25.44

>>388
ただのサンプルコードにそんなこと言われてもwww

>>387
以下理由
・昔デフォルトONだったprefer-interfaceを引きずっている
・自分で管理できるコードなのに、interfaceで拡張する余地を残さねばならないのはおかしい

**デフォルトの名無しさん** · 2020/04/14(火) 08:54:36.47

>>389
> ・自分で管理できるコードなのに、interfaceで拡張する余地を残さねばならないのはおかしい
オブジェクト指向を全否定かよw

**デフォルトの名無しさん** · 2020/04/14(火) 10:13:18.16

>>390
たぶん君は、Java の implements に使える interface のことを言ってるのだと思うが、
type でも implements 相当の宣言ができるので、
TS の interface は src 変更が容易でないが、ライブラリの性質上拡張の余地が必要なケースでしか有効でない

「同じ名前の型なのに、実は後から src のどこかで拡張されてました」なんて嫌だろう？
どこの JavaScript だよ

**デフォルトの名無しさん** · 2020/04/14(火) 18:14:19.90

>>386
なるほど
ありがと

**デフォルトの名無しさん** · 2020/04/26(日) 04:53:02.63

function hoge<T, S> (x: T, f: (x: T) => S) {
// ...
}
みたいな関数があって、引数f のデフォルト値を identity:<T>(x: T) => T
にしたいんだけど、無理かしら？

hoge(1) <-- このときは T: number, S: number と推論してほしくて、
hoge(1, n => `number: ${n}`) <-- このときはT: number, S: string と推論してほしい

**デフォルトの名無しさん** · 2020/04/26(日) 05:47:15.51

ごめん、自己解決した
TypeScriptでは依存型をオーバーロードで実現できるのね

```
function hoge<T>(x: T): T;
function hoge<T, S>(x: T, f: (x: T) => S): S;
function hoge<T, S>(x: T, f?: (x: T) => S) {
if (typeof f === "undefined") {
return x
}
return f(x)
}
```

これで一応、第２引数指定しなかったら、戻り値の型を第１引数の型で推論してくれるようになったし、
指定すればその関数の戻り値の型で推論してくれるようになった

**デフォルトの名無しさん** · 2020/05/13(水) 20:55:34.11

Announcing TypeScript 3.9
https://devblogs.microsoft.com/typescript/announcing-typescript-3-9/

**デフォルトの名無しさん** · 2020/05/13(水) 22:51:12.18

＞Our team has been focusing on performance after observing extremely poor editing/compilation speed with packages like material-ui and styled-components.
あーやっぱり material-ui と styled-components が遅いんだ
両方使ったら耐え難いレベルで重くて辛かった

**デフォルトの名無しさん** · 2020/05/17(日) 20:28:24.81

初学者が今からTypeScriptやるメリットってある？
普段使ってるC#のBlazorが育つまで我慢してそれまではJS使えばいいかなーという気がしてるんだけど

**デフォルトの名無しさん** · 2020/05/17(日) 21:27:13.06

・BlazorがTSと同等レベルまで言語・市場が育つことはありえない
・JSに毛の生えた程度の文法でC#と同等以上のタイプセーフの恩恵を受けられる

と思うよ
正直TS始めてからは、JS（特に他人が書いたやつ）は2度と触りたくなくなった

**デフォルトの名無しさん** · 2020/05/17(日) 22:05:58.39

仕方なく js 書いてる時も jsdoc で型を付けまくってる
もうあの頃には戻れない・・・

**デフォルトの名無しさん** · 2020/05/17(日) 22:08:17.75

毛が生えたと言われてもジェネリクス周りとか仕様がけっこう大きい（大きいだけでそんなに難しくは無いけど）。あと歴史的に同じような機能のものが複数あるのはやや辛い。

**デフォルトの名無しさん** · 2020/05/17(日) 22:10:49.95

素のjsは確かに触りたくなくなったな～

**デフォルトの名無しさん** · 2020/05/17(日) 22:12:40.26

>>400
まぁそうだけど、最初はbetter js程度に :string みたいな単純な型書くだけでいいと思うよ
それだけで劇的に違ってくる

**デフォルトの名無しさん** · 2020/05/18(月) 06:26:49.70

>>402
確かにそうだわ

**デフォルトの名無しさん** · 2020/05/19(火) 12:17:36.04

クラス使えるだけで嬉しかった。prototypeとか二度と触りたくない。

**デフォルトの名無しさん** · 2020/05/19(火) 19:57:31.83

せっかくTypeScript使うのになんでクラス

**デフォルトの名無しさん** · 2020/05/19(火) 20:00:38.62

jsonに型が付くのマジサイコーって気分になる

**デフォルトの名無しさん** · 2020/05/20(水) 18:25:07.86

@types/node を v14:x に上げたら fs.write* 周りでエラーがいっぱい出た
以前の型定義ファイルでは第2引数が any だったために見逃されてたのね

**デフォルトの名無しさん** · 2020/05/20(水) 19:13:29.09

vscoe+deno
d.tsを用意してjsをimportたがインテリセンスに型情報がでない

**デフォルトの名無しさん** · 2020/05/20(水) 19:43:48.30

アーリーアダプタすぎっしょ

**デフォルトの名無しさん** · 2020/05/28(木) 04:29:10.95

質問させてください
初歩的なものかと思いますがよろしくおねがいします

以下の様に getElementById() にてinput要素を取得した場合、value属性を読み取ろうとすると問題が発生します。
　　const input = document.getElementById('input');
　　const text = input.value; // <- プロパティ 'value' は型 'HTMLElement' に存在しません。ts(2339)

解決方法を検索すると、
　　const input = <HTMLInputElement>document.getElementById('input');
　　const input = (document.getElementById('input')) as HTMLInputElement;
などの型アサーション？キャスト？で解決するように書いている記事が多くヒットするように感じます。

質問としましては、
　・HTMLElementではなくHTMLInputElement等の具体的な型で要素を取得する方法はありますか？
　・具体的な型で取得できない場合、それがHTMLInputElementであると判定する方法はどのようなものがありますか？

以上、長くなりましたがご教授頂けると嬉しいです。

**デフォルトの名無しさん** · 2020/05/28(木) 05:30:32.28

>getElementById
英語読め

**デフォルトの名無しさん** · 2020/05/28(木) 07:36:15.22

>>410
https://bi□t.ly/2zBJQbZ

こんな感じでいかがでございましょうか？

getElementById の取得結果は、HTMLElement を継承した何かであることは確実だが
より具体的な型であることは if 文などで判定しないとわからないので
（読みやすい）ワンライナーするのは難しいかな

**デフォルトの名無しさん** · 2020/05/28(木) 07:37:06.32

リンク先は typescript playground
長すぎて貼れなかった

url中の□を取っ払ってアクセスしてほしい
こっちも短縮url規制で貼れなかった

**デフォルトの名無しさん** · 2020/05/28(木) 08:20:23.58

>>412,413
なるほど、constructorと型の名称は一致するので比較に使えるのですね。
3パターンもありがとうございます。参考にさせて頂きます。

**デフォルトの名無しさん** · 2020/06/03(水) 19:01:52.32

vscodeのタスクでビルドしたいのですが、上手くいきません。
最初から入っていた"tsc: ビルド - tsconfig.json"という設定を使ってタスクを実行すると、

> Executing task: tsc -p (省略)\tsconfig.json <
パラメーターの書式が違います - -Command

と出てビルドが終了しません。
コンソールに同じコマンドをコピペするとちゃんとjsファイルが作成されます。
ググってみたのですが、そもそもtscで「パラメーターの書式が違います」というエラーが出るという記事すらありませんでした・・・
どうすればいいでしょうか。

**デフォルトの名無しさん** · 2020/06/03(水) 19:16:49.18

普通にnpmとnpm scriptの一部に組み込んだ方がいいと思う
vscodeのタスクとか使ったことないし、必要性も感じたことないな

**デフォルトの名無しさん** · 2020/06/04(木) 22:32:22.64

tscがどこにインストールされてるか、とか関係ありそう

**デフォルトの名無しさん** · 2020/06/04(木) 23:13:01.10

npx tsc --init
で、tsconfig.json が出来る

package.json に、こう書いておいて、

"script": {
"build": tsc
},

npm run build
で、コンパイルする

**デフォルトの名無しさん** · 2020/06/06(土) 19:11:34.24

>>416
そうすることにします

>>417
AppData\Roaming\npm
にありました。

>>418
元々コンソール上からはどのコマンドも実行できるのですが、
vscodeのタスクから使うとエラーが出てしまうんです。

色々テストしていたところ、
単なるシェルコマンド echo unko ですらエラーが出るのでvscode固有の問題っぽいです

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

>>415
パラメータの書式が違うってのはPowerShellでよく見るエラーだけど、VSCodeってPowerShell叩いてるんだっけ？
VSCode固有の問題と決めつけるんじゃなくてもう少し調査してみたら？

**デフォルトの名無しさん** · 2020/06/07(日) 10:34:46.16

解決しました

日本語版のWindowsではpowershell.exeがShiftJISで読まれるので、
合わせてvscode上のPowerShellの文字コードをShiftJISに変えていたのが原因でした。
元のUTF-8に戻したら問題なく実行できました。

tscをフルパスで実行したらパスの途中にスペースが発生し、
PoweｒShellスクリプトのデバッグ時によく見た文字化けだったので気づけました。

>>420
ご名答です
PowerShellが叩かれていて、エラーもPowerShellからでしたｗ

**デフォルトの名無しさん** · 2020/06/11(木) 18:33:48.61

Nodeでサーバーを立てているような場合、
ユーザーが入力した値を格納する変数の型は一旦unknownとしておいた方が良いのでしょうか？
例えば以下の様な場合です。
　const func1 = (userInput: unknown) => {...};
　const func2 = (userInput: string) => {...};

バリデーション等を行って問題が無ければ、
改めて型宣言した変数に代入し直すような方法が一般的ですか？

**デフォルトの名無しさん** · 2020/06/13(土) 14:38:30.02

ついにDartがnull安全になったそうな
https://forest.watch.impress.co.jp/docs/news/1258690.html

webからiOSまで1言語で書ける(ちゃんと動くとは言っていない)