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/

**デフォルトの名無しさん** · 2016/10/08(土) 21:45:49.55

>>471
|| のことかな？ falseだとダメだけど

**デフォルトの名無しさん** · 2016/10/20(木) 18:22:59.19

typescriptでnode_modules配下のjsコードのimportは可能ですが
自作のjsコードをimportして使いたいのですが可能でしょうか？
具体的に言うとpegjsで作ったparserをtypescriptから使いたいんです。

**デフォルトの名無しさん** · 2016/10/21(金) 09:58:59.53

>>473
http://qiita.com/m0a/items/710b8f2b8327868cf049

**デフォルトの名無しさん** · 2016/10/21(金) 10:02:09.42

公開部分だけなら自分で定義ファイル書くのは容易なんじゃないか
もしくはソースをTypeScriptに変換しちゃって-d付きでコンパイル

**デフォルトの名無しさん** · 2016/10/21(金) 12:40:55.64

ちょっと考えればtsだってjsに変換してからimportしてるわけだからエラーが出てるようにみえるのは
定義がないだけってわかるだろうに。アホですな。

**デフォルトの名無しさん** · 2016/10/24(月) 23:34:32.07

typescript2.0から.d.tsのデフォルトの検索パスってどうなってるんですかね？
とりあえず自分で定義したのはnode_modules/@types/ に置くことで認識はするんですけど
気持ち悪いのでできればnode_modulesに置きたくないんですよね

**デフォルトの名無しさん** · 2016/10/25(火) 00:14:10.49

その手の質問はQ&Aサービス使え

**デフォルトの名無しさん** · 2016/10/25(火) 09:54:10.21

>>477
--typeRoots

次からhttps://github.com/Microsoft/TypeScript/wikiを必読としてテンプレに入れようぜ

**デフォルトの名無しさん** · 2016/10/25(火) 15:38:46.44

そう言わずに教えてあげればいいじゃない。どうせ話題もないんだし

**デフォルトの名無しさん** · 2016/10/25(火) 16:45:27.88

.net frameworkを使えたりframeworkからコンパイルできれば面白くなりそうなのに

**デフォルトの名無しさん** · 2016/10/25(火) 18:39:55.45

たしかに .Net Framework使えたら便利だな

現状ではNode.jsから外部コマンドを叩いて
C#やPowerShellを経由すればできるんじゃね

**デフォルトの名無しさん** · 2016/10/25(火) 20:33:02.00

やっぱりTypeScript使いの人はMicrosoftマンセーの人が多いの？
Mac使いとしては.Netが使えたからどうなんって感じなんだが。
ElectronとかでTypeScriptを使う話をしてるの？

**デフォルトの名無しさん** · 2016/10/25(火) 21:30:56.89

Windows向けtypescript処理系自体jscriptにコンパイルされて.NETオブジェクト経由でファイルアクセスしてなかったか

**デフォルトの名無しさん** · 2016/10/26(水) 02:40:39.39

>>483
＞TypeScript使いの人はMicrosoftマンセーの人が多いの？
特定の企業が好きというよりかは
デファクトスタンダードに乗りたいだけ

WinとMacならWinが（価格性能比的に）使いやすいし
AndroidとiPhoneならAndroidが使いやすいから
（規制が少ないのでとくに開発側としては）

**デフォルトの名無しさん** · 2016/10/26(水) 03:51:14.56

typescript使うよりc#で書くほうが楽だよね

**デフォルトの名無しさん** · 2016/10/26(水) 07:48:56.60

>>481
JsProjectWinRTNamespace: https://msdn.microsoft.com/library/mt125480
WinRT (UWP) ならJavaScript側へ公開できるから、それを使うことは可能。
なんにせよ、JavaScriptホスト側を握っていれば (ChakraCore等) 好きにできる。Macでも。

**デフォルトの名無しさん** · 2016/10/26(水) 10:52:47.34

>>484
.netじゃなくてWSHを使ってると思う
tsc.jsの2630行目辺りを読んでみれ

