TypeScript part4

**デフォルトの名無しさん** · 2021/12/30(木) 22:57:02.78

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/
part3
https://mevius.5ch.net/test/read.cgi/tech/1524746903/

**デフォルトの名無しさん** · 2022/03/06(日) 13:42:08.14

>>117
> ウェブ系だと普通なのか？
Web系ではなく資本主義/自由主義経済において普通。会社だって気に入らなければいくらでも起業しろ、でしょ。
Web系においてはこれが割と厳密に守られてて、Webサイトは自由に作れるし、起業する奴も多い。
(Webサイトも広告貼るならただの集客業《＝ITチンドン屋》でしかない)

> 今あるものをより良くしていこうという考え方の方がいいと思うな
基本的にはこれは社会主義の思想。国で素晴らしい物を一つ作れば十分、という事だから。
ただしこれは現実的に出来ない。だから資本主義が社会主義を圧倒してる。
理由は簡単で、
・「素晴らしい」の定義が人によって全く異なる --- (A)
・そもそも何が「素晴らしい」のか、まだそれを見てない状態で想像出来る奴はほぼ居ない --- (B)
だからめいめいが「オレオレさいきょうの○○」を作りまくる資本主義の方が、社会主義より『結果的に』繁栄する。
ただしその時点で国としてのインフラ(教育/交通/電力等)が全く整って無い場合、
インフラの整備はほぼ全員の国民にとって「素晴らしい」事は明白なので、トップも実際にそれをやる。
だから社会主義/共産主義/独裁主義の方が国としてのスタードダッシュは速いし、歴史的にもそう。
ところがインフラを整えた位のところで、次に何をすべきかが分からなくなって失速する。
だから国としては独裁→自由主義にうまく衣替えするのが一番効率がいいのだが、
独裁してインフラ整備した連中はその時点で『大成功』してるつもりだから、その権力を絶対に離さない。
(実際はその独裁者の才覚によるものではなく、誰がやってもその状況なら大成功するわけだが)

**デフォルトの名無しさん** · 2022/03/06(日) 13:42:30.55

で、Web上のコミュニティについては、

・ゆとりは基本的に許容範囲が無茶苦茶狭い。ちょっとでも不満があったらそれは駄目だと見なす

ので、上記(A)に引っかかって、結果的にコミュニティを上手く成立させられてない。（と見える）
(B)については確率の問題であり、ゆとりも母数は相当数居るのだから、問題ないはず。
現状、Webインフラは既に整備済みだから、「オレオレさいきょうの○○」を作る方が効率がいい。
仮に国有5ch、国有Twitterとして、それぞれ「この方針で行く」なんてやっても社会主義同様停滞するだけ。

そもそも何かしらの場があって、そこに居ついている人にとっては、そこが十分に「素晴らしい」場所なんだよ。
それを「俺がそう思うから」で変更するのは、元々居た人にとっては「素晴らしい」点が失われる事にもなりかねない。
これを防ぐために、並立させた状態で好きな方を選べ、がforkで、基本的にGitHub等もこの方針でしょ。

馬鹿ゆとりにも分かるように言えば、

・ゆとりにとっての快適は、上の世代にとっては不快

だから結果的にそれなりに住分けてる。この事実をちゃんと考えろ、という事。
いずれにしてもtwitter上のコミュニティなんて、勝手に宣言してるだけだし、
気に入らなければ自分で作って競争すればいいだけだろ。
ただ、>>100程度の馬鹿ではこれは出来ないと思うけど、という話。

>>118
100は典型的ゆとり価値観だぞ。
ここは匿名なのだから、自分が何者かは自分の書き込みで示さなければならない。
ゆとりらしい書き込みをしたからゆとり呼ばわりしてるだけ。
これが悪いとは俺は1mmも思わない。
(そうされたくなければそういう書き込みをしなければいいだけ)

**デフォルトの名無しさん** · 2022/03/06(日) 15:28:00.88

