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/

**デフォルトの名無しさん** · 2021/12/30(木) 23:05:57.59

乙

**デフォルトの名無しさん** · 2021/12/31(金) 00:30:19.49

>>1
乙

**デフォルトの名無しさん** · 2021/12/31(金) 10:54:08.06

4.6でmjs対応は入るのかな？

**デフォルトの名無しさん** · 2022/01/16(日) 23:06:00.91

Unionを受け取る関数の返り値の型を引数の型によって変えたいときってどう書けばいいの？

type F<T> = (() => void) | ((x: T) => void);

const wrap = <T>(f: F<T>) => ??? ;

const a: () => void = wrap( () => {} );
const b: (x: string) => void = wrap( (x: string) => {} );

**デフォルトの名無しさん** · 2022/02/01(火) 21:25:57.79

typescript作ったやつ何考えてんだ？
tsconfigにpath alias書いた
babel.configにも書かないと動きません
webpack.condigにも書かないと動きません
jest.configにも書かないとテストできません
あのさぁ俺はビルドツール職人になりたいわけでも設定ファイル書きたいわけでもないんだよ
どうにかしてくれよほんとこのクソッタレエコシステム

**デフォルトの名無しさん** · 2022/02/01(火) 23:58:06.60

typescriptはただのtype check toolです
babelはただのjavascript convert toolです
webpackはただのjavascript concat toolです
jestはただのtesting toolです
全部違うのです

吽孤javascriptを何とかマシにしたい4銃士を連れてきたよみたいなノリだからしゃーない

**デフォルトの名無しさん** · 2022/02/06(日) 13:50:02.45

TS童貞案件がようやっと終わった。辛かった。もうやりたくない。有給とります。

@感想
・reactの時だけ使えばおk！
・鯖では使うな！どうなっても知らんぞ！
・熟練の設定ファイル職人を必ず1人雇え！絶対にだ！

**デフォルトの名無しさん** · 2022/02/06(日) 14:01:40.08

LAMPとか言ってPHPやPerlでバックエンド作ってた狂気の時代よりは遙かにいいと思うけどなぁ

**デフォルトの名無しさん** · 2022/02/06(日) 14:21:47.42

型バリデーションできない人には（TypeScriptは）難しい

**デフォルトの名無しさん** · 2022/02/06(日) 14:32:39.20

鯖サイドは外界とのIOが多いから型バリデーションが増えすぎるのが課題かな
あとはPODの濫用が標準的なコーディングスタイルとして受け入れられてる点が問題だと感じた
これじゃ型があってても不変条件を満たしているかまではわからん

**デフォルトの名無しさん** · 2022/02/06(日) 14:39:40.47

いやPODで問題ないでしょReadonlyなりas const付ければいいじゃん

**デフォルトの名無しさん** · 2022/02/06(日) 14:43:17.15

PODってなんぞ？
Plain Object Darkness？

**デフォルトの名無しさん** · 2022/02/06(日) 15:05:31.38

型の話だしググった感じPlain Old Data型の事だと思って回答した。
プリミティブ及びプリミティブで構成されたオブジェクトからなるコンストラクタを持たないオブジェクト。ざっくり構造体みたいなオブジェクトって意味かなと。C++用語のようだ

**デフォルトの名無しさん** · 2022/02/06(日) 15:19:09.13

つまりPlatina Opal Diamond・・・ってコト！？

**デフォルトの名無しさん** · 2022/02/06(日) 15:33:19.89

>>12
そも辺りはスケールによる
ドメインが薄いならそれでなんとかなるかもしれない
実際の業務システムはどうしてもドメインが大きくなるからちゃんとクラス化しよう

>>13
Plain Old Data
プリミティブとPODの属性だけを持っている単純な型のこと
正確にはPODと呼ぶにはC言語とのデータ互換性が要る
しかしこの文脈では緩いニュアンスで伝わると考えてPODと書いた

**デフォルトの名無しさん** · 2022/02/06(日) 15:46:19.86

>>16
『ドメインが薄い』とか何用語だ。ググっても出てこないような独自なのじゃなくて、もうちょい一般的な用語使って？

色々組み合わせるにしてもTS単独で大きなものを組むにしても入り口から出口までimmutableならそれで問題ないと思うんだけど。
デザインパターンにこだわり過ぎてない？

**デフォルトの名無しさん** · 2022/02/06(日) 16:28:56.52