**デフォルトの名無しさん** · 2016/10/26(水) 14:57:17.75

tsc.js
https://github.com/Microsoft/TypeScript/blob/master/lib/tsc.js

**デフォルトの名無しさん** · 2016/10/27(木) 00:16:48.17

>>485
surfaceて高いイメージあるが。
最近はmacも安いし、unix系だからweb系ならmacの方が人気ないか？
そしてtypeScript使うやつはweb系だよね。

**デフォルトの名無しさん** · 2016/10/27(木) 00:28:41.45

Web系といってもBtoBの比較的かっちりしたものをやってるところはC#やJava使ってWindows上で開発してるところも多いよ
そしてTypeScriptもWeb系の中では比較的そっちの方で好まれてるイメージ

**デフォルトの名無しさん** · 2016/10/27(木) 07:44:18.44

Web系じゃないけどソフトのプログラムでJavaScriptが採用されてるから使ってるよ

**デフォルトの名無しさん** · 2016/10/31(月) 11:16:34.62

データと操作を分離する運用

https://goo.gl/L2gey4

上記スタックオーバーフローを見てたんですが
データ構造を扱うときにclassを使わずにすべてjsonにしてしまうって運用は結構を有る話でしょうか？
個人的にはElixirも触っていてデータ構造と処理関数を分けると言うのはアリだとは思うんですが
手元のコードはclass使いまくりでシリアライズが必要になったタイミングで軽く後悔しているところです(^ρ^)

**デフォルトの名無しさん** · 2016/10/31(月) 12:47:50.83

そんなに難しい話じゃないような
class Pen {
constructor(private json: PenData) {}
}
でいいじゃん

**デフォルトの名無しさん** · 2016/10/31(月) 12:58:02.65

>>494
それでデシリアライズしたものをシリアライズした時にどうやってPenDataだと特定するの？

**デフォルトの名無しさん** · 2016/10/31(月) 13:30:00.95

>>495
シリアライズした構造が固定なら、ルートから順に再構築するのでは？
自分で全てのコンストラクタなりdeserializeメソッドを実装することになる

汎用デシリアライズ関数1個で全てを賄うつもりなら、JSON内にクラス名を保持して
クラス名とJSONからオブジェクトを構築するファクトリを用意するのかな

TypeScriptは実行時型情報が無いから、意外と素直で原始的な方式になると思う

**デフォルトの名無しさん** · 2016/10/31(月) 16:02:19.09

>>496
ですよね。結局こういうめんどくさい実装になるので、だったら
最初からロジック的にデータ構造はすべてjsonにしてしまったほうが楽かなと。

**デフォルトの名無しさん** · 2016/10/31(月) 17:59:38.01

>>497
ロジック的にJSON (=循環の無い木構造) にできるなら、それが楽だとは思う
実行時には循環参照が必要になる場合は、保存時にフラットなJSONに変換せざるを得ない
これを汎用化していくと、いわゆるO/Rマッパーになるんだろうな

**デフォルトの名無しさん** · 2016/10/31(月) 20:32:53.85

ここまでなんのためにシリアライズするか確認するやつなし

**デフォルトの名無しさん** · 2016/10/31(月) 21:41:15.52

>>495
そんなもんまともなスキーマ設計してたら一意に決まるだろ
JSは伝統的にAPI指向で、入出力のスキーマだけはきっちり守って
あとは適当に辻褄合わせすればいいという考え方をするもんなんだよ
エンティティを重視しないの

**デフォルトの名無しさん** · 2016/10/31(月) 21:42:12.65

chrome extension作ってまして
background - popup -contentscript間のデータのやり取りがjson経由でしかできなかったので。

**デフォルトの名無しさん** · 2016/11/01(火) 01:26:11.04

永続化や通信でシリアライズが必要ならまず構成と通信内容を決めて
実装可能であることを確認してから個々の実装に入るべきだった
行きあたりばったりで通信が必要なデータやコマンドが噴出してるだろうから
個別機能に逃げずに先にそこを設計しろ

