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

**デフォルトの名無しさん** · 2015/04/30(木) 18:37:29.98

http://www.typescriptlang.org/

TypeScript lets you write JavaScript the way you really want to.
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
Any browser. Any host. Any OS. Open Source.

前スレ
http://peace.2ch.net/test/read.cgi/tech/1349187527/

**デフォルトの名無しさん** · 2017/04/13(木) 00:44:07.45

変数の型の参照なんて初歩の初歩なんだが教えてやるまい

**デフォルトの名無しさん** · 2017/04/13(木) 01:00:49.62

>>602
えっ　普通推論させるから書かないでしょ
わざわざ書かなきゃならなくなるケースってどんな時よ

**デフォルトの名無しさん** · 2017/04/13(木) 01:13:36.05

const STR = "str";
type STRT = "str";
const ABC3: STRT=STR;

"str"を2回書かずにABC3が作れればそれでいいんだけど。

**デフォルトの名無しさん** · 2017/04/13(木) 01:20:51.05

>>605
const STR = "str";
const ABC3 = STR;

**デフォルトの名無しさん** · 2017/04/13(木) 06:09:08.50

type STRT = typeof STR

**デフォルトの名無しさん** · 2017/04/13(木) 08:01:19.65

すまん、確かに思い違いしていたようだ。ありがとう。

**デフォルトの名無しさん** · 2017/04/13(木) 13:00:24.68

恥ずかしか

**デフォルトの名無しさん** · 2017/04/13(木) 20:33:25.78

認めて謝って感謝してるだけ立派だよ

**デフォルトの名無しさん** · 2017/04/16(日) 20:56:40.61

TypeScriptでExpressを使う場合について教えてください。

express-generatorなどのサンプルコードだと new Error したオブジェクトにstatusを
突っ込んで返していたりしますが、ここ、TypeScript的にはどうするのが普通でしょう？
みなさん自前でErrorのサブクラスを定義しているんでしょうか？あるいはどこかに
定番のものがあったりするんでしょうか？

**デフォルトの名無しさん** · 2017/04/16(日) 22:51:14.41

「どうでもいい」が普通じゃない?
そんなもんエラーハンドラで受けて適当にトレースとエラーメッセージ出したら終わりなんだから
型なんぞ要らん
手段と目的を履き違えるな

**デフォルトの名無しさん** · 2017/04/16(日) 23:30:20.32

>>611
jsonとして扱えるようにインターフェース定義にしておいたほうが無難な気がする。
シリアライズしても簡単にもとに戻せるし。

**デフォルトの名無しさん** · 2017/04/17(月) 00:09:50.93

そういうもんですかね？
エラーを表示するだけとは言ってもstatusは正しくセットしなきゃならないわけで、
TypeScriptを使う以上そこも型安全にやりたいってのは自然だと思うんですが。
そこだけtslintの警告をネグるのも気持ち悪いし。

**デフォルトの名無しさん** · 2017/04/17(月) 00:24:52.52

アプリケーションの仕様としてエラー用のクラスを定義します。Errorのサブクラスだったり新規に自前のクラスを用意するかはケースバイケース。
当然途中で変わることもあり得ます。その際はきちんと他のメンバーと情報共有します。

**デフォルトの名無しさん** · 2017/04/17(月) 07:32:40.57

自分は簡単なアプリではHttpErrorみたいなクラスを定義して使ってる。
もっと複雑なアプリだと、業務エラーのコードとHTTPのエラーコードで
もう一階層作ったりもするけど。
だが、これが推奨なやり方なのかは分からん。俺も知りたい。

**デフォルトの名無しさん** · 2017/04/17(月) 08:40:01.39

ありがとうございます。
statusというプロパティにステータスを返すのは決まっているんだからどこかに
出来合いのものがあるかと思ったんですが、やっぱり自前なんですね。

**デフォルトの名無しさん** · 2017/04/20(木) 11:26:28.02

npm linkを駆使してtypescriptでビジネスロジックを外部モジュールにしてるんだけど
tsc -wで自動コンパイルはできるんだけど
定義ファイルも同時に生成するコマンドオプションってないかな？

**デフォルトの名無しさん** · 2017/04/20(木) 11:42:22.36

>>618
すんません -w -dですね。ホント申し訳ない

**デフォルトの名無しさん** · 2017/04/21(金) 21:22:59.73

TypeScriptで動的なキャストみたいなことってできるんでしょうか？

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

interface AX extends X {
a: string;
}