頭悪いんだよ
融通のきかない頭でっかち

**デフォルトの名無しさん** · 2022/02/06(日) 16:57:31.55

immutable な POD で FP すれば GOOD じゃん
class は not json serializable ビコーズチョベリバ

**デフォルトの名無しさん** · 2022/02/06(日) 17:24:04.04

無茶苦茶言ってるかと思ったらちゃんとした内容で草w

**デフォルトの名無しさん** · 2022/02/06(日) 17:45:58.69

>>17
すまん
DDDのドメイン層を連想してくれると思って言った

イミュータブルだから大丈夫ってのは規模の小さなシステムでならたしかに間違いではない
ただ規模が大きくなるにつれてそれでは難しくなるのもまた事実
というのもイミュータブルなPODだと不正なイミュータブルオブジェクトの生成を抑止する方法が残念ながら無い
なのでプログラムにバグが紛れ込みやすくなってしまう
それと特定の型に対する演算がプログラムのあちこちに分散してしまい凝集度が下がって大混乱というのが典型的な末路だね

>>18
Jsonを必要としているのは主にIOを司る層であってそれはドメイン層ではない
異なる層が負うべき責務を別の層が引き受けるのはクリーンな設計とは言えないよね
なのでドメイン層のクラスがJson Serializableである必要はない
というかドメイン層のクラスに直接Deserializeするのは危険なので大規模案件ではむしろ禁止した方がいい
それは完全コンストラクタを経由せずにオブジェクトをインスタンス化するということであり
不正なオブジェクトを生成してしまう可能性をプログラムに埋め込むということに他ならない

**デフォルトの名無しさん** · 2022/02/06(日) 18:34:09.22

>>21
> イミュータブルなPODだと不正なイミュータブルオブジェクトの生成を抑止する方法が残念ながら無い
不正なイミュータブルオブジェクトの問題ってなに？
イミュータブルオブジェクトがイミュータブルオブジェクトにどうやって影響を与えるのさ。

> 特定の型に対する演算がプログラムのあちこちに分散してしまい凝集度が下がって大混乱
疎結合になってむしろ良いことでは？
TSにおいて凝集度はクラスで担保すべきでは無いでしょ。

**デフォルトの名無しさん** · 2022/02/06(日) 18:49:51.15

>>22
不正なイミュータブルオブジェクトを元に生成した別のイミュータブルオブジェクトもまた不正なイミュータブルオブジェクトになる可能性が高い
その連鎖はいずれIO境界まで辿り着きユーザーに間違ったAPIレスポンスを返したりデータベースに間違ったデータを格納したりする

関数の入り口に間違ったオブジェクトを渡したら関数の戻り値もまた間違ったオブジェクトになることは理解できる？
もちろん途中でバリデーションをかけて落とすことはできるだろうがそれではバリデーションが増えすぎて手に負えなくなる
なのでそもそも間違ったオブジェクトを作れないようにしよう
作れないものを関数に渡すことはできないので安心だ
そういう考え方ね

下だけどそれを疎結合とは言わない
否定したい思いが先走って無茶苦茶言ってない？

**デフォルトの名無しさん** · 2022/02/06(日) 19:01:45.12

>>23
> 不正なイミュータブルオブジェクトを元に生成した別のイミュータブルオブジェクトもまた不正なイミュータブルオブジェクトになる可能性が高い
繰り返しになるけど、イミュータブルオブジェクトはイミュータブルオブジェクトに影響与えないよ？

> 関数の入り口に間違ったオブジェクトを渡したら関数の戻り値もまた間違ったオブジェクトになることは理解できる？
間違ったオブジェクト渡らないよ？なんの為の型だと思ってるの？ structとか使わないの？
データの入り口（IO等）で型バリデーションすればあとは型が化けたりしないよ。

**デフォルトの名無しさん** · 2022/02/06(日) 19:06:18.29

>>21
> Jsonを必要としているのは主にIOを司る層であってそれはドメイン層ではない
> 異なる層が負うべき責務を別の層が引き受けるのはクリーンな設計とは言えないよね
> なのでドメイン層のクラスがJson Serializableである必要はない
横だがこれは完全に間違ってるだろ。

シリアライズするのは確かにI/O側だが、他言語も含めて今現在は
クラス側にserialize手段を用意するのが主流だ。TS知らんがJSと同じならtoJSON()。
だからドメイン側でシリアライズする可能性のあるクラスの全てにtoJSONを用意しておくのが正しい解だという事に今はなっている。

