TypeScript part4

TypeScript part4 (376ﾚｽ)
上下前次 1-新

1(1): デフォルトの名無しさん [] 2021/12/30(木) 22:57:02.78 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
2chｽﾚ:tech
part3
2chｽﾚ:tech

2: デフォルトの名無しさん [sage] 2021/12/30(木) 23:05:57.59 ID:18t9WvJQ(1) AAS
乙

3(1): デフォルトの名無しさん [sage] 2021/12/31(金) 00:30:19.49 ID:/NplslaL(1) AAS
>>1
乙

4(1): デフォルトの名無しさん [sage] 2021/12/31(金) 10:54:08.06 ID:jCXckXJt(1) AAS
4.6でmjs対応は入るのかな？

5(1): デフォルトの名無しさん [sage] 2022/01/16(日) 23:06:00.91 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: デフォルトの名無しさん [sage] 2022/02/01(火) 21:25:57.79 ID:RQFIXaIQ(1) AAS
typescript作ったやつ何考えてんだ？
tsconfigにpath alias書いた
babel.configにも書かないと動きません
webpack.condigにも書かないと動きません
jest.configにも書かないとテストできません
あのさぁ俺はビルドツール職人になりたいわけでも設定ファイル書きたいわけでもないんだよ
どうにかしてくれよほんとこのクソッタレエコシステム

7: デフォルトの名無しさん [sage] 2022/02/01(火) 23:58:06.60 ID:0JyqEM+P(1) AAS
typescriptはただのtype check toolです
babelはただのjavascript convert toolです
webpackはただのjavascript concat toolです
jestはただのtesting toolです
全部違うのです

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

8: デフォルトの名無しさん [sage] 2022/02/06(日) 13:50:02.45 ID:26fWvErU(1) AAS
TS童貞案件がようやっと終わった。辛かった。もうやりたくない。有給とります。

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

9: デフォルトの名無しさん [sage] 2022/02/06(日) 14:01:40.08 ID:23zQCz2C(1/4) AAS
LAMPとか言ってPHPやPerlでバックエンド作ってた狂気の時代よりは遙かにいいと思うけどなぁ

10: デフォルトの名無しさん [sage] 2022/02/06(日) 14:21:47.42 ID:Fo3XpFx5(1/12) AAS
型バリデーションできない人には（TypeScriptは）難しい

11: デフォルトの名無しさん [sage] 2022/02/06(日) 14:32:39.20 ID:grglIiaK(1/2) AAS
鯖サイドは外界とのIOが多いから型バリデーションが増えすぎるのが課題かな
あとはPODの濫用が標準的なコーディングスタイルとして受け入れられてる点が問題だと感じた
これじゃ型があってても不変条件を満たしているかまではわからん

12(1): デフォルトの名無しさん [sage] 2022/02/06(日) 14:39:40.47 ID:Fo3XpFx5(2/12) AAS
いやPODで問題ないでしょReadonlyなりas const付ければいいじゃん

13(1): デフォルトの名無しさん [sage] 2022/02/06(日) 14:43:17.15 ID:23zQCz2C(2/4) AAS
PODってなんぞ？
Plain Object Darkness？

14: デフォルトの名無しさん [sage] 2022/02/06(日) 15:05:31.38 ID:Fo3XpFx5(3/12) AAS
型の話だしググった感じPlain Old Data型の事だと思って回答した。
プリミティブ及びプリミティブで構成されたオブジェクトからなるコンストラクタを持たないオブジェクト。ざっくり構造体みたいなオブジェクトって意味かなと。C++用語のようだ

15: デフォルトの名無しさん [sage] 2022/02/06(日) 15:19:09.13 ID:23zQCz2C(3/4) AAS
つまりPlatina Opal Diamond・・・ってコト！？

16(1): デフォルトの名無しさん [sage] 2022/02/06(日) 15:33:19.89 ID:grglIiaK(2/2) AAS
>>12
そも辺りはスケールによる
ドメインが薄いならそれでなんとかなるかもしれない
実際の業務システムはどうしてもドメインが大きくなるからちゃんとクラス化しよう

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

17(1): デフォルトの名無しさん [sage] 2022/02/06(日) 15:46:19.86 ID:Fo3XpFx5(4/12) AAS
>>16
『ドメインが薄い』とか何用語だ。ググっても出てこないような独自なのじゃなくて、もうちょい一般的な用語使って？

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

18(1): デフォルトの名無しさん [sage] 2022/02/06(日) 16:28:56.52 ID:d9+JDYY/(1) AAS
頭悪いんだよ
融通のきかない頭でっかち

19: デフォルトの名無しさん [sage] 2022/02/06(日) 16:57:31.55 ID:23zQCz2C(4/4) AAS
immutable な POD で FP すれば GOOD じゃん
class は not json serializable ビコーズチョベリバ

20: デフォルトの名無しさん [sage] 2022/02/06(日) 17:24:04.04 ID:Fo3XpFx5(5/12) AAS
無茶苦茶言ってるかと思ったらちゃんとした内容で草w

21(2): デフォルトの名無しさん [sage] 2022/02/06(日) 17:45:58.69 ID:cUJBT0A1(1) AAS
>>17
すまん
DDDのドメイン層を連想してくれると思って言った

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

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

22(1): デフォルトの名無しさん [sage] 2022/02/06(日) 18:34:09.22 ID:Fo3XpFx5(6/12) AAS
>>21
> イミュータブルなPODだと不正なイミュータブルオブジェクトの生成を抑止する方法が残念ながら無い
不正なイミュータブルオブジェクトの問題ってなに？
イミュータブルオブジェクトがイミュータブルオブジェクトにどうやって影響を与えるのさ。

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

23(1): デフォルトの名無しさん [sage] 2022/02/06(日) 18:49:51.15 ID:K22p1cEy(1) AAS
>>22
不正なイミュータブルオブジェクトを元に生成した別のイミュータブルオブジェクトもまた不正なイミュータブルオブジェクトになる可能性が高い
その連鎖はいずれIO境界まで辿り着きユーザーに間違ったAPIレスポンスを返したりデータベースに間違ったデータを格納したりする

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

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

24(1): デフォルトの名無しさん [sage] 2022/02/06(日) 19:01:45.12 ID:Fo3XpFx5(7/12) AAS
>>23
> 不正なイミュータブルオブジェクトを元に生成した別のイミュータブルオブジェクトもまた不正なイミュータブルオブジェクトになる可能性が高い
繰り返しになるけど、イミュータブルオブジェクトはイミュータブルオブジェクトに影響与えないよ？

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

25(1): デフォルトの名無しさん [sage] 2022/02/06(日) 19:06:18.29 ID:AuLf6V7C(1/7) AAS
>>21
> Jsonを必要としているのは主にIOを司る層であってそれはドメイン層ではない
> 異なる層が負うべき責務を別の層が引き受けるのはクリーンな設計とは言えないよね
> なのでドメイン層のクラスがJson Serializableである必要はない
横だがこれは完全に間違ってるだろ。

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

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

上下前次 1-新書関写板覧索設栞歴

あと 351 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.949s*