**デフォルトの名無しさん** · 2016/11/01(火) 03:17:05.88

>>501
普通にobjectを渡せるんじゃないか？

**デフォルトの名無しさん** · 2016/11/09(水) 22:55:56.80

React Componentを相対パスでimportするのはもう嫌なので、絶対パスでimportしてやる
http://qiita.com/endam/items/49696abedb68878d8b01
コレいいなって思ったんですがTypeScriptで絶対パス指定する方法って標準であったりしないですかね？

**デフォルトの名無しさん** · 2016/11/10(木) 00:57:52.66

TypeScript 2.1 RC: Better Inference, Async Functions, and More
https://blogs.msdn.microsoft.com/typescript/2016/11/08/typescript-2-1-rc-better-inference-async-functions-and-more/

**デフォルトの名無しさん** · 2016/11/10(木) 03:11:40.39

モジュール周りはここに書いてあるようだ。
https://www.typescriptlang.org/docs/handbook/module-resolution.html

**デフォルトの名無しさん** · 2016/11/12(土) 00:03:42.69

>>505
TypeScript 2.1.1 変更点
http://qiita.com/vvakame/items/305749d3d6dc6bf877c6

**デフォルトの名無しさん** · 2016/11/16(水) 13:26:15.81

bucklescript ω

**デフォルトの名無しさん** · 2016/11/20(日) 01:23:41.33

みんなエディタは何使ってるの？　VisualStudio以外にいいエディタある？

**デフォルトの名無しさん** · 2016/11/20(日) 08:29:21.81

vscode

**デフォルトの名無しさん** · 2016/11/20(日) 09:20:47.29

vim

**デフォルトの名無しさん** · 2016/11/20(日) 09:40:13.46

Emacs
http://www.typescriptlang.org/
の下の方にEmacsのTypeScript開発環境へのリンクがある。メソッド補完とかリファクタリングとか全部出来る

**デフォルトの名無しさん** · 2016/11/20(日) 16:06:26.39

>>509
ALM
http://alm.tools/

好きが高じてエディタまで作ってしまった例

**デフォルトの名無しさん** · 2016/11/20(日) 17:44:23.07

>>513
+1

**デフォルトの名無しさん** · 2016/11/24(木) 16:16:50.02

ALM 使ってみたけど、JIS キーボードで CTRL+¥ が効かなくてツリービューが出ない…
ファイル操作はツリービューでやるんだよね？

**デフォルトの名無しさん** · 2016/11/25(金) 11:07:12.84

>>513
本家のプレイグラウンドも楽しいけど、ちょっと他のライブラリとか合わせられるようなのもほしい。こういうのと組み合わせて作ってくんないかなー。

**デフォルトの名無しさん** · 2016/12/01(木) 23:31:35.77

TypeScript Advent Calendar 2016
http://qiita.com/advent-calendar/2016/typescript

(今年も)やっちまった感

**デフォルトの名無しさん** · 2016/12/02(金) 15:42:21.41

需要なしか

**デフォルトの名無しさん** · 2016/12/02(金) 21:48:15.76

12月突入数時間前まで誰も立てなかったしそりゃね

**デフォルトの名無しさん** · 2016/12/03(土) 16:07:27.97

いつも納期を守らないひとですねわかります

**デフォルトの名無しさん** · 2016/12/03(土) 22:27:39.83

TypeScript 2.1のkeyofとかMapped typesがアツい
http://qiita.com/Quramy/items/e27a7756170d06bef22a

そろそろ2.1正式版来る気配

**デフォルトの名無しさん** · 2016/12/05(月) 08:39:36.02

人気ないでしょ。

**デフォルトの名無しさん** · 2016/12/05(月) 09:21:11.08

英語圏はどうなのよ

**デフォルトの名無しさん** · 2016/12/05(月) 16:49:11.01

>>521
パスやファイル名に日本語が有ると
エラーする問題はこれで直るのか？