func(x: X) {
if ( xが a: string というプロパティを持っていれば ) {
// ここではxをAXとして扱いたい
}
}

**デフォルトの名無しさん** · 2017/04/22(土) 00:25:56.48

>>620
let ax=<AX>x
でキャスト出来る。
インターフェースが存在するかどうかはチェックはされないから注意。

**デフォルトの名無しさん** · 2017/04/22(土) 10:55:16.81

>>621
ありがとうございました。うまくいきました。

**デフォルトの名無しさん** · 2017/04/26(水) 12:25:16.92

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宣言だとできんのね。

**デフォルトの名無しさん** · 2017/04/27(木) 14:10:54.61

いやーTypeScriptって本当にいいものですよね
恥ずかしいソース書いてもコンパイルすればそれなりの形になってますし
全ソースが1つにまとまったjsファイルを見るとカタルシスを覚えます
javascriptを扱うのに最高の言語です

**デフォルトの名無しさん** · 2017/04/27(木) 16:28:37.55

開発用と納品用でコードわけられるとかありがたい

**デフォルトの名無しさん** · 2017/04/27(木) 17:45:10.06

minifyが出来なくて悩んでおります。
Targetをes5にしてもエラーが出る。

**デフォルトの名無しさん** · 2017/04/28(金) 08:31:59.89

>>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;
}

ってしたら治った。

**デフォルトの名無しさん** · 2017/04/28(金) 09:00:40.63

すいませんminifyの件ですが一番の問題は

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

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

そろそろブラウザもes2015に対応してきたし外部ライブラリもes2015でいいんじゃないかと思いましたがまだまだes5のほうがいいんですかねー

**デフォルトの名無しさん** · 2017/04/28(金) 15:19:33.29

Announcing TypeScript 2.3
https://blogs.msdn.microsoft.com/typescript/2017/04/27/announcing-typescript-2-3/

**デフォルトの名無しさん** · 2017/04/28(金) 21:52:24.09

>>628
ちゃんと設定すれば、TypeScriptが変換してくれるんじゃないの？

**デフォルトの名無しさん** · 2017/04/29(土) 00:20:26.49

>>630
targetをes5にしてlibに”dom”と”es2017”を設定したら
ちゃんとminifyもできつつasync await とかobject.assaignとか使えました。

typescriptの問題というよりuglify-jsの問題ってことすね。

**デフォルトの名無しさん** · 2017/04/29(土) 08:40:51.51

>>629
ギャー！！
適用したらエラーだらけになった！！

**デフォルトの名無しさん** · 2017/04/29(土) 09:01:35.78

アンインストールしたらVSでtsファイル開いても識別子の色分けとかインテリセンスが出てこなくなってVSぶっ壊れたわ
再インストールだなこりゃ

**デフォルトの名無しさん** · 2017/04/29(土) 09:05:24.76

2.3アンインストール後に再度2.3インストールしてもぶっ壊れたまま
迂闊に入れないほうがいいなこれ

**デフォルトの名無しさん** · 2017/04/29(土) 14:53:43.74

馬鹿には無理

**デフォルトの名無しさん** · 2017/04/30(日) 09:24:14.29

不細工ハゲが偉そうに

**デフォルトの名無しさん** · 2017/04/30(日) 11:46:36.73

不細工じゃねーし！

**デフォルトの名無しさん** · 2017/04/30(日) 12:00:27.54

相対パスでimportしようとすると from ’../../lib/a’ と書くことが多いのですが
..を何とかしようと思いtsconfigでbaseUrlを設定したところ
from ‘lib/a’とかけるようになって素敵だったんですが
生成したjs側で同じように相対パスを使わない方法にできずjs側からimportできなくなりました。
どうすればいいんですかね

**デフォルトの名無しさん** · 2017/04/30(日) 12:07:35.75

deployしてみ

**デフォルトの名無しさん** · 2017/04/30(日) 13:53:10.60

おい、>>637に突っ込めよ！

**デフォルトの名無しさん** · 2017/04/30(日) 14:18:46.56

ハゲに付ける薬なし

**デフォルトの名無しさん** · 2017/05/01(月) 13:56:45.49

jsonのデシリアライズ等で得られた任意のオブジェクトが指定のinterfaceに適合するかどうか
簡単に判定する方法ってないでしょうか？
実行コストがかかるのはしょうがないので、npmのライブラリでもあれば助かります。

**デフォルトの名無しさん** · 2017/05/01(月) 14:12:45.68