>>120
お前ここ初めてか？力抜けよ。

**デフォルトの名無しさん** · 2022/03/06(日) 15:42:42.98

>>107
>>121
ゆとりを56してしまえば笑顔になれるよ

**デフォルトの名無しさん** · 2022/03/07(月) 07:16:36.13

こんなやつが暴れてる5chではコミュニティが育つわけもないよなぁ

**デフォルトの名無しさん** · 2022/03/07(月) 07:34:46.32

ぼくのかんがえたさいきょうのこみにゅてぃ以外みとめません！

**デフォルトの名無しさん** · 2022/03/07(月) 13:09:46.84

>>123
なら出ていけばいいだけだね。それでこちらも助かる。
俺はゆとりが全員死ぬのを望んでいる。

というかね、ゆとりは相変わらず『俺様が絶対正義』だと思っているようだが、
そもそも「価値観の違いによるストレス」は相互であり、相手も(符号が違うだけで)全く同じストレスを受けてる。
自分達が一方的に被害者だってことにはならない。お互いに被害者であり加害者だ。

(つかなんでお前らが被害者ポジションマウントを気取るのかさっぱり分からないが、
ネット見過ぎてゴミクズ韓国人がデタラメ言ってるのを真に受けて戦法を学んだつもりなのか？
まあひろゆきが議論上手に見えるようだから実際その程度の頭なのかもしれんが)

**デフォルトの名無しさん** · 2022/03/07(月) 13:10:25.20

この辺、ちょっと考えればすぐ分かるはずなのに、ゆとりは全く考えようともしないから気づけない。
馬鹿ゆとりにも分かるようにくどいが言い直すと、
ゆとりが「上から目線ガー」と感じてるのなら、
ゆとり以前の世代は「なんで下の者にこんな言われようされないといけないんだ？」と思ってる。
上司は友達でも同僚でもない。
勘違いしている奴も中にはいるが、大半は職責を正しく全うしてる。

そこで「もっとフレンドリーにやった方がいい」というのなら「提案」になるが、
当たり前だが「上司と部下」で既に上手く回ってる組織でそれをやっても嫌われる。無茶言うなでしかないからだ。
だから「フレンドリーな会社を作って、そっちの方が上手く回る(=利益が出る)ことを示し、
優勝劣敗の原理により『上司と部下』の会社を廃業に追い込む」というのが正しい自由主義経済での解決法だ。
くどいが、元々成立していた会社を「ぼくのさいきょうのかいしゃ」に変更する事ではないんだよ。

なんでこんな事になってるかというと、そもそも「ぼくのさいきょうのかいしゃ」は実際ただの勘違いが多く、
大半の場合はろくでもない結果にしかならないからだ。
ただ、中には上手く行く事もあるし、そういうのはえてして当初は「無茶だ」としか思えないから、
そういう成長の芽を潰さないために「ぼくのさいきょうの○○」を作る自由は保障されてる。
これが自由主義経済。

ゆとりは昔から「同僚や先輩にお願いするべき事項を、上司に振る？！？！」と言われているが、ここは相変わらずだろ。
ゆとりの「上から目線ガー」はゆとり以前の「何故俺がこんな…」の裏返しでしかない。
お前らがストレスを感じるのであれば、お前らも十分ストレスの原因になってる。
だから棲み分けが妥当なんだよ。

**デフォルトの名無しさん** · 2022/03/07(月) 13:11:19.93

さて本題100、実際そいつがどれ程かは知らんが、俺から見れば普通なんだろうなとは思う。
でもそれが平均的ゆとりにとって看過出来ないストレスで無理なら、
同様に無理だと思ってるゆとりも大勢居るはずだから、そいつらと共にもっと「優しいコミュニティ」を立ち上げればいいだけ。
そしてそれで上手く行けば、他コミュニティも学んで優しくなるところも出てくる。これが自由主義経済。
こうなればゆとり価値観の勝ちでいい。