**デフォルトの名無しさん** · 2016/12/05(月) 17:57:33.20

>>519
Tcl/Tkの誰か立ててよ

**デフォルトの名無しさん** · 2016/12/08(木) 07:43:57.58

https://blogs.msdn.microsoft.com/typescript/2016/12/07/announcing-typescript-2-1/
「...」系の構文が増えるといいなぁ
最近のC++に追加された構文が便利だから

**デフォルトの名無しさん** · 2016/12/08(木) 14:41:29.32

しかしkeyofとかTypeScriptスゲーな
型言語としてやれる事はとことんやろうという方針なんだな
keyofは既存のJavaScriptコードと連携する時にコーディングミスをコンパイル時に分かるようになるって事かな
TypeScriptオンリーの時は多分使いそうにないけど、何か使いどころがあるんだろうか？

**デフォルトの名無しさん** · 2016/12/08(木) 14:49:41.32

と思ったらMapped Typesでkeyofが必要だったんだな。納得した。
Mapped Typesは使いどころを模索中…

**デフォルトの名無しさん** · 2016/12/08(木) 23:29:45.09

ちょっと手段が目的化してる感が否めないなあ
最初からTypeScript前提で作ったモジュールを使う分にはkeyofが必要な状況はそう無いだろうし、
既存のJSライブラリのインターフェース書くための機能だと割り切るんだったら
そこまで厳格にDRYに拘る必要もないように思うが

**デフォルトの名無しさん** · 2016/12/09(金) 08:58:45.48

・interface を readonly の有無で2回書かなくて良い
・エレメントに設定する一連の属性をオブジェクトで渡す際の型安全
ぱっと思いつくだけでも悪くない機能だと思うけど

**デフォルトの名無しさん** · 2016/12/10(土) 08:55:22.73

classのコンストラクタを定義する場合、もしメンバ変数が20個あるとすると、
コンストラクタにも20個の引数を並べて、
constructor(arg1, arg2, ......, arg20){
　this.parm1 = arg1;
　this.parm2 = arg2;
　this.parm3 = arg3;
　..
}
のようにする必要がありますか？
もう少し簡素に書けませんか？

**デフォルトの名無しさん** · 2016/12/10(土) 10:13:56.45

