[過去ﾛｸﾞ] TypeScript part3 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
1(1): 2018/04/26(木)21:48 ID:mMDBzDaB(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
省1
922(1): 2021/12/21(火)19:39 ID:S6JYHyb7(1/3) AAS
外部ﾘﾝｸ:github.com
923: 2021/12/21(火)20:01 ID:ESVu6HO8(2/3) AAS
>>922
どうも
なかなか良さそうだけどちょっと大変そう
普通の型を先に定義してパーサーを生成するのは難しいんですかね?
924: 2021/12/21(火)20:08 ID:fpjBPgEH(1) AAS
TypeScriptのtypeやinterfaceからjsonschemaを生成するライブラリがあるから
それを使ってタイプガード書けば楽よ。
925(1): 2021/12/21(火)20:09 ID:S6JYHyb7(2/3) AAS
外部ﾘﾝｸ:github.com
926: 2021/12/21(火)20:12 ID:S4hmWBPH(2/2) AAS
そういえばAJVがタイプガードに対応してたな
927: 2021/12/21(火)20:17 ID:ESVu6HO8(3/3) AAS
>>925
いいかも
あとはanyの代入を自動的に置き換えることができれば完璧
928: 2021/12/21(火)20:28 ID:S6JYHyb7(3/3) AAS
string -> Date のような transform をしたいなら、型から自動生成を期待するよりもスキーマで変換ロジックを書いて型を導出するアプローチの方が扱いやすい
929: 2021/12/23(木)16:09 ID:qSHzxodN(1) AAS
axiosでの（非同期）通信結果から
最終的にpromiseを外した形でresponse扱いたいんだけど
どうやるとできるのでしょうか？
function的な奴で非同期通信して
そのfunction自体はpromiseでない値を返したいんだけど。。。
awaitやろうと思うと
そのfunctionはasyncになって
省6
930: 2021/12/23(木)20:50 ID:aMbIyyBR(1) AAS
不可能です
直接 XMLHttpRequest を同期モードで使用してください
931: 2021/12/23(木)22:47 ID:j1Nwu6l7(1) AAS
非同期を同期にはできない。
これ、初心者の頃は辛かったけど、気がついたら慣れてたし不便さより便利さを感じるようになったから人間の適応能力ってすごい。
932: 2021/12/24(金)11:16 ID:8YLKxFwi(1) AAS
うーんわからん
type X = A & { foo: string}
ってやるとXがanyと判定される現象が起きてて原因が全くわからない
Aはちゃんと型が認識されてる
const a: A = { 略 }
a.
ここまで打てばインテリセンスが出てくる
省2
933: 2021/12/24(金)12:01 ID:vCO0x3fk(1) AAS
export type X = A & { foo: string }
const x: X
これは型が生きてるしインテリセンスも出る
import { X } from ‘…’
const x: X
これはanyになってしまう
ファイルを跨がなければおkみたい
省2
934: 2021/12/25(土)12:39 ID:mJNzEC98(1/3) AAS
色々調べて行き詰まったんだけどこれで合ってる？
babelのpreset-typescriptはTSから形情報を落としてるだけ
なのでtsconfigを無視する
なのでproject referencesも無視される
プロジェクト分割したい場合のオフィシャルな手段がない
なのでプロジェクト分割したければ各自好きな方法でハックするしかない
暫定対応として被参照側のプロジェクトでwatch & buildを仕掛けて
省1
935: 2021/12/25(土)13:16 ID:YYlOH5kW(1/4) AAS
babel がどう動くかなんて tsc には関係ないだろ
それともあなたのエディタは babel で型情報を解析しているのか？
936: 2021/12/25(土)13:22 ID:YYlOH5kW(2/4) AAS
コンパイル済みのファイルに型情報がないという話なら、型定義ファイル(.d.ts)も出力しないとそりゃそうだろと
937: 2021/12/25(土)13:40 ID:mJNzEC98(2/3) AAS
プロジェクト分割についてはどう考えますか？
938: 2021/12/25(土)13:54 ID:YYlOH5kW(3/4) AAS
情報を小出しにせず、問題が再現するリポジトリ丸ごと上げるかせめてファイル構造や各種設定ファイルの内容など全部書き出して
& がダメなのかファイルを跨ぐのがダメなのかプロジェクト分割がダメなのか話がどんどん移っててわからんぞ
939: 2021/12/25(土)14:17 ID:YYlOH5kW(4/4) AAS
これ別人の別の話か…そうだったらスマン
940: 2021/12/25(土)14:25 ID:mJNzEC98(3/3) AAS
別ですね
単刀直入に言うとbabel & preset -typescript環境で正しいプロジェクト分割のしかたを聞きたかった
941: 2021/12/26(日)11:58 ID:yczrikVs(1) AAS
色々と試して結論が出た
プロジェクト参照は諦めてシンプルに相対パスでimportすることにした
依存パッケージを全てのプロジェクトに入れなければならないのが面倒だけど妥協
ようするに昔VB6やC言語などでよくやってたDLL化せずにコードファイルを共有するスタイル
モダンな言語でやることとは思えないけど何日も調べてできないなら仕方ない
942: 2021/12/26(日)12:26 ID:6ScHvZpk(1) AAS
バベるのが悪い
943: 2021/12/26(日)16:05 ID:SvIlyqah(1) AAS
でもフレームワークがバベれって言うんです
944: 2021/12/26(日)16:14 ID:imvxWhRx(1) AAS
これを
babel_proj
webpack_proj
tsc_proj
tsconfig.json
tsc_lib_1
tsconfig.json
省13
945: 2021/12/28(火)17:28 ID:X7A0KCIT(1) AAS
バックエンドはexpress一択？
946: 2021/12/28(火)20:29 ID:qjWVy58S(1) AAS
そんな🍌
947: 2021/12/28(火)23:38 ID:QExnrlZb(1) AAS
僕はFastify!
948: 2021/12/29(水)02:36 ID:tTEsT75E(1) AAS
nestjsはレガシーなデコレータ依存がなあ
949: 2021/12/30(木)13:04 ID:8IVD/YcY(1/4) AAS
そもそもサーバーサイドにTS選ぶメリットが無い
950: 2021/12/30(木)13:42 ID:XEA11GKy(1/15) AAS
JavaScriptがって話ならわからんでもないが
951: 2021/12/30(木)13:49 ID:8IVD/YcY(2/4) AAS
TS始めた時からずっと思ってたけど型が簡単に嘘を付ける言語仕様はバックエンドでは到底受け入れられんわ
フロントエンドでは気楽さと壊れやすさのトレードオフってことで受け入れるけど
952: 2021/12/30(木)13:53 ID:XEA11GKy(2/15) AAS
じゃあC/C++なんかもダメだな
953: 2021/12/30(木)14:00 ID:qk2rIpzk(1) AAS
バリデーションもできない奴がなんか言ってら
954: 2021/12/30(木)14:01 ID:8IVD/YcY(3/4) AAS
そうだね
バックエンドでは実質Cと大差ない
ちょっとだけ楽できるけど
955: 2021/12/30(木)14:10 ID:XEA11GKy(3/15) AAS
じゃあ逆にバックエンドで受け入れられる言語ってなんだろう？JavaとかRustくらい？
956: 2021/12/30(木)14:23 ID:8IVD/YcY(4/4) AAS
JavaとC#だね
型安全性がしっかりしてて実績も多い言語って言えばそれぐらいじゃないか？
957: 2021/12/30(木)14:42 ID:XEA11GKy(4/15) AAS
んー、つまり
>TS始めた時からずっと思ってたけど型が簡単に嘘を付ける言語仕様はバックエンドでは到底受け入れられんわ
JavaとC#以外の言語を触るたびに同じように思ったってことでいいのかな？
958: 2021/12/30(木)15:01 ID:Q5xANRZc(1) AAS
まあ、そうだね
959: 2021/12/30(木)16:23 ID:se0ux0qB(1) AAS
C♯やJavaよりはTypeScriptやRust選びますわ
960: 2021/12/30(木)16:31 ID:tab5g/QS(1/2) AAS
そしてバグが出ると
961: 2021/12/30(木)16:52 ID:XEA11GKy(5/15) AAS
まるでTypeScriptやRustを選ぶとバグが出るかのような物言いだが
C#やJavaを選べばバグが出ないというわけでもあるない
962(1): 2021/12/30(木)17:38 ID:tab5g/QS(2/2) AAS
TypeScriptは型が簡単に嘘をつけるのでバグが出やすい
型安全性がバグ削減に貢献しているのはプログラマの常識
963(1): 2021/12/30(木)17:46 ID:18t9WvJQ(1/6) AAS
それはあなたがバリデーション書けないからでしょ？
964(1): 2021/12/30(木)17:56 ID:XEA11GKy(6/15) AAS
>>962
具体的にどういうのを言っている？まさか故意にasでキャストした場合の話じゃないだろうが
965: 2021/12/30(木)18:04 ID:cY7zFSmj(1) AAS
その返答で書けないということが露呈したゾ
966(2): 2021/12/30(木)19:17 ID:zuTar3e4(1/7) AAS
>>963
型が嘘をつけることとバリデーションは別次元の話
>>964
明示的キャストなんかしなくてもTSにはいくらでも型が嘘をつく罠がある
代表的なところだとjsonのパース、DBのI/O、api I/O、野良ライブラリのI/O、、、
967(2): 2021/12/30(木)19:25 ID:zuTar3e4(2/7) AAS
言語仕様を変えるべきなんだろうな
typeで宣言した変数への代入は実行時に型チェック付きのマッピングにトランスレートすべき
ついでに言うとtypeで未定義の属性はマッピングするときにundefinedにすべき
これだけでTypeScriptによくある馬鹿馬鹿しいバグがかなり減るはずだ
type Foo {
x: string;
y: number; }
省4
968(1): 2021/12/30(木)19:33 ID:18t9WvJQ(2/6) AAS
>>967
いやそれはそのコードがバカじゃん……
969: 2021/12/30(木)19:34 ID:zuTar3e4(3/7) AAS
Javaは最も優れた設計でそもそもanyみたいな言語仕様がない
Objectは定義できるが暗黙のキャストでスルッと行くなんてことはあり得ないし無理やりキャストしたって実行時に必ず例外が飛ぶ
C#はanyに近いものでdynamicというのがあるがこれも誤ったキャストには実行時に例外が飛ぶ
どちらも型が嘘をつかないように言語基盤がしっかり担保してくれるから型を信用していい
当たり前のことを当たり前にやってくれる堅実な言語だ
970(1): 2021/12/30(木)19:36 ID:zuTar3e4(4/7) AAS
>>968
このコードは説明のためのスニペットだ
現実的にこんなコード書くわけないだろ
現実的には先に挙げたような状況でanyと戦わなければならない
971(1): 2021/12/30(木)19:44 ID:18t9WvJQ(3/6) AAS
>>966
>>970
なんの為のバリデーションとタイプガードだよ。
どこで間違った型が入りうるかなんか普通把握できるでしょうに
972(2): 2021/12/30(木)19:48 ID:pcTvcAXH(1) AAS
Javascriptのスーパーセットという最大のセールスポイントを見てなさすぎだろ
構造的部分型も便利だしany型なんて使うときには型ガードするよね
型に関してはJavaより好きだわ
973(1): 2021/12/30(木)19:51 ID:HvA/IBjD(1) AAS
Nullableを長年放置してたり文化的にも言語的にもImmutableを軽視してきたJavaもちょっと信用できないですね
974(1): 2021/12/30(木)19:59 ID:zuTar3e4(5/7) AAS
>>971
バリデーションってのは値が正しいかどうか検証するものであって型が嘘をついているかどうか調べるためのものじゃない
どこで型が嘘をついているか確実に判断することはむずかしい
自分達の管理するコードベースの外界とのI/Oは全て疑わしい
先も述べたようにJsonのパース、ApiのIO、DBのIO、野良ライブラリのIO
疑わしい箇所が多すぎる
型が嘘をつかない言語なら外界とのI/Oの型定義が信用できる
省3
975: 2021/12/30(木)20:05 ID:zuTar3e4(6/7) AAS
>>972
構造的部分型もわかりにくいバグの温床だな
anyよりは全然マシだが
まあ楽なのは楽だよそれはわかる
ただ楽なのと安全でりかいしやすいのとは同じじゃないからね
typeは俺が言ったような真の意味で型安全を担保するための仕様
interfaceは構造的部分型でサボるための仕様
省1
976: 2021/12/30(木)20:09 ID:zuTar3e4(7/7) AAS
>>972
セールポイントであり最大の弱点でもある
思い切って互換性切った方が絶対上手くいってた
>>973
まあ先発の古い言語だからある程度は仕方ないね
Null安全は対応してきてる
イミュータブルは昔から使えてた(final)
977(1): 2021/12/30(木)20:42 ID:18t9WvJQ(4/6) AAS
>>974
型さえあってりゃどんなライブラリも安全安心だと思っているのか……
978(1): 2021/12/30(木)20:51 ID:iK2C+Pgo(1) AAS
>>977
ちゃんと読めてます？
「信用できない領域がグッと減る」って書いてあるでしょ？
型安全であれば全てが安全なんてことはない
これは常識
でも型安全ならそうでない場合に比べて大部分が安全になる
これも常識
省4
979: 2021/12/30(木)21:06 ID:18t9WvJQ(5/6) AAS
>>978
お、これは失敬
980: 2021/12/30(木)21:26 ID:XEA11GKy(7/15) AAS
>>966
あんたの言う「型が嘘をつく」の意味がよくわからんが。オレオレ用語じゃなくて一般的な用語で説明してくれんかな。
>先も述べたようにJsonのパース、ApiのIO、DBのIO、野良ライブラリのIO
>疑わしい箇所が多すぎる
嘘をつくもなにも、JSONはそのJSON自体の構造以上の型を主張したりはしないが。
それを勝手に別の型と見做したとしたらそのコードの方に問題があるわけだろう。
981(1): 2021/12/30(木)21:31 ID:XEA11GKy(8/15) AAS
>>967
ああなるほど。
型の合わせ方がわからなくてasやanyで誤魔化したらバグったってのの逆恨みか。
982(2): 2021/12/30(木)21:32 ID:yBt1j67p(1/4) AAS
型が嘘をつくってのは
コンパイル時に指定した型以外の値が入ってることがある
入れることが簡単にできるということ
type X = { foo: string }
function xxx(): X
例えば↑こういう定義があったとする
実際にxxx()の戻り値が文字列型のfooという属性を持っているかどうか？
省3
983: 2021/12/30(木)21:33 ID:yBt1j67p(2/4) AAS
>>981
ちげーよ
984: 2021/12/30(木)21:36 ID:yBt1j67p(3/4) AAS
JavaやC#ではこういう事は起こらない
正確には低レベルAPIでメモリを不正に書き換えれば起こせるが無理すれば起こせないこともないと言った程度
JavaやC#ではXがfooという文字列型の属性を持っていてxxxの戻り値の型がXであると書いてあったらそれを信用していい
JavaやC#は型が嘘をつかないからだ
985(2): 2021/12/30(木)21:37 ID:XEA11GKy(9/15) AAS
>>982
？
おめーのtscはそれコンパイルエラーにしてくれないの？
986: 2021/12/30(木)21:39 ID:rc2c+xCv(1/2) AAS
>>985
本当に恥ずかしいからお前はもう黙ってろ
987(1): 2021/12/30(木)21:39 ID:yBt1j67p(4/4) AAS
>>985
しない
988(1): 2021/12/30(木)21:42 ID:18t9WvJQ(6/6) AAS
そんなにTSが嫌いならずっとJavaなりC♯なり使ってれば良いじゃん
989(1): 2021/12/30(木)21:45 ID:XEA11GKy(10/15) AAS
>>987
コンパイルエラーにならない function xxx() の例よろ。
990: 2021/12/30(木)21:57 ID:hxNkeOah(1/4) AAS
>>988
そだね
選択権があるプロジェクトなら必ずそうしてるよ
991(1): 2021/12/30(木)21:59 ID:hxNkeOah(2/4) AAS
>>989
function xxx(): X {
return {
foo: bugLib.getStringValueEvil();
}
}
992(1): 2021/12/30(木)22:09 ID:XEA11GKy(11/15) AAS
>>991
？
bugLib.getStringValueEvil() がstringと宣言されていればコンパイルが通るけどそっちが嘘だったって話？
993: 2021/12/30(木)22:21 ID:hxNkeOah(3/4) AAS
>>992
そう
994(1): 2021/12/30(木)22:24 ID:XEA11GKy(12/15) AAS
じゃあ bugLib.getStringValueEvil() はどうやって嘘をついたわけ？堂々巡りだが。
995(1): 2021/12/30(木)22:28 ID:hxNkeOah(4/4) AAS
>>994
さあどうだろうな？
だから>>982でソースコード隅々まで見たら…って書いたんだけどね
JavaやC#だったら型だけ見ればああこの戻り値のfoo属性は文字列なんだなと信頼できる
ソースコードを隅々まで見る必要はない
なぜなら型が嘘をつかないからね
996: 2021/12/30(木)22:34 ID:rc2c+xCv(2/2) AAS
anyなんかから型変換する際にランタイムチェックを追加するオプションはあっていいとは思うがTypeScriptにとってのno goalだから無いのも仕方ない
型安全性だけに拘るならTypeScriptは適当じゃないのはそれはそう(そもそもがoptional typeでしかない)
他の要素も考慮すれば個人的には悪い選択肢じゃないのでJavaScriptよりはTypeScriptを選ぶけども(C#やJavaと比較するかは目的による)
997: 2021/12/30(木)22:38 ID:XEA11GKy(13/15) AAS
ようはTypeScriptに限らず強い型付け以外全否定ってことかね
998: 2021/12/30(木)22:56 ID:XEA11GKy(14/15) 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
省4
999: 2021/12/30(木)22:57 ID:XEA11GKy(15/15) AAS
TypeScript part4
2chｽﾚ:tech
1000: 2021/12/30(木)23:01 ID:chdQ4etC(1) AAS
>>995
それって型指定のバグなわけで、バグを回避する為に他の言語でもソースコード全部読む必要あるのは変わらないのでは……
1001(1): 1001 ID:Thread(1/2) AAS
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 1344日 1時間 13分 15秒
1002(1): 1002 ID:Thread(2/2) AAS
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
省7
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.107s*