ただまあ、一般的にWebコミュニティは優しいだけでは上手く回らない。
塩対応には必ず理由があって、お前らは「人格ガー」って事にしたいのだろうけど、大半はそうではない。
まあその辺はやれば分かるし、やらないと分からないので、やってみればいい。
それで上手く行けばよりよい物を得られ、全体に利益がある。駄目でも損失はない。これがforkの良いところだ。

(forkの場合はそのままの現行と一部改造した新規の構成のため、失敗しても現行は無傷で、プラス方向にしか進化しない。
現行を直接変更する「改善」だと、「改悪」される事もあり、マイナス方向に進む場合もある。
つまり、自由主義経済は進化の方向がデタラメで速度も遅いが、プラス方向にしか進化しないため、長期的にはなんだかんだで成長する。
対して社会主義だとスタートダッシュは速いが、「改善」の難易度も段々高くなるため、
ある程度以降は改善改悪を繰り返し、長期的には停滞してしまう。
これが社会主義が資本主義に負けた根本的な理由。
だから俺達はやっぱり自由主義的にforkで行くしかないんだよ。
『自分が大正義だ』と思ってる限りforkなんて効率が悪すぎると思えるだろうが、それは傲慢でしかない。
正しかったかどうかは結果《＝多数の支持》で判断されるべきであって、お前の思想に合致してるかどうかではないから。
《というかパヨクが根本的にずれてるのはここで、『俺様が絶対正義』だと自信持ちすぎてるからあんなことになる。
そしてゆとりにもこの傾向はあるよ。これは自覚した方がいい》)

**デフォルトの名無しさん** · 2022/03/07(月) 13:12:24.61

5chでtwitterの悪口を言っても何ら生産性がない。
文句があるのならまずはやってみる事だ。お前もコミュニティ立ち上げ宣言してみればいい。
それで上手く行けばよし、駄目なら駄目で、何故塩対応してたのかが分かるだろうさ。
だからいずれにしても君には利益があると思うけど。

あとついでに聞きたいんだが、なぜゆとりは5chに拘るのだ？
5chなんてゆとり以前の世代「ゆとりにはついていけねえ…」の巣窟だ。
ゆとり以前からあるんだから当然だが。
いずれにしても、ゆとりにとって快適な場所にはならないよ。
(5chの連中を見下したり馬鹿にしたりするのも自由だけど、それを5chに来て言うのは頭がいかれてる。
まあそれ以前に、twitterの悪口を5chで言うのも頭がいかれてるが)

既に言ったがQiitaがゆとり価値観の場所で、
「Qiitaに掲示板機能付けてくれ」が「5chを使う」よりお前ら的には正しい解のはずだ。
もちろんQiitaはそれが出来ないと分かってるからやってないのだが、
それでも「ゆとり価値観の掲示板」を何処かに作らない事には、お前らの安寧の地はないと思うけど。

**デフォルトの名無しさん** · 2022/03/07(月) 22:53:54.14

TypeScriptもついに4.6か
翻ってウチのNuxtプロジェクトときたら未だに4.2にロックイン
Nuxt 3になれば何とかなると待って信者が祈りを捧げて早幾年
未だβのまま
そもそもbreaking changeに耐えられる品質でもない

この型無し糞ゴミ採用した奴●してやりてえわ
そもそもVueコミッター全員●したい
早く潰れろ

**デフォルトの名無しさん** · 2022/03/07(月) 23:53:20.52

.NETやってるけど快適

**デフォルトの名無しさん** · 2022/03/08(火) 05:55:37.35

つまり言語作者が同じTSも快適って事か

**デフォルトの名無しさん** · 2022/03/08(火) 08:51:42.58

jsファミリーに期待するな

**デフォルトの名無しさん** · 2022/03/08(火) 12:40:02.06

やはりRustのみが縁なき衆生をお救いくださるのである（過激派

**デフォルトの名無しさん** · 2022/03/18(金) 11:45:07.12

