X

TypeScript part2 [転載禁止]©2ch.net

■ このスレッドは過去ログ倉庫に格納されています
0604デフォルトの名無しさん
垢版 |
2017/04/13(木) 01:00:49.62ID:IFJ42qsr
>>602
えっ　普通推論させるから書かないでしょ
わざわざ書かなきゃならなくなるケースってどんな時よ
0605デフォルトの名無しさん
垢版 |
2017/04/13(木) 01:13:36.05ID:rVYtPk7E
const STR = "str";
type STRT = "str";
const ABC3: STRT=STR;

"str"を2回書かずにABC3が作れればそれでいいんだけど。
0606デフォルトの名無しさん
垢版 |
2017/04/13(木) 01:20:51.05ID:IFJ42qsr
>>605
const STR = "str";
const ABC3 = STR;
0610デフォルトの名無しさん
垢版 |
2017/04/13(木) 20:33:25.78ID:IFJ42qsr
認めて謝って感謝してるだけ立派だよ
0611デフォルトの名無しさん
垢版 |
2017/04/16(日) 20:56:40.61ID:nOhMz2bP
TypeScriptでExpressを使う場合について教えてください。

express-generatorなどのサンプルコードだと new Error したオブジェクトにstatusを
突っ込んで返していたりしますが、ここ、TypeScript的にはどうするのが普通でしょう？
みなさん自前でErrorのサブクラスを定義しているんでしょうか？あるいはどこかに
定番のものがあったりするんでしょうか？
0612デフォルトの名無しさん
垢版 |
2017/04/16(日) 22:51:14.41ID:SqhlDt4o
「どうでもいい」が普通じゃない?
そんなもんエラーハンドラで受けて適当にトレースとエラーメッセージ出したら終わりなんだから
型なんぞ要らん
手段と目的を履き違えるな
0613デフォルトの名無しさん
垢版 |
2017/04/16(日) 23:30:20.32ID:R4TJTEcK
>>611
jsonとして扱えるようにインターフェース定義にしておいたほうが無難な気がする。
シリアライズしても簡単にもとに戻せるし。
0614デフォルトの名無しさん
垢版 |
2017/04/17(月) 00:09:50.93ID:CyuLkfZA
そういうもんですかね？
エラーを表示するだけとは言ってもstatusは正しくセットしなきゃならないわけで、
TypeScriptを使う以上そこも型安全にやりたいってのは自然だと思うんですが。
そこだけtslintの警告をネグるのも気持ち悪いし。
0615デフォルトの名無しさん
垢版 |
2017/04/17(月) 00:24:52.52ID:GVmJ+xSa
アプリケーションの仕様としてエラー用のクラスを定義します。Errorのサブクラスだったり新規に自前のクラスを用意するかはケースバイケース。
当然途中で変わることもあり得ます。その際はきちんと他のメンバーと情報共有します。
0616デフォルトの名無しさん
垢版 |
2017/04/17(月) 07:32:40.57ID:k0Nquy2H
自分は簡単なアプリではHttpErrorみたいなクラスを定義して使ってる。
もっと複雑なアプリだと、業務エラーのコードとHTTPのエラーコードで
もう一階層作ったりもするけど。
だが、これが推奨なやり方なのかは分からん。俺も知りたい。
0617デフォルトの名無しさん
垢版 |
2017/04/17(月) 08:40:01.39ID:CyuLkfZA
ありがとうございます。
statusというプロパティにステータスを返すのは決まっているんだからどこかに
出来合いのものがあるかと思ったんですが、やっぱり自前なんですね。
0618デフォルトの名無しさん
垢版 |
2017/04/20(木) 11:26:28.02ID:T7Zz78Cb
npm linkを駆使してtypescriptでビジネスロジックを外部モジュールにしてるんだけど
tsc -wで自動コンパイルはできるんだけど
定義ファイルも同時に生成するコマンドオプションってないかな？
0620デフォルトの名無しさん
垢版 |
2017/04/21(金) 21:22:59.73ID:Uj6lwvRH
TypeScriptで動的なキャストみたいなことってできるんでしょうか？