I/O側にやらせていたのは昔の設計だ。ただそれの何が悪かったのかは俺は知らない。
（実行効率だけは無茶苦茶良かったから、クラスを導入して非効率になっただけなのかもしれんが）

**デフォルトの名無しさん** · 2022/02/06(日) 19:18:05.78

>>24
つーか「影響を与える」と私が一言でも書いたかな？
君のレスでは影響を与えるって言葉を変化させるという意味で使ってるように読める
だが私はイミュータブルオブジェクトを元にイミュータブルオブジェクトを「生成する」としか書いてない
modifyとcreateはプログラミングにおいて全く異なる概念なので明確に区別することをおすすめする

PODなら間違ったデータを簡単に渡せる
IO境界だけでバリデーションすればいいという考え方は人間を信用しすぎている
人間は間違えるという前提を忘れてはいけないよ
百点満点のコードを確実に書けると確信できるようなちっぽけなシステムではそれでなんとかなるかもしれないけどね

**デフォルトの名無しさん** · 2022/02/06(日) 19:28:15.98

>>26
イミュータブルがイミュータブルなままなら問題ないって話しかしてないよ？

> 人間は間違える
そのためのTypeScriptのstructだよ？

**デフォルトの名無しさん** · 2022/02/06(日) 19:34:50.15

>>25
今はなっている？ないないなってない
適当なことを言わんでくれ

JSONやXMLやバイトストリームやフォームデータのような外界の都合を吸収してシステムが扱いやすい形式に変換する(あるいはその逆の流れ)はドメイン層の仕事じゃない
それは外界とやり取りをするための専門の層の仕事だ

**デフォルトの名無しさん** · 2022/02/06(日) 19:39:52.33

>>27
structだけじゃ人間は間違えるし問題あるって話をしてる
structではデータ型が合ってるところまでしか保証できない
インスタンスが抱えてるデータが満たすべき条件を満たしていることを保証できるか？そこがポイント
それを保証するにはstructでは不十分で完全コンストラクタを実装したクラスが不可欠

**デフォルトの名無しさん** · 2022/02/06(日) 20:00:52.90

>>29
だからデータの入り口で型バリデーションするんだよ。
君は前スレの最後で暴れてた型バリデーションできない人だったか。話が通じないわけだ。

**デフォルトの名無しさん** · 2022/02/06(日) 20:04:35.10

>>30
だからそれじゃバリデーション箇所が多すぎて手が回らんっての
話がループしてるよ

**デフォルトの名無しさん** · 2022/02/06(日) 20:06:04.45

>>31
だからIOとかfetchみたいなデータの入り口だけなんだよ？

**デフォルトの名無しさん** · 2022/02/06(日) 20:12:58.65

>>32
またループしてる
そこだけバリデーションしても人間のミスはカバーしきれない
規模の小さなシステムならなんとかなるかもしれないが大きなシステムでは絶対無理
これ以上は無限ループして時間の無駄っぽいね

**デフォルトの名無しさん** · 2022/02/06(日) 20:14:05.76

>>33
そうだね。止めてもいいよ。

**デフォルトの名無しさん** · 2022/02/06(日) 20:51:55.71

>>28
toJSONを呼ぶのはI/O層の仕事で、
toJSONを定義するのはドメイン層の仕事だよ。

つか、そうじゃないと無理なんだよ。
JSONでは対応出来ない型があるから、何が入っているか分からない状態ではシリアライズは出来ない。
逆に言えば何でもシリアライズ出来れば全部I/O側に任せる事は出来るのだが、
現時点で現実的にこれはバイトストリームしかないから、バイナリデータでメモリダンプ形式で良ければ出来るけど、
これはJSONともXMLとも言わないし、実際これをやってるシステムは今は無いでしょ。

**デフォルトの名無しさん** · 2022/02/06(日) 21:05:05.78

>>35
ん？別の人か？

ドメイン側が提供するのは属性の読み取りアクセスと同等の引数を受け取る完全コンストラクタオーバーロードだけ
読み取った属性を外界が要求する形式に整形、シリアライズする(あるいはその逆)のはIO層の仕事

どの外界とどんな形式でやり取りするのか？
ドメイン層はそんなことは知らないし知ってはいけない
だから外界に依存しない純粋な読み取り属性とコンストラクタでIO層と連携する
IO層はそのデータをどうすべきか全て知っている