実行時に型情報は取得できないので無理

**デフォルトの名無しさん** · 2017/05/01(月) 14:56:45.23

>>642
俺は各interfaceの定義にtypeを入れてる。

**デフォルトの名無しさん** · 2017/05/01(月) 15:43:26.17

>>642
あーなるほどtypesciptのinterface要件を満たしてるかチェックするライブラリかー。
interfaceに対するメタプログラミングができる仕組みってtypescript側に用意されてんのかな

**デフォルトの名無しさん** · 2017/05/01(月) 16:42:03.86

ランゲージサービスから情報引っ張ってコード生成するまでやればできる

**デフォルトの名無しさん** · 2017/05/01(月) 18:22:52.40

>>642
初心者なんで教えて欲しいんですが
どう言う状況でそう言うのが必要に
なるんですか?

**デフォルトの名無しさん** · 2017/05/01(月) 22:27:57.85

>>643-647
回答ありがとうございます。
外部から入手したany型のオブジェクトに対して、一度型チェックしたらTypeGuardの下で
扱えたら便利だと思ったんですが、そう単純なものはなさそうですね。
interface毎にUser-Defined Type Guard Functionてのを用意するのが今のところ
いちばんシンプルですかね。

**デフォルトの名無しさん** · 2017/05/01(月) 23:04:54.13

>>646
interfaceをparseするの簡単にできたわ
ジェネレータは作れそう。後はObjectをチェックするコードをかければ、、、
そっちがよくわかんないな。

**デフォルトの名無しさん** · 2017/05/02(火) 00:15:01.17

JSON限定でいいならJSON Schema生成するだけじゃね

**デフォルトの名無しさん** · 2017/05/05(金) 00:50:33.95

webpackでtypescript使う時にts-loaderがtypeRootsオプションを認識してくれないような。
自作の定義ファイルを読みに行ってくれない。
結局nodes_modules/@types/においたらうごくんだけど。なんだかなぁ

**デフォルトの名無しさん** · 2017/05/05(金) 10:24:07.07

**デフォルトの名無しさん** · 2017/05/07(日) 12:47:49.44

redux のreducer書く時型付きじゃないと死ぬ。
素のjsでよく書ける人いるなぁ

**デフォルトの名無しさん** · 2017/05/10(水) 22:53:30.65

>>650
これやってみようかと思ったけど、class定義からschema生成するか逆にschemaから生成するか、
どっちがいいか悩ましいなぁ。

**デフォルトの名無しさん** · 2017/05/11(木) 06:23:41.84

JSON Schemaの方が表現力がずっと高いから、
実用的に意味があるのは後者だろうね
型だけなら全部空文字と0とfalseでもいいんだから

**デフォルトの名無しさん** · 2017/05/11(木) 06:40:52.39

JSON Schemaからのdts生成は既存のツールがいくつかあるみたいだな
逆はバリデーションとしてはほぼ無意味かと

**デフォルトの名無しさん** · 2017/05/11(木) 21:37:19.65

目的が上で書いているようにシリアライズ-デシリアライズされたオブジェクトの型の復元なら、
interface定義を自分で書いてschemaは裏方というのが自然だとは思うが。
ただ、schemaを生成する方のツールは技術的にハードルが高いせいか選択肢があまりないな。

**デフォルトの名無しさん** · 2017/05/15(月) 21:27:32.04

そもそもシリアライズという発想自体がJavaScript的でないと思うけどね
データスキーマから入るのがJSでしょ

**デフォルトの名無しさん** · 2017/05/15(月) 22:43:08.64

シリアライズってJSONのこと言ってるわけだろ。
言語自体にサポートの無いC++などと比べてもよっぽど馴染みがあると思うが。
で、JavaScriptだとそこまででいいんだけど、TypeScriptで型まで戻すにはどうするか？って話だろ。

**デフォルトの名無しさん** · 2017/05/15(月) 23:00:01.30

バリデーションとシリアライズが別系統なのは煩雑じゃない?
コードだけで全部定義するならアノテーション使うなりしてJSON Schema相当の表現力は欲しいし、
割り切って別にするならシリアライズ系の方は中途半端なバリデーションなんかいっそ無しにて
ノーチェックでいいと思うよ

**デフォルトの名無しさん** · 2017/05/15(月) 23:16:34.01

うん、上から目線で何か言いたいという気持ちだけは伝わった。