// どこかで定義されたclass
class X {}

interface AX extends X {
a: string;
}

func(x: X) {
if ( xが a: string というプロパティを持っていれば ) {
// ここではxをAXとして扱いたい
}
}
0621デフォルトの名無しさん
垢版 |
2017/04/22(土) 00:25:56.48ID:NysYFg8M
>>620
let ax=<AX>x
でキャスト出来る。
インターフェースが存在するかどうかはチェックはされないから注意。
0623デフォルトの名無しさん
垢版 |
2017/04/26(水) 12:25:16.92ID:mOputr8e
f8appのコード読んでんだけど
flowって驚くほどtypeScriptと似てるね。
んでReduxのアクションな書き方が参考になる。

type ParseObject = Object;

export type Action =
{ type: 'LOADED_ABOUT', list: Array<ParseObject> }
| { type: 'LOADED_NOTIFICATIONS', list: Array<ParseObject> }
| { type: 'LOADED_MAPS', list: Array<ParseObject> }

コレ普通にtypeScriptでも使えた。
interface宣言だとこういう書き方できなけどtype宣言だとできんのね。
0624デフォルトの名無しさん
垢版 |
2017/04/27(木) 14:10:54.61ID:2oprloyo
いやーTypeScriptって本当にいいものですよね
恥ずかしいソース書いてもコンパイルすればそれなりの形になってますし
全ソースが1つにまとまったjsファイルを見るとカタルシスを覚えます
javascriptを扱うのに最高の言語です
0625デフォルトの名無しさん
垢版 |
2017/04/27(木) 16:28:37.55ID:a+4IBLmk
開発用と納品用でコードわけられるとかありがたい
0627デフォルトの名無しさん
垢版 |
2017/04/28(金) 08:31:59.89ID:IMlkcp1b
>>626
結局該当箇所っぽいところの構造を変えて解決した

case 'Text':
{
let text: Text;
/* ごちゃごちゃした処理*/
text = {
type: 'Text',
value: node.value,
cache: nodeCache
};
return text;
}
ってなってるところで
なぜがtextという変数がminifyで消えずに残っていてエラーになっていたところ

case 'Text':
{
// let text: Text; <―削除
/* ごちゃごちゃした処理*/
let text:Text = {
type: 'Text',
value: node.value,
cache: nodeCache
};
return text;
}

ってしたら治った。
0628デフォルトの名無しさん
垢版 |
2017/04/28(金) 09:00:40.63ID:IMlkcp1b
すいませんminifyの件ですが一番の問題は

外部ライブラリとして別にパッケージを作ってnpm linkしていたんですが
その外部ライブラリのtsconfigの設定でtargetをes2015にしていたのが原因のようです。

npm上で公開してるライブラリってes2015のものとes5のものが混ざってるんですかね？もしそうならminifyのとき問題でそう。

そろそろブラウザもes2015に対応してきたし外部ライブラリもes2015でいいんじゃないかと思いましたがまだまだes5のほうがいいんですかねー
0631デフォルトの名無しさん
垢版 |
2017/04/29(土) 00:20:26.49ID:Ix6JNrOr
>>630
targetをes5にしてlibに”dom”と”es2017”を設定したら
ちゃんとminifyもできつつasync await とかobject.assaignとか使えました。

