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

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

**デフォルトの名無しさん** · 2017/06/11(日) 21:09:00.82

理解してない奴を炙り出すのにも静的チェックは必要なんやなって

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

>>702
プロパティだとセットのときを考えるとcontravariantじゃないとダメだしゲットのときにはcovariantじゃないとダメだから結局invariantが必要になるような気がする
アクセサならsetのパラメタとgetの返却値で型が異なってもいいから問題ないと思うけど

**デフォルトの名無しさん** · 2017/06/11(日) 22:09:32.03

>>702
継承出来ないのは当たり前って言うのは分かる
ただ上書きする構文が欲しい

**デフォルトの名無しさん** · 2017/06/11(日) 22:13:08.61

>>705
ジェネリクスあるし上書きする構文が必要になる状況が分からん

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

上書きなんぞせずとも別の名前付ければよくね？
デメリットしか思い付かないし実装されないと思うが、仮に実装されたとしても予想される実装方法はBの型を通してアクセスしたときは型名とかをprefix付けた別名になるようにトランスパイルされるようになるだけでしょ

**デフォルトの名無しさん** · 2017/06/11(日) 23:47:19.06

extends Aじゃないけどその定義を流用してBを定義したいということか？

**デフォルトの名無しさん** · 2017/06/11(日) 23:48:25.17

>>708
そういう事

**デフォルトの名無しさん** · 2017/06/11(日) 23:49:49.29

B extends Aじゃないから当然
(hoge:B)=>{
let foo:A=hoge;
}

みたいな事は出来なくて良い(というか出来ない)

**デフォルトの名無しさん** · 2017/06/12(月) 00:58:34.90

継承じゃないんだから諦めてジェネリクス使いなよ

**デフォルトの名無しさん** · 2017/06/12(月) 08:01:38.24

世の中にxがstringかnumberの場合があるのなら、x: string | number という定義が正しい気がしますが

**デフォルトの名無しさん** · 2017/06/12(月) 08:11:52.28

ジェネリクスだと>>699の問題がどこまで解決できるんだろう。

**デフォルトの名無しさん** · 2017/06/12(月) 08:26:45.30

>>713
interface X<T> {
　x: T;
　y: string;
}
interface A extends X<string> { }
interface B extends X<number> { }

**デフォルトの名無しさん** · 2017/06/12(月) 18:05:51.91

flowとtypescriptって
どっちが良いの？

**デフォルトの名無しさん** · 2017/06/12(月) 18:14:08.97

>>715
圧倒的TypeScript
異論は見ろめない

**デフォルトの名無しさん** · 2017/06/12(月) 21:00:25.44

酔うの早すぎるだろ

**デフォルトの名無しさん** · 2017/06/13(火) 22:10:43.81

Announcing TypeScript 2.4 RC
https://blogs.msdn.microsoft.com/typescript/2017/06/12/announcing-typescript-2-4-rc/

**デフォルトの名無しさん** · 2017/06/14(水) 08:28:34.92

enumってstring literal型出てからほぼ使わなくなったからなあ
コード内でimportできるのもよくわからん
何がよくなったんだ

**デフォルトの名無しさん** · 2017/06/14(水) 09:04:40.52

新importは関数であることに意味がある

**デフォルトの名無しさん** · 2017/06/14(水) 21:28:45.57

>>720
なるほど Promiseで返すってことはasync await 前提なんかな。
ちょっと非同期周りで互換性のないライブラリ使ってると途端に不便になるから
一長一短ではあるんだけど。全部がPromise使うライブラリで固められれば便利になるんかな。

**デフォルトの名無しさん** · 2017/06/14(水) 21:29:54.91

jsの仕様変更そろそろ収まって欲しい。
import周りってこれで安定するようになるのかな。

**デフォルトの名無しさん** · 2017/06/15(木) 19:20:45.69

filterの中でasync await って使えないんですかね？

**デフォルトの名無しさん** · 2017/06/15(木) 19:24:11.68

>>723
無理
rxjs使うか設計見なおせ
具体的に何をしたい？

**デフォルトの名無しさん** · 2017/06/15(木) 21:25:19.64

filterの評価関数を作ろうとした時に、今まで作ったやつが全部プロミス返す設計になっていたので、
シームレスに使おうとしたらasync-awaitを使えないかなーと。
将来的にここもasync await使えるようになるのかな。
結局ループを回して絞込処理を実装しましたわ。

**デフォルトの名無しさん** · 2017/06/15(木) 21:30:12.69

rxjs使え

**デフォルトの名無しさん** · 2017/06/15(木) 21:32:03.12

それか自作。そんなに難しくないぞ

**デフォルトの名無しさん** · 2017/06/16(金) 01:22:09.50

rx推しが謎すぎる。

**デフォルトの名無しさん** · 2017/06/16(金) 07:51:13.34

ループでawaitしちゃうってパフォーマンス悪くない?
await promise.all([].map(async () => {}))

こういうのが普通では?

**デフォルトの名無しさん** · 2017/06/16(金) 12:37:39.06

>>729
ずっとpromise.allの存在を失念してた。
これでmap的な使い方できるね。

ところでtypescriptのプロジェクトで自作helperライブラリを使う時にいちいちimportを使うのが面倒くさいんで
自動でimportする設定ってtsconfigにないかな？

**デフォルトの名無しさん** · 2017/06/17(土) 10:56:23.79

typescript便利だけどやっぱり型が後付の弊害がなかなかしんどい。
nullを許容しない前提かと思って使っても結局
実体はnullが突っ込んであったりする。

**デフォルトの名無しさん** · 2017/06/17(土) 17:32:41.06

弊害じゃなくて人為的ミス
誤りに気付いた者が正せばいい

