[過去ﾛｸﾞ] TypeScript part2 [転載禁止]©2ch.net (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
605(1): 2017/04/13(木)01:13 ID:rVYtPk7E(4/5) AAS
const STR = "str";
type STRT = "str";
const ABC3: STRT=STR;
"str"を2回書かずにABC3が作れればそれでいいんだけど。
606: 2017/04/13(木)01:20 ID:IFJ42qsr(5/6) AAS
>>605
const STR = "str";
const ABC3 = STR;
607: 2017/04/13(木)06:09 ID:32cPtkAw(1) AAS
type STRT = typeof STR
608: 2017/04/13(木)08:01 ID:rVYtPk7E(5/5) AAS
すまん、確かに思い違いしていたようだ。ありがとう。
609: 2017/04/13(木)13:00 ID:XE18llYI(1) AAS
恥ずかしか
610: 2017/04/13(木)20:33 ID:IFJ42qsr(6/6) AAS
認めて謝って感謝してるだけ立派だよ
611(1): 2017/04/16(日)20:56 ID:nOhMz2bP(1) AAS
TypeScriptでExpressを使う場合について教えてください。
express-generatorなどのサンプルコードだと new Error したオブジェクトにstatusを
突っ込んで返していたりしますが、ここ、TypeScript的にはどうするのが普通でしょう？
みなさん自前でErrorのサブクラスを定義しているんでしょうか？あるいはどこかに
定番のものがあったりするんでしょうか？
612: 2017/04/16(日)22:51 ID:SqhlDt4o(1) AAS
「どうでもいい」が普通じゃない?
そんなもんエラーハンドラで受けて適当にトレースとエラーメッセージ出したら終わりなんだから
型なんぞ要らん
手段と目的を履き違えるな
613: 2017/04/16(日)23:30 ID:R4TJTEcK(1) AAS
>>611
jsonとして扱えるようにインターフェース定義にしておいたほうが無難な気がする。
シリアライズしても簡単にもとに戻せるし。
614: 2017/04/17(月)00:09 ID:CyuLkfZA(1/2) AAS
そういうもんですかね？
エラーを表示するだけとは言ってもstatusは正しくセットしなきゃならないわけで、
TypeScriptを使う以上そこも型安全にやりたいってのは自然だと思うんですが。
そこだけtslintの警告をネグるのも気持ち悪いし。
615: 2017/04/17(月)00:24 ID:GVmJ+xSa(1) AAS
アプリケーションの仕様としてエラー用のクラスを定義します。Errorのサブクラスだったり新規に自前のクラスを用意するかはケースバイケース。
当然途中で変わることもあり得ます。その際はきちんと他のメンバーと情報共有します。
616: 2017/04/17(月)07:32 ID:k0Nquy2H(1) AAS
自分は簡単なアプリではHttpErrorみたいなクラスを定義して使ってる。
もっと複雑なアプリだと、業務エラーのコードとHTTPのエラーコードで
もう一階層作ったりもするけど。
だが、これが推奨なやり方なのかは分からん。俺も知りたい。
617: 2017/04/17(月)08:40 ID:CyuLkfZA(2/2) AAS
ありがとうございます。
statusというプロパティにステータスを返すのは決まっているんだからどこかに
出来合いのものがあるかと思ったんですが、やっぱり自前なんですね。
618(1): 2017/04/20(木)11:26 ID:T7Zz78Cb(1/2) AAS
npm linkを駆使してtypescriptでビジネスロジックを外部モジュールにしてるんだけど
tsc -wで自動コンパイルはできるんだけど
定義ファイルも同時に生成するコマンドオプションってないかな？
619: 2017/04/20(木)11:42 ID:T7Zz78Cb(2/2) AAS
>>618
すんません -w -dですね。ホント申し訳ない
620(1): 2017/04/21(金)21:22 ID:Uj6lwvRH(1) AAS
TypeScriptで動的なキャストみたいなことってできるんでしょうか？
// どこかで定義されたclass
class X {}
interface AX extends X {
a: string;
}
func(x: X) {
省4
621(1): 2017/04/22(土)00:25 ID:NysYFg8M(1) AAS
>>620
let ax=<AX>x
でキャスト出来る。
インターフェースが存在するかどうかはチェックはされないから注意。
622: 2017/04/22(土)10:55 ID:scznilxz(1) AAS
>>621
ありがとうございました。うまくいきました。
623: 2017/04/26(水)12:25 ID:mOputr8e(1) AAS
f8appのコード読んでんだけど
flowって驚くほどtypeScriptと似てるね。
んでReduxのアクションな書き方が参考になる。
type ParseObject = Object;
export type Action =
{ type: 'LOADED_ABOUT', list: Array<ParseObject> }
| { type: 'LOADED_NOTIFICATIONS', list: Array<ParseObject> }
省3
624: 2017/04/27(木)14:10 ID:2oprloyo(1) AAS
いやーTypeScriptって本当にいいものですよね
恥ずかしいソース書いてもコンパイルすればそれなりの形になってますし
全ソースが1つにまとまったjsファイルを見るとカタルシスを覚えます
javascriptを扱うのに最高の言語です
625: 2017/04/27(木)16:28 ID:a+4IBLmk(1) AAS
開発用と納品用でコードわけられるとかありがたい
626(1): 2017/04/27(木)17:45 ID:/9P4GBtP(1) AAS
minifyが出来なくて悩んでおります。
Targetをes5にしてもエラーが出る。
627: 2017/04/28(金)08:31 ID:IMlkcp1b(1/2) AAS
>>626
結局該当箇所っぽいところの構造を変えて解決した
case 'Text':
{
let text: Text;
/* ごちゃごちゃした処理*/
text = {
省20
628(1): 2017/04/28(金)09:00 ID:IMlkcp1b(2/2) AAS
すいませんminifyの件ですが一番の問題は
外部ライブラリとして別にパッケージを作ってnpm linkしていたんですが
その外部ライブラリのtsconfigの設定でtargetをes2015にしていたのが原因のようです。
npm上で公開してるライブラリってes2015のものとes5のものが混ざってるんですかね？もしそうならminifyのとき問題でそう。
そろそろブラウザもes2015に対応してきたし外部ライブラリもes2015でいいんじゃないかと思いましたがまだまだes5のほうがいいんですかねー
629(1): 2017/04/28(金)15:19 ID:ZmVIrkLy(1) AAS
Announcing TypeScript 2.3
外部ﾘﾝｸ:blogs.msdn.microsoft.com
630(1): 2017/04/28(金)21:52 ID:CfPEmNk9(1) AAS
>>628
ちゃんと設定すれば、TypeScriptが変換してくれるんじゃないの？
631: 2017/04/29(土)00:20 ID:Ix6JNrOr(1) AAS
>>630
targetをes5にしてlibに”dom”と”es2017”を設定したら
ちゃんとminifyもできつつasync await とかobject.assaignとか使えました。
typescriptの問題というよりuglify-jsの問題ってことすね。
632: 2017/04/29(土)08:40 ID:fFSdol5k(1/3) AAS
>>629
ギャー！！
適用したらエラーだらけになった！！
633: 2017/04/29(土)09:01 ID:fFSdol5k(2/3) AAS
アンインストールしたらVSでtsファイル開いても識別子の色分けとかインテリセンスが出てこなくなってVSぶっ壊れたわ
再インストールだなこりゃ
634: 2017/04/29(土)09:05 ID:fFSdol5k(3/3) AAS
2.3アンインストール後に再度2.3インストールしてもぶっ壊れたまま
迂闊に入れないほうがいいなこれ
635: 2017/04/29(土)14:53 ID:D/W8thCK(1) AAS
馬鹿には無理
636: 2017/04/30(日)09:24 ID:V5NYhrdd(1) AAS
不細工ハゲが偉そうに
637(1): 2017/04/30(日)11:46 ID:A3RU6CWl(1) AAS
不細工じゃねーし！
638: 2017/04/30(日)12:00 ID:0Jw8BHIT(1) AAS
相対パスでimportしようとすると from ’../../lib/a’ と書くことが多いのですが
..を何とかしようと思いtsconfigでbaseUrlを設定したところ
from ‘lib/a’とかけるようになって素敵だったんですが
生成したjs側で同じように相対パスを使わない方法にできずjs側からimportできなくなりました。
どうすればいいんですかね
639: 2017/04/30(日)12:07 ID:VPr4LyhY(1) AAS
deployしてみ
640: 2017/04/30(日)13:53 ID:bwYTEyCy(1) AAS
おい、>>637に突っ込めよ！
641: 2017/04/30(日)14:18 ID:uAfPQWLU(1) AAS
ハゲに付ける薬なし
642(4): 2017/05/01(月)13:56 ID:1hc/XS6U(1/2) AAS
jsonのデシリアライズ等で得られた任意のオブジェクトが指定のinterfaceに適合するかどうか
簡単に判定する方法ってないでしょうか？
実行コストがかかるのはしょうがないので、npmのライブラリでもあれば助かります。
643(1): 2017/05/01(月)14:12 ID:y6q+iQAV(1/2) AAS
実行時に型情報は取得できないので無理
644(1): 2017/05/01(月)14:56 ID:dX7m944z(1) AAS
>>642
俺は各interfaceの定義にtypeを入れてる。
645(1): 2017/05/01(月)15:43 ID:FD8bdV22(1/2) AAS
>>642
あーなるほどtypesciptのinterface要件を満たしてるかチェックするライブラリかー。
interfaceに対するメタプログラミングができる仕組みってtypescript側に用意されてんのかな
646(2): 2017/05/01(月)16:42 ID:y6q+iQAV(2/2) AAS
ランゲージサービスから情報引っ張ってコード生成するまでやればできる
647(1): 2017/05/01(月)18:22 ID:s/VndsAg(1) AAS
>>642
初心者なんで教えて欲しいんですが
どう言う状況でそう言うのが必要に
なるんですか?
648: 2017/05/01(月)22:27 ID:1hc/XS6U(2/2) AAS
>>643-647
回答ありがとうございます。
外部から入手したany型のオブジェクトに対して、一度型チェックしたらTypeGuardの下で
扱えたら便利だと思ったんですが、そう単純なものはなさそうですね。
interface毎にUser-Defined Type Guard Functionてのを用意するのが今のところ
いちばんシンプルですかね。
649: 2017/05/01(月)23:04 ID:FD8bdV22(2/2) AAS
>>646
interfaceをparseするの簡単にできたわ
ジェネレータは作れそう。後はObjectを チェックするコードをかければ、、、
そっちがよくわかんないな。
650(1): 2017/05/02(火)00:15 ID:79+IkLPk(1) AAS
JSON限定でいいならJSON Schema生成するだけじゃね
651(1): 2017/05/05(金)00:50 ID:oXL5lOIH(1) AAS
webpackでtypescript使う時にts-loaderがtypeRootsオプションを認識してくれないような。
自作の定義ファイルを読みに行ってくれない。
結局nodes_modules/@types/においたらうごくんだけど。なんだかなぁ
652: 2017/05/05(金)10:24 ID:E/UcmmKD(1) AAS
-g
653: 2017/05/07(日)12:47 ID:tRHTfDHo(1) AAS
redux のreducer書く時型付きじゃないと死ぬ。
素のjsでよく書ける人いるなぁ
654: 2017/05/10(水)22:53 ID:TahTqR8d(1) AAS
>>650
これやってみようかと思ったけど、class定義からschema生成するか逆にschemaから生成するか、
どっちがいいか悩ましいなぁ。
655: 2017/05/11(木)06:23 ID:6GcWGmCe(1) AAS
JSON Schemaの方が表現力がずっと高いから、
実用的に意味があるのは後者だろうね
型だけなら全部空文字と0とfalseでもいいんだから
656: 2017/05/11(木)06:40 ID:Uo4oHcSP(1) AAS
JSON Schemaからのdts生成は既存のツールがいくつかあるみたいだな
逆はバリデーションとしてはほぼ無意味かと
657: 2017/05/11(木)21:37 ID:Foo76VTo(1) AAS
目的が上で書いているようにシリアライズ-デシリアライズされたオブジェクトの型の復元なら、
interface定義を自分で書いてschemaは裏方というのが自然だとは思うが。
ただ、schemaを生成する方のツールは技術的にハードルが高いせいか選択肢があまりないな。
658: 2017/05/15(月)21:27 ID:ZdTGw5ha(1/2) AAS
そもそもシリアライズという発想自体がJavaScript的でないと思うけどね
データスキーマから入るのがJSでしょ
659: 2017/05/15(月)22:43 ID:JDFIgPdx(1/2) AAS
シリアライズってJSONのこと言ってるわけだろ。
言語自体にサポートの無いC++などと比べてもよっぽど馴染みがあると思うが。
で、JavaScriptだとそこまででいいんだけど、TypeScriptで型まで戻すにはどうするか？って話だろ。
660: 2017/05/15(月)23:00 ID:ZdTGw5ha(2/2) AAS
バリデーションとシリアライズが別系統なのは煩雑じゃない?
コードだけで全部定義するならアノテーション使うなりしてJSON Schema相当の表現力は欲しいし、
割り切って別にするならシリアライズ系の方は中途半端なバリデーションなんかいっそ無しにて
ノーチェックでいいと思うよ
661: 2017/05/15(月)23:16 ID:JDFIgPdx(2/2) AAS
うん、上から目線で何か言いたいという気持ちだけは伝わった。
662(1): 2017/05/15(月)23:59 ID:5dbS9yKw(1) AAS
外部ﾘﾝｸ:stackoverflow.com
Yesの回答にそれっぽいコードがあるが本当に動作するのか疑問。
他はSchemaを使う回答だが、よほどでないと大袈裟な気も。
663: 2017/05/16(火)00:46 ID:6a8gh5yc(1/5) AAS
自分でコンパイラ拡張して実装したみたいだけどこういうの本家の更新についてけずに陳腐化するのが常だから使えない
ついでにビルドツールなどのエコシステムも使えない
664: 2017/05/16(火)07:36 ID:MR0lnxJG(1/2) AAS
正攻法だとanyを受け取って目的の型のオブジェクトにして返す関数を用意することになるんだろうが、
やることは同じようなものなのにそれぞれ型ごとに個別に用意しなければならないのが煩雑だな。
よっぽど重要な型でしかやりたくない感じ。
確かにこれが、型ガードの感覚で気軽に使えるようになったら便利だと思うけど。
665: 2017/05/16(火)08:02 ID:64KrDfHK(1/3) AAS
TypeScriptの思想的にもスキーマありきで型は後付けの方が自然だと思うわ
666(1): 2017/05/16(火)08:27 ID:MR0lnxJG(2/2) AAS
その「スキーマ」が何を指しているかよくわからんな。
まさか「JSON schemaありき」って言いたいわけじゃないだろうが。
667: 2017/05/16(火)09:01 ID:64KrDfHK(2/3) AAS
>>666
別に実装は何でもいいんじゃない?
先にJSONドキュメントそのものを設計しろってこと
668: 2017/05/16(火)10:11 ID:Jgr59aIg(1) AAS
objectを先に設計してstringifyの方が一般的だと思うが。
つまりtsなら型が先。
669: 2017/05/16(火)13:21 ID:xkpWN83w(1) AAS
jsonに対するinterface適用にわざわざスキーマ使うのはだるいな。
やはりメンバにtypeとかを事前に追加しておいて、そこを見てキャストさせるほうが楽だわ。もちろんそのjson自体が自分で改変可能である必要はあるが。
670: 2017/05/16(火)13:49 ID:6a8gh5yc(2/5) AAS
言語がサポートしてるのはその使い方だからな
671: 2017/05/16(火)14:24 ID:KRJlMJox(1/2) AAS
TypeScript ⇔ JSONSchema を相互に変換するコードは既に転がってるから
どちらでも好みで原本にすれば良いんじゃないの？
まぁあまり自動化を頑張っても、構造が複雑になると結局手書きが必要になる分野だとは思うけど
672: 2017/05/16(火)14:48 ID:64KrDfHK(3/3) AAS
型で記述しきれないバリデーションについてはDecoratorsを使うのがベストなんだろうけど、
interfaceには使えないんだよな
まあJSONだけならそれでもいいかもしれないが
673(1): 2017/05/16(火)15:28 ID:6a8gh5yc(3/5) AAS
リリースノートも見ずにオレオレソリューションひねり出すのやめない？
外部ﾘﾝｸ:github.com
674: 2017/05/16(火)15:33 ID:4P1sgrCm(1) AAS
interfaceがトランスパイル後に消滅しちゃうの辛いよな。
言語機能でいい感じに残す機能つけてほしいが、そういう提案ってないの？
最近ついたというプラグインで可能になる？
675(1): 2017/05/16(火)15:42 ID:6a8gh5yc(4/5) AAS
>>662で公式で却下されたと書いてある
まあESの仕様壊すし残当
676(1): 2017/05/16(火)15:48 ID:KRJlMJox(2/2) AAS
>>673
この文脈 (>>642 648) では、型フィールドを信用するのはノーチェックと同じ意味だぞ
外部からのデータが、内部的な制約を満たすことの保証を求めてる
677: 2017/05/16(火)16:10 ID:6a8gh5yc(5/5) AAS
いや関数に隠蔽すれば壊すまではいかんか
>>676
入力データの検査も値レベルの制約も手でやること
型システムに求めることじゃない
型を信じてノーチェックが型安全でありそうでなければオーバーヘッドで死ぬ
本人もタイプガードで満足してるしそれが正解
678: 2017/05/16(火)17:11 ID:rTo/YyDO(1) AAS
>>675
まぁESの仕様＋型だけだから学習コストが低いってのはあるしね。 でも直感的にinterface定義が消えちゃうのはなんだかなぁって気はする。
こうなったらES側に頑張ってもらうしかないな。パターンマッチング付けてー
679: 2017/05/29(月)18:33 ID:DGY6L2yw(1) AAS
>>651
コレが解決した。
悩んでいつつも暫定対処で乗り切ってただけに小骨が喉に刺さっているような気分でしたわ。
結論としてはtypeRootsオプションは/// <reference types=".." />
を使う時のpath解決でしか使わないって。
ハンドブックをどう読んでもそう書いているように見えない。
680: 2017/06/02(金)03:21 ID:0selKGQ0(1) AAS
typescriptでimmutablejs使ってるけどいまいち恩恵を得づらい。
updateInとかパスが補完効いたり出来ればいいのに
681(1): 2017/06/02(金)08:57 ID:vyfZNbsR(1) AAS
thisを変数に入れたいときの変数名ってみんな何してる？
_thisが使えればいいんだけどなー
682: 2017/06/02(金)09:08 ID:Ef+/+PyI(1/3) AAS
変数に入れた後のthisはthisなんですか・・・・？
683: 2017/06/02(金)09:09 ID:lCCVb2h3(1/3) AAS
thatだがそもそもそんなこと必要にならない
684: 2017/06/02(金)09:20 ID:8OnrstJc(1) AAS
JavaScriptのクロージャにおけるthis問題の回避はselfが定番
TypeScriptで必要なケースは少ないはずだけど
685: 2017/06/02(金)09:43 ID:LceXbV2F(1) AAS
>>681
_thisはダメなの？
上下前次1-新書関写板覧索設栞歴
あと 317 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.020s