typescriptの問題というよりuglify-jsの問題ってことすね。
0633デフォルトの名無しさん
垢版 |
2017/04/29(土) 09:01:35.78ID:fFSdol5k
アンインストールしたらVSでtsファイル開いても識別子の色分けとかインテリセンスが出てこなくなってVSぶっ壊れたわ
再インストールだなこりゃ
0634デフォルトの名無しさん
垢版 |
2017/04/29(土) 09:05:24.76ID:fFSdol5k
2.3アンインストール後に再度2.3インストールしてもぶっ壊れたまま
迂闊に入れないほうがいいなこれ
0635デフォルトの名無しさん
垢版 |
2017/04/29(土) 14:53:43.74ID:D/W8thCK
馬鹿には無理
0638デフォルトの名無しさん
垢版 |
2017/04/30(日) 12:00:27.54ID:0Jw8BHIT
相対パスでimportしようとすると from ’../../lib/a’ と書くことが多いのですが
..を何とかしようと思いtsconfigでbaseUrlを設定したところ
from ‘lib/a’とかけるようになって素敵だったんですが
生成したjs側で同じように相対パスを使わない方法にできずjs側からimportできなくなりました。
どうすればいいんですかね
0642デフォルトの名無しさん
垢版 |
2017/05/01(月) 13:56:45.49ID:1hc/XS6U
jsonのデシリアライズ等で得られた任意のオブジェクトが指定のinterfaceに適合するかどうか
簡単に判定する方法ってないでしょうか？
実行コストがかかるのはしょうがないので、npmのライブラリでもあれば助かります。
0645デフォルトの名無しさん
垢版 |
2017/05/01(月) 15:43:26.17ID:FD8bdV22
>>642
あーなるほどtypesciptのinterface要件を満たしてるかチェックするライブラリかー。
interfaceに対するメタプログラミングができる仕組みってtypescript側に用意されてんのかな
0648デフォルトの名無しさん
垢版 |
2017/05/01(月) 22:27:57.85ID:1hc/XS6U
>>643-647
回答ありがとうございます。
外部から入手したany型のオブジェクトに対して、一度型チェックしたらTypeGuardの下で
扱えたら便利だと思ったんですが、そう単純なものはなさそうですね。
interface毎にUser-Defined Type Guard Functionてのを用意するのが今のところ
いちばんシンプルですかね。
0649デフォルトの名無しさん
垢版 |
2017/05/01(月) 23:04:54.13ID:FD8bdV22
>>646
interfaceをparseするの簡単にできたわ
ジェネレータは作れそう。後はObjectを チェックするコードをかければ、、、
そっちがよくわかんないな。
0651デフォルトの名無しさん
垢版 |
2017/05/05(金) 00:50:33.95ID:oXL5lOIH
webpackでtypescript使う時にts-loaderがtypeRootsオプションを認識してくれないような。
自作の定義ファイルを読みに行ってくれない。
結局nodes_modules/@types/においたらうごくんだけど。なんだかなぁ
0652デフォルトの名無しさん
垢版 |
2017/05/05(金) 10:24:07.07ID:E/UcmmKD
-g
0654デフォルトの名無しさん
垢版 |
2017/05/10(水) 22:53:30.65ID:TahTqR8d
>>650
これやってみようかと思ったけど、class定義からschema生成するか逆にschemaから生成するか、
どっちがいいか悩ましいなぁ。
0655デフォルトの名無しさん
垢版 |
2017/05/11(木) 06:23:41.84ID:6GcWGmCe
JSON Schemaの方が表現力がずっと高いから、
実用的に意味があるのは後者だろうね
型だけなら全部空文字と0とfalseでもいいんだから
0656デフォルトの名無しさん
垢版 |
2017/05/11(木) 06:40:52.39ID:Uo4oHcSP
JSON Schemaからのdts生成は既存のツールがいくつかあるみたいだな
逆はバリデーションとしてはほぼ無意味かと
0657デフォルトの名無しさん
垢版 |
2017/05/11(木) 21:37:19.65ID:Foo76VTo
目的が上で書いているようにシリアライズ-デシリアライズされたオブジェクトの型の復元なら、
interface定義を自分で書いてschemaは裏方というのが自然だとは思うが。
ただ、schemaを生成する方のツールは技術的にハードルが高いせいか選択肢があまりないな。
0658デフォルトの名無しさん
垢版 |
2017/05/15(月) 21:27:32.04ID:ZdTGw5ha
そもそもシリアライズという発想自体がJavaScript的でないと思うけどね
データスキーマから入るのがJSでしょ
0659デフォルトの名無しさん
垢版 |
2017/05/15(月) 22:43:08.64ID:JDFIgPdx
シリアライズってJSONのこと言ってるわけだろ。
言語自体にサポートの無いC++などと比べてもよっぽど馴染みがあると思うが。
で、JavaScriptだとそこまででいいんだけど、TypeScriptで型まで戻すにはどうするか？って話だろ。
0660デフォルトの名無しさん
垢版 |
2017/05/15(月) 23:00:01.30ID:ZdTGw5ha
バリデーションとシリアライズが別系統なのは煩雑じゃない?
コードだけで全部定義するならアノテーション使うなりしてJSON Schema相当の表現力は欲しいし、
割り切って別にするならシリアライズ系の方は中途半端なバリデーションなんかいっそ無しにて
ノーチェックでいいと思うよ
0663デフォルトの名無しさん
垢版 |
2017/05/16(火) 00:46:18.76ID:6a8gh5yc
自分でコンパイラ拡張して実装したみたいだけどこういうの本家の更新についてけずに陳腐化するのが常だから使えない
ついでにビルドツールなどのエコシステムも使えない
0664デフォルトの名無しさん
垢版 |
2017/05/16(火) 07:36:06.00ID:MR0lnxJG
正攻法だとanyを受け取って目的の型のオブジェクトにして返す関数を用意することになるんだろうが、
やることは同じようなものなのにそれぞれ型ごとに個別に用意しなければならないのが煩雑だな。
よっぽど重要な型でしかやりたくない感じ。
確かにこれが、型ガードの感覚で気軽に使えるようになったら便利だと思うけど。
0666デフォルトの名無しさん
垢版 |
2017/05/16(火) 08:27:24.80ID:MR0lnxJG
その「スキーマ」が何を指しているかよくわからんな。
まさか「JSON schemaありき」って言いたいわけじゃないだろうが。
0669デフォルトの名無しさん
垢版 |
2017/05/16(火) 13:21:49.91ID:xkpWN83w
jsonに対するinterface適用にわざわざスキーマ使うのはだるいな。
やはりメンバにtypeとかを事前に追加しておいて、そこを見てキャストさせるほうが楽だわ。もちろんそのjson自体が自分で改変可能である必要はあるが。
0671デフォルトの名無しさん
垢版 |
2017/05/16(火) 14:24:04.58ID:KRJlMJox
TypeScript ⇔ JSONSchema を相互に変換するコードは既に転がってるから
どちらでも好みで原本にすれば良いんじゃないの？
まぁあまり自動化を頑張っても、構造が複雑になると結局手書きが必要になる分野だとは思うけど
0672デフォルトの名無しさん
垢版 |
2017/05/16(火) 14:48:54.41ID:64KrDfHK
型で記述しきれないバリデーションについてはDecoratorsを使うのがベストなんだろうけど、
interfaceには使えないんだよな
まあJSONだけならそれでもいいかもしれないが
0674デフォルトの名無しさん
垢版 |
2017/05/16(火) 15:33:13.80ID:4P1sgrCm
interfaceがトランスパイル後に消滅しちゃうの辛いよな。
言語機能でいい感じに残す機能つけてほしいが、そういう提案ってないの？
最近ついたというプラグインで可能になる？
0676デフォルトの名無しさん
垢版 |
2017/05/16(火) 15:48:01.77ID:KRJlMJox
>>673
この文脈 (>>642, 648) では、型フィールドを信用するのはノーチェックと同じ意味だぞ
外部からのデータが、内部的な制約を満たすことの保証を求めてる
0677デフォルトの名無しさん
垢版 |
2017/05/16(火) 16:10:10.21ID:6a8gh5yc
いや関数に隠蔽すれば壊すまではいかんか

