TypeScript part4 (396ﾚｽ)
上下前次1-新
1(1): 2021/12/30(木)22:57 ID:XEA11GKy(1) AAS
外部ﾘﾝｸ: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
2chｽﾚ:tech
part2
省3
2: 2021/12/30(木)23:05 ID:18t9WvJQ(1) AAS
乙
3(1): 2021/12/31(金)00:30 ID:/NplslaL(1) AAS
>>1
乙
4(1): 2021/12/31(金)10:54 ID:jCXckXJt(1) AAS
4.6でmjs対応は入るのかな？
5(1): 2022/01/16(日)23:06 ID:CViIeqBQ(1) AAS
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) => {} );
6: 2022/02/01(火)21:25 ID:RQFIXaIQ(1) AAS
typescript作ったやつ何考えてんだ？
tsconfigにpath alias書いた
babel.configにも書かないと動きません
webpack.condigにも書かないと動きません
jest.configにも書かないとテストできません
あのさぁ俺はビルドツール職人になりたいわけでも設定ファイル書きたいわけでもないんだよ
どうにかしてくれよほんとこのクソッタレエコシステム
7: 2022/02/01(火)23:58 ID:0JyqEM+P(1) AAS
typescriptはただのtype check toolです
babelはただのjavascript convert toolです
webpackはただのjavascript concat toolです
jestはただのtesting toolです
全部違うのです
吽孤javascriptを何とかマシにしたい4銃士を連れてきたよみたいなノリだからしゃーない
8: 2022/02/06(日)13:50 ID:26fWvErU(1) AAS
TS童貞案件がようやっと終わった。辛かった。もうやりたくない。有給とります。
@感想
・reactの時だけ使えばおk！
・鯖では使うな！どうなっても知らんぞ！
・熟練の設定ファイル職人を必ず1人雇え！絶対にだ！
9: 2022/02/06(日)14:01 ID:23zQCz2C(1/4) AAS
LAMPとか言ってPHPやPerlでバックエンド作ってた狂気の時代よりは遙かにいいと思うけどなぁ
10: 2022/02/06(日)14:21 ID:Fo3XpFx5(1/12) AAS
型バリデーションできない人には（TypeScriptは）難しい
11: 2022/02/06(日)14:32 ID:grglIiaK(1/2) AAS
鯖サイドは外界とのIOが多いから型バリデーションが増えすぎるのが課題かな
あとはPODの濫用が標準的なコーディングスタイルとして受け入れられてる点が問題だと感じた
これじゃ型があってても不変条件を満たしているかまではわからん
12(1): 2022/02/06(日)14:39 ID:Fo3XpFx5(2/12) AAS
いやPODで問題ないでしょReadonlyなりas const付ければいいじゃん
13(1): 2022/02/06(日)14:43 ID:23zQCz2C(2/4) AAS
PODってなんぞ？
Plain Object Darkness？
14: 2022/02/06(日)15:05 ID:Fo3XpFx5(3/12) AAS
型の話だしググった感じPlain Old Data型の事だと思って回答した。
プリミティブ及びプリミティブで構成されたオブジェクトからなるコンストラクタを持たないオブジェクト。ざっくり構造体みたいなオブジェクトって意味かなと。C++用語のようだ
15: 2022/02/06(日)15:19 ID:23zQCz2C(3/4) AAS
つまりPlatina Opal Diamond・・・ってコト！？
16(1): 2022/02/06(日)15:33 ID:grglIiaK(2/2) AAS
>>12
そも辺りはスケールによる
ドメインが薄いならそれでなんとかなるかもしれない
実際の業務システムはどうしてもドメインが大きくなるからちゃんとクラス化しよう
>>13
Plain Old Data
プリミティブとPODの属性だけを持っている単純な型のこと
省2
17(1): 2022/02/06(日)15:46 ID:Fo3XpFx5(4/12) AAS
>>16
『ドメインが薄い』とか何用語だ。ググっても出てこないような独自なのじゃなくて、もうちょい一般的な用語使って？
色々組み合わせるにしてもTS単独で大きなものを組むにしても入り口から出口までimmutableならそれで問題ないと思うんだけど。
デザインパターンにこだわり過ぎてない？
18(1): 2022/02/06(日)16:28 ID:d9+JDYY/(1) AAS
頭悪いんだよ
融通のきかない頭でっかち
19: 2022/02/06(日)16:57 ID:23zQCz2C(4/4) AAS
immutable な POD で FP すれば GOOD じゃん
class は not json serializable ビコーズチョベリバ
20: 2022/02/06(日)17:24 ID:Fo3XpFx5(5/12) AAS
無茶苦茶言ってるかと思ったらちゃんとした内容で草w
21(2): 2022/02/06(日)17:45 ID:cUJBT0A1(1) AAS
>>17
すまん
DDDのドメイン層を連想してくれると思って言った
イミュータブルだから大丈夫ってのは規模の小さなシステムでならたしかに間違いではない
ただ規模が大きくなるにつれてそれでは難しくなるのもまた事実
というのもイミュータブルなPODだと不正なイミュータブルオブジェクトの生成を抑止する方法が残念ながら無い
なのでプログラムにバグが紛れ込みやすくなってしまう
省8
22(1): 2022/02/06(日)18:34 ID:Fo3XpFx5(6/12) AAS
>>21
> イミュータブルなPODだと不正なイミュータブルオブジェクトの生成を抑止する方法が残念ながら無い
不正なイミュータブルオブジェクトの問題ってなに？
イミュータブルオブジェクトがイミュータブルオブジェクトにどうやって影響を与えるのさ。
> 特定の型に対する演算がプログラムのあちこちに分散してしまい凝集度が下がって大混乱
疎結合になってむしろ良いことでは？
TSにおいて凝集度はクラスで担保すべきでは無いでしょ。
23(1): 2022/02/06(日)18:49 ID:K22p1cEy(1) AAS
>>22
不正なイミュータブルオブジェクトを元に生成した別のイミュータブルオブジェクトもまた不正なイミュータブルオブジェクトになる可能性が高い
その連鎖はいずれIO境界まで辿り着きユーザーに間違ったAPIレスポンスを返したりデータベースに間違ったデータを格納したりする
関数の入り口に間違ったオブジェクトを渡したら関数の戻り値もまた間違ったオブジェクトになることは理解できる？
もちろん途中でバリデーションをかけて落とすことはできるだろうがそれではバリデーションが増えすぎて手に負えなくなる
なのでそもそも間違ったオブジェクトを作れないようにしよう
作れないものを関数に渡すことはできないので安心だ
省3
24(1): 2022/02/06(日)19:01 ID:Fo3XpFx5(7/12) AAS
>>23
> 不正なイミュータブルオブジェクトを元に生成した別のイミュータブルオブジェクトもまた不正なイミュータブルオブジェクトになる可能性が高い
繰り返しになるけど、イミュータブルオブジェクトはイミュータブルオブジェクトに影響与えないよ？
> 関数の入り口に間違ったオブジェクトを渡したら関数の戻り値もまた間違ったオブジェクトになることは理解できる？
間違ったオブジェクト渡らないよ？ なんの為の型だと思ってるの？ structとか使わないの？
データの入り口（IO等）で型バリデーションすればあとは型が化けたりしないよ。
25(1): 2022/02/06(日)19:06 ID:AuLf6V7C(1/7) AAS
>>21
> Jsonを必要としているのは主にIOを司る層であってそれはドメイン層ではない
> 異なる層が負うべき責務を別の層が引き受けるのはクリーンな設計とは言えないよね
> なのでドメイン層のクラスがJson Serializableである必要はない
横だがこれは完全に間違ってるだろ。
シリアライズするのは確かにI/O側だが、他言語も含めて今現在は
クラス側にserialize手段を用意するのが主流だ。TS知らんがJSと同じならtoJSON()。
省3
26(1): 2022/02/06(日)19:18 ID:7lkHt7VO(1/9) AAS
>>24
つーか「影響を与える」と私が一言でも書いたかな？
君のレスでは影響を与えるって言葉を変化させるという意味で使ってるように読める
だが私はイミュータブルオブジェクトを元にイミュータブルオブジェクトを「生成する」としか書いてない
modifyとcreateはプログラミングにおいて全く異なる概念なので明確に区別することをおすすめする
PODなら間違ったデータを簡単に渡せる
IO境界だけでバリデーションすればいいという考え方は人間を信用しすぎている
省2
27(1): 2022/02/06(日)19:28 ID:Fo3XpFx5(8/12) AAS
>>26
イミュータブルがイミュータブルなままなら問題ないって話しかしてないよ？
> 人間は間違える
そのためのTypeScriptのstructだよ？
28(1): 2022/02/06(日)19:34 ID:7lkHt7VO(2/9) AAS
>>25
今はなっている？ないないなってない
適当なことを言わんでくれ
JSONやXMLやバイトストリームやフォームデータのような外界の都合を吸収してシステムが扱いやすい形式に変換する(あるいはその逆の流れ)はドメイン層の仕事じゃない
それは外界とやり取りをするための専門の層の仕事だ
29(1): 2022/02/06(日)19:39 ID:7lkHt7VO(3/9) AAS
>>27
structだけじゃ人間は間違えるし問題あるって話をしてる
structではデータ型が合ってるところまでしか保証できない
インスタンスが抱えてるデータが満たすべき条件を満たしていることを保証できるか？そこがポイント
それを保証するにはstructでは不十分で完全コンストラクタを実装したクラスが不可欠
30(1): 2022/02/06(日)20:00 ID:Fo3XpFx5(9/12) AAS
>>29
だからデータの入り口で型バリデーションするんだよ。
君は前スレの最後で暴れてた型バリデーションできない人だったか。話が通じないわけだ。
31(1): 2022/02/06(日)20:04 ID:+4OSlPdc(1) AAS
>>30
だからそれじゃバリデーション箇所が多すぎて手が回らんっての
話がループしてるよ
32(1): 2022/02/06(日)20:06 ID:Fo3XpFx5(10/12) AAS
>>31
だからIOとかfetchみたいなデータの入り口だけなんだよ？
33(1): 2022/02/06(日)20:12 ID:W5e759ag(1) AAS
>>32
またループしてる
そこだけバリデーションしても人間のミスはカバーしきれない
規模の小さなシステムならなんとかなるかもしれないが大きなシステムでは絶対無理
これ以上は無限ループして時間の無駄っぽいね
34: 2022/02/06(日)20:14 ID:Fo3XpFx5(11/12) AAS
>>33
そうだね。止めてもいいよ。
35(2): 2022/02/06(日)20:51 ID:AuLf6V7C(2/7) AAS
>>28
toJSONを呼ぶのはI/O層の仕事で、
toJSONを定義するのはドメイン層の仕事だよ。
つか、そうじゃないと無理なんだよ。
JSONでは対応出来ない型があるから、何が入っているか分からない状態ではシリアライズは出来ない。
逆に言えば何でもシリアライズ出来れば全部I/O側に任せる事は出来るのだが、
現時点で現実的にこれはバイトストリームしかないから、バイナリデータでメモリダンプ形式で良ければ出来るけど、
省1
36(1): 2022/02/06(日)21:05 ID:Y8lZmwFL(1) AAS
>>35
ん？別の人か？
ドメイン側が提供するのは属性の読み取りアクセスと同等の引数を受け取る完全コンストラクタオーバーロードだけ
読み取った属性を外界が要求する形式に整形、シリアライズする(あるいはその逆)のはIO層の仕事
どの外界とどんな形式でやり取りするのか？
ドメイン層はそんなことは知らないし知ってはいけない
だから外界に依存しない純粋な読み取り属性とコンストラクタでIO層と連携する
省1
37(3): 2022/02/06(日)21:14 ID:AuLf6V7C(3/7) AAS
>>36
まあそれでも出来るけど、それが面倒で二度手間で意味無いからみんなPODを使ってるんだと思うぞ。
FizzBuzzEnterpriseEditionとか、君は本気でやりそうだね。
外部ﾘﾝｸ:github.com
38: 2022/02/06(日)21:24 ID:Fo3XpFx5(12/12) AAS
>>37
なんだこれww
39: 2022/02/06(日)21:25 ID:7lkHt7VO(4/9) AAS
>>37
君も話がループしてるね
面倒だからPODで済ませるで通じるちっぽけな規模ならそれでいいんだよ私は一貫してそこは否定してないでしょ？
それなりに規模が大きくなった時の話をしてんの
FizzBuzzをエンタープライズの手法で作るのが馬鹿馬鹿しいのと同じように
エンタープライズのシステムをFizzBuzzを書くようなノリで作るのも馬鹿馬鹿しいってこと
40(1): 2022/02/06(日)21:33 ID:7lkHt7VO(5/9) AAS
>>35
ちなみにバイナリでシリアライズするのはprotocol buffersとか普通にあるよ
で、どんな形式で通信すんの？JSON？バイナリ？XML？CSV？
そんなのはドメイン側は知りたくない絶対に知りたくない
ドメイン側がシリアライズの責務を負ってしまったらじゃあ通信の形式が増えるたびにドメイン側を拡張するのか？
そんなのドメイン側の本質とは全く関係ない通信様式の問題なのに？
41: 2022/02/06(日)22:02 ID:AuLf6V7C(4/7) AAS
>>40
JavaScriptといえばJSON以外無い。
そしてXMLもDOMParserでどうにでもなる。
通信形式をドメイン側と分離するべきなのは「あらゆる形式に対応する」大前提でだ。
今時JSONかXMLしかないし、実際これで事足りるからみんなこれを使ってる。
密結合が駄目なのは「変更される可能性がある箇所」であって、何でもかんでも分離すればいいというものではない。
疎結合にすれば結局間接参照を中に挟むから、実行効率もコード効率も落ちるだけ。
省11
42(1): 2022/02/06(日)22:16 ID:jR6D7dXS(1/3) AAS
PODがダメなら普通にclassを使えばいいじゃない
その class に完全コントスクラタと toJSON を実装すればいい
つか贅沢言いすぎや
TSほどJSON API と神話性高く、堅く書けて、ほどよく柔軟な言語ないで
ワイはバックエンドをGoで書かされているが、言語機能の貧弱さに発狂しそうや
爆速でコンパイルできても爆裂バグだらけじゃ話にならん
43: 2022/02/06(日)22:20 ID:jR6D7dXS(2/3) AAS
>>37
ヤバスギでしょ
44(1): 2022/02/06(日)22:29 ID:7lkHt7VO(6/9) AAS
あらゆる形式に対応するためじゃない責務を明確に分けるため
仮に変更される可能性がなければ１つの関数でシステムを組むのか？そうはならんやろ
変更される予定がなくても責務は分けて作るんだよお仕事ではね
ProtobufはgRPC
バイナリで有名なのだと他にもMessage Packとか
こっちはゲームとかfluentdで有名
君はFizzBuzzのノリでエンタープライズ開発しそうだね
上下前次1-新書関写板覧索設栞歴
あと 352 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.013s