node_modulesの下のコードが静的エラー出して鬱陶しいです
typescriptの開発者って静的エラー消さずにパッケージ出荷しちゃうんですか？

**デフォルトの名無しさん** · 2022/03/18(金) 11:57:30.55

excludeしろ

**デフォルトの名無しさん** · 2022/03/27(日) 17:58:36.93

TSはもしかして例外あんまり使わないんですか？

**デフォルトの名無しさん** · 2022/03/30(水) 14:38:24.60

みなさんどういう単位でファイル分割されてますか？
1ファイル1クラスのphpと違って自由だから逆に迷ってしまいます
ベストプラクティスないかググっても見つからず…

**デフォルトの名無しさん** · 2022/03/30(水) 14:47:13.20

どうでもいいので好きにすればいい
そもそもスクリプト言語ではそんなガチガチにこだわらないほうがいい
スクリプトは雑で汚くてもいいから小さいシステムをサクッと作るための道具だから

**デフォルトの名無しさん** · 2022/03/30(水) 15:27:58.67

>>137
教科書的な正解が欲しいならGitHubでTypeScriptコンパイラかVSCodeのソースを見ればいい
機械的な基準ではなく、意味のある単位で適当に分けていることがわかる
身も蓋もないことを言えば、十分に頭の良い人間の裁量でケースバイケースで判断するのがベストだ

**デフォルトの名無しさん** · 2022/03/30(水) 15:33:36.80

>>137
普通にクラス単位で分けるし、型（関心事）とその周辺関数郡で分割するかな。あとは1ファイルをなるべく小さく保つ。改修で膨らむ可能性があるから。
個人的には1ファイル250行超えたら危機感持つ。

**デフォルトの名無しさん** · 2022/04/18(月) 21:22:21.94

>>137
なるべくファイル数は少なく保つ
微塵切りの千切りファイルで見通しを悪くしてはいけない
classは使わない
十分に小さく参照等価なfunctionを組み合わせる
どうせ改修で膨らむほど使われないから。
個人的には1ファイル250行未満なら危機感持つ。

**デフォルトの名無しさん** · 2022/04/22(金) 12:41:47.72

初心者です
serverlessってフレームワークを使ってるんだけど、規模小さいコードなのにビルド始めるとesbuildが16Gメモリ使って完了までくっそ時間かかる
業務用のソースだから晒せないんだけど、一般論的に言ってこの最適化オプションはハマりやすいので注意、みたいなのってあります？

**デフォルトの名無しさん** · 2022/04/22(金) 15:45:27.64

ここよりフロントエンドのフレームワークのスレで聞いたほうが良いと思うな

**デフォルトの名無しさん** · 2022/04/26(火) 21:25:48.15

JSファミリーの仕様のごちゃごちゃ加減が酷い
なんでこれが流行ったんだ

**デフォルトの名無しさん** · 2022/04/26(火) 21:27:37.78

他の言語が取って変わろうとするたびに、
javascript側の仕様更新による延命がうまくいったせいで、
ごちゃごちゃな歴史を引きずったまま、いまでもゾンビのように君臨してるパターンか
フロントのフレームワーク、JS一択なのが酷い

**デフォルトの名無しさん** · 2022/04/26(火) 21:37:42.76

ブラウザがまともにサポートしてるのがそれだけだったから仕方がない
もし最初に軌道に乗ったブラウザスクリプトがVBだったら今頃VBが流行ってたよ

**デフォルトの名無しさん** · 2022/04/26(火) 22:16:40.32

ありえんわ
勘違いもはなばなしい
なんだかんだ（古い文法を除けば）JS/TSの文法はプログラミング正統派として読みやすい
だから未だに使われ続けている

**デフォルトの名無しさん** · 2022/04/26(火) 22:16:58.75

と思いたいんだね

**デフォルトの名無しさん** · 2022/04/26(火) 22:23:32.66