>>676
入力データの検査も値レベルの制約も手でやること
型システムに求めることじゃない
型を信じてノーチェックが型安全でありそうでなければオーバーヘッドで死ぬ
本人もタイプガードで満足してるしそれが正解
0678デフォルトの名無しさん
垢版 |
2017/05/16(火) 17:11:36.85ID:rTo/YyDO
>>675
まぁESの仕様＋型だけだから学習コストが低いってのはあるしね。 でも直感的にinterface定義が消えちゃうのはなんだかなぁって気はする。

こうなったらES側に頑張ってもらうしかないな。パターンマッチング付けてー
0679デフォルトの名無しさん
垢版 |
2017/05/29(月) 18:33:36.63ID:DGY6L2yw
>>651
コレが解決した。
悩んでいつつも暫定対処で乗り切ってただけに小骨が喉に刺さっているような気分でしたわ。
結論としてはtypeRootsオプションは/// <reference types=".." />
を使う時のpath解決でしか使わないって。
ハンドブックをどう読んでもそう書いているように見えない。
0680デフォルトの名無しさん
垢版 |
2017/06/02(金) 03:21:08.54ID:0selKGQ0
typescriptでimmutablejs使ってるけどいまいち恩恵を得づらい。

updateInとかパスが補完効いたり出来ればいいのに
0681デフォルトの名無しさん
垢版 |
2017/06/02(金) 08:57:46.98ID:vyfZNbsR
thisを変数に入れたいときの変数名ってみんな何してる？
_thisが使えればいいんだけどなー
0684デフォルトの名無しさん
垢版 |
2017/06/02(金) 09:20:29.61ID:8OnrstJc
JavaScriptのクロージャにおけるthis問題の回避はselfが定番
TypeScriptで必要なケースは少ないはずだけど
0686デフォルトの名無しさん
垢版 |
2017/06/02(金) 10:31:35.82ID:QxLZOlf9
_thisは重複エラーになっちゃうんでやすよね
目的としては、deferredを返すfunctionがあって、その返り値のdoneで呼び元のthisを使いたいんです
0689デフォルトの名無しさん
垢版 |
2017/06/02(金) 12:13:45.27ID:QxLZOlf9
>>687
var testFucntion = () => {

    var defer = $.Deferred();

    defer.resolve("a");

    return defer.promise();

}

 