**デフォルトの名無しさん** · 2022/02/06(日) 21:14:45.88

>>36
まあそれでも出来るけど、それが面倒で二度手間で意味無いからみんなPODを使ってるんだと思うぞ。

FizzBuzzEnterpriseEditionとか、君は本気でやりそうだね。
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

**デフォルトの名無しさん** · 2022/02/06(日) 21:24:14.91

>>37
なんだこれww

**デフォルトの名無しさん** · 2022/02/06(日) 21:25:43.66

>>37
君も話がループしてるね
面倒だからPODで済ませるで通じるちっぽけな規模ならそれでいいんだよ私は一貫してそこは否定してないでしょ？
それなりに規模が大きくなった時の話をしてんの

FizzBuzzをエンタープライズの手法で作るのが馬鹿馬鹿しいのと同じように
エンタープライズのシステムをFizzBuzzを書くようなノリで作るのも馬鹿馬鹿しいってこと

**デフォルトの名無しさん** · 2022/02/06(日) 21:33:21.13

>>35
ちなみにバイナリでシリアライズするのはprotocol buffersとか普通にあるよ

で、どんな形式で通信すんの？JSON？バイナリ？XML？CSV？
そんなのはドメイン側は知りたくない絶対に知りたくない
ドメイン側がシリアライズの責務を負ってしまったらじゃあ通信の形式が増えるたびにドメイン側を拡張するのか？
そんなのドメイン側の本質とは全く関係ない通信様式の問題なのに？

**デフォルトの名無しさん** · 2022/02/06(日) 22:02:56.26

>>40
JavaScriptといえばJSON以外無い。
そしてXMLもDOMParserでどうにでもなる。

通信形式をドメイン側と分離するべきなのは「あらゆる形式に対応する」大前提でだ。
今時JSONかXMLしかないし、実際これで事足りるからみんなこれを使ってる。
密結合が駄目なのは「変更される可能性がある箇所」であって、何でもかんでも分離すればいいというものではない。
疎結合にすれば結局間接参照を中に挟むから、実行効率もコード効率も落ちるだけ。

Protocol Buffers見てみたが、ぶっちゃけこれ誰も使ってないだろ。
JSに対応してない時点で今現在のコンピューティングとかけ離れている。
現在もJSONで揺るぎないし、今後もJSONがさらに蔓延る雰囲気だ。
なら、ドメイン側がJSON形式に依存しても全く問題ないんだよ。
そこを無理矢理分離して、分離する意味の無いところも含めてあらゆる分離を行ってるのがFizzBuzzEnterpriseEdition。
君が言ってるのはこれ。

勿論、JSONが廃れればドメイン側のコードを書き換える必要が発生するけど、これは多分あり得ない未来なんだよ。
それでもこれに備えたければ備えるのも自由だけど.。

尚一応言っておくがJSONはJavaScriptObjectNotationの略で、つまりJSネイティブ形式だ。
だからPython等の他言語がJSON依存を避けるのならまだ分かるが、TS/JSで避ける意味はない。
君は完全にFizzBuzzEnterpriseEditionのノリでプログラミングをしてる。

**デフォルトの名無しさん** · 2022/02/06(日) 22:16:09.49

PODがダメなら普通にclassを使えばいいじゃない
その class に完全コントスクラタと toJSON を実装すればいい

つか贅沢言いすぎや
TSほどJSON API と神話性高く、堅く書けて、ほどよく柔軟な言語ないで
ワイはバックエンドをGoで書かされているが、言語機能の貧弱さに発狂しそうや
爆速でコンパイルできても爆裂バグだらけじゃ話にならん

**デフォルトの名無しさん** · 2022/02/06(日) 22:20:03.49

>>37
ヤバスギでしょ

**デフォルトの名無しさん** · 2022/02/06(日) 22:29:45.95

あらゆる形式に対応するためじゃない責務を明確に分けるため
仮に変更される可能性がなければ１つの関数でシステムを組むのか？そうはならんやろ
変更される予定がなくても責務は分けて作るんだよお仕事ではね

ProtobufはgRPC
バイナリで有名なのだと他にもMessage Packとか
こっちはゲームとかfluentdで有名

君はFizzBuzzのノリでエンタープライズ開発しそうだね

**デフォルトの名無しさん** · 2022/02/06(日) 22:30:03.08