実に華々しい勘違いですね

**デフォルトの名無しさん** · 2022/04/27(水) 09:19:38.83

いや、鼻々しい勘違いでいた

**デフォルトの名無しさん** · 2022/04/27(水) 09:21:46.08

でも、TS様のおかげでJSの酷さがかなり軽減されていると思る
勿論、TSスレだから媚びを売ってるだけだ

**デフォルトの名無しさん** · 2022/04/27(水) 20:19:12.60

interfaceのほうがコードきれいになるな
typeは便利だが良くない発明だ

**デフォルトの名無しさん** · 2022/04/28(木) 21:43:14.60

interfaceできれいになるような糞コード書いてるのが問題なのでわ？

**デフォルトの名無しさん** · 2022/04/28(木) 21:53:14.86

クソコードって|とか&使ってる馬鹿なコード
unionって今どきＣ言語かよ

**デフォルトの名無しさん** · 2022/04/29(金) 05:07:46.33

まあC++使えない奴は、大抵何させてもたいしたこと無いけどなw

**デフォルトの名無しさん** · 2022/04/29(金) 05:15:00.80

う、うん…(´・ω・｀)

**デフォルトの名無しさん** · 2022/04/29(金) 05:37:28.64

ヨシ！

**デフォルトの名無しさん** · 2022/04/29(金) 05:57:49.75

このスレやべーやつ住んでるな。ワッチョイつけなかったからこんなもんか

**デフォルトの名無しさん** · 2022/04/29(金) 08:07:44.25

次世代言語スレから何か流れてきてるだろ

**デフォルトの名無しさん** · 2022/04/30(土) 02:13:26.17

C++を使うにはCの知識も当然必要だがな

**デフォルトの名無しさん** · 2022/04/30(土) 11:22:16.98

オーバーロードがもうちょいマシだったらなと思う

**デフォルトの名無しさん** · 2022/05/10(火) 11:41:45.53