**デフォルトの名無しさん** · 2017/06/17(土) 22:27:47.68

swaggerのジェネレーターが出すコードなんだよね。プルリク出すのが面倒です

**デフォルトの名無しさん** · 2017/06/18(日) 00:50:13.20

サーバーサイドの言語仕様とswaggerがstrict null checkに対応してないだけであって
typescriptは何も悪くないのでは

**デフォルトの名無しさん** · 2017/06/18(日) 15:17:38.51

ほんそれ

**デフォルトの名無しさん** · 2017/06/18(日) 20:34:02.75

>>734
本体がstrict null check対応しても
モジュール側が対応してないとそこは無視するってことです？
例えばモジュールが強制的に T | undefined | null 型になるとかならいいんですけどね

**デフォルトの名無しさん** · 2017/06/19(月) 00:15:28.42

type Action =
{
type: “A”,
id: number
} |
{
type: “B”,
payload: any
} ….

みたいな定義がある時に

interface ALias {
[type: Action.type]: () => any;
}

export default <Alias> {
“A”: func1,
“B”: func2,
}

みたいに書けないですかね？
つまりAction.typeをinterface の条件に入れたいってことなんですが。

**デフォルトの名無しさん** · 2017/06/19(月) 09:56:19.65

インデックスシグネチャがstringかnumberしか受け入れない現状では
Aliasを定義する時点でキー(Action.typeの値)が
分かってるなら interface Alias { 'A'?: Func; 'B'?: Func; }
分からないなら interface Alias { [type: string]: Func; }

**デフォルトの名無しさん** · 2017/06/19(月) 20:30:47.90

>>730
interface Actions {
A: {id: number};
B: {payload: any}
}

interface Arias {[key in keyof Actions]: () => Actions[key]}

こういうことかな？

**デフォルトの名無しさん** · 2017/06/19(月) 21:29:43.40

携帯から書いたけどエラー起きてるし意図理解できてなかった。
こういうことかな？
type Action = { type: "A" } | {type: "B"};
type Arias = {[K in Action["type"]]: () => void}
http://i.imgur.com/17xtAlw.png

**デフォルトの名無しさん** · 2017/06/19(月) 22:19:36.13

Arias（笑）

**デフォルトの名無しさん** · 2017/06/20(火) 16:14:46.75

>>740
おー。聞いてみて良かったです。半分諦めてたんで。
上手く動きました。ありがとうございます。

**デフォルトの名無しさん** · 2017/06/21(水) 12:13:37.61

>>742
もっとこういう質問で賑わってほしい
書いてて気持ちいい言語だから
angularやreactは流行らなくていいけどフロント開発の標準はtypescriptになってほしい

**デフォルトの名無しさん** · 2017/06/21(水) 14:47:30.10

>>743
定義ファイルがなくて自作するハメになると途端に苦痛になるけどな。
あとReactというかReduxつかってて合わせてimmutable.js使ってると
いつの間にかclassがjsonに変わってることがあってその場合はtypescriptの型と合わなくなるから
しんどい。型が後付じゃない言語ならこういうことがないから、ちょっと辛い。
結局reducer内で使う時にjsonからimmuatblejsのclassに変換して
state返す時にjsonに戻す処理を毎回入れる方針になった。

immutable.jsは全然typescriptと相性が良くない。
XXX.set(‘member’, value) みたいな構文になるから。
もっとtypescriptで使いやすいimmutableなライブラリないかしら。

**デフォルトの名無しさん** · 2017/06/21(水) 16:08:20.66

>>744
新バージョンではXXX.setが型安全になるからもう少し待て
リテラル型とkeyofを使うらしい

**デフォルトの名無しさん** · 2017/06/21(水) 19:23:40.28

https://goo.gl/7Ty7Tq
こんな感じのコードでファイルのアップロード処理を作りたいんですが
上手く動かなくて悩んでいます。お助け下さい

**デフォルトの名無しさん** · 2017/06/21(水) 21:09:26.65

>>746
ブラウザのセキュリティ設定で、`input.click()`はfileエレメントには効かないみたいですね。
https://stackoverflow.com/questions/210643/in-javascript-can-i-make-a-click-event-fire-programmatically-for-a-file-input

**デフォルトの名無しさん** · 2017/06/21(水) 21:50:59.59

>>744
immutablejsというのは使ったことないけど、
XXX.set(‘member’, value)みたいな処理もkeyof使ってラップしてあげればkey毎に違う型のvalueに対応できる。
例えばES6のMap<K,V>クラスをラップすれば以下みたいなこともできる。
まあ新しいバージョンで対応されるならわざわざラップクラス作る必要ないがｗ
class TypeSafeMap...(省略

interface IObject {
name: string;
height: number;
isYes: boolean;
}

const safeMap = new TypeSafeMap<IObject>();
safeMap.get("name") // string型
safeMap.get("height") // number型
safeMap.set("name", 1) // NG
safeMap.set("name", "one") // OK

https://goo.gl/j6hy4T

**デフォルトの名無しさん** · 2017/06/21(水) 22:49:52.97

>>747
こちらは結局イベントリスナーをcickではなくchange にすることで上手く動くようになりました。

>>748
typescriptのジェネリクスの性能いいですね。
結構知らない機能がまだありそう。

**デフォルトの名無しさん** · 2017/06/22(木) 00:17:25.62

>>749
それはよかったです、てっきりclickイベントをjsで発火させてファイル選択ダイアログを自動で開かせたいのか思ったw

**デフォルトの名無しさん** · 2017/06/22(木) 17:18:45.24

>>750
そうなんですけどリスナーのイベント指定がclickではなくchnageだったってことです。
https://goo.gl/QHZCsG

before
i.addEventListener(‘click’, async (e) => {
after
i.addEventListener('change', async (e) => {