var hoge: string;

testFucntion()

    .done(function (data: string) {

        this.hoge(data);

    })

こんな感じ
0693デフォルトの名無しさん
垢版 |
2017/06/02(金) 23:52:05.01ID:7H2+/kur
functionが自然な場所は、アローにしてて、
アローで解決できる箇所はfunctionなのはなぜ。
0694デフォルトの名無しさん
垢版 |
2017/06/03(土) 02:14:50.79ID:QIr3+kxI
>>689
doneのほうをアロー式にしたらいいんやで
あとvsで開発してる場合、デバッグ時にウォッチしたとき、そのthisにはtestFucntionが入るけど
実際にはちゃんと使いたい値が入ってるから安心しな
0699デフォルトの名無しさん
垢版 |
2017/06/11(日) 19:15:01.32ID:AskXGu9A
interface A{
　x:string;
　y:string;
}

interface B extends A{
　x:number;
}

が型の互換性エラーになるの何とかならない？
let a={x:'hoge',y:'foo'};
let b={...a,{x:1}};

みたいな事は出来るのにbを現す型を簡単に定義出来ないのが辛い
0700デフォルトの名無しさん
垢版 |
2017/06/11(日) 19:18:40.94ID:AskXGu9A
>>696
ngxのスレは別にある
0702デフォルトの名無しさん
垢版 |
2017/06/11(日) 20:29:27.66ID:zURolSWc
>>699
型が変わったら継承できないのは当たり前では？

interface Parent {
x: string | number;
y: string;
}

interface A extends Parent {
x: string;
}

interface B extends Parent {
x: number;
}

こういう関係が正しい関係では？
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況