　　　　 ,―彡 ⌒ ミ―､
　　　〈　〈|　´ん`　|〉　〉
　　　　＼　ヽ＿／／
　　　　　/　　　　　 /みんなで
　　　　 /　　　　　 /ホモセックス

**デフォルトの名無しさん** · 2022/05/30(月) 21:44:48.53

バカが書いたTypeScriptってマジで糞だな
って思ったけどJavaScriptだったらもっと糞になってたんだよなって思って心の平静保ってる

**デフォルトの名無しさん** · 2022/05/30(月) 21:47:51.98

それ言ったら賢い奴が書いたらCでも何も問題ないんだが
言語が縛ってるのは所詮馬鹿対策でしかない

**デフォルトの名無しさん** · 2022/06/29(水) 20:00:27.28

質問です。

type t = (a: string) => string;
const f: t = (a) => false;
console.log(f('x'));

で false のところで、
Type 'boolean' is not assignable to type 'string'.ts(2322)
になりますが、
・type t = ... を書き換えてはいけない
・const f の実装を
　const f: t = (a) => <string><unknown>false;
　のように書き換えてはいけない
・// @ts-ignore
　を使ってはいけない。
という縛りで、例えばですが、
type t = (a: string) => string;
overwrite type t = (a: string) => string | boolean;
const f: t = (a) => false;
console.log(f('x'));
のように同名の型のまま戻り値の定義を書き換えるということはできるのでしょうか？
（overwrite type...は、そんな文法は無く、仮想の方法です。）

また、型定義と型指定部分だけ書き換え不可としたら、普通は、
<string><unknown>false;
// @ts-ignore
どちらで乗り切るのでしょうか？

**デフォルトの名無しさん** · 2022/06/30(木) 01:29:29.02

>>165
普通はfの型をtにしないと思うのだが、どういう意図があるの？

**デフォルトの名無しさん** · 2022/06/30(木) 07:51:24.33

>>165
>のように同名の型のまま戻り値の定義を書き換えるということはできるのでしょうか？
型定義を後付けで変更できたらいろんな前提がひっくり返る気が
そんなことが必要な状況が想像できないけどコードの臭いがプンプンする

**デフォルトの名無しさん** · 2022/06/30(木) 09:29:37.43

ライブラリの型が間違ってるとか？
質問あるあるだが、抽象化も大事だが、具体的な状況も書き添えると回答してもらいやすくなると思うよ
そもそもの質問がずれてるとかもあるからね

**デフォルトの名無しさん** · 2022/06/30(木) 11:29:36.59

>>165
です。ありがとうございます。
実際のケースでお話しします。
・ライブラリの型を利用している。
・ライブラリの実装をそのまま真似ている。（実装は変えられる。）
・anyは使わない方針。
の状況です。
【型定義（サードパーティ）】
declare const visit: { <V extends Node>(tree: Node,test: Test<V> | Array<Test<any>>,visitor: visit.Visitor<V>,reverse?: boolean): void }
export = visit
declare namespace unistUtilIs {
type TestFunction<T extends Node> = (node: unknown,index?: number,parent?: Parent) => node is T
type Test<T extends Node> = TestFunction<T> | null | undefined }
【実装（大部分省略）】
import visit from 'unist-util-visit';
import { Node, Data } from 'unist';
　function visitX(node: any): void {
　　if (!node.type) return;
　}
　return function transformer(tree): void {
　　visit(tree, (node: Node<Data>) => node.type === 'xxx', visitX);
　};
ここで、function visitX(node: any)　の Unexpected any. を消すのに難儀しています。
function visitX(node: Node<Data>): void {
にすると、
visit( の部分で
No overload matches this call.
Overload 1 of 2, '(tree: Node<Data>, test: any[] | Test<Node<Data>>, visitor: Visitor<Node<Data>>, reverse?: boolean | undefined): void', gave the following error.
...
と怒られます。極端な話、サードパーティの定義の方をいじらないと解決しないかもと思った次第です。

**デフォルトの名無しさん** · 2022/06/30(木) 12:31:53.04

5chだと読みづらいからts playgroundなりcode sandboxなりに書いて欲しい

**デフォルトの名無しさん** · 2022/06/30(木) 12:53:38.41

>>165　です。
すみません。かなり省略して、改行も削除しました。
伝えたかったのは、以下です。
https://tsplay.dev/WJyrDm

**デフォルトの名無しさん** · 2022/08/26(金) 00:55:54.58

Recordとmapped typesの使い分け方が分かりません
Record<Key, Value>と{ [key: Key]: Value }ってinterchangeableな気がするんですが、
どっちかにしかできないことがあったりするんですか？

**デフォルトの名無しさん** · 2022/08/26(金) 08:07:49.83

mapped の方が柔軟

type X = { age: number, name: string }

これは Record では定義できないだろう

**デフォルトの名無しさん** · 2022/08/26(金) 08:46:09.94

Recordはキーがいくつかの既知の値のみに限られる場合に使う
{ [key: Key]: Value }だとキーが何でも入っちゃうでしょ

**174** · 2022/08/26(金) 10:07:43.28

限られるというより、必ず既知のキーを持っていることが保証されるというべきか
record.knownKey のような既知のキーによるアクセスがタイプセーフになり、コード補完も効く

**デフォルトの名無しさん** · 2022/08/26(金) 10:18:44.77

微妙にインデックス型とmapped typeがごっちゃになってて話をややこしくしてる気がする

**デフォルトの名無しさん** · 2022/08/26(金) 22:54:52.76

>>173
それはただのオブジェクト型だと思うが

**.NET MAUI HighScool** · 2022/11/03(木) 11:06:25.02

もしかしてTypeScriptってC#で良いのでは？
静的型付け言語だしオブジェクト指向だし作った人も一緒

**デフォルトの名無しさん** · 2022/11/03(木) 11:18:14.22

C#でいいならわざわざ同じ人が新言語作らないだろ
ヘルスバーグはMS内では神みたいな扱いらしいから、自分で意味ないと思ってる仕事なんかやらないよ

**デフォルトの名無しさん** · 2022/11/03(木) 11:27:45.04

TypeScriptが解決してる問題をC#が全て解決出来るか考えてみれば？

**.NET MAUI HighScool** · 2022/11/03(木) 11:38:56.77

>>180
できてるじゃん

**デフォルトの名無しさん** · 2022/11/03(木) 12:08:35.27

or型というのかunion型というのか忘れたけど、C#にはなくない？
type a = b | c

(C#にもこの機能欲しい）

**デフォルトの名無しさん** · 2022/11/03(木) 12:23:54.28

JavaScriptに静的型付けの恩恵を与えるために作られたのがTypeScript
C#でそれは出来ないでしょ

**.NET MAUI HighScool** · 2022/11/03(木) 12:26:39.11

>>183
C#が静的型付けじゃん

**デフォルトの名無しさん** · 2022/11/03(木) 12:29:42.91

C#ではJavaScriptに静的型付けの恩恵を与えられないでしょ

**.NET MAUI HighScool** · 2022/11/03(木) 12:39:42.87

>>185
なんで？

**デフォルトの名無しさん** · 2022/11/03(木) 12:47:16.05

>>186
君はC#がJavaScriptに静的型付けの恩恵を与えられると思ってるの？

**デフォルトの名無しさん** · 2022/11/03(木) 12:57:24.44

>>182
これについてはTypeScriptが便利というよりは、JSのやり方に合わせるために必要となっているものだと思う
C#では型が条件によってコロコロ変わるような設計は普通しないから、nullabilityさえ指定できれば多くの場合十分

**.NET MAUI HighScool** · 2022/11/03(木) 13:04:33.62

>>187
いや別にJavaScript使う必要なくね？

**デフォルトの名無しさん** · 2022/11/03(木) 13:12:15.66

>>189
それは論点のすり替えでしょ

**デフォルトの名無しさん** · 2022/11/03(木) 14:21:47.63

代数的データ型は静的型付け言語にもあるよ。
最近のC#でも出来るけど記述量が多い。F#なら比較的楽に書けるけど。

**デフォルトの名無しさん** · 2022/11/03(木) 15:50:32.38

typescriptが実行時型安全まで保証してくれたらもう他の言語いらんのよな
REST APIというかJSONとの相性もマックスバリューだし
世にはびこっている型なし糞言語を全て地獄に葬り去ってほしい

**デフォルトの名無しさん** · 2022/11/03(木) 16:11:11.85

>>191
union typesは静的型において一般的な直和型とはかなり違ってて癖が強い
値が型持ってないからね

**デフォルトの名無しさん** · 2022/11/03(木) 16:27:43.63

>>193
まあそれはそうか。型ガードベースだもんね。
別に型が一致してなかったとしてもメンバさえ合ってれば雑代入しても問題ないし。

**デフォルトの名無しさん** · 2022/11/03(木) 18:23:11.89

>>192
型をバリデーションライブラリから生成すると捗るよ

**デフォルトの名無しさん** · 2022/11/03(木) 20:49:50.25

>>195
おっ　zodmanか？

**デフォルトの名無しさん** · 2022/11/03(木) 20:56:17.04

interface/classからjsonschemaを生成して、それを型ガード関数で使うってのが鉄板。

**デフォルトの名無しさん** · 2022/11/03(木) 21:05:34.21

>>196
すまねぇsuperstructなんだ。すまねぇ。

>>197
AJVはコードサイズデカくね？

**デフォルトの名無しさん** · 2022/11/03(木) 21:36:19.22

コードサイズは気にしたことがないがスキーマ手書きは面倒臭いからやだなあ。

**デフォルトの名無しさん** · 2022/11/03(木) 22:05:24.52

RestAPIの型チェックはio-tsっていうライブラリつかってバリデーションしてるな。
実行時コストがあるけど、自分は業務アプリがメインなんで変な結果で次に進まない方が大事。

**デフォルトの名無しさん** · 2022/11/03(木) 22:38:04.12

>>199
ZodとかSuperstructとかはtypeで型書くのとほぼ同じくらいの手間でバリデーションと型が生成されるからすげー楽だよ。

**デフォルトの名無しさん** · 2022/11/03(木) 22:52:51.54

うーん、俺はやっぱりTypescriptで書いた型そのまま使える方が楽だわ。

**デフォルトの名無しさん** · 2022/11/04(金) 15:37:16.21

HighScool君は納得して帰ったのか

**デフォルトの名無しさん** · 2022/11/04(金) 23:24:08.39

superstruct と zod ならどっちがええのんか？

**.NET MAUI HighSchool** · 2022/12/16(金) 16:55:41.78

C#だとvar型でも何ら問題無いと思われてるのにTypeScriptのanyはなんでTwitterでネタにされるんでしょうか？
私もあまりvar型使いませんが公式とかvar型使いまくってるしTypeScriptでany使っても何ら問題なさそうなのですが…

**デフォルトの名無しさん** · 2022/12/16(金) 17:30:57.27

コーディング時にvarは右辺で型が決まるけどanyは決まらないからかな

**.NET MAUI HighSchool** · 2022/12/16(金) 18:26:46.45

>>206
決まらないんですか？
ではvar型ではなくdynamic型と言うことなのですかね

**デフォルトの名無しさん** · 2022/12/16(金) 21:33:55.14

そもそもvarは正確には型じゃないだろ

**デフォルトの名無しさん** · 2022/12/16(金) 21:58:06.83

var型はないな

型の堅牢性などを享受するためにTypeScriptを使用しているはずなのに、anyを持ち出せばそれが途端に失われるから絶対に使わない方がいい
そして確かにanyはdynamicに近いものと考えて良い

**デフォルトの名無しさん** · 2022/12/16(金) 22:10:24.90

TypeScriptに対する理解が浅いのはともかくC#の理解もそんな程度だったのかこのコテ

**.NET MAUI HighSchool** · 2022/12/17(土) 00:18:30.36

>>208
型推論型だろ
>>210
何いってんだこいつ？

**.NET MAUI HighSchool** · 2022/12/17(土) 00:22:25.11

dynamic型は次の値を入れたらその型に変わる
例えば
dynamic x="おはよう"
dynamic x=123
でも大丈夫なわけ
anyは型の再代入ができないって見たけど？これdynamic型なの？

**デフォルトの名無しさん** · 2022/12/17(土) 00:38:58.67

>>178程度の理解のヤツに何を説明しても無駄よ

**デフォルトの名無しさん** · 2022/12/17(土) 00:50:14.95

>>212
流石にこれは触っちゃいけないレベル

**デフォルトの名無しさん** · 2022/12/17(土) 00:55:05.65

anyはまさにJavaScriptの元々の変数の扱い様そのもの。

**.NET MAUI HighSchool** · 2022/12/17(土) 01:46:39.51

>>213
TypeScriptはC#以下だったってわけか
理解

**デフォルトの名無しさん** · 2022/12/17(土) 01:54:57.82

目的が違うんだよ。C#ではTypeScriptのようなことは出来ない。
良い意味でも悪い意味でもJavaScriptのスーパーセットかつトランスパイラである必要があるんだから。
ただTypeScriptが将来C#でやってることを概ね肩代わりすることは可能だったりはするんだけどね.netライブラリをそのまま動かすように改変していくことも障害は少ない。

**デフォルトの名無しさん** · 2022/12/17(土) 02:13:01.40

そいつにかまうなよ
あちこちの言語やフレームワークスレに乗り込んでは意味不明な喧嘩売って
C#マンセーMAUIマンセーしてるだけの荒らし