constructor(public parm1, private parm2) {

**デフォルトの名無しさん** · 2016/12/10(土) 13:08:54.64

>>532
そんな技が有ったのですか！
ありがとうございました。

**デフォルトの名無しさん** · 2016/12/16(金) 22:23:17.99

型システムがチューリング完全になっててもおかしくないな
たしか scala と c++ は達成してた筈

**デフォルトの名無しさん** · 2016/12/16(金) 22:39:54.50

C++はtemplateでしょ
template引数の扱いがほぼ帰納関数の定義みたいなもんだしな

**デフォルトの名無しさん** · 2016/12/16(金) 22:40:27.11

TypeScriptの型はあくまで検査専用でメタプログラミングには使えないから無理じゃない?

**デフォルトの名無しさん** · 2016/12/16(金) 23:19:39.50

C++のテンプレートがチューリング完全だとしても文字列のハッシュ値は計算出来ない
なぜならC++の文字列はポインタでしかないけどコンパイル前に参照する事が出来ないから
それでもチューリング完全なのは間違いないけど、別にチューリング完全だからってなんでも出来るわけじゃないってことだな

**デフォルトの名無しさん** · 2016/12/16(金) 23:21:43.20

ちなみに文字列じゃなくて文字の配列にすれば問題ない
const char* str = "hoge";じゃなくて
const char str[] = { 'h', 'o', 'g', 'e' };ってこと

**デフォルトの名無しさん** · 2016/12/16(金) 23:24:42.09

間違えた…
const char str[] = { 'h', 'o', 'g', 'e', '\0' };
だった
連投ごめんなさい

**デフォルトの名無しさん** · 2016/12/16(金) 23:29:20.71

ゲーデル「そこはゲーデル数で…」

**デフォルトの名無しさん** · 2016/12/16(金) 23:34:58.93

ゲーデルはホント天才だよな
紙と手廻し計算機しかない時代に
「符号化すれば数式だろうが証明図だろうが数で表せるし
数の計算が数式処理や証明じゃん」なんて

**デフォルトの名無しさん** · 2016/12/17(土) 17:02:33.38

むしろその世代だったからよかったのかも

**デフォルトの名無しさん** · 2016/12/18(日) 15:38:22.61

TypeScript 2.0.8でちょっとお尋ね

~~~~file1.ts
namespace TestNS { export interface TestInterface {} }
~~~~

~~~~file2.ts
/// <reference path="file1.ts" />
import * as Lib from "～"; ← こいつがいると下のTestInterfaceでTS:2304 Cannot find nameが出る(コメントアウトすれば出ない)
namespace TestNS {
export class Test implements TestInterface {}
}
~~~~

上に書いた通りimport文がいるとTestInterfaceでTS:2304 Cannot find name 'TestInterface'になるんだけれども, これってどう理解したらよい？
import文の有無で見つからなくなるのはとても不思議な感があるんだけど

**デフォルトの名無しさん** · 2016/12/18(日) 15:52:58.94

内部モジュール形式と外部があって内部だとネームスペースはすべて同じものとしてマージされるから参照できる
内部ゴミだから外部覚えろ

**デフォルトの名無しさん** · 2016/12/19(月) 20:40:04.16

reference pathは使わないことを勧める
型定義ファイルの参照はreference typesや--types
連結するなら目的別にプロジェクトを分けて--outFile

**543** · 2016/12/19(月) 23:08:19.83

結局外部モジュール化して解決しました
細かいことは組んでからコンパイル済みソース見て考えることにします

**デフォルトの名無しさん** · 2017/01/19(木) 09:39:46.00

https://chrome.google.com/webstore/detail/%E3%81%AF%E3%81%A6%E3%81%AAng/mbgdnfmdelffjdhkdggilmphfdihnmcj?hl=ja

**デフォルトの名無しさん** · 2017/02/03(金) 10:13:11.49

TypeScript 2.2
https://blogs.msdn.microsoft.com/typescript/2017/02/02/announcing-typescript-2-2-rc/
・object type - "non-primitive"を表す型
・mixins and composable classes - 無名クラスを返す関数のサポート

**デフォルトの名無しさん** · 2017/02/03(金) 11:53:48.71

>>548
rcかあ
入れるのはやめとくわ

**デフォルトの名無しさん** · 2017/02/13(月) 21:38:00.71

typescript版のjsFiddleみたいなのないですかね？

**デフォルトの名無しさん** · 2017/02/13(月) 21:52:46.81

>>550
https://jsfiddle.net
typescript選べるんだけど、何がお望み？

**デフォルトの名無しさん** · 2017/02/14(火) 08:03:16.30

>>551
補完が効かないとtypescriptの意味ないよね。

**デフォルトの名無しさん** · 2017/02/14(火) 22:01:13.41

なぜ TypeScript の型システムが健全性を諦めているか
http://qiita.com/na-o-ys/items/aa56d678cdf0de2bdd79

**デフォルトの名無しさん** · 2017/02/15(水) 11:35:44.90

typescriptでvue.js使ってる人っています？
どんな感じか聞いてもいいですか？
vueファイルのscriptにtypescriptを使った場合にVisualStudioCodeから補完聞かせる方法ってあるんですかね？

**デフォルトの名無しさん** · 2017/02/15(水) 13:37:43.12

いいよ
あるよ

**デフォルトの名無しさん** · 2017/02/16(木) 14:34:53.75

typescript ってclassの中でclassは定義できないの？

**デフォルトの名無しさん** · 2017/02/16(木) 16:54:40.22

>>556
innerClass = class { ... } の構文を使ってみては？

**デフォルトの名無しさん** · 2017/02/16(木) 18:23:19.49

>>557
さんきゅう。
その後、自分でも調べてそういう構文を見付けたのだが、
なぜ一般的な言語のようにclassをネスト出来ないのかな？

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

構造的にESにないものは採用されないんじゃなかろうか
俺もprivate static Inner = class {...で試したけどあまり使えなさそうだからやめた

**デフォルトの名無しさん** · 2017/02/23(木) 21:12:34.52

Announcing TypeScript 2.2
https://blogs.msdn.microsoft.com/typescript/2017/02/22/announcing-typescript-2-2/
TypeScript 2.2.1 変更点
http://qiita.com/vvakame/items/eb6c054360868b88f9b1

**デフォルトの名無しさん** · 2017/03/19(日) 00:28:00.75

Chrome拡張機能を作ってる方結構いるみたいなので教えてほしいのですが
「chrome.～～～」のAPIが「Supplied parameters do not match any signature of call target.」とコンパイルエラーになります
「/// <reference path="./node_modules/@types/chrome/index.d.ts" />」でd.tsは指定しているのですが、他にも何か記述が必要ですか？

**デフォルトの名無しさん** · 2017/03/19(日) 02:18:51.51

>>561
そもそも今は/// <reference path=みたいな書き方はしない。
@types/XX npm install すれば使えるはず。

**デフォルトの名無しさん** · 2017/03/19(日) 02:40:46.59

インストしても明示的なインポートなしには使えんよ

**デフォルトの名無しさん** · 2017/03/19(日) 03:16:06.29

>>561
エラーしてる部分のソース貼るといいよ

**561** · 2017/03/19(日) 11:24:02.73

皆様ありがとうございます…解決しました…chrome.～～に引数が設定されてなくてエラーになるという超凡ミスでした…
エラーメッセージの意味をきちんと理解しないといけないですね…

--- コンパイルエラー ----------------------------------------------------------
if (window.location.href.indexOf('aaa.com') !== -1) {
chrome.pageAction.onClicked.addListener();
}
------------------------------------------------------------------------------

--- コンパイル正常 -----------------------------------------------------------
if (window.location.href.indexOf('aaa.com') !== -1) {
chrome.pageAction.onClicked.addListener(() => {

});
}
------------------------------------------------------------------------------
あと、仰る通り<reference path= />なくてもコンパイル通りました

皆様お騒がせしました

**デフォルトの名無しさん** · 2017/03/19(日) 13:25:11.81

>>565
エディター何使ってんの？
typescriptなら書いてるそばから検出できるエラーじゃないのか？

**デフォルトの名無しさん** · 2017/03/28(火) 10:03:39.39

ターゲットにWebAssemblyを追加する計画とか無いのかな

**デフォルトの名無しさん** · 2017/03/28(火) 14:44:15.57

interfaceの定義でArrayの要素が２つしかない場合の定義の仕方ってあるかな

interface Pair {
number[2]
}

interface Data {
pairs :Pair[]
}

みたいな感じで定義できないもんか。
諦めてnumber[]にするしかない？

**デフォルトの名無しさん** · 2017/03/28(火) 14:54:23.37

タプル使え

**デフォルトの名無しさん** · 2017/03/28(火) 17:30:18.19

>>569
thanks

type Pair = [number,number]
interface Data {
pairs :Pair[]
}

**デフォルトの名無しさん** · 2017/03/30(木) 23:49:26.09

index.htmlに直接CDNからreactとreact-domを読み込んで
npmからは@types/reactと@types/react-domをインストールし
tsxファイルからimport文を使わずにreactを使ったところ何の問題もなく動いた。

plotly.jsを同じように使おうとしたら自動では定義ファイルを読んでくれない。
この違いは一体何なのか？

と思って定義ファイルを見たところreactとreact-domには以下のような記載がある

export as namespace ReactDOM;
export as namespace React;

上記を真似て定義ファイルに
export as namespace Plotly;
を追加したら同じ挙動になった。

export as namespace XXX ってなんすか？