そのDDDの文脈でTSだとバリデーションが必要で
GoやC#だとバリデーションが必要ないケースってどんな場合のこと？

**デフォルトの名無しさん** · 2022/02/06(日) 22:33:52.37

>>45
Goは完全コンストラクタを実装できない、誰でもインタスンス作り放題ヤリ放題だからバリデーションなんかいらんのや！
バリデーションなんて軟弱フニャチンオカマ野郎がへっぴり腰を振ってるようなもんだ！
ﾌｧｯｷｭｰLGBT！

**デフォルトの名無しさん** · 2022/02/06(日) 22:50:56.58

>>42
TypeScriptでもそうすれば良いじゃんってのはその通り
別にTypeScriptがclass使えないとかそういうことを問題視してるわけじゃぜんぜんないんだ

ここで最初に戻ってよくレスを読んでみて
私が提起した問題点はこれね
「PODの濫用が標準的なコーディングスタイルとして受け入れられてる」
この問題に関しては言語自体の話題じゃないんだよ

ようするに今日やったような問答をTypeScript人材を雇うと毎回全員にやらなきゃならない可能性が高いってこと
これじゃ申し訳ないけど仕事にならないよ
なので鯖サイドではTypeScriptは残念だけど人集めの段階でNGってことになるわけ

規模でかくなるのわかってるんだから最初から鯖サイドではちゃんとレイヤ分けましょうねクラス使いましょうねSOLIDなコード書きましょうねでスッと話が通じる人が多い言語で計画立てたいわけさ
そうなると古臭いけどJavaなど無難な選択肢しかないんだよな…

**デフォルトの名無しさん** · 2022/02/06(日) 22:57:06.33

>>44
まあ君とは平行線のようだね。

> 仮に変更される可能性がなければ１つの関数でシステムを組むのか？
組むぞ。俺は変更される可能性がない所に依存するのは全く問題ないと見てる。
そして基本的に実行効率重視だから、無駄な事はしない。

君はドメインが「１年が365日である事を知っている必要はない」として、365すらもリテラルでは書かないのだろう。
そして人類が火星に到達した時、君のコードは無修正で動くが、俺のコードは役に立たない。
でも俺は、「一方ロシアは鉛筆を使った」は大切にすべきだと思ってるから、
365はリテラルで書いてしまって、火星に到達してから書き直す事を選択する。

俺はJSONが廃れる未来なんてないと思ってるから、コードがJSON形式に依存するのも何ら問題を感じないし、
今のJSのアーキテクチャ、つまりtoJSONを整備しろ、で全く問題ないと思ってる。
これは確かに分離出来てないアーキテクチャだけど、する意味もないと思うよ。
むしろ他言語でもJSON使えないのはポンコツ扱いだろ今は。

> gRPC
> Message Pack
> fluentd
JSONがあまり効率のいい形式ではないのは事実で、これに対する策のようだね。
ただ、俺ならI/O層でJSON形式から変換させる。
つまりドメイン層はtoJSONを定義して、それでおしまい。それ以上の形式が欲しければI/O層で変換だ。
君のアプローチより現実的だと思うけど。

**デフォルトの名無しさん** · 2022/02/06(日) 23:02:11.49

>>47
そりゃお前のノリでやってくれる奴はお前の畑の奴だよ。
それがJavaならそうすればいいだけ。

ただ、PODが駄目だってのはただの先入観で、
実際それでやってる奴が多くて、それでも世界が回ってるのなら、お前が勘違いしてるだけだよ。

**デフォルトの名無しさん** · 2022/02/06(日) 23:08:32.84

>>48
うん
TypeScripterとは分かり合えない人が多いだろうなとは思ってたけど君とは特に分かり合えないと思う
関数１つでシステム書く人を理解するのは私には不可能だ

365をリテラルで書かないのはDDDとかそれ以前の問題だと思うよ
君の書いたコードって四年に一回ぐらいバグ出してない？大丈夫？

処理効率が大事な部分でわざわざJSONを経由して効率落とすの？
ライブラリ開発者が必死になって直列化コストを削減してくれたのを嘲笑うかのような所業
やっぱり理解できないや

**デフォルトの名無しさん** · 2022/02/06(日) 23:09:14.59

>>49
それで回る規模の世界はそりゃ回るだろうね
これも何度も言ってるよね

**デフォルトの名無しさん** · 2022/02/06(日) 23:34:35.72

なら、その規模を確認してからでよかったんじゃね？