TypeScript part3
■ このスレッドは過去ログ倉庫に格納されています
http://www.typescriptlang.org/
JavaScript that scales.
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
Any browser. Any host. Any OS. Open Source.
part1
https://peace.5ch.net/test/read.cgi/tech/1349187527/
part2
https://mevius.5ch.net/test/read.cgi/tech/1430386649/ 流石に不親切すぎる。猿でもわかるgitとか読むと良い TypeScript使うな。汚らわしい。
バカはバカらしくPHPでも使ってろゴミ。 elem.onclick = function () {
if (this.classList.contains('classA')) {
・・・
}
こんなコードを書くと、Visual StudioのTypeScriptで
エラー TS2339 (TS) プロパティ 'classList' は型 'GlobalEventHandlers' に存在しません。
と出るのですが、生成されるJavaScriptコード(上のコードを同じ)は問題無く実行出来る。
これは何故ですか? あのさぁ…何のためにTypescript使ってんのよ… thisを使わないか、addEventListener使う this: GlobalEventHandlers のところは this: thisじゃだめなのかな? >>126
elemにちゃんと型(多分HTMLElement?)が指定されてればそんなエラー出ないぞ >>129
addEventListenerでも同じだろ addEventListenerは要素ごとにシコシコ定義されていて、thisがその要素になっているのでOK
onclickとかはGlobalEventHandlersでmixin的に定義されていて、this: GlobalEventHandlersになっちゃってるのでNG >>135
なるほど。でも、そもそも
this.classList ではなくて
elem.classList と書けばいいんじゃないか ようやくEitherでホイサーできるTSがきたか
しかしleftrightとパタマチがないとダメやろこれ よんだら、これEitherじゃなくホイサーだろ・・・
エラー処理強制できないEitherってナンジャー?
ゴミジャー 通常、string と string | null は同等なんでVSCodeのポップアップでも | null は省略されるけど、
これを省略させないで表示する設定ってないのかな。
strictNullChecks 使ったら区別できなくて困った。 通常、string と string | null は同等じゃないです 他に困ってる人がいないってことは strictNullChecks 自体あまり使われてないのかな。 strictNullChecksは使ってるけどその困り方がよく分からないから具体的にどういうコードを書こうとした時に何が困るのか教えてくれるとありがたい function f(): string | null {
if(Math.random() === 0) {
return null;
}
return 'abc';
}
function g(): string {
return 'abc';
}
const x = f();
const y = g();
VSCode で x や f() にマウスポインタを当ててポップアップで型を表示しても
string | null じゃなくて string としか表示されないんでこれを区別できるようにしたい。 * プロジェクトルートにtsconfig.jsonはあるか
* tsconfig.jsonでstrictNullChecks或いはstrictが有効になっているか
* そもそもVSCodeでプロジェクトルートを開いているか なるほど、VSCode用のtsconfig.jsonを置いてやればいいってことか。ありがとう。
ビルド用のtsconfig.jsonは別の場所に置いてた。 そりゃプロジェクトルートに無けりゃどういう原理で探してくるんだって話だ じゃなくて、VSCodeがtsconfig.jsonのビルドオプションに合わせて表示を変えているとは想像してなかった。 そもそもtscもtslintもプロジェクトルートのtsconfig.jsonなりtslint.jsonなり読むんだから・・・・・ 各.tsに対してどのtslint.jsonが使われるかという認識はあったけど、
tslintもtsconfigを見てるのか。なるほど。 誤解を招く書き方だったから訂正しておくけどtslintはtsconfig.json読まんよ 今日は emitDeclarationOnly でd.tsだけ出力できることを発見した export as namespace が何をどうしてるのかさっぱりわからん JavaScriptを勉強したことがないので、今からならどうせならとTypeScriptの方を身につけたいんだけど・・・・
これって先ずJavaScriptが出来ないことには実用にならないの? typescript は javascript の上位互換なのだから、ts やってるうちに js のことも勉強しなければならなくなる (特に、es5, es2015 とかのキーワードで)
言い換えれば、ts を勉強してれば js が出来るようになる >>167
javascript9割以上+TypeScript追加仕様なんだからjsやらないなら使う意味ねえだろ 正確にはTypeScript使ってるとJavaScriptの深い部分が気になってきて、最終的には自然とJavaScriptを勉強し始めてるよ
気にせずTypeScriptから始めれば良い tsだけで理解できることをjsを経由する意味はないしむしろ型を考慮しないダーティーな解法を覚えさせられるだけ有害 tsの、ライブラリの95パー以上がjsなんだから
どうにもならん。
pythonの型アノテーションを
完全に付ける書き方に別言語名つけてるようなもんだ。 >>172
動的型は型を考慮しないと思ってんのはお前だけだ
JavaScriptの全ての変数に型は存在しているし目の前の変数の型を知らずにコーディングしてる奴なんていない
JavaScriptは実行時に型チェックして型の正しさを保証して、
TypeScriptは実行前に型チェックして型の正しさを保証するって違いだけだ 作ってる時に頭の中にある型なんか、作った後には何の意味もないし、実行時に型チェックするなんて馬鹿の極み >>175
頭の中w
JavaScriptには全ての変数に型があるんだよ
アンダースタン? >>177
保守する人には作ってる人の意図はわからないって意味だよ 動的のつらみはrubyとかjavascriptで散々通ってきてtypescriptに行き着くわけだけど、
まだそこを通過中の人とは話が噛み合わないんだよなあ
結局こっちに来ることになるのに TypeScriptにUnion型がある時点で最早動的型と言ってもいい
宣言したあとに離れた場所のコードを見ても、パッと見じゃどっちの型になってるかは分からないからね >>181
typescirptってそういうところもチェックしてくれるんだぞ 動的型の言語、結局人気が年々下落しはじめてる。
c#やtypescriptぐらいの、型あり基本で、
いざとなったら、部分的問わないのも、
自然で簡単に書ける、程度が今はよいな。 >>185
型を意識しない、というのは私には有用にみえます、ただし変数宣言は動的型言語にも必要だと思いますが、それを表立って採用している言語はありますかね… 言語の人気が年々移り変わる、
ということは、
いつかtypescriptも、ほかの型付き、部分的型付き言語の人気も、移り変わる、
とは、考えないのか? 動的ウンコガイジどもに型の有用性説いても、豚に真珠だろ
ペチプァやらルビ豚やら、あいつら中卒のガチゲェジだからな >>188
> 型の有用性
だから動的型言語にも型はあるし型の有用性を享受してんだけど…何度言っても分からない奴は分からないんだな そんな誰でもわかってることで得意げになってるのが恥ずかしい
一合目で山に登ったつもりになってる感じ
みんなもっと上にいるから! 動的型と静的型では型の目的が違うことを理解していないらしいな 昔は動的型付け言語と静的型付け言語って対義語みたいに思ってたけど、
TypeScriptやってみたら単純な二元論じゃないって気付かされた。 そう対義語じゃない、分かりやすい表現だなぁ
本当に型が無いのはアセンブリ言語で、全てが整数になっててそれをどう解釈するかは本当に人間次第だからな そういうのを昔の人は「型あって型なし」と言ったのだ 同じファイルの書き込み処理なんかをRubyが5行で書けて、Javaが15行とかで書いて、いかにJavaが駄目かってブログ記事がはてなブックマークとかでよくバズってたな
声のでかい人はいつでもいる Javascriptのthisというか変数スコープが厄介でHaxeやってるけど
Typescriptはその辺の問題点引き継いでる? 「thisというか変数スコープ」?
分かってないことは分かった。
お前はどの言語やっても大成しない。 JavaScript(JS)/TypeScript(TS) のthis は、おかしい!
一方、jQuery, Haxe は、それを修正してる
また、JS/TS の== は危険だから、使っちゃいけない!
厳密等価演算子=== を使うべき!
一方、Haxe, Ruby は、== でOK
Haxe には、マクロ、引数つき列挙(enum)、代数的データ型、パターンマッチ、マルチプラットフォームがあるけど、TS には無い。
特に、switch 文での、enum が強力!
引数の型で分岐できるから、インタフェースと同等!
このサイトで、ブラウザでプログラミングして、実行できる
Try Haxe !
try.haxe.org/
Haxeプログラミング入門、尾野政樹、2015
Haxe は、Elixir に似てね?
プログラミングElixir、2016 thisや==は今ならeslint/tslint任せでほとんど問題ないね。
引数付きenumはようはUnion Typeだし、代数的データ型はTagged Union Typeかな。
パターンマッチそのものはないけどType Guardで似たようなことができる。
マクロとマルチプラットフォームはさすがにないな。 弊社、ガイジが導入したhaxeが完全な負の遺産化しててうんざりするわ
死ねとまでは思わないけど、産まれてこなければよかったのに thisはそもそも使う必要がない
jQueryとか昔のライブラリを使うとthisを使わざるを得なくなって混乱する
変数スコープの問題は多分変数の巻き上げの事だと思うけど、TypeScriptは変数を宣言する前にアクセスはエラーだから変数スコープの問題は無い 一般にバイナリ互換のこと。
スクリプト言語はソースコード=バイナリ扱いだが。
Qtとかのライブラリはソース互換やね。
そのライブラリと標準ライブラリ使う分にはマルチプラットフォーム。 TypeScriptのリテラル型を知って目から鱗だったんだけど、元ネタってどこなのかな?
TypeScript以前に採用していた言語とかある? https://www.infoq.com/jp/news/2019/03/typescript-3-3-release
Flowは,少なくともこの分析を実施した1年前には,Facebookによって極めて閉鎖的な方法で進められていた言語です。
開発はまったく透過的ではなく,ロードマップも公開されていませんでした。
プロジェクトへのコントリビューションは,Facebook以外からはほとんどありませんでした。
対照的にTypeScriptは,数年前にGitHubに移動して以降はオープンソース開発を採用しています。
最新のロードマップを公開し,外部からのコントリビューションを受け入れ,全般的にコミュニティとの密接な関係を維持しています。
Flowオープンソースはほぼ放置されているので,現時点ではTypeScriptに切り替えた方がよいと思います。
このような懸念に対してFlowチームは,現在の進捗状況と2019年計画の見直しによる対処を始めている。
この概要の中で,FacebookのソフトウェアエンジニアであるAvik Chaudhuri氏は,FlowからTypeScriptへの移行について取り上げている。
最近,Facebookを起源とするオープンソースプロジェクトの多くが,TypeScriptでのリライト計画を発表しています。
Facebookでは個々のチームの独立性を強く尊重しており,各チームがロードマップを作成し,
開発中のプロダクトに対して最大限の努力を払っています。TypeScriptへの切り替えを決定したプロジェクトは,
この切り替えによって外部コントリビュータによる支援をより多く受けられるようになります。私たちはこの決定を尊重します。 export default Vue;
export as namespace Vue;
型定義が↑だとjsのスクリプトモード(import なし)で↓のようにvscode認識してしまって悲しい
new Vue(); // NG
new Vue.default(); // OK
export default Vue じゃなくて export = Vue なら大丈夫っぽいんだが 質問なんですが、
interface TypeMap<T> {
a: number
b: string
c: T
}
declare function test<T, K extends keyof TypeMap<T>>(arg: K): TypeMap<T>[K]
test("b")
test<number, "c">("c")
↑
これをtest<number>("c")って書けるfunction testの定義の仕方ってあります? ついにunion distributionを理解してしまった TS3のunknown型いいな。
てかany入れずに最初からこれにしとけや。 esの上位互換である以上anyは無きゃいかんだろう。 unknownからの簡単にキャストできるような値ばかりなら、確かにanyはいらんかったろうな TSも知らんフロントエンドエンジニアとか死んでほしいわ 知ってるだけでデカい顔してるフロントエンドエンジニアも死んで欲しいわ ts知ってるだけででかい面できるってどんな現場だよ それくらい世界はまだJSの悲しみに満ちているってことさ
救ってあげようよ、僕らで ■ このスレッドは過去ログ倉庫に格納されています