**デフォルトの名無しさん** · 2017/05/15(月) 23:59:53.11

http://stackoverflow.com/questions/33800497/check-if-an-object-implements-an-interface-at-runtime-with-typescript
Yesの回答にそれっぽいコードがあるが本当に動作するのか疑問。
他はSchemaを使う回答だが、よほどでないと大袈裟な気も。

**デフォルトの名無しさん** · 2017/05/16(火) 00:46:18.76

自分でコンパイラ拡張して実装したみたいだけどこういうの本家の更新についてけずに陳腐化するのが常だから使えない
ついでにビルドツールなどのエコシステムも使えない

**デフォルトの名無しさん** · 2017/05/16(火) 07:36:06.00

正攻法だとanyを受け取って目的の型のオブジェクトにして返す関数を用意することになるんだろうが、
やることは同じようなものなのにそれぞれ型ごとに個別に用意しなければならないのが煩雑だな。
よっぽど重要な型でしかやりたくない感じ。
確かにこれが、型ガードの感覚で気軽に使えるようになったら便利だと思うけど。

**デフォルトの名無しさん** · 2017/05/16(火) 08:02:09.48

TypeScriptの思想的にもスキーマありきで型は後付けの方が自然だと思うわ

**デフォルトの名無しさん** · 2017/05/16(火) 08:27:24.80

その「スキーマ」が何を指しているかよくわからんな。
まさか「JSON schemaありき」って言いたいわけじゃないだろうが。

**デフォルトの名無しさん** · 2017/05/16(火) 09:01:29.19

>>666
別に実装は何でもいいんじゃない?
先にJSONドキュメントそのものを設計しろってこと

**デフォルトの名無しさん** · 2017/05/16(火) 10:11:34.64

objectを先に設計してstringifyの方が一般的だと思うが。
つまりtsなら型が先。

**デフォルトの名無しさん** · 2017/05/16(火) 13:21:49.91

jsonに対するinterface適用にわざわざスキーマ使うのはだるいな。
やはりメンバにtypeとかを事前に追加しておいて、そこを見てキャストさせるほうが楽だわ。もちろんそのjson自体が自分で改変可能である必要はあるが。

**デフォルトの名無しさん** · 2017/05/16(火) 13:49:23.26

言語がサポートしてるのはその使い方だからな

**デフォルトの名無しさん** · 2017/05/16(火) 14:24:04.58

TypeScript ⇔ JSONSchema を相互に変換するコードは既に転がってるから
どちらでも好みで原本にすれば良いんじゃないの？
まぁあまり自動化を頑張っても、構造が複雑になると結局手書きが必要になる分野だとは思うけど

**デフォルトの名無しさん** · 2017/05/16(火) 14:48:54.41

型で記述しきれないバリデーションについてはDecoratorsを使うのがベストなんだろうけど、
interfaceには使えないんだよな
まあJSONだけならそれでもいいかもしれないが

**デフォルトの名無しさん** · 2017/05/16(火) 15:28:34.19

リリースノートも見ずにオレオレソリューションひねり出すのやめない？
https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#tagged-union-types

**デフォルトの名無しさん** · 2017/05/16(火) 15:33:13.80

interfaceがトランスパイル後に消滅しちゃうの辛いよな。
言語機能でいい感じに残す機能つけてほしいが、そういう提案ってないの？
最近ついたというプラグインで可能になる？

**デフォルトの名無しさん** · 2017/05/16(火) 15:42:38.42

>>662で公式で却下されたと書いてある
まあESの仕様壊すし残当

**デフォルトの名無しさん** · 2017/05/16(火) 15:48:01.77

>>673
この文脈 (>>642, 648) では、型フィールドを信用するのはノーチェックと同じ意味だぞ
外部からのデータが、内部的な制約を満たすことの保証を求めてる

**デフォルトの名無しさん** · 2017/05/16(火) 16:10:10.21

いや関数に隠蔽すれば壊すまではいかんか

>>676
入力データの検査も値レベルの制約も手でやること
型システムに求めることじゃない
型を信じてノーチェックが型安全でありそうでなければオーバーヘッドで死ぬ
本人もタイプガードで満足してるしそれが正解

**デフォルトの名無しさん** · 2017/05/16(火) 17:11:36.85

>>675
まぁESの仕様＋型だけだから学習コストが低いってのはあるしね。でも直感的にinterface定義が消えちゃうのはなんだかなぁって気はする。

こうなったらES側に頑張ってもらうしかないな。パターンマッチング付けてー

**デフォルトの名無しさん** · 2017/05/29(月) 18:33:36.63

>>651
コレが解決した。
悩んでいつつも暫定対処で乗り切ってただけに小骨が喉に刺さっているような気分でしたわ。
結論としてはtypeRootsオプションは/// <reference types=".." />
を使う時のpath解決でしか使わないって。
ハンドブックをどう読んでもそう書いているように見えない。

**デフォルトの名無しさん** · 2017/06/02(金) 03:21:08.54

typescriptでimmutablejs使ってるけどいまいち恩恵を得づらい。

updateInとかパスが補完効いたり出来ればいいのに

**デフォルトの名無しさん** · 2017/06/02(金) 08:57:46.98

thisを変数に入れたいときの変数名ってみんな何してる？
_thisが使えればいいんだけどなー

**デフォルトの名無しさん** · 2017/06/02(金) 09:08:17.58

変数に入れた後のthisはthisなんですか・・・・？

**デフォルトの名無しさん** · 2017/06/02(金) 09:09:32.94

thatだがそもそもそんなこと必要にならない

**デフォルトの名無しさん** · 2017/06/02(金) 09:20:29.61

JavaScriptのクロージャにおけるthis問題の回避はselfが定番
TypeScriptで必要なケースは少ないはずだけど

**デフォルトの名無しさん** · 2017/06/02(金) 09:43:18.53

>>681
_thisはダメなの？

**デフォルトの名無しさん** · 2017/06/02(金) 10:31:35.82

_thisは重複エラーになっちゃうんでやすよね
目的としては、deferredを返すfunctionがあって、その返り値のdoneで呼び元のthisを使いたいんです

**デフォルトの名無しさん** · 2017/06/02(金) 11:16:51.90

やりたいことが分からん
コード例plz

**デフォルトの名無しさん** · 2017/06/02(金) 11:38:44.20

アロー関数で済むやつでは

**デフォルトの名無しさん** · 2017/06/02(金) 12:13:45.27

>>687
var testFucntion = () => {

    var defer = $.Deferred();

    defer.resolve("a");

    return defer.promise();

}

var hoge: string;

testFucntion()

    .done(function (data: string) {

        this.hoge(data);

    })

こんな感じ

**デフォルトの名無しさん** · 2017/06/02(金) 12:15:24.11

>>689
>>688

**デフォルトの名無しさん** · 2017/06/02(金) 12:17:24.53

草ｗｗｗ

**デフォルトの名無しさん** · 2017/06/02(金) 12:20:14.11

自演乙としか

**デフォルトの名無しさん** · 2017/06/02(金) 23:52:05.01

functionが自然な場所は、アローにしてて、
アローで解決できる箇所はfunctionなのはなぜ。

**デフォルトの名無しさん** · 2017/06/03(土) 02:14:50.79

>>689
doneのほうをアロー式にしたらいいんやで
あとvsで開発してる場合、デバッグ時にウォッチしたとき、そのthisにはtestFucntionが入るけど
実際にはちゃんと使いたい値が入ってるから安心しな

**デフォルトの名無しさん** · 2017/06/03(土) 09:18:06.31

アロー使えばselfいらないって知った時感動した

**デフォルトの名無しさん** · 2017/06/04(日) 01:06:25.77

Angular(2以降)の話題もここでよろしょうございますか？

**デフォルトの名無しさん** · 2017/06/04(日) 02:05:52.05

まったくではないが違うんじゃないか？

**デフォルトの名無しさん** · 2017/06/04(日) 05:58:20.77

http://medaka.2ch.net/test/read.cgi/php/1415599223/

**デフォルトの名無しさん** · 2017/06/11(日) 19:15:01.32

interface A{
　x:string;
　y:string;
}

interface B extends A{
　x:number;
}

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

みたいな事は出来るのにbを現す型を簡単に定義出来ないのが辛い

**デフォルトの名無しさん** · 2017/06/11(日) 19:18:40.94

>>696
ngxのスレは別にある

**デフォルトの名無しさん** · 2017/06/11(日) 19:55:36.52

>>698
2以降はこっち
http://mevius.2ch.net/test/read.cgi/hp/1484055394/

**デフォルトの名無しさん** · 2017/06/11(日) 20:29:27.66

>>699
型が変わったら継承できないのは当たり前では？

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

interface A extends Parent {
x: string;
}

interface B extends Parent {
x: number;
}

こういう関係が正しい関係では？