Hyperappのloggerの型定義ファイルってどこで手に入りますか？
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
19LH5
TypescriptでReactを使用してますが、型定義がないReactのライブラリが多すぎて、大変ではないですか？
型定義があっても、古くて最新のライブラリと違ったりしてうんざりしてるんですが、みなさんは平気ですか？
ないよりか遙かにマシ、というスタンスでいた方がいい
何なら自分でtypedにコミットすべき
FacebookはReactの開発をTypescriptで行わない理由として、Flowの方が型が厳密だと言っているけど、
その辺、Typescript使いとしてはどう？
>>16
それ情報古くね？今はTypeScriptでも遜色ないし型情報が集まってるtsの方が優位 型定義にそんなに悩む理由がわからん。
C#とPythonやって、Pythonは動的型付けなんだ、ですぐ慣れた。
jsの時だけ悩む理由がわからん。
推測するに、恐らくJava的な多人数による土方的開発法やってるからだろうと思う。
jsは少人数でアジャイルが基本でしょw
型を理解できない低学歴にはTSの学習コストは高かろうな
まぁ、ずっとjQueryとかでウンコみたいな小規模LP作ってればいいんじゃないか？
正直に言うと、Typescript使えると仕事の幅が広がるじゃんか。
あと何かカッコイイし（笑）
なるべく使った方が早く覚えるでしょ。
収入に直結するからそれだけ。
土方がどうとかは否定できない。
大人数だと事前に仕様をビシッと決めるから、型定義も仕様書に落とし込んでおかないといけない。
まあPerlやPythonではなんで型にこだわってる人いなかったのに、JavaScriptだけうるさいのかはよく分からないね。
自分はそれだけ世間の本気度が高い証拠なんだろうと勝手に解釈しているよ。
>>23
> まあPerlやPythonではなんで型にこだわってる人いなかったのに、JavaScriptだけうるさいのかはよく分からないね。
PerlやPythonでは「製品」を作らないからだろう。 perlはただのゴミ
pythonはTypeHinting導入されたぞ
そんなことも知らないのか（呆れ、嘲笑、溜息）
本来スクリプト言語は動的型付で良い。
ただJavaScriptは近年汎用性を増して、一般的なスクリプト言語の域から超越しつつある。
TypeScriptはJavaScriptを本格的なシステム開発言語に昇格させる為の試みの一つ。
ただこれは諸刃の刃でもあり、JavaScriptがスクリプト言語から卒業したら、第二のJavaと変わらない。
意外とそれを望んでる奴は多いかもな。
静的型付などBASICから実装されていたのだから、昔に戻ったと言う事だ。
漸進的型付けの目指すところは、Javaの古臭い型とは異なるし、その認識は間違っている
土方だの言ってる馬鹿は論外
jQueryみたいなのつかってるヴァカが騒いでいるんだろう
あんなもの使わないといけないなら、要件定義がそもそも間違えている。
TypeScriptも使えないヴァカは存在価値がない。
俺らは土方じゃなくて、プログラミングの職人なんだよ。
私大文系のヴァカはおとなしくエクセルでもいじってろよ
>>26
△ ただJavaScriptは近年汎用性を増して
○ ただ、ブラウザは近年汎用性を増して、それに付帯するプログラミング言語であるJavaScriptも
WebAssemblyもどうやらマジでやってるようだし、
実現した際にはJavaScriptも一つの選択肢にすぎない。
型あり、型推論、形無し言語を自由に選べるようになる。勿論Javaも含めて。
（というか本来Javaが機能していればWebAssemblyは不要だったはず)
俺自身はTSを使ってはいないのだが、
コンセプト的には「書きたいところだけ書ける型」のTSがいいと思うよ。 >>29
お前はマ版から出てくるな
＞ヴァカに混じってJSをやる事になったのだが
＞Angularのドキュメント書いた奴氏ねよ
＞
＞私大文系が格好付けてワザと分かりにくく書いてるだろ
＞何言ってるのかさっぱりだわ
＞
＞ヴァカに文章かかせるなよ
Angular.jsの解説文も理解できない奴が何言ってんだよ 確かにヴァカだなぁ
解説文以前に、AngularはVue並のゴミなんだから
その指摘はあさってだわ
Angularみたいなゴミに難しい解説付けてるのが悪い
私大文系のクズが自分らを偉そうに見せる為にやってんのがバレバレだ
ヴァーカは救いようがないな
俺は長年Java一筋だったが変数に型が無いのなどあり得ないわ
仕様書に型が書いてないなんて自分で型考えろとでも言うのか？
ジャップの甘ったれた屑SEにとって都合のいい話だよな
TypeScript良いじゃねーか
こちらは仕様書をコードに落とし込むのが仕事だ
設計は設計専門職がいて高い金もらってんだろ？
型はそいつらが考えるんだよ。詳細をプログラマーに丸投げしてる時点で屑仕様なんだよ。
ヴァーカ！
こういう型が何なのかも知らんゲェジは型無し糞言語のウンポコペチプーで糞にまみれてろｗ
tsはcodeとセット感あるからideあってこその型付言語ですよ。
そういう意味で最高。
codeのExtension書けるしね
タイプスクリプトでVS Codeが最高。
たまに鉛筆と紙で手書きでコードかけると自称する奴いるけど、俺はそういう無理だし無駄だと思う。
コード補完機能が1番良い感じ。
このスレの諸兄は普段どのような開発でTypeScriptを使っておられるのかな？
>>38
学校で出された課題色々。
就職したらレベル低い奴多そうだから、俺は無双出来ると思うぜ。 型の概念も分かってないバカがいっぱいいるようだし
俺の方が知識は上だ。
論破して相手が悔しがってるの想像すると楽しい。
こんなロートルな連中に負ける気はしない。
もうすぐ全てのjava有料になるからjvm系は絶滅するんじゃないの？
ざまぁwwww
俺が社会人になったら土方どもに色々教えたるよ
惨めな土方どもwww
こういう頭でっかちは社会に出てから潰されてニートになったりするからね。勉強会に参加して早めに鼻っ柱を折る経験をしといたほうが良い
UWPアプリ開発でTypescript+Reactを使っているのは自分含めて数人だろうな。
ブラウザのアドオンからネイティブアプリも含めてTypeScriptだけで大抵の事は出来る
TypeScriptできる→俺凄い
ネトウヨ的DQN思考法
素直にC#使えばぁ～
>>47
>詳しく。reactと相性良いよね
詳しくも何も、Windows10はjs+htmlでデスクトップアプリが開発できるから、それでソフトを作っているだけ。
ただUIを全部作る必要がある。 >>49
最近Blazorとかいう強引な技術が出てきてるぞ TypeScriptは折角ならC#と継承とかの書き方も統一して欲しかったなぁ
Javascriptのフレームワークででかい顔w
Javaプログラマーからしたらお笑い種ですよ
ヴァカっぽくて笑える
JavaScriptやらないでいきなりTypeScriptから勉強するのってアリ？
でもjQuery覚えようとしたらJSも勉強しなきゃならなんのよね
つうか型システム以外はJavaScriptなんだから、TypeScriptを覚えることは普通にJavaScriptを覚えることにほぼ等しい
特に最新のJavaScriptに変換すると、単純に型指定だけが無くなったものが出力されることが多くなったな
むしろtsから入った方がいいくらいだ
生のjsは危険
俺もTypeScriptから学んだ口だ。
ライブラリの使い方とかvscodeが教えてくれるようになるからむしろjsを巣のまま学ぶより調子が良い
ビルドするのめんどくさい
TypeScriptのままレスポンスを返して動くようにしてほしい
Typescript からやるにも、良い書籍が無くない？
JavaScript の良い書籍で基礎学んでからTypescript やった方がわかりやすい気がする
書籍とか流れが速すぎて向いてないわ
最初にやる言語以外で言語を学ぶ目的で書籍買うなんてC/C++くらいだろ
そこまで変わらないのね 安心
tsから学んでみます
皆さん教えてくれてありがとう～
TypeScriptに __LINE__ マクロみたいな行番号埋め込む機能ってないよね？
デバッグ用にあったら良かったんだけど。
>>62
んなこたーない
Effective JavaScriptに書いてあるようなことが自然と全て理解できてるなら要らないけど、そんな奴が5chを見てるわけないし Effectiveは確かに読む意味がある本だわ
でもそれJavaScript既に知ってる人間が読む本だろ
effは時代遅れ
tsやってりゃ半分は知る必要も無い
tsそんなにいいかなぁ？
jQueryからvue、angularまで色々やってるけど、利点がよく分からないよ。
そらjQueryからvue、angularなんて脇道に逸れた時代遅れのゴミ使ってるセンスのない、
ぼんやりしたボンクラにとっては、利点も糞も気付けないわなｗ
angularは1系とか触ってたん？
今はtsで書かれてるはずだからts必須みたいなもんでわ？
>>71
> 2017年10月から
なんとゆう今さらωωω
そしてAndroidではKotlin標準化と併せてTSも標準化されたのをご存知ないのですンゴ？ωωω TSの標準化はGoogle社内の話で、Android関係なくね？
別に。何も変わらん。
諸事情でバベってるのにFlowも入れてないゴミどもは
最新のバベルなんて使わないし使えないだろうから相変わらずコヒースクリプト（爆）みたいな生カスジャバスクだし
既にTS使ってる奴らはTSだし
何も変わらん。
今さらドヤ顔でゆるいルール厳しいチェックとか言ってるのくそむかつく
厳しいルールが今まで普通だったのは
アバウトなのを許したらめちゃくちゃなのを差し込んで意図的に環境破壊していく会社がいたからだ
てめーらだけ安全地帯だからって
早く世の全てのJSプロジェクトがTSになりますように
>>51
めちゃくちゃ重くてスマホではまず動かないレベルってんじゃなかったっけ？ importは他ファイルのクラスを持って来れるようにするのよね
@xxxxxのデコレータの役割がわからないのだけど誰か教えてくれんかね・・・
「付加情報をclassやmethod等に付与するための仕組み」ってなんぞ
Javaでいうアノテーションらしからそれも調べたけどわからない・・・＾ｐ＾
TypeScriptでジェネリクスを使ったとき、C++でいうテンプレートの特殊化のようなことって
できないもんですかね？
function func<T>(x) でTがnumberとstringの場合とで別の処理ができたらいいんだけど。
型情報で実際に呼ぶ関数のオーバーロードの振り分けはできたりはしない
共用型 string | number を使えば string と number 以外の型は入らなくなる
実装部分は typeof arg === 'string' とかで分岐。返り値の型は推論される
推論が思ったようにいかなそうなら mapped type 使うなりオーバーロードの宣言を書いたりしても良い
ありがとう。やっぱりダメか。
> typeof arg === 'string'
Tがstringだったら'string'と比較するってのをやりたかった。
Typescriptのコンパイラのソースコードを見たが、
swicth文による条件分岐が乱用されていて美しいソースコードではなかった。
もっと良い設計があるはず。
構文木のような構造には多態はうまくマッチしないんだよ
構文解析とか条件分岐(状態遷移)の塊だろ
状態遷移とかswitch文そのものだ
>>88
そう思うならお前が改善してプルリク送ってもいいのよ >>91
なぜ高貴なハイクラスエンジニアの俺様がただ働きせにゃならんのだ？
バカなのか？ Typescriptのコンパイラのアルゴリズムは何ですか？
ソースコードを見たところ再帰下降解析らしいけど、それだと左再帰で問題が出るよね。
ハイクラスの俺様が就職したら低レベルの土方を蹴散らしす
５ｃｈになってから急に自分の書き込みに誤植増えた
絶対何かある
就職してないのかよw
ハイクラスなら就職なんてしなくても学生の内から引く手あまただろ
または起業しろよ
今の職場でts+Vue.jsで作ってる案件があるんだけど、コードの肥大化と共に
型チェック付きのビルドに10分以上かかるようになっちゃって型チェックなしのヒルドに変更してしまってるんだけど
そういう事例って他のところにもある？
世界でも有数の大規模ソフトウェアであるVSCodeがTypeScriptでビルドされている以上、
利用者のスキルの問題でしかないな
まぁ、今どきVueを選んじゃう技術力・審美眼のないとこじゃしょうがないんじゃないか？
糞うるさいポンコツウインドウズXPとか使ってそう
React使いがよく言うよな。技術力&審美眼。
魔窟になってるのを技術力と言い換えて、そのアーキテクチャを美と言い換えるやつ。
うちのプロジェクトもビルド時間5分なんでどうにかしたいなぁ。
makedepend+makeが欲しい。
>>98
それ可笑しくね？vscodeビルドしたことあるの？ >>99
mbp2017つかってる。メモリは8gbだけど >>103
チャイニーズに尻尾振るガラパゴスVue民にはお似合いのゴミだなｗ module と namespaceの使い分けは
どうやればいいの？
使い分けるものではない
moduleはnamespaceに置き換えられた
常にnamespaceを使用せよ
type と interface の使い分けは
どうやればいいの？
>>108
ほぼ一緒だから気にしなくていい。
Typescriptの仕様書にも「非常に似ている」と書いてある。
ただ、interfaceは
inteface Point {
x:number:
}
interface Point {
y:number:
}
というようにプロパティの追加ができるが、typeはできない。それぐらいしか違いがない。 TSLintのデフォがtypeよりinterfaceを推してくるからとりあえずinterfaceにする事が多い
>>110
これメンスだがtypeしか使えない機能なかったっけ？ 交差型、共用体型を定義できるのはtypeだけだな。
例えば file1.tsを編集していて、バックアップとしてそのファイルを複製して
file1 - コピー.ts
を作ったとすると、関数名が重複していますみたいなエラーがダダダーと
出るんですが、どのように対策すれば良いでしょうか？
自分はいつもバックアップはfile1.ts.bakって付けてる。
>>115
サーバーが必要なんでしょ？
そんなの持っていないし gitにサーバが必要とか正気か
いいからとりあえずチュートリアルやってみろ
>>119
man git
で英語を読む
でも、君にはそんな技術も学も根性もなさそうだから、
やっぱりfile1 - コピー.ts.bak181110ってするのがいいと思うんだ。
いや君をバカにしてるわけではなくて。
猿は猿らしい生活をした方が幸せだと思うからさ。ね。 >>119
これ以上は他所でやってくれ
お前さんの質問に対する回答は
* 編集バックアップをファイルコピーでとるというのがクソ
* 拡張子も変えてないならビルド対象になって当然
でおしまい 流石に不親切すぎる。猿でもわかる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の悲しみに満ちているってことさ
救ってあげようよ、僕らで
strictNullChecksをtureにしてる人いる？？
ロジックではnull禁止できるけどさ、
dbからgetしたデータに混じるんだよね。
未入力状態のデータって奴。
null撲滅マスターの方は、どう解決してるの？？
それはDBの設計が腐ってるし、unknown | null型なんだろ
ロジックが間違ってる
そもそも、実行時にnullやundefinedが混じるという話とstrictNullChecksに直接の関係はないだろ。
その中間のどこかで困っているんだろうけど、それがわからないとなんとも。
nullableなfieldをgetしたらそりゃnullableでしょ
Visual Studio Code でAngularの勉強をしているのですが、
TypeScriptのthisがどこのコードを参照しているのかイマイチ理解できていません。
このthisをマウスオーバーしたら参照先のコードを表示してくれる拡張機能はありませんか・・・？
現状ですとthisにマウスオーバーをすると this:this と表示されます
みんな、質問。
TSって公式のスタイルガイド無いけど、
みんな何使ってる？
正直googleのは末尾カンマが受け付けない。。
prettierで終わり
受け付けないもクソもない
おまえのスタイルは全てクソで、prettierを信じろ
>>231
設定は？？
信じていいprettierはデフォ設定でOKなの？ >>232
デフォと言いたいが
arrowParens: "always",
semi: false,
trailingComma: "es5",
のみ付けるのが多い（気がする） semi: false,
だけは本当に極稀に問題になるから、設定しなくてもいい
目障りだから俺は設定するけどね
const x = { a: 'b' };
この x の型は { a: string } になってしまうみたいだけど、 { a: 'b' } 型にする方法ってないんでしたっけ？
TypeScript 3.5です。
const x: { a:'b' } = { a: 'b' };
const x = { a: 'b' as 'b' }; もいけるみたいだけど冗長だなぁ。
デフォルトで全部 as const にするオプションとかあればいいのに
anyを許すルールにするっつったら
「でもapiからくる値なら全て型定義できますよね？」
って言われたことにものすごい疲れた
完璧なappなんかねーんだよ！！！ってキレそうだったわ
unknown確か途中で足されたよな。最初から入れとけおもた。
>>247
許容派です。
再帰処理とかをまともに型付してたら、辛すぎる。。
ちなみに
const arr = []
で、never[]型になるのがしんどい。
設定でany[]型にならないでしょうか・・？ てかリテラルの [] が never[] になんかなる？
eslint が v6.0.0 になったら @typescript-eslint/parser が読み込めなくなった
とりあえず issue をみて ./node_modules/@typescript-eslint/parser/dist/parser.js で
require("eslint/lib/util/traverser")
↓
require("eslint/lib/shared/traverser")
でやり過ごしてる
この研究によるとTypeScriptは最もバグ発生率が低い言語なんだけどその理由とか体感とかありますか？
https://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf
>TypeScript －1.32 (0.40)∗∗ －2.15 (0.98)∗ －1.34 (0.41)∗∗ －0.34 (0.07)∗∗∗ コンパイラにバグが無い
コンパイル中にコードのバグは発見出来る
アルゴリズムのバグは知らんがな
TypeScriptで書いたプロダクトにバグが少ないのか、TypeScriptコンパイラにバグが少ないのか、どっちよ？
あと今土器pdfなんかで出すなよボケカス
日本語翻訳使えないだろが
>>254
TSで書かれたソフトウェアにバグが少ない
そのPDFによれば調査対象のメジャーな10種くらいの言語の中で最も少ない C#と大して変わらんのにバグが少なくなるって根拠がよく分からん
JavaScript上がりのプログラマが使うことが多いから良く訓練されているってのが考えられる根拠だなw
ユーザのリテラシが高いが後押ししてるのはありえそうだな
phpあたりは言語もユーザもガイジだからかわいそう
JavaScriptは初心者が触るには最悪の言語と言っても過言ではないないから、ありとあらゆるバグを出して大変な目に遭ったプログラマがTypeScriptを使うことになると、バグも少なくなるだろうなという意味だよ
よくよく読んだら、ほんとは一番バグが多かったとかいうオチ？？
スレッドがないとかポインタがないとかでできないことがある分バグも減るでしょ
>>263
できないことだらけにしたGoさんはどうなりましたか・・・？ >>264
Ｗｅｂ画面なんて壊れてても気にしないからコミット取り消さないし
そもそも画面実装とかサーバに比べて問題の範囲が限定的でたいして難しくないだろ
最初から扱ってる問題が言語ごとにちがうんだ
この表ってか論文で一緒にしてるのおかしい
あ、型なし言語はあかんと思います 確かにCとかC++は基礎的なソフトに使われるから
僅かなバグも絶対に許されないとこありそう
それ以外にポインタ使ってるからってのもあるだろうけど
>>266
動画の新しいエンコーダ作るとか、プログラムじゃなくて数学のレベルを求められる仕事は置いといて、
webならフロントの方がよっぽど複雑じゃない？
バックなんて同期処理でお決まりのレールに乗ってダラダラ書いてくだけだし。
複雑でパフォーマンスが要求されるpwaとか、typescript無かったら絶対に完成する気しないわ。
カオス過ぎる js/tsだけどダイアログとか出すときに
モードレスにした方がユーザーには使い易いのに
バグが増えそうだからモードレス禁止ってことで
全部モーダルで造らされたことがある
型の判定の正しい手順ってどうだっけ？5行目で引っかかってしまう。
function isMyType(o: unknown): o is MyType {
if (typeof o !== 'object') { return false; }
if (!o) { return false; }
if (!('key' in o)) { return false; }
if (!o.key) { return false; } // ts7053
return true;
}
そりゃTypeScriptだって魔法じゃないんだから。
すごいのは外部から渡された得体の知れない値をこうやって動的に型判定して
それを静的な型の世界に持ち込めるところ。
ts知らないけど処理系がロード済みの型一覧を取得できないの
>>270
この返り値、なんていう記法？
というか、なぜこんな書き方が必要なの？ user defined type guard function でググれ。
>>269
jQuery, jQuery UI のダイアログを使えば？
モーダルが多いような気がする /* eslint-disable @typescript-eslint/explicit-function-return-type */
const mapDispatchToProps = (dispatch: TodoAsyncDispatch) => {
return {
fetchTodo: (id: TodoId) =>
dispatch(todoAsyncRequestActions.fetchTodoRequest({ id })),
}
}
/* eslint-enable */
type ReduxDispatchProps = ReturnType<typeof mapDispatchToProps>
---
これをeslint-disableなしで実装する方法ってないですか？
例えば、↓こんな感じで「any」の部分が「型推論させる型」みたいにできる、とか。
redux-thunkの型付けが難しいお・・・
---
type MDTP = (dispatch: TodoAsyncDispatch) => any
const mapDispatchToProps2: MDTP = (dispatch) => {
return {
fetchTodo: (id: TodoId) =>
dispatch(todoAsyncRequestActions.fetchTodoRequest({ id })),
}
}
type ReduxDispatchProps2 = ReturnType<typeof mapDispatchToProps2>
その暗黙の推論を禁止するルールなんだから普通に考えたら無いよね。
型付けが難しい場合があるのはわかるけど、eslint-disableじゃだめな理由は？
全体として入れているチェックの例外を設けるなら後からその箇所がわかるように
しておかなきゃ困ると思うが。
>>280
型付け自体はそう難しくはないんだが、この2重定義感がだるくて。
mapDispatchToPropsに型ちゃんと書いてそこに集約したいというか。
---
type ReduxDispatchProps = {
fetchTodo: (id: TodoId) => Promise<void>
}
const mapDispatchToProps = (
dispatch: TodoAsyncDispatch
): ReduxDispatchProps => {
return {
fetchTodo: (id) =>
dispatch(todoAsyncRequestActions.fetchTodoRequest({ id })),
}
}
---
> eslint-disableじゃだめな理由
mapDispatchToProps は書く頻度が高いから、あまり eslint-disable を撒き散らしたくない
とはいえ普通の function で explicit-function-return-type を false にしたくない
というお気持ち
やっぱ無理ッスかね { allowExpressions: true }
>>284
既にこれで設定してます
---
"@typescript-eslint/explicit-function-return-type": [
"error",
{
allowExpressions: true,
allowTypedFunctionExpressions: true,
},
],
--- Nest.js使ってサーバサイドもts使ってる人いる？
むしろ整合性が求められるサーバーサイドでこそ活躍する
tslintが年内収束ってことなんでeslint移行を試しているが、まだ微妙に使いづらいな。
Svelte 試してるんだが TS にできない……
eslint-config-prettierがほぼ使用不可になるのもしんどい
vs2019に入れるときはどうしたらいいですか？
色々やってて、2017には入ったけど、HelloWorldが正しく動いてくれない。
悪いことは言わんからVSCodeにしとけ
それにTypeScriptはIDEにインストールするもんじゃなく、npmでインストールするただの1ライブラリだ
リテラル型からそのリテラルの値を作ることってできないんだっけか。
Record<Foo,boolean>の変数の初期値にReacord<Foo,false>の値が使えたらよかったんだが。
tsはコンパイル後の結果に型情報は含まないというポリシーだけど、
そういう定数を埋め込むことはやろうと思えばできる話だろ。
androidで使えるts用のeditorないかな
トランスパイルとかはメインの環境でやるからコーディングのための入力支援だけでも受けられるようなやつ
tslintの"max-classes-per-file"のデフォルト値が１なんだけどこれどういう意味合いがあってこんな制限がかかってるの？
Best practice is to keep each file limited to a single responsibility.
プロジェクトの規模が大きくなっても1ファイル1classって維持できるものなのか？
tsファイルに
string型のnormalize('NFC')を
使おうとしたんだけど、エラーになる。
なんで？
プロジェクトが大きくなることとひとつのファイルに書くクラスの数が増えることとが結びつかないんだが
バズワードに踊らされてるだけなのか、ツッコミどころてんこ盛りなのは置いておいて・・・
Geekly Media ライター
バスコ
最新の記事がXAMPPで草生えた
10年前からタイムスリップしてきたのか？
>>307
>TypeScriptはクラスベースオブジェクト指向です。
完全に合っているが…何が問題なんだ？ TypeScriptはクラスベースでJavaScriptはプロトタイプベースって対比しているのは完全におかしい
クラス構文はただの糖衣構文で実態はプロトタイプベースだし、そもそもクラス構文はES2015にあるんだからJavaScriptもクラスベースという話になってしまう
Haskellは最終的に再代入しまくりのCに変換される(出来る)けど、Haskellは純粋な関数型言語と言われている
オブジェクト指向言語の様に書けてその通りに動けば、オブジェクト指向言語と言える
TypeScriptが言語仕様を全く変えずにWebAssemblyにコンパイルされるようになっても、TypeScriptはプロトタイプベースと言い張るのか？
オブジェクト指向的な言語機能に関して言えばTypeScriptはJavaScriptと何ら変わりはないんだから
そのHaskellの例は思いっきり的外れというか牽強付会というか。
>TypeScriptが言語仕様を全く変えずにWebAssemblyにコンパイルされるようになっても、TypeScriptはプロトタイプベースと言い張るのか？
プロトタイプが動作しなくなるなら別だが、仕様をまったく変えないという前提なら何も変わらんだろ。
ところで、こんなこと言い張っていた奴なんて見当たらないが、
>TypeScriptはプロトタイプベース
もしかしてクラスベースを否定したらプロトタイプベースを主張していることにされちゃうんだろうか。
TypeScriptはprototypeをいじくるようなコーディングは推奨してないだろ
型システムが破綻する
その時点でプロトタイプとは関係無い単なるオブジェクト指向言語なんだよ
最終的にどう動いてるか何て関係無い
Haskellの様にね
いやなんでそんな必死にその糞ガイジ記事を擁護したがるのかわからん
バスコ本人か？
ちゃんと頭のお薬飲めよ
知らなかったが、AssemblyScriptなんてあったのか。
既存のTypeScriptのコードがそのままコンパイルできるわけじゃなくて
文法だけが共通の別言語って感じだが。
ES5以前はともかく、今はPrototypeを意識することは全然ないな
ずっとJavaとかPHPだった人でも違和感なく始められると思う
asserts ええな
pipelineオペあくしろよ
>>323
すでにTSはNull安全なんですがそれは >>326
Recursive Type References
こんなん出来るのか？
再帰はanyで逃げてたわ。 >>330
いや、必要なのはパッチじゃなくて、明示的なdeprecatedだろ。
MSは全ての官公庁に対して、blinkのブラウザーを強制させるべき。
ゴミ政治家じゃ無理なので、MSがやれ。
黒船代行料として10兆払っても惜しくない。 Object の OR を自動判別ってできないのかな？
下のURLは、TypeScript Playgroundで書いてみたもの
規制で書き込めなかったから、お手数だが concat して開いてほしい
https://
bit.ly
/30Pw8K3 そういうのは、{ type: 'Succeeded'; result: string }と{ type: 'Failed'; message: string } みたいにして、typeで分岐させるのが普通だけど、
if ('result' in resp) {} でもいけるよ
typescriptの型はただの構造でしかないことがわかれば理解できると思う
>>333
うおお、できた、ありがとう、感動、感謝、完璧です tsconfig.jsonでソースディレクトリの指定は
"include": [
"src/**/*"
]
と "compilerOptions":{
""rootDir": "./src",
のどっちが正しいのですか？
コンパイルできる方
マジレスすると上
rootDir って要らなくね？
もう3ヶ月前くらいに本番でeslint移行したが、全く問題なくてビビるぞ
( ﾟдﾟ)
＿(__つ/￣￣￣/＿
＼/ /
きたか…！！
( ﾟдﾟ ) ｶﾞﾀｯ
.r ヾ
＿_l_l /￣￣￣/＿
＼/ /
( ﾟдﾟ ) ｽｯ
＿(__つ/￣￣￣/＿
＼/ /
>さらにSTSは、TypeScriptの型規則からも逸脱している。TypeScriptがクラスに構造的型付け(structural typing)を
>使用するのに対して、Static TypeScriptでは名前的型付け(nominal typing)を使用しているのだ。
TypeScriptの人気にあやかった別言語じゃね？
結局ただのC言語の亜種だろ
MSもそんな事をいちいちアピールしないといけないほど落ちぶれたか…
TypeScriptはJSerへの強制型付けギプスだと思えばそこそこ優秀
いつまでもギプスつけた状態で満足するものではないのでそのうちRustなり別の静的型付けに移行する前提であれば賞賛できる
TypeScriptはタイプ脳への強制補助輪だと思えばそこそこ優秀
いつまでも補助輪つけた状態で満足するものではないので
そのうち生JSなり別の動的型付けに移行する前提であれば賞賛できる
TypeScriptはタイプ脳への強制補助輪だと思え
ばそこそこ優秀いつまでも補助輪つけた状態で満足するものではないのでそのうち生JSなり別の動的
型付けに移行する前提であれば賞賛できる
型無し糞言語は死ねだと思え
動的糞言語はいつまでも糞でそのうち糞
糞糞糞
すみません
今までES5.1を使って来て、これから扱い易いと言われる
TypeScriptを学習しようと思うのですが
逆にTypeScriptの方がJavaScriptより
難易度高いと言う事はありませんでしょうか。
型は値に付く物で変数はそれへの参照、
prototypeはファンクションへの参照格納用プロパティ
Objectは可塑性のある便利な何かという感覚が身についています。
vscodeといっしょに使えば、jsより楽
型エラーは全てTSが教えてくれる
>>350
型は値に付くというその感覚はそのままでいいよ。TypeScriptはそれに加えて
- それぞれの変数にどんな型の値が入るかコンパイラが調べてくれる
- それぞれの変数にどんな型の値が入ってほしいかプログラマが指定できる
- その両者に食い違いがないかどうかコンパイラがチェックする
というだけ。 TSの機能を余す事なく使おうと思うと難易度高いけど
其処を目指す必要はない
ありがとうございます。
とりあえず tslint を緩めにしてやってみます。
TS初心者ですがお勧めの書籍ありませんか？webpackとかも合わせて勉強したいです。
interface A {
x: string;
}
a: A;
A.xの型(string)を取り出したい場合 typeof A.x じゃダメで typeof a.x ならいけたけど、
aみたいな変数を使わずに typeof A.x 相当のことってできないんだっけ？
なるほど。ブラケット記法って最近とんと使わなくなったけど、こんなところに使い道残ってたんだ。
実践TypeScript - BFFとNext.js&Nuxt.jsの型定義、吉井 健文、2019/6/26
今まで、TS の本は、あまり無かったので買ってみた
入門者用の文法の説明が、130ページしかない。
残りの190ページが、各フレームワークへの対応
本屋で、他の本を見たら、
掌田津耶乃は、Node.js, Vue.js, React, Angular の本を出してるw
山田祥寛も、Vue.jsの本を出した
日本人は馬鹿だからしょうがない。
世界的にはreactなのに、世界と同じものでは戦えないからなのか、日本ではvueを使おうとする
記述がスゲー長くなって見づらい
これって劣化javaみたいな記述にならない？
jsの良さが完全に死亡してる気が…
実践TypeScript を読んでるけど、TS の細かい挙動の怪しい所が多いから、
その例外的なルールの数を覚えるのが大変。
つまり、ハマる箇所を避けるのが大変
TS を学ぶと、Haxe の偉大さが分かる！
JavaScript のおかしい部分を修正しているから、かなりやりやすい
3.7でECMA private field 使えないんだな。ガチのprivateはお預けかぁ
ECMA private fieldの必要性、全く感じないわ
ts拡張子のts動画との棲み分けってうまい方法あるかな？
ts-jestはテストのたびに*.test.tsをTypescriptからJavaScriptにコンパイルしてテストを実行しているのですか？
テストコードが変わらなくても、内部的にコンパイルしてるの？
それとも、tscコマンドでテストコードもコンパイルしてｊｓファイルに変換したら、それを利用してるの？
プロパティでyield のやりかたわからん。
get hoge : Generator<number,void,boolean> {
return (function* (){ yield 1; yield 2; yield 3; })();
}
とかでええの?
なんか get* hoge も *get hoge も get *hoge も怒られる。
getterでそんな複雑なことをするんじゃあない・・・
<Ts extends Array>(...args: Ts)=>
でTsの全ての型の交差型を返したいんだけど可能？
締め付けはガチガチなのにガバガバな構文
トランスパイルのせいで起動は遅いし設定項目やハマりポイントはクソ増える
選択肢のないフロントはともかく、言語を選び放題なサーバーでts入れてまでjsを使う意味ってなに？
>>376
キツマンなのに誰とでも寝るみたいなん感じか https://github.com/microsoft/vscode-textbuffer/blob/master/src/common/position.ts をC#に書き直してる。
44行目からのwithが分からん。
with(newLineNumber: number = this.lineNumber, newColumn: number = this.column): Position {
if (newLineNumber === this.lineNumber && newColumn === this.column) {
return this;
} else {
return new Position(newLineNumber, newColumn);
}
解説とC#に書き直して。"Create a new postion from this position."ってあるけど、
どう呼ばれるの？もしかしてwith文じゃなくて、with()ってメソッド？ そもそも JavaScript に with 文なんて・・・あるのかよ何だこの邪悪な臭いがプンプンするやべえやつは
>>382
何も変わっとらんよ
機能拡張もできないから、現状維持という名の放置 違い何？
interface Dictionary<T> { [key: string]: T; }
type Dictionary<T> = { [key: string]: T; };
そのコードに限っては、違いないかもな
interface は後から追加できる
これ playground にでも貼ってみ
```
interface DictionaryI {
a: string
b: string
}
type DictionaryT = {
a: string
b: string
};
interface DictionaryI {
wow: number
}
type DictionaryT {
wow: number
}
const di: DictionaryI = ({} as any)
console.log(di.wow)
```
だから、ライブラリの定義ではたまに使われる
プロダクトコードで使ってる奴は物知らないか、設計力のないやつ
>>386
ケツにIとかTを付けるのは設計力の無いやつ >>388
ただのサンプルコードにそんなこと言われてもwww
>>387
以下理由
・昔デフォルトONだったprefer-interfaceを引きずっている
・自分で管理できるコードなのに、interfaceで拡張する余地を残さねばならないのはおかしい >>389
> ・自分で管理できるコードなのに、interfaceで拡張する余地を残さねばならないのはおかしい
オブジェクト指向を全否定かよw >>390
たぶん君は、Java の implements に使える interface のことを言ってるのだと思うが、
type でも implements 相当の宣言ができるので、
TS の interface は src 変更が容易でないが、ライブラリの性質上拡張の余地が必要なケースでしか有効でない
「同じ名前の型なのに、実は後から src のどこかで拡張されてました」なんて嫌だろう？
どこの JavaScript だよ function hoge<T, S> (x: T, f: (x: T) => S) {
// ...
}
みたいな関数があって、引数f のデフォルト値を identity:<T>(x: T) => T
にしたいんだけど、無理かしら？
hoge(1) <-- このときは T: number, S: number と推論してほしくて、
hoge(1, n => `number: ${n}`) <-- このときはT: number, S: string と推論してほしい
ごめん、自己解決した
TypeScriptでは依存型をオーバーロードで実現できるのね
```
function hoge<T>(x: T): T;
function hoge<T, S>(x: T, f: (x: T) => S): S;
function hoge<T, S>(x: T, f?: (x: T) => S) {
if (typeof f === "undefined") {
return x
}
return f(x)
}
```
これで一応、第２引数指定しなかったら、戻り値の型を第１引数の型で推論してくれるようになったし、
指定すればその関数の戻り値の型で推論してくれるようになった
＞Our team has been focusing on performance after observing extremely poor editing/compilation speed with packages like material-ui and styled-components.
あーやっぱり material-ui と styled-components が遅いんだ
両方使ったら耐え難いレベルで重くて辛かった
初学者が今からTypeScriptやるメリットってある？
普段使ってるC#のBlazorが育つまで我慢してそれまではJS使えばいいかなーという気がしてるんだけど
・BlazorがTSと同等レベルまで言語・市場が育つことはありえない
・JSに毛の生えた程度の文法でC#と同等以上のタイプセーフの恩恵を受けられる
と思うよ
正直TS始めてからは、JS（特に他人が書いたやつ）は2度と触りたくなくなった
仕方なく js 書いてる時も jsdoc で型を付けまくってる
もうあの頃には戻れない・・・
毛が生えたと言われてもジェネリクス周りとか仕様がけっこう大きい（大きいだけでそんなに難しくは無いけど）。あと歴史的に同じような機能のものが複数あるのはやや辛い。
>>400
まぁそうだけど、最初はbetter js程度に :string みたいな単純な型書くだけでいいと思うよ
それだけで劇的に違ってくる クラス使えるだけで嬉しかった。prototypeとか二度と触りたくない。
@types/node を v14:x に上げたら fs.write* 周りでエラーがいっぱい出た
以前の型定義ファイルでは第2引数が any だったために見逃されてたのね
vscoe+deno
d.tsを用意してjsをimportたがインテリセンスに型情報がでない
質問させてください
初歩的なものかと思いますがよろしくおねがいします
以下の様に getElementById() にてinput要素を取得した場合、value属性を読み取ろうとすると問題が発生します。
const input = document.getElementById('input');
const text = input.value; // <- プロパティ 'value' は型 'HTMLElement' に存在しません。ts(2339)
解決方法を検索すると、
const input = <HTMLInputElement>document.getElementById('input');
const input = (document.getElementById('input')) as HTMLInputElement;
などの型アサーション？キャスト？で解決するように書いている記事が多くヒットするように感じます。
質問としましては、
・HTMLElementではなくHTMLInputElement等の具体的な型で要素を取得する方法はありますか？
・具体的な型で取得できない場合、それがHTMLInputElementであると判定する方法はどのようなものがありますか？
以上、長くなりましたがご教授頂けると嬉しいです。
>>410
https://bi□t.ly/2zBJQbZ
こんな感じでいかがでございましょうか？
getElementById の取得結果は、HTMLElement を継承した何かであることは確実だが
より具体的な型であることは if 文などで判定しないとわからないので
（読みやすい）ワンライナーするのは難しいかな リンク先は typescript playground
長すぎて貼れなかった
url中の□を取っ払ってアクセスしてほしい
こっちも短縮url規制で貼れなかった
>>412,413
なるほど、constructorと型の名称は一致するので比較に使えるのですね。
3パターンもありがとうございます。参考にさせて頂きます。 vscodeのタスクでビルドしたいのですが、上手くいきません。
最初から入っていた"tsc: ビルド - tsconfig.json"という設定を使ってタスクを実行すると、
> Executing task: tsc -p (省略)\tsconfig.json <
パラメーターの書式が違います - -Command
と出てビルドが終了しません。
コンソールに同じコマンドをコピペするとちゃんとjsファイルが作成されます。
ググってみたのですが、そもそもtscで「パラメーターの書式が違います」というエラーが出るという記事すらありませんでした・・・
どうすればいいでしょうか。
普通にnpmとnpm scriptの一部に組み込んだ方がいいと思う
vscodeのタスクとか使ったことないし、必要性も感じたことないな
tscがどこにインストールされてるか、とか関係ありそう
npx tsc --init
で、tsconfig.json が出来る
package.json に、こう書いておいて、
"script": {
"build": tsc
},
npm run build
で、コンパイルする
>>416
そうすることにします
>>417
AppData\Roaming\npm
にありました。
>>418
元々コンソール上からはどのコマンドも実行できるのですが、
vscodeのタスクから使うとエラーが出てしまうんです。
色々テストしていたところ、
単なるシェルコマンド echo unko ですらエラーが出るのでvscode固有の問題っぽいです >>415
パラメータの書式が違うってのはPowerShellでよく見るエラーだけど、VSCodeってPowerShell叩いてるんだっけ？
VSCode固有の問題と決めつけるんじゃなくてもう少し調査してみたら？ 解決しました
日本語版のWindowsではpowershell.exeがShiftJISで読まれるので、
合わせてvscode上のPowerShellの文字コードをShiftJISに変えていたのが原因でした。
元のUTF-8に戻したら問題なく実行できました。
tscをフルパスで実行したらパスの途中にスペースが発生し、
PoweｒShellスクリプトのデバッグ時によく見た文字化けだったので気づけました。
>>420
ご名答です
PowerShellが叩かれていて、エラーもPowerShellからでしたｗ Nodeでサーバーを立てているような場合、
ユーザーが入力した値を格納する変数の型は一旦unknownとしておいた方が良いのでしょうか？
例えば以下の様な場合です。
const func1 = (userInput: unknown) => {...};
const func2 = (userInput: string) => {...};
バリデーション等を行って問題が無ければ、
改めて型宣言した変数に代入し直すような方法が一般的ですか？
今TypeScript+Reactを勉強しているのですけど、テーブルのコンポーネントで使いやすいものって無いですか？
テーブルのヘッダはそのままで縦は内容だけスクロールして横はテーブルも一緒にスクロールするみたいなものが良いです
jexcel
react-table
react-tableは、初心者なら v6 おすすめ
理由は、標準でUIが付いてるから簡単にそれっぽいものができる
ドキュメント調べれば割と多くの挙動に対応できるはず
代わりに、UIのカスタマイズがつらい
「あそこのcssを弄りたいけど、どうやって指定すればいいかわからん」
「!importantじゃないと上書きできない」
的なことになりがち
あと、@types を v6 のをインストールするよう注意すること
UIごりごりにカスタマイズしたいなら最新の v7
headless と謳われてるように、UIが一切ないから全て自分の思い通り
代わりに、学習コストが高い
あと @types 書いたやつがバカなのか、Genericsの対応が酷くて
キャストがたくさん必要でうんざりする
>>425
有難うございます、react-tableを調べてみます。
material-uiがElectronで
TypeError: Cannot use 'in' operator to search for 'ontouchstart' in null
とか出て動かなくて困っていました。
ボタン一個しか指定していないサンプルを写してこれです。 これっぽいの見たことあるけど、他にも気になる事があって見落としてました
<div>に書いてあるの要るのかな？
今試せる環境でないので後日に
TypeScriptってsetIntervalとかsetTimeout,
async/await, Promiseとか使えるんですか？
Ruby on Rails では、React も多いけど、
TypeScript を使う香具師は、いるのかな？
ルビカスは宗教上の理由からTypeScriptなは絶対に使えないんで消えて
フロントエンドの方が厳格な言語で書かれてるとか頭おかしいからなw
Ruby on Rails 6 から、Node.js, webpack が標準になったから、
もう、Coffee Script には依存していない
webpack使えるなら、普通にもうRoRでhtml作る必要ないのでは
ほんまやな
PHPもRubyも、型無し糞言語は滅びるべきや
json以外を喋る邪悪なWebサーバーは1台残らず破壊しろ
この場違いRuby妖怪はアンカ飛ばさんでも一応レス見てる素振りを見せるのがちょっとしたホラー
GUI は、React, Bootstrap で良いけど、
サーバ側が、Node.js じゃ辛い
Rails, Sinatra などの、Ruby の方が分かりやすい
Rubyの欠点は、web アプリだけしか作れないこと！
スマホ用アプリも必要なら、Electron, React Native + Expo
それか、Unity
Rubyの欠点はお前みたいなキチガイがスレチのクソ宣伝で評価を下げてることだよ
型無し糞言語やってる人は帰るだけじゃ済まされない
死んでください
>>442
10年以上前に同じようなJava disやってたスピーカーがいたが
別のスピーカー/コミッター達にあれはやめたほうがいいって厳しく批判されてたけどな
その時代の話なのかな ありますで喩えると
Java山中さん
*by笹井さん
TypeScript で、無名配列のJSON ファイルは、import できない
[
["a", 10],
["b", 20]
]
名前を付ければ、import できる。
import { xyz } from "./a.json";
{"xyz": [
["a", 10],
["b", 20]
]
}
typescriptに限らず
そういう実装結構ある
全体は{}を仮定してるの
jsonってトップレベルはObject必須だと思ってた
そういう仕様あるのかな
Type Script 使ってみて思ったけど
最初から ES がこの仕様だったら本当に助かってた
そして今の課題は既にある ES のライブラリ摂りこむのが面倒
なんとかならんのか？？っていう
C# 使ってみて思ったけど
最初から C がこの仕様だったら本当に助かってた
そして今の課題は既にある C のライブラリ摂りこむのが面倒
なんとかならんのか？？っていう
割とマジで攻守共にTypeScriptが最強だわ
TSに欠けてるのは、あとはパターンマッチくらいだろう
TypeScriptがネイティブバイナリ吐くようになればいい
>>449
そもそもimportはjsonを読むためにあるわけじゃないから読めなくても不思議はないが、
ts3.9.6で試してみたら普通に読めるんだが？
>>451
rfc読めばわかるがトップレベルだけ特別扱いする必要ないしね。 ./a.json に以下だけを書いて、どういうimport 文を書いたの？
[
["a", 10],
["b", 20]
]
ふつうに
import j from './a.json';
"module"は"commonjs"
esModuleInterop か allowSyntheticDefaultImports は true になってる？
false や未設定なら、 `import * as j from './a.json';` でインポートする必要がある
ああすまん、"resolveJsonMdule": true してた。
つまりmoduleじゃないjsonをロードしたいならこれが必要ってことね。
あれ？ 普通に、これで、import できた！
漏れの勘違いだったみたい
import j from "./a.json";
漏れの設定は、
"module": "es2015",
"esModuleInterop": true,
"resolveJsonModule": true,
こういうのはだめなんだっけ
[
["a", 10],
["b", 20],
]
TypeScript の開発中は、
Webpack のオフライン機能、workbox を使わないから、
package.json の、"workbox-webpack-plugin": "^5.1.3" を、
コメントアウトしようとしたが、形式エラーになって出来ない
削除はできるけど、コメントアウトで残しておきたい
>>461
JSON ファイルでは出来ない
よく知らないけど、新しめの、JS/TS ファイルでは出来るかも >>461
ケツカンマをファックできるのはECMAScript 5以上
JSONはファックできない クライアント向けの開発サーバーが付いている、Parcel を使っている香具師いる？
Postman を使っている香具師いる？
これは、REST クライアントかな？
漏れは、VSCode の拡張機能の、REST Client を使っているけど
他には、TypeScript で、Express サーバーを実行する、ts-node-dev は？
pacage.jsonのバージョンを取得したくて
src/index.tsで
import {version} from '../package.json'
を思いついたのですが、これだとコンパイルでdistに排出されるときにpackage.jsonも排出されてしまいます
これを解決する（依存関係をdistに持ってくるのではなくが./package.jsonを常に読むようにしたい)方法はあるのでしょうか？
コンパイルするたび常に最新のpackage.jsonがdistに排出されるんだから
それでええんちゃう？
>>469
自分的にはdistに排出される先にもう一つpackage.jsonが作られるのが気持ち悪いと感じたのですがそうでもないんですかね？ 普通にgitignoreしてるだろうしdistにpackage.jsonがあっても特にデメリットないし
distに何が吐かれててもええんちゃう？
>>468
process.env.npm_package_version
じゃダメなの？ もう4.0の時代なのか・・・
それなのにおまいらのプロダクトときたら・・・
ここで聞いて良いのかわからないけどimportの拡張子(.js)を省略して、js変換時に拡張子をつけることってできないかな？
開発中はtsc使って開発者終了時だけwebpack使いたいのだけども
そのようにwebpack設定するだけでは
cssやjpgとかの非プログラムファイルにしかimport文に拡張子書いたことないわ
webpackの方でなんとかするしかないか。
ありがと
typescript のポリシーからすると将来的にも対応される可能性は低い
TypeScriptのまえにWebAssemblyが登場していたらみなそっちに飛び付いたのだろうか。
何だかんだ言ってみんなJavaScriptが大好きだからな
それにブラウザに実装されているAPIはJavaScriptから使うこと前提だからWebAssembly使っても余計な苦労するだけだ
ゲームには向いてるだろうけど
既存のJS資産を流用できたのも強みの1つだったと思うから、やっぱTSの戦略勝ちじゃねえの
つかWASMって一時期騒がれてたけど今どうなったんだ？
>>489
Unityが実用？になってるぐらい。
なにしろ、仕様も含めて
今後どうなるかわからん状況では？ FlutterがDartじゃなくてTSだったら良かったのに
ほんとそれな
あんな劣化Javaみたいな言語ありがたがってる連中の頭が理解できない
大して機能違わないじゃん。
何が足りないと思ってるの？
そうだな、JavaとJavaScriptも一緒だしな
>> Microsoftが2018年に75億ドル（約8000億円）を投じて買収したGitHub
知らんかった
オンライン版のvscodeがGitHubにあるのはそういうわけか
こんにちは。プログラミング初心者です。
TypeScriptとJavaScriptはどっちが最強なんでしょうか？
これから始める場合はどっちがいいのですか？
TypeScriptはJavaScriptとくらべ実行速度は変わらないのに
静的型付けのため記述が面倒で学習する価値がないと友達が
言ってたんですがこれは正しいですか？
>>501
普段からめちゃくちゃな
読めないコード書いてる人には
難しいと思いますよ。 >>502
なるほど。つまりTypeScripはtコードをきれいに見せるためだけの言語ってことなんですね。 価値がわかるようになるまではJS使うのをおすすめする
今TS触っても嫌いになるだけだと思う
ん。。。価値が分かる人にしかわからないプロ向けの言語なんですね。。。
綺麗に見えるということは他人が書いたコードであっても理解しやすいといえる
複数人で開発するとき用ってことですね。
一人でWEBアプリ作って満足してる分には必要なさそうですね。
ソースを公開する時に型は必須だな
複数人開発だと必然的に他人にソースを公開する訳だから型は必須だな
一人で開発してる時も未来の自分にソースを公開すると考えれば型は必須だな
この理屈で行くと型が必要無い状況は使い捨てのコードを書く時になる
実際、実験的なコードを書くときはJavaScriptでサクッと書いてる
型を指定するのは実行速度のためだと思ってましたが違うんですね。
個人で、1ファイル、2, 300行程度のオモチャしか書かない奴にはいらないかもしれんな
複数人で、2ファイル以上のまともなコード書くなら、型は必須
「全てのfunctionが何かを引数にとって何かを返します。その『何か』はコードを読まないとわかりません」
じゃ困るだろ
複数人でも一つ一つ関数定義を確りして
コメントを残せば後から見返してもわかりそうな気がするのは
私がまだ未熟なんですね。
3ヶ月前の自分は他人
webのようにリリース後にメンテする可能性があるなら確実に過去の自分を恨むだろう
>>512
でもそのコメント、人によって書き方バラバラだし、その通りに実装・使用されているかわからないよね
そのコメントが規格化されていて、その通りに実装・使用されていることを保証してくれるのがTypeScriptとでも思え わかりました。TypeScriptの勉強をしてみます。
バックにはMicrosoftとGoogleがついてるみたいですので
安心して学習してみます。
せや
どこの馬の骨ともしれんバカではなく
MicrosoftとGoogleの天才たちを信じろ
型情報による補完などのエディタの支援機能がないと書けない体になってしまった…
>>502
これさ無茶苦茶なコード書いてる人がキレイなコードかけるようになるって点でTSって素晴らしいと思う 今日までエラーがでなければどんなコードでもいいと思ってました。
最終的にはそうだよ
同じ動きをするならユーザーにはどんなコードも同じ
開発側から見てどうか？ってだけ
開発側の立場で考えるとTypeScriptが必要になるんですね。
>>501
なんか…Javascriptやってる人達ってこれくらいのレベルなんだよな…
今から始めるあなたはともかくとして、そのアドバイスしてくれたお友達のレベルもたかがしれてそう。 Pythonなんかもっとひどいぞ
ただ色んなレベルの人がいるというのは新しい人が入ってきている証拠でもあるので、歓迎すべきことでもある
誰でも最初は初心者なんだしさ
技術ブログ等で公開されているTypeScriptなコードの品質の平均はJavaScriptのそれと比べて高い。そういう意味でも使う価値がある。
もちろん例外はあるけどね
>>521
開発環境でリファクタリング機能の
性能に注目出来るぐらいになりましょう！ javascriptの言語仕様では
まともな物は作れませんので。
>>524
それはTypeScriptの採用によって品質が向上したというより、タイプ量やビルドの複雑さの多少の増大と引き換えに静的型付けを取るという
極めて正しい選択ができるだけの能力があるエンジニアが書いたからだろうね 俺はC/C++からやってるけど、JavaScriptで型がなくって困るって事はないなあ。
ただ、形無し言語しかやったことないのなら、TypeScriptの方を薦めるけど。
（なお俺は生JSしかやっておらず、TSは触ってもいない）
Cみたいにメモリ領域を厳密に規定する為ならともかく、
Java以降の言語の型って、コンパイラで落とす為でしかない。
しかも、入口と出口で都合2回書いて、それが合っているかを確認するだけ。
実際、それでもタイポを落とせるので大変役に立つのは事実だけど、
型を間違ってエラーになるなんて事はほぼ無いし、有ってもスモークテストで確実に落とせる。
だから、言ってしまえば、スモークテストが通るまで捗るだけ。
この点、現状のC++やRustは空回りしてて、
コンパイラで落とす為に厳密に書く必要があり、結果的にやたら遠回りしてたりする。
俺が思うにあれは完全に本末転倒。コード構造が制限を受けてどうするんだよ？
この点、TSは無駄に気負わず、
型の恩恵を受けつつ、面倒になれば省略出来る、位だから受けているのだと思う。
ただ、型の恩恵なんて上記の通り、スモークテストが通るまででしかない。
その後のメンテナンス性は、特にオブジェクト指向(OOP)を正しく適用出来てるかがキモになる。
ところが、JSではOOPは学べない。これはTSも同じだと思う。
周りの環境が酷すぎて、初心者～中級者にはOOPするメリットを感じられないから。
(HTMLも酷いが、ネイティブオブジェクトを拡張してもろくに動かないのも酷い）
Javaや.NETみたいにびしっと作ってあれば、比較的小さな規模でも恩恵を受けられるが、
JSはそれらよりは断然高レベルプログラミングで、その分行数も少なく済み、
大体においてそんなに大規模にもならないし、OOPガッツリやる意味もほぼ無く全て済んでしまう。
だからその先、具体的にはソースコードが10k行を越えるまでは、
JSやTSは学習用言語としてはいいと思うよ。
その辺になってきて、一つの言語しか使えないってのもほぼ無いから、杞憂かもしれんが。
OOPなんて使えて当たり前。OOPを神格化してる奴でOOP以外の技法も使いこなせてるヤツ見たことない。
それにOOPの価値はコードの大小に依らない
俺は困らないからJSでいい論は全てゴミ
想像力の欠けた引きこもりアスペが書いた妄想
これはガチ
TSスレだから、TSマンセー、型マンセーな奴の echo chamber になってるだけだぞって事。
TSは悪い言語でもないが、お前がら思ってるほどJSも酷くない。
だから数あるAltJS、勿論TypeScriptもそれに含まれるが、それでもJSを殺しきれない。
型で恩恵受けるのは、スモークテストまでだろ。
そもそも変数名みれば型なんて自明だし、そうじゃないのが問題。
そして関数を小さく、というのがほぼ最強で、そもそも規模が小さければ変数の型が分からないなんて事はない。
型に囚われてる奴は、型の先、つまり、型が有ろうがなかろうがどうにもならない世界が見えてないのだと思うよ。
この意味でRustもリソースリークを気にしすぎ。そもそもリークなんてしないし、面倒なら最初からGC使えばいいだけ。
TSはこの辺変に気取ってないからいい。
まあ自分のコードだけで完結する世界で閉じこもってる分にはそれでいいんじゃない
>>532
> そもそも変数名みれば型なんて自明
ハンガリアン信者の方ですか？
こんなこという奴の久々に見たわ
> そもそも規模が小さければ変数の型が分からないなんて事はない
ほんと自分の都合のいい側面しか見えてないよな
俺は困らないからJSでいい論は全てゴミ
想像力の欠けた引きこもりアスペが書いた妄想
この通りやンけ！ >>530
OOPを神格化している奴がゴミなのは認める。Javaの連中が特にそう。
そして俺はそうじゃない。
ただな、DOMとかその辺が酷くて、OOPの恩恵を小さいコードでは得られないのはOOPを学ぶ上では痛いと思う。
Javaみたいにたった50行のコードにOOP強いて余計に意味不明になるのも問題だが、
自作コードのみでOOPの恩恵が受けられるのは3k行程度以上必要で、
そこまでOOPを囓れないでいるのもまた問題。
正直、ここにいるお前らの半分以上はOOPを正しく理解出来てないと思うよ。
ただ、それでも書けるところが良いところなんだが。
OOPは大規模コードの整理術であって、そもそも大規模化しないのならそれが大正義だ。 >>534
それはそもそも読み方を間違ってんだよ。
関数なんて大体20行程度だし、問題になるにしてもI/Fだけ。
ただそれ以前に、俺はサイトのmimnify済みのJSでも割と読めてしまうことに気づいてしまった。
「訳の分からないことをやってないこと」が重要で、そうじゃなければ追えるんだよ。
だから、初心者のコードほど読めない。これは事実。 >>536
世界中のプログラマーが関数なんて大体20行程度で訳の分からないことをやってないコードを書いてくれる理想郷にお住まいなのであれば、TSはいらないだろうね >>537
逆だろ。そういう理想郷を作るようにお互い努力するんだろ。
そしてTSはJSよりはそれを目指していると思うが。
関数が20行ってのはGoogleかnpmのコーディングルールに有ったはず。
コードレビューする時に「パワポ１画面に入らないような関数を書くな」だった。
実際、そこまで短くすれば、訳の分からない複雑なことは出来なくなるから、確かに効くんだよ。 TS は、もっと後でよい
Ruby 3.0 で型推論が入ることになったけど、作者のMatz が、
型を入れると難しすぎて、初心者が簡単にプログラミングできなくなると言ってた
型はプロ向き。
型があると、初心者のfirst choice にならない
コンパイルエラーで検知できずに動かしてみるまでわかんないとか…
ついでに言っておくと、多分TSの「型」ってのはC++やRustの連中の「型」の範疇には入らない。
多分、連中からすると「型道」から外れてる、邪道だ、と見えると思う。
それは認識しておいた方がいい。
ただ、俺はむしろその方がいいと思っている。
C++のテンプレートなんて、
「これって型がなくてダックタイプでよければさらっと書いて終わりでしたよね？」ってのが多すぎる。
MSはそこら辺、極めて現実的でいい。
あと、既に言われているが、JSerなんてこの程度、というのは当たっている。
具体的に言えば、実力を過大評価している勘違い馬鹿が多い。
ただ、それは界隈のオンボロさと、楽勝さによっているのであって、環境を共有しているTSでも同じだよ。
とはいえ俺はこれも良いことだと思っている。
つまり技術レベルが低くても達成出来ることが（見た目）大きいわけだから。
だからCとかの連中は、なんでJSerがあんなに馬鹿でも世界が回るのか、
それはつまり、界隈のシステムが上手く出来てるからなんだけど、その辺学ぶべきだと思うよ。
>>539
難しくはならないが、煩雑にはなるんだよ。
そしてその煩雑さを利益が上回る為には、最低限ある程度の規模が必要で、
それは最初の最初の初心者が書くコードの規模（精々100行）では全然足りない。
だからってスクリプト言語で調子に乗ってガシガシ書いた後に型が欲しくなる時は確かにある。
その辺、従来は対応出来なかったが、TSはそこを上手く掬い取れた。 JavaScriptで昔書いた3000行のコードをTypeScriptに直しているんだけど
いやまあ型は便利と思えるいろんな発見があったわ；；
現在もっとも人気と将来性があって最強と言われる
Pythonに型がないのはどういう理由なんでしょうか？
>>545
Pythonが受けているのは、馬鹿でも書けるから。これに尽きる。
Cだと、PCの物理的構造をある程度知ってないと理解しにくい面があるから。
ただ、Pythonが将来性があるかは疑問だと思う。
使われ続けるという意味では確実だが、プログラマを目指すのにいいか？と言われると微妙。
俺はPythonやってないが、最近かじろうとして、止めた。
String.replace(regexp)がなくて、RegExp(str)しかなく、ああこりゃ駄目だ、と思った。
なるほどPythonではクソコードしか書けない、というのは納得だ。
しかも3.0になってずいぶん経つのに、え？まだこんな所で揉めてるの？みたいな制限事項多すぎ。
ただまあ、明らかに君はそれ以前なのだから、グダグダ言わずにさっさと始めるべきだよ。
君のレベルなら、TSでもJSでもPythonでもどれでもいいと思うよ。
Pythonのクソさが分かるようになるまでに2年ほどはかかるだろうし。 >>546
クラスが使える＝オブジェクト指向が出来る、という意味では、
最近のプログラミング言語でそもそもOOP出来ないものは存在しない。
それほどまでにOOPは認められた存在だと言うこと。
ラムダも同様だが。（なおPythonのラムダには制限あり）
だから最近の言語はどれもこれも同じだ！と言われていて、実際そうなのだが、
敢えて違う言語を！とやったのがGo。
ただしGoは別方向にかなり糞なので初心者は止めた方がいい。（と思う）
ただ、実際はGoも結構初心者受けしている。特に形無しスクリプト言語上がりには。 Pythonは 機械学習関連のライブラリが充実していて 最強の地位は10年後も20年後もおそらく変わらないだろう とプログラミングに詳しい知り合いが言ってました。 マシンスペックも上がってきているので Python のようなスクリプト言語でも 十分に実行速度が発揮でき益々 需要が伸びる可能性が高いと聞きましたが。
>>549
ならその知り合いに聞けよ。ただそいつはヘボだと思うが。
Pythonが強いのはライブラリが揃っているからだが、今のところ実行速度が致命的に遅い。
それはCPUやGPUの性能向上程度では何ともならない。
機械学習なら結局のところは何回回せるかが勝負で、C比80-800倍遅いのだから話にならない。
だからCythonなんて物も出てくる。
ただしアルゴリズムを頻繁に書き換えるとなると違う。
ちゃっちゃと書き換え、夜流して朝結果を回収、夕方までにプログラムを変更してまた夜流す、
という繰り返しなら、「新しいプログラムがいつ出来るか」が勝負となり、当然スクリプト言語の方が有利だ。
ただ、これが出来る学生なんてなかなかいないと思うし、そこまで行くのなら多分Cも普通に使える。
そもそも機械学習ならそんなにアルゴリズムも変えないはずだし。
だから今でもガチの計算機工学科ではCもやってるだろ。
Cだと1時間で結果が出るのにPythonだと3日かかります、では研究の進捗も全然違ってしまう。
だから用途に合わせて使い分けることが必要で、
はっきり言ってCも大して難しくもないからそういう奴等はCを最初から学ぶようになってる。
PythonやRuby界隈が高速化を目指さないのは俺には完全に疑問だ。
何だかんだで今後とも速度は重要であり、正義だ。
Rubyなんて死にかかってるが、JSと同程度の速度が得られれば、復活するとも思っている。
ただ、Matzもその周りもそれをしようとしないんだな。クソ言語なんてもう要らないのに。
TSはその点、JSの実行速度と、スクリプト言語の弱点、
「調子乗って書いてたらグダグダになってきてヤバイっす」を型付加により多少は緩和出来る、という点でかなり立ち位置はいい。
しかもJSも今のところ死ぬ感じはないから、TSも勿論死なない。
一般的にはJSerは次第にTSerになっていくと見られているが、これも概ね正しいだろう。
確かにTSは駄目な点がない。
（界隈の駄目な点をJSからモロに受け継いでいるが） 型無し糞言語は死あるのみ
型推論でスマートに型サポートを受けるのが今のトレンドだよ
質問ですが
interface IPoint {
x: number;
y: number;
}
があるとして、（例えば）一致判定関数を書く場合、
function isequal(p1: IPoint, p2: IPoint) { return (p1.x == p2.y && p1.y == y2.y); }
function isequal<T extends IPoint>(p1: T, p2: T) { return (p1.x == p2.y && p1.y == y2.y); }
はどっちが良いの？
どっちもプロパティー{ x: number, y: number }を持つ任意のオブジェクトを受け入れるので同等に見えまつ、
戻り値を忘れたorz
: boolean
型推論って便利ですよね、、、
YouTube で有名な雑食系エンジニア・KENTA は、
初心者が進む道を、サーバー側言語のRuby → Go を王道としてる
Python, PHP, JavaScript などを絶対に言わない
初心者のfirst choice としては難しすぎる。
挫折確率が高すぎる
ただ年末に、Ruby 3.0 で型推論が入るから、
KENTA も、この方針を変えるかも知れない
大事件勃発！
Ruby on Rails に頼っている、すべての学校の方針が変わってしまう
ただ、first choice がGo と言うのは、絶対に無理
>>554
この場合は多分同等なのでシンプルな前者で良い
後者はTを他の箇所（戻り値やコールバック関数の引数など）でも使う場合に適していることがある
例えば
function double<T extends IPoint>(p: T): T {
p.x *= 2;
p.y *= 2;
return p;
}
とか
function check<T extends IPoint>(p: T, validator: (p: T) => boolean): void {
if (!validator(p)) { throw new Error('...'); }
}
とか
ただしこれらの場合でも必ずしもextendsが適しているとは限らないので注意（特に上の例はかなり適当なので） Pythonは型を書いてもインタプリタがそれを無視して実行してくれる
高速に実行したければPyPy使えばネイティブコードに近い速度で実行出来るしmypyで型チェックも出来る
JavaScriptで型を書くと単に構文エラーになるだけだが、その内無視して実行してくれる様になるだろう
そうなったらTypeScriptは要らなくなる
Pythonみたいに動的型言語に型アノテーションを追加する事が主流になるだろう
Union型は動的型だから出来る事で、完全に静的型にするとC++みたいになってしまう
動的型＋型アノテーションは良いとこ取りで、プロから初心者まで皆が満足出来る
Pythonは10年前にやったときは凄い言語機能だと思ったけど、それからあんまり進化しなくて今はJSにすら言語機能的には劣ってる。Pythonの良いとこ他の言語も取り込んじゃったからね。
でもそれとライブラリが充実してるってのは別問題で、このライブラリの充実っぷりがJS|TSにもあったら天下取れるのになぁと思う。
機械学習はライブラリの最適化がキモで言語の速度なんてほとんど関係ないし
なんどもコードの書き換えが必要な機械学習において
Pythonのような可読性にすぐれ、少ないコードで実行できる言語はが必要不可欠なのよ。
Cythonを使えば実行速度もC/C+＋と変わらないしね。
JavaScriptはTypeScriptとして生き残ると思われる。
>>556
そのYouTubeはPythonとJavaScriptで作られているという皮肉 >>560
最近の初心者がすぐ「俺がやってる言語スゲー、俺スゲー」なポジショントークに走る理由が分からん。
Pythonが良かろうが悪かろうが、お前の実績でもなかろうに。
結局のところ、「○○言語スゲー」をやってる奴は、「他言語なんて絶対学びたくないマン」であって、
それを正当化する為に言い訳をしているようにしか見えん。
それは549の「知り合い」も同じ。
ただ>>554が典型的な「型の問題点」で、
規模的に「見りゃ分かるだろ」な場合でも、型あり言語は型を書くことを強制され、
結果的に煩雑なコードになってしまっていた。
それ、JSで
function isEqualPoint(p1,p2) { return (p1.x === p2.x && p1.y === p2.y); }
だったら、悩む必要もなく、その先にさっさと進めてただろ、という話。（※）
普通の頭してたらこれで十分だ。
ちなみに（メソッドではない関数で）isEqualは短すぎ。
isEqualPointはお前らが大嫌いなハンガリアンだが、どう見てもPointを受け取る前提で、そうじゃなきゃエラーだと分かる。
それを型を書いてコンパイラにやらせるのがTSで、目で見て落とすのがハンガリアン。
ただ、コードの精度を上げたいなら併用すべきで、
形無しのisEqualというのは.NETみたいにisEqualインタフェースを全部の型に対して供給し、
isEqualを持っている型はこれ使えます、てな事をやるために使う。
ただこれは.NETは世界の全てがOOP前提だから出来るのであって、JS界隈ではかなり無理。
そしてそれ以前に、isEqualはPointのメソッドとして実装すべき。
メソッドであればそもそもPoint以外を与えようがなくなるし、見た目もハンガリアン同様にエラーを検出出来る。
そしてインタフェースへの拡張も見えてくる。
どうしても野良関数にしたければ、ハンガリアンにしておく方が無難だと思うが。
なおOOPの問題点は根本的にここら辺で、
この程度のどうでもいい規模しか書けない初心者にも無駄にいちいち考えることを強いて手を止めてしまう。
このレベルならグダグダ言わずに何とでも書いてどんどん先に進んだ方がいい。
どうせ今書いてるコードなんてゴミで、後から使える事はない。 少し遠回りしたが話を※の時点に戻すと、
だから「全部について型を書け」というのは少々煩雑で、型あり言語は型推論で型を書かなくて良い方向に動いてる。
逆に、形無し言語は型をアノテートすることで、コンパイル時に落とせる方向に動いてる。
結果的に、どっちも同じような状況になりつつある。
落としどころは多分、C#の「ローカルは型推論、それ以外は型を書け」がまあ妥当なラインなのだろう。
だから初心者でこの辺の塩梅が分からないのなら、C#から入るのもありだと思うけど。
現実的にバランスが取れた仕様にはなってる。
>>561
JSが取り込んだPythonの良い所って何？
そんなの初耳だが。
そもそもPythonが褒められてる点なんてマジで何一つないと思うが。
（ただし俺は10年も使ってないので歴史的経緯はほぼ知らんが）
JS|TSが天下を取る為に必要なのは「同期」だよ。
asyncとかじゃなくて、普通の「同期」の方が分かりやすいし、実際スクリプト言語が担当する分野ではほぼそれでいい。
c10k問題等には非同期が有利なのは事実だが、見た目の分かり易さは「同期」の方が断然いい。
「それ、同期だったらそもそも理解する必要すらなくて、上から順に実行される、で済みますよね？」が多すぎる。
ただ、「非同期」は最早宗教だから、「同期」を入れることはないのだろうけどね。
「同期」が入れば、CPUリソースが厳しいサーバ側のPHP/Ruby/（ほぼいないが）Pythonの半分ほどはNodeに移行するだろう。
(実際、Goがその界隈で流行ってるのも、大した手間をかけずに快速が得られるからであって）
また、普通のスクリプト業務、つまりPythonが蔓延っている分野でも、
Python同様に簡単に書け、速度は16倍なのだから、当然普段使いする奴が出てくる。（というか俺がそれ欲しい）
そうすれば、ライブラリも充実していく。
「同期」がないから普段使いしにくいのがとにかく問題。
逆にPythonは実行速度が問題で、現実的な文句はほぼこれに尽きる。
だから彼等が何故高速化を目指さないのかは俺には本当に謎。 >>563
あれPythonで作られてるから進化が遅いんだぞ
外向きにはPythonで問題ないって強弁してるが完全に負債化しちゃってる
Pythonで作ったWebサービスあるある 時代についていけない老害エンジニアがC/C++を必死に推してるように思うのだが
>>566
浅いというか個人 or 小規模開発しかしたことなさそう Pythonの速度が遅いと言ってるのは情弱
Cで書いたライブラリに受け渡せばC言語の速度で実行できるし
Cython使えばPythonのコードほぼそのままC言語の速度がでる
Pythonで困るのはGUIくらいだろ？
継承とジェネリクスが役割が被る領域において
TypeScriptではどっちの書き方がメジャー（もしくは効率的）とされているのかわからなかったのです＞＜！
>>557
レス㌧クス、
わかりた、 次の質問なのですが、
タイプガードとか書くときにクラス（やハッシュ）にプロパティーが有るのか無いのか調べると思うのですが
つぎのどっちの書き方が良さげ？
(1) 'someProperty' in foo
(2) foo.someProperty != undefined
なんとなく(2)の方が早いのではないか、という気がするのですが気のせい？？
>>570
俺もCのDLLをスクリプト言語から呼ぶ、というのが現実的な解だとは思う。
ただ、Pythonの問題はそこじゃない。
演算を変えたい場合は結局Cを書く羽目になるから、結局Cも出来ないと駄目。
そしてCは仕様が小さいので、本気で正しく学べば簡単な部類だ。
GUIは今は現実的にHTMLがダントツで良く、何から何までWebアプリ化してる。
なら今ならElectronの方が相性がいい。当然JS/TS。
サーバ用途でPython使ったら大体は速度の問題にブチ当たるが、
これは「お気楽に書ける分遅い」というスクリプト言語の特有の問題であり、Rubyも同様で、回避手段がない。
(Nodeはgoogleの努力で例外的に異常に速いだけ）
だからPythonは「何一ついいところはないが、何も悪くもない」という、ある意味「絶対的な2番手」だ。
だからこそ「絶対他言語を学びたくないマン」はこれに拘り、ポジショントークを繰り返す。
ただ、今時の言語なんてどれも似たようなもので、実際そこに拘る理由もなく、普通の奴は易々と言語の壁なんて飛び越えていく。
普通はこちらを目指すべきだと思うけど。
PHPもクソと言われて久しいが、いまだに蔓延っているのは、あの用途では絶対的に便利だから。
それはjQueryも同じ。 >>572
無料相談所じゃねえんだぞ調子に乗るな
(2)にしろ
(1)は型の保証までしてないから最後の手段
あとinterfaceはライブラリなど汎用的なコードに使うもの、普段はtypeを使え ていうか自己解決しますた、
e: Event を e: MouseEvent として扱ってよいか（ダウンキャスト可能か）どうかを
確認するとき、(1)の書き方でないと
MouseEventにあってEventに無いプロパティー
（e.offsetXやe.offsetY（））の有無の判定が書けませんぬ、
>>574
機械学習の勉強してみ。演算やアルゴリズムなんて二の次 三の次だから。
とにかく何度もコードを書き換えてひたすらパラメーターと変数の調整作業になる。
言語の実行速度よりコードの記述速度の方が大事になる。
この時はじめて「Pythonさん。なめててごめんなさい」って言いたくなる。 >>577
パラメータの変更しかしないのならそうだろうとしか。
俺は別にPythonを使うことが悪いとは言ってないぞ。
俺はJSを大変気に入っているが、それは「手抜きで書けるわりに速い」からだ。
だから俺はJSからCのDLLを呼びたいんだよ。
それがお前の場合はPythonなだけだろ。別に不思議でもないよ。 >>578
PythonはCythonを使えば
ほぼPythonコードのままCのライブラリが作れるんだよ
速度はCで記述したものとほとんど変わらん >>572
それはJSでは議論し尽くされた質問。多分ググッた方がいい。
会社で書く場合は多分コーディングルールでどっちにするか決まってる。
プロパティのありなしのチェックだけなら(1)の方が原理的に速い。
ただしJSの場合はundefinedという値を設定出来るので、その場合は(1)も(2)もアウトだが。
これはJSの仕様バグだが、この辺含めてJSは厳密な型管理には向いてない。
そもそも型無しなので当然だが。
>>576
そもそもダウンキャストが必要となってる時点でOOP的には邪道。
多分それは無駄にアップキャストしてるから。
OOP初心者あるあるの、張り切って無駄にOOPして余計に複雑になってるケースだと思うよ。
それも含めて頑張れでしかないが。 >>579
ならお前はPython/Cythonで一生暮らすでいいだろ。
俺はC使えるからCythonを使うことはないし、
Pythonも色々糞だからJSで済むところはJSで行く。
だからCscriptはそこそこ良かったのだが、MSはこれを捨ててPowerShellという別糞言語押しなのは残念。 >>547
>俺はPythonやってないが、最近かじろうとして、止めた。
>String.replace(regexp)がなくて、RegExp(str)しかなく、ああこりゃ駄目だ、と思った。
>なるほどPythonではクソコードしか書けない、というのは納得だ。
馬鹿ですね判ります >多分それは無駄にアップキャストしてるから。
型消去が必要な場面なんていくらでもあると思うが。
そもそもダウンキャストって動的な型判定でしかないんでOOPとは直交する概念だよな。
>>580
>そもそもダウンキャストが必要となってる時点でOOP的には邪道。
HTML5とかを決めているmozilla.orgに言って、
ﾎｽｲ >>582
String.replaceとRegExp.exec(str)は明確に用途が異なる。
だからそのどちらを使ったかで何を目的にしてるかをコード上に残せる。
Pythonはそれが出来ないから糞、というだけ。
どうやらPython教の「そのやり方は一つであるべき」が根本的にある。
これが「数ある中からそれを選んだ、それを持って意図を残す」俺と決定的に合わない。
なおRubyも同様に「いろんなやり方があるべき」であり、Pythonはプログラミング言語の中ではかなり異端だと思う。
だからこそ受けている、というのはあるらしいが。
なおJS、String.search と Regexp.test 等、大体においてその状況では交換可能なメソッドは多々あるし、
Array.map/forEach/filter/reduceも、無理矢理やれば大体交換可能だ。
これについては俺は => はクロージャ無し、つまり外変数を掴めない仕様にするべきだったと思う。
そうすれば => で与えている限り「無理矢理交換」は出来なくなり、コードも読みやすくなるし、エラーも文法的に落とせた。
現状では「無理なことをしてないか目で確認」するしかなく、これは型アノテーションではどうにもならない。
だから目で落とすハンガリアンを馬鹿にしていて、でも => の仕様不備には全く文句を言わないのは、
同様にお前らも単なる馬鹿かポジショントークでしかないからだよ。
実際、 => で与える関数で外変数を掴まなければならないケースなんて半数以下だし、
その場合は function と長々と書く、でよかった。 >>585
それはその通りだが、そもそもHTMLの仕様がOOP前提ではないので継承構造が綺麗になってない。
それを無理矢理それっぽく見せかけているのがHTMLElement（というかDOM）だが、
ちょこちょこ例外的なのがあって統一的に扱いきれない。
多分割と早い段階で無理だと諦めると思うよ。それも含めて頑張れだが。
mozallaが悪いわけではなく、OOP前提で作られてない物を載せ直そうとしてるから無理があるんだ。
なら不整合な古い仕様はばっさり切っていった方がいいと思うが、それは互換性の問題で切れないらしい。
だから、今後とも直ることもないよ。 >>570
PythonはOO機能が中途半端で型システムも貧弱だからアプリケーションのコアとなるドメインモデルの実装には使われない
Cythonでドメインロジック書くのはもっと非現実的
機械学習やデータ分析のようにコアとなる部分を汎用的にCでライブラリ化できるような用途には適してる
NetflixやUberのようなテクノロジ先進企業がアプリのコアからPython外して
機械学習を含むデータ分析系かシステム管理系に絞って使ってる理由 >>586
外変数を掴まないArray関数？
センス無いなぁ。やっぱあんたOOPしかできないでしょ >>561
記述が簡単。ライブラリが充実。これが最強の所以だよ。
コードの学習コストと記述に時間がかからない分、他に時間をさける。
機械学習、データ分析、科学系でPythonの最強はしばらく続くだろう。
今話題のディープラーニングにおいてもPyTorchが最強の座に着こうとしている。
大企業が多額の資金を投入してね。
JavaScriptもネットでは必須なのでPythonと肩を並べる言語になるだろう。
この2つを極めたものだけが将来生き残れる。jabaは10年後には消えてるだろうな。 >>589
外変数を掴む前提ならreduceは全てforEachで代替出来る。
逆に言うと、わざわざreduceを入れたのは、見た目immutableにしたいだけ。(戻り値をconstで受けられる）
しかし現状では与えた関数が外変数を変更していない、という確証が「文法的には」ない。
つまり、「見て判断」するしかない。
この辺がハンガリアンを馬鹿にしているお前らが理解出来てないところだ。
=> がクロージャ無しなら、
const tmp = arr.reduce( => );
において、tmp以外の変数に変更がないことを文法的に保証出来た。
これをせずに、immutableだあ、型でエラーが落とせるだあ、なんて言ってる時点で意味ねえ、というだけ。
もっと効率的にエラーを落とせる仕様は有ったって事だよ。 >>590
多分そのとおりなんだけどTS使いがPython使うとイライラするぜw
型情報もジェネリクスも貧弱だし、多少トリッキーでも短くて副作用のないコードを書くTS使いに対して、Python界隈は助長で副作用も使う簡易なコードを書く。
どっちが優れてるとは言わないけど。文化がかなり違うように感じる >>590
Javaが10年後に消えることは原理的にない。
Javaが使われているインフラとかは10年更新だが、そのまま問題ないとかで20年とかに伸びたりしてる。
そして更新時、Javaのままにするか、思い切って他言語(C++等）にするかが問われるわけだが、
今現在はJavaのまま更新されているのが普通だと思う。
だから10年後も「今更新している案件」が更新案件として出てくる。
これはガチで20年分ほど積み上がっているから、書くかどうかはともかく、読める必要は10年後も確実にある。
Pythonは今のところ「何でも出来る」という意味で安牌だが、速度が遅いのがとにかく致命的。
何度も言ってるが、俺はPython陣営がここに消極的な理由がさっぱり分からない。
原理的にはJSと同程度までは行けるはずで、そうなれば完全に天下を取れる。
対してJSは勝手に速くしてもらえただけの棚ぼたではあるが、
そもそもGUIのHTMLとダントツに相性が良く、（元々JS用だから当たり前だが）
非同期が超絶ウザイながらもデスクトップアプリケーションまでに進出してきた。
Pythonが遅いままなら、JSが「同期」を出したらPythonを普通に殺せると思う。
少なくとも、今現在の言語としての出来は、JSの方が数段上だ。
それも分かってか、Python使いはPythonの「言語として」良い点なんて絶対に挙げないだろ。
ここでも無視されてる。実際、ないと思うし。
彼等にとっては使っている人数が多いこと自体が武器であり、それを目指しているからだ。
勿論これもありだが、Javaもそうだったが、これだとどうしても古くなっていく。
だから、仮にJavaが死ぬなら、同様に「古い」とされて死ぬのはPythonだろうね。 >>593
30年前のレガシー言語と比べて言語機能的に優秀じゃなければ存在価値ないよね
PythonがTSに比べて優秀なのは今まで使われてきた歴史があるところ >>594
PythonはJavaScriptの”中途半端”な速度を切り捨てて自由を手にしたのだ。
そもそも、処理速度がネックになるなんて単純計算を繰り返す場合がほとんどで
そんなもんライブラリに任せればいいんだよ。Pythonを使ってるのはプログラマだけじゃない。
科学者、数学者など他業種も多い。記述の簡単さ。ライブラリという遺産。大企業の投資。
すべてがPython最強を示している。
GUIはJavaScriptに軍配があがる。これに異を唱える奴はいないだろ。
JavaScriptはWEBで棲み分けができていて最強言語の一つだ。
そんなにPythonを逆恨みする必要はないよ。 >>595
言語の記述が簡潔。これが一番だな。
パソコンよりスマホ。FLASHよりYouTube。マニュアル車よりオートマ。
人間は楽な方にながれる生き物。
処理に時間のかかるものはライブラリになげてスクリプト言語で記述。
これがこれからの流れだと思う。生産性もあげていかないと。 「ワシもCで苦労したんだから、お前ら若者も苦労せい」
↑
こんな考えの老害が生産性を著しく低下させてる
>>596
綺麗なだけのコードを書くことは実は簡単なんだよ。ただしそれは通常遅い。
だから処理系がそもそも速いって事がコードの美しさを保つ上でも重要ではある。
実際、Pythonから書き換えを迫られる場合はほぼ全て処理速度の問題だろ。
だから、
> 多少トリッキーでも短くて副作用のないコードを書くTS使いに対して、Python界隈は助長で副作用も使う簡易なコードを書く。 (>>593)
これの遠因もそこにある。トリッキーだが短いコードってのは通常、実行速度が遅い。
だからこれを許容出来るのは、速い処理系があるからこそ。
Pythonの場合はそもそも書けない可能性もあるが、書けたとしても遅いから使えない可能性もある。
トリッキーとは言わないが典型的なのは正規表現だ。
今現在正規表現は速いとは言えない状況で、「バックトラックを理解して速い正規表現を書く」という本末転倒なことをやらかしてるだろ。
あれも本来は「糞速い正規表現ルーチン」と「一番分かりやすい正規表現」で済むことでしかない。
ただ、今は現実的にそれが出来ないわけでさ。
同様に、正規表現で書けば至極単純なのを、indexOfやforとかで自前で探索してたりするのもそのため。
処理系の速さがコードの簡潔さ/美しさを下支えするものではあるんだよ。
だからつまり、「単純簡潔で分かりやすいが遅いコード」を許容する為には速度が不可欠で、
Pythonも速度対策すればこの辺が使えるようになって現実的な利用価値が上がるんだけどね。
それ以前に速度なんて考えてないコードばかりだから全体的に糞遅いのかもしれんが。
ただそれ以前に、JSもPythonと比べて難しい言語ではない。
Python界隈の戦略的には「Pythonこそ最易言語」であり、それ以外の意見は認められないのだろうけど、
いわゆるLL言語はどれもこれも簡単だし、大差ない。
JSにおいては「非同期」が無駄に嵌りポイントになってるから、
これさえなくなれば難易度はPythonよりもむしろ簡単になる。（文法が超絶簡素だし）
(ただし、無くなることはないとも思うが。非同期宗教酷すぎ) >>596
>>598
ちなみにお前は何か勘違いしているようだが、俺はPythonを嫌っているわけでもないし、Cを強いているわけでもない。
そもそも俺はCに苦労もしてない。そう思えるのは、お前がCに苦労しているからだ。
既に言ったが、俺がJSを気に入ってるのは、「手抜きの割には速いから」だ。
速く動かす為にはこう書いた方がいい、と分かっていても、面倒なのが大半で、
どうでもいいところから完全に手が抜けるからいいのだ。
だから「JS」というよりは「JSの処理系の速さ」が好きなのであって、逆にJSが遅くてPythonが速ければ、俺はPythonを使っていただろう。
その程度の話でしかない。
それとは別に、JSも言語的にはかなり面白いので気に入ってはいるが。
なおC、あれは難しいのではなくて、理解するのにPCの物理的構造の理解が不可欠なだけだ。
実はそれを知っている奴は最初からつまずかない。
そして仕様はJSやPythonよりも単純な為、覚える範囲だけなら多分1週間もあれば例のK&Rは読めてしまう。
似ているのは物理で、ma=Fが全ての力学も、最初から理解して使いこなせる奴と、1年経っても全然理解出来ない奴と綺麗に別れたろ。
あれは理解力/思考力の問題だが、とにかく、「理解出来る奴は最初から苦労もせずに理解出来てしまう」というのはCと同じ。
君はCがとても難しくて、若者がPythonしか使えず、Pythonしか使えない自分が置き去りにされない世界を望んでいるのだろうけど、
それはない。
Cは他言語と比べたら「ドハマリする奴は絶対に抜け出せない」だけで、仕様としてはかなり簡単な言語だ。
そして計算機工学なら普通に授業してるし、実際、彼等は普通に使えていると思うよ。
ただ、データサイエンティストみたいな、計算機を使うことが主目的ではなく、単純に計算だけしたい奴等はまずはPythonからだろうさ。
そこもしばらくは変わらないとは思う。
Python使えば生産性が高いと思ってるのはお前が馬鹿なだけ。
生産性が高い奴は、その時々に応じて最適の手法を選択するだけ。
それがPythonならそうだろうし、どうせ速度が問題になると分かり切っているのなら最初からCもありだろうさ。 このクソ冗長な駄文書く奴が簡潔なコード書けると思うかい？
せっかく丁寧に説明したのに今の若者は長文が読めないとかキレ出すのに1票
>>603
お前はCが出来る奴が憎くて憎くて仕方ないのは分かった。
ただ、何度も言ってるが、Cも大して難しくはない。
昔だったらプログラミングなんてしなかった馬鹿連中も最近はプログラミングするようになってきてるから、
大勢の比較的馬鹿から見たら同じ物が難しく見えるだけ。
当たり前だがCなんて昔から変わって無いし、（というか変わらな過ぎだが）
今はIDEのサポートもありネットでも情報を探せるから、昔よりは断然簡単に学べる。
同じ理系学科で比較すれば、脱落率は劇的に改善しているはずだよ。
そもそも昔は１人1台PCでもなく、家で予習/復習すら出来なかったわけでさ。
F12押せばIDEモドキがいきなり出てくる今とは全然違う。 Cの仕様は確かに小さいよ、しかしだからといって小さいイコール簡単な世界じゃない。
メモリパズルしたりガチで役立つマクロ組んだりSIMDで最適化したり未定義動作と戦ったりしてみると良いよ
>>609
未定義動作以外はもちろんやってるぞ。
ただJSでもTypedArrayは導入されたし、メモリパズルや最適化はCだけの話でも無いけど。
むしろそれをやる気がなければ最高速は目指せない。
numjsとか使ってる奴はJS/TSでそれやってると思うよ。
あと、お前もそうだが、最近の若い奴は使いこなす＝全機能を使う、と勘違いしている。
Cのマクロなんて深入りしたら余計に生産性が落ちる。あれはぱっと見て分かる範囲で使うべき物。
プログラミング言語なんてアプリを作る道具であって、道具を使い倒すのが目的ではない。
分かる範囲で使い、希望の動作をするアプリが出来るのなら、それでいい。
全く使って無い機能があったとしても、関係ない。 別にここTSスレなんだからmallocできん奴おってもええやろ。今は細分化の時代だし。
>>609
613読んで気づいたが、別人であったか。
Cにはもうこりごりなら、それもいいと思うけどね。
一応Nodeからffi経由でCのDLLは呼べるらしい。
それなりにオーバーヘッドはあるらしいけども、普通に使ってる分にはほぼ誤差だと思われる。
JSの数値はdouble相当だし、一応32bitのビット演算もあるし、
環境自体がそこそこ速いから、事前準備はJS側でやっても大して問題ないだろう。
単発の演算でオーバーヘッドがでかいのは問題だから、そこを何とかできれば、
科学技術計算からPythonを駆逐できる可能性がある。
ただ、PythonのCのDLLコールも同様にそれなりに遅いらしいので、マーシャリングであればどうにもならないけどね。 >>600
＞C、あれは難しいのではなくて、理解するのにPCの物理的構造の理解が不可欠なだけだ
PCの物理的構造とやらが理解できたところで void (*signal(int sig, void (*func)(int)))(int) なんて宣言を読めるようになるとはとても思えないんだが >>615
それは慣れだね。
ただ、俺もあの文法はかなり謎で、正直、仕様がよくないと思う。
それはカーニハンも文句言われてて、言い訳は多分ググッたらヒットする。
確か、曰く、この形式ならマクロにしても入れ子でも動く、らしいが、
俺が試した限りはGoみたいな分かりやすい形式でも普通に出来た。
ただ、それ以前に実は当時のCでは関数ポインタをそんなに使わなかった。
正確に言うと、sortとかでは必要とされていたが、単発で使う分には呪文扱いでよく、
勿論熟練者はそれでも使ってたのだろうけど、今ほどカジュアルには使われてなかった。
K&Rでも、「関数ポインタも出来るよ」とさらっと触れられている程度でしかない。
それがJavaで関数ポインタが存在しなかった理由だし、
C#でも最初は採用されなかった理由だ。(C#は確か2,.0から)
当時はOOPで全て行ける、継承すれば関数ポインタを直接扱う必要も無い、と思われていた。（のだと思う）
ただその後、おそらくJSのブレークにより、クロージャ/ラムダの有用性がプログラミング界隈で認識された。
勿論Lisperはそれ以前からずっと呟いていたのだろうが、今も昔もLisperなんて空気だ。
そしてあまりにも感化された連中がClosure言語をリリースする始末。
だから、今のC初心者がいきなり関数ポインタを使おうとしているのなら、
それは確かに昔のC初心者より難しいことをやってる。
ただそれは呪文扱いでいいと思うよ。
自分が望むアプリを作ることが目的であって、呪文使いになることが目的ではない。
まあ確かに、ここ20年でプログラミング回りもだいぶ変わったから、
C言語自体は確かに変わって無いけども、学ぶべきことが明らかに増えてるのは事実だ。
関数ポインタも、OOPも、クロージャも、並列も、昔の学生には必要なかったから。 思ったよりは詳しいみたいだし、その長文書くエネルギーでTypeScriptもっと使い込んで？
批判するならその上で批判して。ここTSスレだから。
使うまでも無いとか技術者らしからぬ事言わないでね。
>>617
TSについては、今のところ使う予定無いからね。
理由は既に言ったとおり、「スモークテストまでだけの為に記述が増えすぎ」だから。
ただTSは確かに立ち位置は悪くない。
型のおいしいところだけつまみ食いしよう、という意図が明確でいい。
そもそも使って無いから細かい粗も知らんし、批判しようも無い。
JSが糞な点は多々あるけど、それはTSでどうにかなるものでも無いし。 >>616
>C#でも最初は採用されなかった理由だ。(C#は確か2,.0から)
Delegateは1.0からあるよ >>620
確認してみたがどうやらそのようだ。
なんだかんだでC#はマトモだな。 実際のところ、皆さんtsを仕事で使ってたりするの？
使ってるよ。
元々JS使いだから最初は型と戦ってばかりで時間かかって生産性下がって辛かったけど、慣れればむしろ早いし、リリースした後の安心感が段違い。
小規模開発でもこれだから規模が大きいとさらに影響は大きいだろうね
フロントエンドエンジニアやってるけど、React + TypeScriptが鉄板過ぎる
これ以外でUI組む気になれん
サーバーサイドでも使ってる人いるのかな
typescriptとサーバーサイドでググると
サーバーサイドでもtypescript 最高たぜ～みたいな記事出てくるけどほんまかいなと。
Java,や.NET使った上でそう判断してる現場もあるんだろうか。
いま.NETしか経験がないメンバーにtsを習得させるか、思い切ってBlazorに手を出しちゃうか悩み中。
鯖サイドってOSコロコロ変わるイメージ無いんだけど、JVMにしろ.netにしろVMで動かす意味ってあるの？
GoとかRustで良いんじゃ無いかって思うんだが。
Ruby on Rails では、Bootstrap, React だけど、
JavaScript(JS) に、Ruby の式を埋め込む、ERB を使って、JSへ変換する。
a.js.erb
<%= Rubyの式 %>
$( "body" ).append( "<%= j(render partial: 'example_partial') %>" );
こういう書き方で、TypeScript を使えるかな？
>>628
むしろVM使ってるかどうかで言語を選択するケースのほうが稀 >>627
TSに手を出すのとBlazorに手を出すのでは冒険度合いが違いすぎない？ >>632
だよね…
こんなところで聞くことじゃないかもしれないんだけど、
サーバーサイドに記述されてるクラスって、フロントでも使えるの？
それともフロント側でもtypescriptで同じクラスを宣言しないといけない？
Blazorはクラスを共有できるくさくて…それはメリットとしてかなりでかいなあと。 >>628
サーバーは言語何を使うとしても仮想化前提だろ。 >>633
同じ言語だからクラス書いたファイルを両方から参照すれば良くない？
そういう意味でなくてサーバとクライアントでシームレスにインスタンスをやり取りしたいとかであればフレームワークが居るのでは？ >>633
両方同じ言語なら共有ライブラリとしてそれぞれから参照すればいいけど
言語が違ってもOpenAPIみたいの使ってコード生成すればいいから
2度手打ちする必要はないかも ごめんごめん
サーバーサイドはasp.net coreです
OpenApiとやらを使えば、クラスの生成が楽ちんてことね…
しかし二度手間感はすごいあるな…
でもBlazorに手を出すリスクを考えるとまだマシか…
Blazorも使ってるけど、まだ.NET5対応のツール周りが全然だめなんだよね…業務なら素直にTypeScriptでいいと思うよ
over knight blazorくらいになってからが本番。
>>631,634
だよね。
なのに何でJavaとC#何だろ？って思った。 >>634
特に仮想化前提で遅くなるのに何で言語をネイティブコンパイラ言語にしないんだろ？と。
昔は実質C++しか無かったなら仕方ないとして、今なら選択肢はもっとあるのに・・・。 Goのコードは高機能でファットなランタイムに依存している
ランタイムとアプリを分離できないだけで、実質VM言語みたいなものだ
一方、.NET Coreはアプリとランタイムを実行ファイルに全部ぶっこんで配布することも可能
従来のVM言語という線引きは曖昧になりつつある
C#だとジェネリクス関連はJITに任せたほうが速かったりできるし、
.NET CoreはReady to Runでネイティブコンパイルされたコードを同梱することもできるぞ。
あー・・・。
そう言えばC#はネイティブにもコンパイル出来るようになったんだっけ・・・。
C#については納得。
Javaはまあ、コード資産だろうし。
JITについては正直半分くらいしか信じてないんだけど、あり得なくは無いなと思ってる。
Dや一部のC++みたいにコンパイル時実行での最適化とどっちが速いんだろうとか思う。
>>643
ジェネリクスってコンパイル時に解決するものだと思ってた >>645
コンパイル時の方が多少早いけど、cppのジェネリクスもといテンプレートは型の分関数を用意するって愚直な方法をとってるので、バイナリサイズがデカくなる。
型情報も使えないしね。
あと、分岐命令なんかはどっちのほうが頻度高いかとか見て、動的にプロファイル取りながら最適化しつつ実行してるので、JITの方がより良い形になる事もある。
>>646
コンパイル時に解決はしてるけど、ILレベルでは複数の関数が作られてる訳ではなかったはず。
もちろん実行時には、JITで型ごとに関数が生えることもある。 質問なのですがTypeScriptでC++みたいに関数引数をconstにするにはどうすれば
良いの？
>>648
>あと、分岐命令なんかはどっちのほうが頻度高いかとか見て、動的にプロファイル取りながら最適化しつつ実行してるので、JITの方がより良い形になる事もある。
ﾃﾞﾏくね…？
プロファイル取る手間はタダじゃないし、 >>652
eslint no-param-reassign Ruby では、1秒で100万回ループすると、
JIT されて、1秒で1,000万回ループされる
>>653
どっかで読んだけどな。
というか、AOTの制限事項として、JITより効率が悪い可能性の一つとして挙げられてるよ。 >>654
「Invalid option '--param-reassign'」って言われた つ∀`；)
ESLint: 6.5.1.
ていうかできたとして無差別にconnstというのもそれはそれでC++と違う希ガスorz JavaScriptからTypeScriptへの書き換えｵﾜﾀ＼(^o^)／
JavaScrpit最初に知って一ヶ月で全部書いたから3000行ぐらいだろうと思っていたら
あとでちゃんと数えたら8790行やったorz
実作業4日かかった
ここで4日というのは4日×8Hではなくて4日×24Hの意m（ｒｙ
乙
TypeScriptやってない頃に書いたコードってTypeScriptのこと意識してなくてオブジェクトの形を動的に変えたりしない？
自分がやったときはそのせいでだいぶ時間かかったわ
prototype文で無理矢理classにしていたやつを
さらに基底クラス（にあたるﾌﾞﾂ）の所有でもって継承を表現していたやつの普通のclassと継承への書き換えが苦痛やった、
機械的とはいえ自動化できるほど単純には行かず苦痛やった、
手製イベントのインターフェースが実際何になるのかがぐちゃらけていたので3種類のインターフェースのORで
表現できるとﾜｶﾙまで試行錯誤を要した、
あとはだいたいうまいぐあいに逝けた
とわいえVSCodeの強力なインテリセンスとリアルタイムエラー報告（スクロールバーのところが赤くなるやつ）が無かったら
到底完遂不可能なところやった、、、
webpack使用
ウンコードなJSをTSに変えることで人は強くなるのだ
おまえはまた強くなった
委譲から継承に切り替えたらそりゃ辛いっしょ。
乙～
delegation over inheritance って言うしな
GithubでもTsは定義箇所にジャンプできたりするんだな
強い
今からTypeScriptやるならDenoでいーの？
あっギャグじゃないです真面目な質問
Denoあんまり詳しくないけど、何やりたいかにもよると思う
Web開発をする分にはまだNodeなんじゃないかな
周辺のツールやライブラリが揃ってるので
CLIツールとかならDenoでいーんでの？
>>669
jsx/tsx でもイケるようになったね 逆にバージョンアップでシンプルになっていく言語ってあるの？
互換を完全に切るような言語なら可能だろうけど
>>677
Schemeが小さくはなったな
ま、大規模に使われてる言語じゃないから出来る芸当だ 言語機能が増えたからと言って全部使う必要はないしな
たまにどこかで使われてるのを見てあれってなったら調べるくらいで良い
JavaScriptは動的型だけど、動的型は意識しなくても複雑な事が出来てしまう
TypeScriptはそれらに対して何としてでも型を付けたいんだよ
それだけの事
JavaScript自体は何も変わってない
もうaltJS風WebAssemblyコンパイラにして
C++並にコンパイル遅くなったりしてね。
実質マクロだから実行時は速いんちゃう？
>>678
あれ小さくなったって言えんの？
r7rs なんて common lispよりでかいじゃん。
コアだけなら小さいだろうけどコアだけじゃなんもできんだろ。 うちのtsプロジェクト、tslintも入れてビルドに10分くらいかかってる。
前に -incremental 試してみてなんかの理由で断念したんだよな。
もう一度トライしてみるか。
スクリプトのメリット完全に失っててワロタ
スクリプトはビルドしちゃいけないんだよ
IDEでパラレルLintするぐらいならいいけどな
ビルドしないと動きませんじゃ本末転倒でなにがなんだか
ビルドするならC#とかGoでやりゃいい
ts-nodeならビルド不要だけど、それとは違う話か
TypeScriptを直に実行できる処理系は今後も現れないだろうな
>>689
＞ビルドするならC#とかGoでやりゃいい
ブラウザで使うのが現実的じゃない そもそもスクリプト言語でスクリプト言語向きじゃない大規模なことをやろうとしてるからこれができたわけで、言語のせいにするのは違う
そもそも今のWeb（アプリ）はTS使ってなくてもビルドしてるものばっかりだし
まあ、べつに「スクリプトのメリット」を期待してtsを使ってるわけじゃないしな。
とはいえビルド時間が短縮できるならそれに越したことはないが。
watch使うからビルド速度そんなに気にならないなぁ
>>687
RSR7-smallは5をベースにしてるから、それでなんも出来ないとか言ったら、それまでのSchemeを全否定じゃんw いっそガチでマクロ入れてくれたら色々捗るなぁ。凄く読みにくくなるだろうけど。
そこまで行かなくとも、（内部的に複数の関数を持つ）関数オーバーロードとか欲しいかも
ブラウザ使っててよく Webページ が固まることがあるから、ちゃんとUIスレッド以外で処理しろよとよく思ってたが
JavaScript 自体がシングルスレッドだったのね
WebWoker とかいうのもあるみたいだが、MDN見るに、
言語側でがっつり管理するからスレッドセーフあんまり考慮しなくてもいいみたいだし、これは楽でいいわ
Java やってて、クリティカルセクションの処理が一番嫌いだった
デッドロックの原因探すの大変すぎた
そもそもIO待ちにスレッドを使うのがナンセンスだったんだよな
まぁでも、
JavaScript のソースコード内に書いたものが全部同じスレッドで走ってる
ってだけで、setTimeout とかの実装内では普通に別スレッド走ってるのか。
そりゃそうだよな、そうしないと非同期処理なんてどうあがいても不可能だものね。
非同期処理はスレッドの場合とそうでない場合の2種類ある
そうでない場合は基本的にハードウェア割り込みで実装されてる
タイマーとか通信処理とか
ファイルアクセスもOS毎に非同期APIが有るけど、libuvは互換性の為に敢えて同期APIを使う処理をスレッドプールに投げているようだ
setTimeoutはスレッドを使ってない様に思うけど、結局の所ユーザー側でそれを知る術が無い
>>698の問題はスレッドがどうとか関係なくて、html中のある個所の内容が決まらないと
全体のレンダリングができない構造になっていたとか、jsをダウンロードしないと
レンダリングされないのにその取得に時間がかかっているとかそんなところだろうな。 最近ないように思うけど、１つのページがブラウザ全体をストールさせることが多かったのよ
そんでブラウザを起動し直さなければいけない
その原因が、JS のスレッドと ブラウザのレンダリングスレッド（UIスレッド）が同じスレッドを共有してることにある
DOM 書き換えてる最中に レンダリングされちゃうと、ページレイアウトがぐちゃぐちゃになるから、全部同じスレッドで処理してるんだけど、
JSの処理でUIが固まるのを防ぐには、JS の DOM 書き換え「以外」の操作を別スレッドでやって、レンダリングスレッドと同期処理すればいい
（Java の synchronize とかの要領）
DOM 自体が レンダリングスレッドに属してるのは、しょうがないと思う
昔、マルチスレッドで動作する UI ライブラリ の多くがデッドロックその他のバグでどうにもならなくなって廃棄された（Java でいう AWT）
ということで、UI が固まるのにはスレッドは関係あると思うのよ
まぁ書き方が悪かったのかもしれんが
あと、JS がシングルスレッドなのはとても良いことだと思ってるからね、自分は
マルチスレッド化したら、どのみち同期化処理に失敗して、デッドロックで今よりも固まること多くなるだろうから
参考にした：
https://stackoverflow.com/questions/30932870/why-doesnt-javascript-get-its-own-thread-in-common-browsers JS で重めの処理をしたりバグがあっても、レンダリングスレッドと分離されてれば、
少なくとも UIが固まることはないということね（デッドロックがなければ）
あと、上で最初に書いた、ブラウザ全体が固まるって話は語弊あったかもしれない
ブラウザの各タブのレンダリングスレッドと、ブラウザ全体のUIスレッドは、多分分けられてるんだよね？
後でちゃんと調べます
firefoxがフリーズすることは最近ちょくちょくあったな
edgeに乗り換えたらきれいさっぱり直った
ffはもうだめかもわからんね
「Firefox が Tab ごとにスレッド」って書きたかった
そのスレッドも Main Thread = UI Thread （DOM 操作と JS 実行）が１個って意味で、
Raster Thread とか、Composer Thread とか多分他にもいろいろスレッド作る
すみません、TypeScriptって開発中はコンパイルなしでブラウザですぐに変更の動作確認をできますか？
Chromium Edge で、YouTube を見て、
動画を、5秒先へ進めたりすると、フリーズする
WebWorkerは完全にスレッドだぞ
更にAtomicsを使えばスレッド間でatomicなデータ更新が出来る
WebWorker使いやすくて好き。並列処理面倒くさいからたまにしか使わないけど
しかし、SharedArrayBufferはSpectreのせいでほぼ使えない状態だけどね
Spectreに対応したCPUが普及しきらない限り有効にされる事は無い
Webではもはや余計な機能追加はセキュリティーホールの元という認識でこれ以上進化することも無いだろう
ただ、ストアからインストールするPWAはネイティブアプリの代わりだから、機能追加していくと思われる
ストアの収益減らすの絶対許さないマンのアップル
ｖｓ
Webから情報吸いたいマンのグーグル
promise（もしくはasync/await）が使えたらシングルスレッドでも実質別段困らない
希ガス
WebWorkerとか知らんかった．．．
メインと状態を共有しないのが明確なら便利そうだな
さもなくばAsync/Awaitか
I/O boundはPromiseでいいけど
CPU boundはPromiseじゃだめだからWebWorker使う
マルチコアの有効活用
>>715
それは有る
Appleはブラウザの進化を完全に否定した(WebUSBとか実装しないと明言した)
建て前はセキュリティーだけど、真実はPWAがネイティブアプリと同等の事が出来るとApple税が取れなくなるからだろうね 税なら税で素直に払えばいい
それでいい製品が使えるならいいことだ
NHKのようなものだな
Appleが採用しない事で足並みが揃わなくなって、Web全体に影響するという……
SharedArrayBufferの代替手段って無いの？
結局これは解決する問題なの？
WebUSBに関してはFireFoxも実装する予定はないので
足並みを揃えてないのはChrome
目の前に機器があってスマホからコントロールしたい要求は一般的だと思うけど、USBの番号を個人で取れなくなったので、ブラウザに実装する意味は薄れたかもしれないですね。
ここだけはappleを応援するわ
消費者としてブラウザにどんどん変な機能つけるんじゃねぇ
IoT的な意味合いで必要とする人たちが居るんですよ。
自分は見ないから動画機能を付けるなとか、聞かないから音機能を付けるなっていうのと同じでは？
USB APIをサーブしてajaxでlocalhostと通信でいいじゃん
わざわざブラウザがサポートすることじゃない
まあ百歩譲って乗せるとしても拡張でいいよな
標準化しようとするのはでしゃばりすぎ
ブラウザがんばって欲しい
React + TS 最高
swift + storyboard とかいう糞オブ糞のそびえ立つ糞まみれは2度と触りたくない
PWAの定義が今一漠然としてるから、今後はその辺りが進化していくと思われる
で、PWAでない場合はJavaScriptの動作は思いっきり制限されるだろうね
ま、それで良いと思う
> わざわざブラウザがサポートすることじゃない
ほんとこれ
なぜわざわざブラウザでなんでもやろうとするのか
IoTなんだから普通にツールとかアプリとかドライバ書けよと
結局ああいうのって「すげええブラウザでこんなことできた!」
いいたいだけちゃうんか、みたいなのがマジ多い
ブラウザが高機能化しすぎてブラウザさえ動作すりゃいい感じになってきてる
最終的にOS=ブラウザまで進化しかねない
モバイル用OSがそんなかんじ
アプリを全てサンドボックスで隔離して出来ることを制限
じっくり時間をかけて出来ることを解放してきた
これPromiseとWeb Workerのマルチスレッドでパズルを生成してる。組み合わせ無限大。しかもInternet Explorerでも動作する。まあ、素人にはひと目では分からんだろうな。
webworkerってjoinみたいなメソッドある？
>>740
Promise.allとかPromise.anyがあるぜ。 Promise.anyとWorkerを使った例が
>>736
にある。ご参考に。 最近のCPUってコア数バラバラでかつ非対称なコア載ってるから、6個くらいWorker立ち上げて平等に処理投げるんじゃなくて、20個くらいのWorker立ち上げて非対称でいいから適当に処理投げてあとはOSに良きに計らってもらうとかの方がベターなのかな？
navigator.hardwareConcurrency
でコア数取れるぞ
>>746
なるほど。そういうのがあるのか。
じゃああとは非対称コアへの対応になるけど、これは細かくスライスして逐次投入で良いか >>745
そうです
素人が考える半端なスケジューリングはアンチパターンです >>747
お前に向けて書いたんじゃない。
許可無くレスするな糞コテ export interface TypeA {
paramters: {
[k: string]: {
// body
}
};
}
こんな型があるとき、上記bodyの部分の型を取り出すことってできますかね？
const f = (k: string, o: ???): TypeA => {
return { parameters: { [k]: o } };
};
こんなことがしたい。
ヨーわからんがこうかね
bitどっとly
/3aJV7Hw
ts playground だが短縮URL NGワードになってるからすまんな
そこの type Hage の定義に "extreme" を書かずに済ませたい。
この例だと {extreme:string} という型になる部分が変更されたとしても
type Hage の記述を変えずに済むよう TypeA の定義から取り出す
方法がないかと。
ありがとう、わかった。
["extreme"] を削れば目的の型になりますね。
["paramters"] を使えばいいことに気付かなかった。
|
| また髪の話してる
| 彡⌒ミ
＼ (´･ω･,彡⌒ミ
(| |(´･ω･`):::: 感じ悪いよね
(Y /:(| |)::::::
し ＼:(Y /::
＼し´
もう一つ教えてください。
typeTypeB =
{
tag: 'a';
/* a のボディ */
} | {
tag: 'b';
/* b のボディ */
};
こんな Tagged union type があるとき、 tag === 'a' の時の型(下記)を
取り出すことはできるでしょうか。
type x = {
tag: 'a';
/* a のボディ */
}
TypeB & { tag: 'a' } でいけた。ありがとう。
型に欲情する変態さんは piotrwitek/utility-types でも npm 愛するといいぞ
またまた教えてください。
type X = A | B | C | undefined;
この X から undefined を除いた型 (A | B | C) を求めるにはどうしたらいいでしょうか。
何に使うんじゃ…
漏れの限られた経験では、
x: (A | B | C | undefined)
が渡ってきたら、
if (x is A) { ... }
else if (x is B) { ... }
else if (x is C) { ... }
else if (x == undefined) { ... }
else {
(エラー)
}
ぐらいしかやることが無いｷﾓｽ
少し簡略化するけど
type A = { [k: string]: number };
type B = { [k: string]: string };
type C = { [k: string]: boolean };
ここで type X[string] で number | string | boolean を取り出したかったけど
undefined が混じっているとうまくいかなかった。
typescriptのd.tsファイルについて網羅的に解説されているドキュメントはありますでしょうか
公式は最低限の事しか書かれていなくて。
例えば、test1.d.tsは以下の通りに書いてあって
export type A1 = boolean;
type A2 = boolean;
test2.d.tsは以下の通りに書いてある場合、
type B1 = boolean;
type B2 = boolean;
A2 B2はどっちも「type XX = boolean;」という書き方をしているのに、別のtsファイルで
const x1 : A2 = true; と書くと、Cannot find name A2 とエラーになる(importする必要がある)が
const x2 : B2 = true; と書くと、import無しでもエラーは出ない。
test1.d.ts はexport文があるから「このファイル内の定義は、importをしないと使えない」というようなモードになっているのかなと思うけど、このあたりの挙動について知りたい。
declare module文を使った場合とか、namespaceやらでネストされた場合どうなるのかとか、/// <reference types="xxx" /> と書かれているとどういう扱いになるのか とか
とにかくd.tsファイルの一番細かい仕様が見たい。
フロントエンド系の解説動画上げてる 英語話者の Youtuber
イケメン率高すぎじゃね？
イケメンじゃなくても、
リーナスやRMSやバーナーズリーみたいな、ひと目みただけで「変人だわ」って思う人が少ない
どうなってんのよ
お前らもイケメンなの？
俺もよく歩いてると三浦春馬さんやっぱり生きてたんですねって話し掛けられて困るわ
オレもしょっちゅう『二郎さんっ……！』って声を掛けられるから、「おやっ、オレは田宮二郎の生まれ代わりなのかな……？」って思ってたら、坂上二郎さんの生まれ代わりだったわ
加齢臭とかいうレベルでなく今の30代ぐらいならもう何の話してるかもわからんだろうな
TypeScript で、React やったけど、いちいちいちいち型定義めんどすぎな…
相性くそわるなめくじかよ
ビジネスモデルのオブジェクトとかは型定義したいが、
いちいち props のインターフェースとか書いてらんねー
変更があったらいちいちインターフェースも書き換えなきゃいけないし
みんなどうやって使ってるの？
Angular とか他のフレームワークだと TypeScript でのやりやすさ違う？
>>774
ts使いこなせてないのか？
面倒ならanyにしとけ。 >>774
>>Angular とか他のフレームワークだと >>TypeScript でのやりやすさ違う？
やっぱts理解してしないね。 > 変更があったらいちいちインターフェースも書き換えなきゃいけないし
おまえさんのようなうっかりガイジでも変更忘れがないよう指摘してくれてるというのに
わがままうっかりガイジにランクアップや
リファクタリングしない人もいるからね。
（いまもみじかににいるし、
拒否るかも...その人）
VSCode の補完で関数シグニチャ確認する時、カオスすぎない？
ライブラリがユニオンやら使いまくってるの多くて、パット見引数が何個あるのかわかりにくいし、
もう少し見やすいポップアアップ表示にならんのかな
>>779
c#以上だね。
改行で見やすくなりそーーなもんだけど。 JavaScriptというそび糞をまともにするためだ
しゃーない
型を半ば無理矢理付けてるだけで、最終的には型を削除したJavaScriptになる
要するに動的型言語というのは、それだけ豊富な表現力を秘めてると言うことだ
本来はそれと引き換えに実行速度が犠牲になるもんだが、VMのチューニングによりネイティブコードと遜色無いのが凄いところ
>>780
そうよな
割と改行するだけでも全然違うと思うんよな
できれば色もついたらそりゃ見やすいけど
なんか Extension ないんかね >>786
可変長型もう入ってなかったっけと思ったら3年前の記事か サードパーティライブラリの型定義に関しては、
定義書くのめんどくさそうなときは any で通してる
型定義あったほうが便利なのは確かなので、
作業自動化して楽にしてくれるツール出てくるとありがたいなと思ってる
インテリセンスの進化とか
あと、VS Code で、TypeScript の型定義読みにくすぎ、
ドキュメント書いてあること少なすぎ、JavaScript のコードに直接とべねーすぎ（？）
でも、こういうアーキテクチャに関する抽象的な議論って
個々の案件に落とし込まないと本質見えてこないことととか、
そもそも想定する状況が議論する相手と食い違ってることがあるから
GitHub にある具体例でも明示してくれると議論は捗るんじゃないかなと思う
弊社は障害者雇用枠しかいないのでPHPしか書けません並の駄文書いてる奴って
生きてて恥ずかしくないのかなって思っちゃう、ごめんね
>>790
この人有名人なの？
個人ブログに対する反応としては量が多くて驚く
アンサーのほうは避けられない複雑性を
”複雑な型”で表現した場合としない場合のトレードオフについては
“消えてしまうことは無い”で濁してるだけで正面から回答してないよね
最初のブログの人も感覚的な話だからどっこいどっこいだけど
↓こういうのは頑張りすぎじゃねって感じる
type ArrayOfLengthRec<Num, Elm, T extends unknown[]> = T["length"] extends Num ? T : ArrayOfLengthRec<Num, Elm, [Elm, ...T]> まぁでも型定義するの楽しいからね
パズルみたいで
夢中になっちゃうのは分かる
>>794
まじかよｗ
めんどくせーだけなんだが… 初心者のうちは考えなくて良いんだよ。
わけ解らなくてもコード補完してくれる位
思ってれば良い。
コード補完力・エラー発見力を高めるために型書いてる感はある
JavaとかGoの型を”書かねばならない”という強制感がないんだよな
コード補完はすごいメリットだよね
あと型定義通ってると書いてて安心するし
クラスの中で、毎回 this. っての書かなきゃいけないの面倒くさくない…？
忘れるし
Java 並感
javascriptのthisのややこしさ知ってて言ってる？
>>802
JS使いは誰もそう思わないと思うよ
そこでも最初から否定されてるし、その通りだよ
thisを省略可能なのは各メソッドにクロージャがない言語だけだよ
JSはそうではないから、余計に分かりにくくなるだけ this省略が欲しいなんて1度も思ったことないわ
レガシーなJavaプロジェクトで、クソデカclass相手にした時は eclipse で this 強制せんとやってられんかった
で、Javaならローカル変数とクラス変数の違いが見分けられないだけだが
JavaScriptはただのfunctionもある
アホがJavaScriptでthisの省略悪用したら、簡単に地獄の蓋が開いて中から飛び出たイエスファッキンキリストに脳までファックされる未来が見えるね
つかしばらくclassもthisも書いた記憶ねえわ
POJOと参照透過なarrow functionがあればそれでいい
個人的にはオブジェクトが副作用を持つ（と明示したい）ときは使うかな。
あとErrorを継承とか継承以外にスマートな方法が無いときも使う。
出番はそんなに多くないけども
[TypeScript のテストを Jest (ts-jest) でやってみる - Qiita](https://qiita.com/mangano-ito/items/99dedf88d972e7e631b7)
これ参考にjestでテストしたのですが、ts-jest使うと、テスト時にts-jestが内部的にトランスパイルすｒので、JavaScriptコードがファイルとして生成保存されないから
テストするたびに、前のテストから変更されてないソースもいちいち全てトランスパイルしてるのですか？
それともjsファイルが生成されてれば、それを利用してくれるのですか？ >>811
ありがとう！
その図みても自分じゃ難しくてよくわからんが、確かにキャッシュ使ってるみたいだね。
思ったより複雑にいろいろしてるみたいだから、やっぱり自分が心配するような事は考慮済みだね、当たり前か。 Flutter2 とともに Dart にnull安全がやって来たなあ
ちょっと勉強してみようかな
Dartのことゴミだと思ってるけど
聳え立つクソof真のゴミofゴミstoryboard & xcodeをやるくらいなら、Dartで首吊った方がマシなのかもしれん
TypeScript勉強してたらオブジェクトの配列とか出てきて型の使い方が全くわからなかった。
type user2 = {
id: number;
name: string;
}[];
let test2: user2 = { id: 1, name: "大谷" };
console.log(test2);
---
type user2のオブジェクトをオブジェクトの配列にしたけど、これを利用するのはどうすればいいの？
eslintのno-unsafe-member-accessチェックを有効にするために怪しいanyは全部タイプガードを通して
使うようにしようと思ったんだが、タイプガードの中でメンバーチェックするところがno-unsafe-member-accessに
引っかかってしまう。
詰んでる？
interface TypeA {
member_a: string;
}
functin isTypeA(a: any): a is TypeA {
if (typeof a !== 'object') return false;
if (!('member_a' in a)) return false;
if (typeof a.member_a !== 'string) return false; // Unsafe member access .member_a on an any value.
return true;
}
「型がないと開発できない」
「型がないと開発できないっていうのは無能」
↓翻訳
「うんこって汚い」
「うんこは汚いと思ってるやつは無能」
↓翻訳
「バーカ」
「アーホ」
>>821
なるべくweb標準に寄せたほうが良いと思ってるので、俺は使ってる。
コンストラクタ引数でブロパティ初期化のシンタックスシュガーが無いのだけが不満 GoとかRustみたいにenumとかtypeに直接メソッド生やしたい...
>typeに直接メソッド生やしたい.
いまいちどういうことをやりたいのかわからないが、classじゃなくてtypeじゃないとダメなの？
typeに関数型のメンバを追加すりゃいい話じゃなくて？
「typeに直接」ってのが何を言っているのかよくわｑからん。
GoやRustを触ったことがあれば分かるけど, クラスではなくあくまでデータ構造(struct)を定義して, Goではレシーバ付きの関数, Rustではimplでデータ構造に対して操作を定義していく
C#だと定義済みのクラスに拡張メソッドでメソッド追加したり
素のJavaScriptならprototypeにメソッド追加する, みたいな
で, TypeScriptだと今は出来ないと思うけど, 需要はありそうだし, RFCとか出されてない？
構文的にJavaScriptと互換にやるのが難しいかな？
Githubでとあるプロジェクトをパブリックにしてたら何かヤベーアメ公に絡まれた
気に入らなきゃさっさとフォークしろやハゲ
ふぇぇ…
Angularのバージョン上がるの早すぎだよぅ…
Angular4を使ったSPAのセキュリティが心配だよぅ…
Angular とかとっくに死んだと思ってたわ
誰が使ってるんだ？
1系で身動き取れなくなったレガシーサービスくらいしか見たことない
>>833
Teams（そろそろReactで書き換えられるけど） Google 自身が Google のサービスで全く使ってないのに、何で作ってるのかわかんない
いつ捨てられてもおかしくなくね
teamsってangularだったのか。
reactにしたらもっさりが直るかな
>>836
Electron+AngularJsからWebview2+Reactになってメモリ消費は半分になるとか 質問させてください。
WebAPIを呼んでJsonを取得し、その一部の項目を使いたいのですが、
以下の２つの方法を考えました。
１．提供されるJsonと全く同じ項目をもつクラスを定義してパース
const data = axios.get<クラス[]>("複雑なJsonを返すURL");
２．getの結果をとりあえずanyで受け取り、必要な部分だけをクラスのコンストラクタに渡す
axios
.get("("複雑なJsonを返すURL")
.then((results) => {
const items = JSON.stringify(results.data);
const parseItems = JSON.parse(items);
const data = new クラス(parseItems.必要な項目1,parseItems.必要な項目2...)
以下略
「１」の方法は、不要な項目もクラスに定義するのでいろいろ無駄が多いが、オブジェクトの作成が簡単。
「２」の方法は、型情報が使えなくて不便。だなと思ったのですが、
上記のような場合、通常はどちらの方法を使うものでしょうか？
もしくは全然別なやり方があれば教えていただきたいです。
すみません838です。自己解決です。
２の方法で、
const parseItems : インターフェース = JSON.parse(items);
みたいにすれば、必要なとこだけ埋めることできました。
Express を用いてwebアプリケーションを開発しているものです。質問なのですが、webpackで.tsのコンパイルとバンドルを行う際に出来たbundle.jsをdist フォルダに出力するとして、.ejs などのテンプレートが入ったviewsはどこに配置するのが正しいのでしょう。srcでいいような気もするのですが、実際に動くのはbundle.jsだし、dist の方がいいのかなと…….
ようやくtsconfigのmoduleをesnextにしたわ
TS型安全は良いけどハマると時間ロスするね
エラーパッと見ではなんでエラーが出てるかわからない
C++をやってた頃を思い出した
TSってプログラミングしてるっていうより問題解いてる感が強い
パズルっぽくはあるが。スリザーリンクみたいに定石に当てはめたらパタパタと解けていく印象だな。
TypeScriptのジェネリクスで型消去する方法って無いんだっけ？
あるいはJavaのワイルドカード型<?>みたいなのとか。
ああなるほど、<T extends any>なら<any>でいいわけか。
Promiseを同期的にwaitすることってできますか？
awaitではなくC#のTaskで言うところの.Resultなんですが…
え、できないんですか困った
外部ライブラリに渡すコールバック関数がPromiseをサポートしてない
けど、その中で非同期関数を呼びたい
というユースケースなんですが諦めるしかないんですかね…
C#は呼び出し側のスレッドをブロックしてもTaskは別スレッドで動いてるから困らない
JavaScriptはシングルスレッドだから同期的にwaitできたら
呼び出し側がブロックされるだけじゃなくPromiseで動かそうとしてる処理もブロックされるので困る
コールバック関数をPromise化すればいいケースのような気がする
コールバックというと正確じゃないかもなんですけど
あるフレームワークが拡張のためのフックをサポートしてる
その関数は決まった名前のjsあるいはtsファイルのデフォルトエクスポートで指定する
フレームワークはそれがあれば利用し、なければ何もしない
その関数のシグネチャーは非同期をサポートしてない
こんな感じのシチュエーションですね
>>854
>その関数のシグネチャーは非同期をサポートしてない
async/awaitのこと言ってる？
もしそうならasync/await使わない旧来のPromiseのやり方すれば？ >>855
Promiseもサポートされてないです
function libFunc( myFunc: (x: X) => Y )
イメージとしてはこんな感じで
myFuncはPromiseを返せないようなってます
myFuncのなかでOneWayのPromiseを走らせてPromiseを捨てることはできますが
libFuncはmyFuncの戻りであるYを使って処理を続けるのでOneWayでは意味がありません const ox = await new Promise(resolve=>
libFunc(x=> {
// yを作成
resolve(x)
return y
}))
とかじゃ駄目なん？
>>857
あくまで>>854という前提があるのでlibFuncを呼び出すタイミングはこちらでは選べません >>856
やりたいことがいまいちわからんが、同期呼び出しでmyFuncの結果を取得したいというならそれは無理。 Promiseも使えないならもう一つ昔のコールバックヘル方式でやるしかないね
>>858
何がやりたいかわかんね～
myFuncさえ登録できりゃ発展形でやり様子はあると思うけど 変数の先頭に$を付けるのは何の意味があるのでしょう？
Cの __FILE__ や __LINE__ みたいにトランスパイル前のファイル名や行番号を埋め込む方法って無いのかな？
一応source-map-supportでスタックトレースは読めるようになったけど、もっと手軽に埋め込むログで
場所を示せたらいいんだが。
tscの前にプリプロセッサとかかまして実現できるならそれでもいいんだけど。
>>866
英語で議論できれば提案すればいいと思うけどね >>868
手動でやるのは簡単だよね？
TS使ってないからビルドシステム知らんけど、Pythonか何かを挟み込める余地があったらそこでやってしまえば？
或いはいっそのことmakefileでラップしてしまうとか。(makefile内でビルドコマンドを起動） >>872
多分ね。（俺は871、TS使ってない）
他言語（何だったかは忘れた）でも同様に「ないのか？」って聞かれてて、
仕様に入れない理由が「ちゃんと関数名書け」だったと思ったよ。
実際あれって、実装するのは簡単だけど、Cにしかないでしょ。
個人開発ならともかく、Gitな今だと複数バージョンが同時に使われてたりするから、収拾付かなくなるのではないかな。
その辺のCの便利機能って、今の大規模開発にはフィットしないから、基本的には嫌われてる。
多分、提案したところで入らない。 技術的にそう難しくもなさそうなのに今無いってことはもう入れられる見込みは無いんだろうけど
これが絶対に相容れられないようなポリシーってなんかあったかな？
TSって滅多にクラス使わないけどDIってどうやってんの？
クラス全く使わないわけじゃないよ。まぁ明示的に副作用使いたい時ぐらいしか使わないけど
DIの件はこれで解決した
function F(deps: { … }, p1: T1, p2: T2)
よくよく考えると
たったこれだけのことだったんだ
フレームワークとかややこしいことを考えたのが間違いだった
type X = {
foo: string;
bar: string;
baz: string;
}
この型から
type Y = {
foo: string;
bar: string;
}
この型をMappedTypesで定義したい
つまり特定の属性を除去した型を作りたいのだけど出来る？
.NETでいうところの.NET StandardのようなものってTSには無いの？
フルスタックでTS使う案件に間違って入っちゃったんだけど環境ごとに何が出来るのか把握しきれなくてツラミを感じる
ストリームと文字列の処理みたいな「こんなもんどの環境でも動くだろ」ってコードすら移植すると動かない時があって泣きそう
スタンダードなライブラリが無いならビルダーの設定でもいい
tsconfigでターゲットプラットフォームとランタイムバージョンを指定すると「このパッケージはこのターゲットプラットフォームでは使えないよ」って教えてくれるだけでもだいぶ楽になると思うんだけど…
こういう機能ってどっかに絶対あると思うんだけどググっても古い断片的な情報ばっかり出てきてその設定を探すのも難しい
主な実行環境として node.js とブラウザがあるってことはわかってる？
あとは泥とりんごでしょ？
せめてその4つのメジャーな環境でほぼほぼ同じように動く基本ライブラリ、基本ライブラリだけに依存して、つまりほぼほぼどこでも動くサードパーティライブラリ
それらが日常的な作業に不自由しないレベルで揃ってて然るべきだろう、と俺は思うんだけど無いのかな？
基本ライブラリというならJavaScript API群があるが。
「日常的な作業に不自由しないレベル」って具体的にはどんなものを期待している？
まず.NETが世界の中心。みんな知ってるだろ全部揃ってて当然だろみたいな考え方をやめろ。
フロント側についてはサイの絵が書いてある本買ってくるか、MDNを熟読すれば良い。Node側はNodeの公式を読め。話はそれから。
あとはtsconfigのcompilerOptions以下のtargetとlibを指定しろ。この辺はNodeのバージョンや、対象ブラウザで変わるからググれ。すぐ出てくる。
> 主な実行環境として node.js とブラウザがあるってことはわかってる？
> あとは泥とりんごでしょ？
これわかってないだろ
自分は知っているみたいな錯覚してるせいで根本的に間違ってることに気づいてない
根本的な勘違いとして、それはTypeScriptの責務では無い。TypeScriptはJavaScriptにモダンな型を付与するもの（一部例外はある）で、APIの提供はしない。
例に出てきたFileReaderの様なAPIはブラウザとNode側で求められる機能もセキュリティレベルも異なり、それぞれが提供するものだ。それを統一はできない。ましてnpmのバッケージで提供されているものはパッケージ作者が責務を負うものだ。
自分の勉強不足を棚に上げて言語に文句を言うのは筋違いも良いとこ。
そこがTSの限界であり、使いにくい原因なんだろなぁ
FileReaderなんてのはたまたま出てきた一例でしかないが
リンク先のポストを読めば、トピ主のやりたいことはストリームから文字列への変換とわかるだろう
その程度はどのプラットフォームでもサポートできる
使用頻度もそこそこだから、標準ライブラリとして用意されていて当たり前
encode(s: string, format: string): Blob
decode(b: Blob, format: string): string
これでいいだろ？
セキュリティやハードウェアに依存するものが標準化されないのは許されるだろう
しかしなぜ簡単にできるものすら標準化しない？
そのストリームってのは何のストリーム？
ひょっとして用語を間違えてるから調べても出てこないのでは？
>>888
型演算に末尾再帰最適化（みたいなの）追加されるやん！ 型の@types だけインポートするにはどうしたらよいでしょうか。
leafletという地図のjsライブラリがあって、グローバルでL という変数をnamespaceとして使っています。
npmの層を薄くしたくて、地図ライブラリはnpm を使わずにhtmlにscriptタグを直接書いて読み込んでいます。
でも型補完は欲しいので、"@types/leaflet"はnpmでインストールしています。
この状態で変数L に型補完を動作させるにはどうすればよいでしょうか。
何もしないと、変数Lは未定義だよ というエラーが出ます。
(エラーを消すだけなら適当なd.tsを作って declare const L: any; とでも書けばいいんだろうけど)
import type * as Leaflet from 'leaflet'
declare const L: typeof Leaflet
Dateが使いにくいのどうにかする最高のライブラリ教えてよ
date-nfs、momentあたりは試したけどしっくりこんかったわ
JSONが非対称ってのもSo Badやでほんま
よくこんな罠だらけの言語でやってられるなー
フロントエンド勢の忍耐力には尊敬の念を禁じえんわい
>>899
> JSONが非対称
とは？
JSON.parse, JSON.stringify 知ってるか？ >>899
date-nfsで駄目ならオススメは無いかなぁ。
ご指摘の通り罠も多いけどC++とかに比べたらずっと楽な言語だと思うな >>899
> Dateが使いにくいのどうにかする
そんなあなたに Temporal Effective TypeScript
ちと古いが読んだ方がいい？
あーくそ
なんでstrictをOFFにできるんだよ
VB.NETか！
既存の JavaScript を段階的に移行したい時かな
非同期がよーわからん
ワーカーを考えない場合
ブラウザでもモバイルでもバックエンドでも基本的に一本のキューにジョブを入れてって順次処理するモデル
promiseやawaitを使うと処理の前後関係は保障されるけど間に他のジョブが割り込む可能性がある
処理そのものはシングルスレッドで行われるのでpromiseやawaitを挟まない限り全てのJSコードがアトミックに実行される
fetchなどJS外の処理についてはアトミックは保障されない
こんな感じであっとる？？？
>>907
だいたい合ってる。基本的には処理の予約と考えるだけで済む。
JS外の処理はWebWorker含めてJS環境に干渉してこないんだから（戻り値以外）ほぼイベントとか割込と同質で特殊なものだと考える必要もなくないかな？ なんかプロジェクトでtypescript使う流れになって今から勉強してるんだが、これ何に優れてるの？
javascriptの拡張言語で型の宣言できるぐらいがメリット？
実行するためにいちいちコンパイルもどきなことをしないといけないしデバッグ面倒で正直やりづらいとしか思えないんだが
「正直、特別優れた言語設計でもないし、基本的なライブラリ貧弱だし、なんか色々と不安定なので、他の言語を使えるならそっちのがいい。
でもJavaScriptよりかは遥かにマシだからターゲットプラットフォームがブラウザ、ReactNativeなら積極的に使っていこうぜ」ぐらいの認識ですかね
型パズルとかゆるゆるなインターフェースとか最初はこりゃ楽チン、便利だなと思うけどメンテナンス性は疑問
あとTypeScriptは生のJavaScriptよりanyの凶悪さが増してると思う
所詮はALT JSですね
>>910
watch使うとわざわざコンパイルする手間が省けるので楽だよ。あとmapファイルも出力するようにすればデバック時も面倒じゃなくなるよ。
型だけじゃなくて、同じコードで古い環境でも動くソースを吐くこともできるよ。
でも、型にメリットを見いださない人向けの言語で無いね。 動的型付け言語しか使ったことがない人ならそんなものだよね
個人開発だとTypeScriptガンガン使ってる
型パズルたのちい
型パズルはアンチパターンだ
ほどほどにしとけ
人類はC++を教訓にしなければならない
TypeScriptにはSFINAEみたいな凶悪な仕様はないだろう。
conditional typeは少し難解かもしれないが自分で使わなければいいだけのことだし。
any型のデータをそれ以外の型に変換可能かどうか判定する、または変換するライブラリってあります？
↓こんな感じの
type T = { id: number; name?: string; timestamp: Date; }
const data1: any = { id: 1, name: “bob”, timestamp: new Date() }
const t1: = convert<T>(data1); // OK
const data2: any = {
id: “2”, // number format string
timestamp: “2021-12-21T11:00:00Z”, // ISO Date string
}
const t2 = convert<T>(data2); // OK
const data3: any = { // without required field
timestamp: new Date()
}
const t3 = convert<T>(data3); // throw Error
const data4: any = {
id: 4,
timestamp: “hello” // invalid format
}
const t4 = convert<T>(data4) // throw Error
TypeScriptって型が嘘をつくことが結構あって
Date型なのに実行時には文字列が入ってるとか
型定義では省略不可なのに実行時には省略されてるとか
そういう実行時の型エラーをなんとかして削減したい、というのが根本的な課題です
上でレスしたようなライブラリがもし有れば多少はマシになるかな、と
ランタイムがキャスト例外を投げてくれればそれがベストなんですが、JSに実行時型情報はないのでそれは難しい
> JSに実行時型情報はないので
つ typeof, instanceof
すげー斜め読みしてタイプガードではいかんのかと思った
タイプガードでもいいんですけど数が多いので一発で全部よしなにやってくれるものがほしいって感じですかね
C#のdynamicのように非互換の代入をその場で例外にしてくれれば楽なんですが
なんでかanyは非互換でもエラー無しでスルッと進んでしまうので苦労してます
>>922
どうも
なかなか良さそうだけどちょっと大変そう
普通の型を先に定義してパーサーを生成するのは難しいんですかね? TypeScriptのtypeやinterfaceからjsonschemaを生成するライブラリがあるから
それを使ってタイプガード書けば楽よ。
>>925
いいかも
あとはanyの代入を自動的に置き換えることができれば完璧 string -> Date のような transform をしたいなら、型から自動生成を期待するよりもスキーマで変換ロジックを書いて型を導出するアプローチの方が扱いやすい
axiosでの（非同期）通信結果から
最終的にpromiseを外した形でresponse扱いたいんだけど
どうやるとできるのでしょうか？
function的な奴で非同期通信して
そのfunction自体はpromiseでない値を返したいんだけど。。。
awaitやろうと思うと
そのfunctionはasyncになって
結局promiseになってしまう
イメージ
conct func = (): string => {
// axiosの戻りがstringだとして、このvalを同期的に返したい
axios.get("hogehoge").then(val=>{return val})
}
不可能です
直接 XMLHttpRequest を同期モードで使用してください
非同期を同期にはできない。
これ、初心者の頃は辛かったけど、気がついたら慣れてたし不便さより便利さを感じるようになったから人間の適応能力ってすごい。
うーんわからん
type X = A & { foo: string}
ってやるとXがanyと判定される現象が起きてて原因が全くわからない
Aはちゃんと型が認識されてる
const a: A = { 略 }
a.
ここまで打てばインテリセンスが出てくる
でも&を挟むとなぜかanyになる
コンパイラのバグかな？
export type X = A & { foo: string }
const x: X
これは型が生きてるしインテリセンスも出る
import { X } from ‘…’
const x: X
これはanyになってしまう
ファイルを跨がなければおkみたい
エクスポート/インポートのプロセスでバグるのかな？
他の型は問題出てないからAだけが特殊なんだろうけど文字列型のフィールド幾つか持ってるだけのなんの変哲もない型なんだよな…
色々調べて行き詰まったんだけどこれで合ってる？
babelのpreset-typescriptはTSから形情報を落としてるだけ
なのでtsconfigを無視する
なのでproject referencesも無視される
プロジェクト分割したい場合のオフィシャルな手段がない
なのでプロジェクト分割したければ各自好きな方法でハックするしかない
暫定対応として被参照側のプロジェクトでwatch & buildを仕掛けて
babel側のプロジェクトから被参照側の出力フォルダをimportしてるんだけど正直辛いものがある
babel がどう動くかなんて tsc には関係ないだろ
それともあなたのエディタは babel で型情報を解析しているのか？
コンパイル済みのファイルに型情報がないという話なら、型定義ファイル(.d.ts)も出力しないとそりゃそうだろと
情報を小出しにせず、問題が再現するリポジトリ丸ごと上げるかせめてファイル構造や各種設定ファイルの内容など全部書き出して
& がダメなのかファイルを跨ぐのがダメなのかプロジェクト分割がダメなのか話がどんどん移っててわからんぞ
別ですね
単刀直入に言うとbabel & preset -typescript環境で正しいプロジェクト分割のしかたを聞きたかった
色々と試して結論が出た
プロジェクト参照は諦めてシンプルに相対パスでimportすることにした
依存パッケージを全てのプロジェクトに入れなければならないのが面倒だけど妥協
ようするに昔VB6やC言語などでよくやってたDLL化せずにコードファイルを共有するスタイル
モダンな言語でやることとは思えないけど何日も調べてできないなら仕方ない
これを
babel_proj
webpack_proj
tsc_proj
tsconfig.json
tsc_lib_1
tsconfig.json
tsc_lib_2
tsconfig.json
こうする
babel_proj
symlink => ../libs
webpack_proj
symlink => ../libs
tsc_proj
tsconfig.json
symlink => ../libs
libs
lib_1
lib_2
JavaScriptがって話ならわからんでもないが
TS始めた時からずっと思ってたけど型が簡単に嘘を付ける言語仕様はバックエンドでは到底受け入れられんわ
フロントエンドでは気楽さと壊れやすさのトレードオフってことで受け入れるけど
そうだね
バックエンドでは実質Cと大差ない
ちょっとだけ楽できるけど
じゃあ逆にバックエンドで受け入れられる言語ってなんだろう？JavaとかRustくらい？
JavaとC#だね
型安全性がしっかりしてて実績も多い言語って言えばそれぐらいじゃないか？
んー、つまり
>TS始めた時からずっと思ってたけど型が簡単に嘘を付ける言語仕様はバックエンドでは到底受け入れられんわ
JavaとC#以外の言語を触るたびに同じように思ったってことでいいのかな？
C♯やJavaよりはTypeScriptやRust選びますわ
まるでTypeScriptやRustを選ぶとバグが出るかのような物言いだが
C#やJavaを選べばバグが出ないというわけでもあるない
TypeScriptは型が簡単に嘘をつけるのでバグが出やすい
型安全性がバグ削減に貢献しているのはプログラマの常識
>>962
具体的にどういうのを言っている？まさか故意にasでキャストした場合の話じゃないだろうが >>963
型が嘘をつけることとバリデーションは別次元の話
>>964
明示的キャストなんかしなくてもTSにはいくらでも型が嘘をつく罠がある
代表的なところだとjsonのパース、DBのI/O、api I/O、野良ライブラリのI/O、、、 言語仕様を変えるべきなんだろうな
typeで宣言した変数への代入は実行時に型チェック付きのマッピングにトランスレートすべき
ついでに言うとtypeで未定義の属性はマッピングするときにundefinedにすべき
これだけでTypeScriptによくある馬鹿馬鹿しいバグがかなり減るはずだ
type Foo {
x: string;
y: number; }
const foo: Foo = { y: “s” } as any
これはコンパイル時には無視していいが実行時にはエラーになるべきだし
const foo2: Foo = { x: “a”, y: 100, z: “111” }
これはzは消えるべき
Javaは最も優れた設計でそもそもanyみたいな言語仕様がない
Objectは定義できるが暗黙のキャストでスルッと行くなんてことはあり得ないし無理やりキャストしたって実行時に必ず例外が飛ぶ
C#はanyに近いものでdynamicというのがあるがこれも誤ったキャストには実行時に例外が飛ぶ
どちらも型が嘘をつかないように言語基盤がしっかり担保してくれるから型を信用していい
当たり前のことを当たり前にやってくれる堅実な言語だ
>>968
このコードは説明のためのスニペットだ
現実的にこんなコード書くわけないだろ
現実的には先に挙げたような状況でanyと戦わなければならない >>966
>>970
なんの為のバリデーションとタイプガードだよ。
どこで間違った型が入りうるかなんか普通把握できるでしょうに Javascriptのスーパーセットという最大のセールスポイントを見てなさすぎだろ
構造的部分型も便利だしany型なんて使うときには型ガードするよね
型に関してはJavaより好きだわ
Nullableを長年放置してたり文化的にも言語的にもImmutableを軽視してきたJavaもちょっと信用できないですね
>>971
バリデーションってのは値が正しいかどうか検証するものであって型が嘘をついているかどうか調べるためのものじゃない
どこで型が嘘をついているか確実に判断することはむずかしい
自分達の管理するコードベースの外界とのI/Oは全て疑わしい
先も述べたようにJsonのパース、ApiのIO、DBのIO、野良ライブラリのIO
疑わしい箇所が多すぎる
型が嘘をつかない言語なら外界とのI/Oの型定義が信用できる
信用できない領域がグッと一気に減る
だから型は嘘をついちゃいけないし
簡単に嘘をつける言語仕様は絶対におかしい >>972
構造的部分型もわかりにくいバグの温床だな
anyよりは全然マシだが
まあ楽なのは楽だよそれはわかる
ただ楽なのと安全でりかいしやすいのとは同じじゃないからね
typeは俺が言ったような真の意味で型安全を担保するための仕様
interfaceは構造的部分型でサボるための仕様
こう使い分ければよかったんだろうな >>972
セールポイントであり最大の弱点でもある
思い切って互換性切った方が絶対上手くいってた
>>973
まあ先発の古い言語だからある程度は仕方ないね
Null安全は対応してきてる
イミュータブルは昔から使えてた(final) >>974
型さえあってりゃどんなライブラリも安全安心だと思っているのか…… >>977
ちゃんと読めてます？
「信用できない領域がグッと減る」って書いてあるでしょ？
型安全であれば全てが安全なんてことはない
これは常識
でも型安全ならそうでない場合に比べて大部分が安全になる
これも常識
そしてTSは一見すると型安全であるかのように見えるけれど
型が簡単に嘘をつける言語仕様のせいで実は型安全ではなく安全でない言語である
これが私の主張
よく読んでね >>966
あんたの言う「型が嘘をつく」の意味がよくわからんが。オレオレ用語じゃなくて一般的な用語で説明してくれんかな。
>先も述べたようにJsonのパース、ApiのIO、DBのIO、野良ライブラリのIO
>疑わしい箇所が多すぎる
嘘をつくもなにも、JSONはそのJSON自体の構造以上の型を主張したりはしないが。
それを勝手に別の型と見做したとしたらそのコードの方に問題があるわけだろう。 >>967
ああなるほど。
型の合わせ方がわからなくてasやanyで誤魔化したらバグったってのの逆恨みか。 型が嘘をつくってのは
コンパイル時に指定した型以外の値が入ってることがある
入れることが簡単にできるということ
type X = { foo: string }
function xxx(): X
例えば↑こういう定義があったとする
実際にxxx()の戻り値が文字列型のfooという属性を持っているかどうか？
それはソースコードを隅々まで読んで間違いないことを確認するまでわからない
コードはXという型はfooという文字列型の属性を持っていると主張しているわけだが実際にはそうでない場合がある
これを俺は型が嘘をついていると表現する
JavaやC#ではこういう事は起こらない
正確には低レベルAPIでメモリを不正に書き換えれば起こせるが無理すれば起こせないこともないと言った程度
JavaやC#ではXがfooという文字列型の属性を持っていてxxxの戻り値の型がXであると書いてあったらそれを信用していい
JavaやC#は型が嘘をつかないからだ
>>982
？
おめーのtscはそれコンパイルエラーにしてくれないの？ >>985
本当に恥ずかしいからお前はもう黙ってろ そんなにTSが嫌いならずっとJavaなりC♯なり使ってれば良いじゃん
>>987
コンパイルエラーにならない function xxx() の例よろ。 >>988
そだね
選択権があるプロジェクトなら必ずそうしてるよ >>989
function xxx(): X {
return {
foo: bugLib.getStringValueEvil();
}
} >>991
？
bugLib.getStringValueEvil() がstringと宣言されていればコンパイルが通るけどそっちが嘘だったって話？ じゃあ bugLib.getStringValueEvil() はどうやって嘘をついたわけ？堂々巡りだが。
>>994
さあどうだろうな？
だから>>982でソースコード隅々まで見たら…って書いたんだけどね
JavaやC#だったら型だけ見ればああこの戻り値のfoo属性は文字列なんだなと信頼できる
ソースコードを隅々まで見る必要はない
なぜなら型が嘘をつかないからね anyなんかから型変換する際にランタイムチェックを追加するオプションはあっていいとは思うがTypeScriptにとってのno goalだから無いのも仕方ない
型安全性だけに拘るならTypeScriptは適当じゃないのはそれはそう(そもそもがoptional typeでしかない)
他の要素も考慮すれば個人的には悪い選択肢じゃないのでJavaScriptよりはTypeScriptを選ぶけども(C#やJavaと比較するかは目的による)
ようはTypeScriptに限らず強い型付け以外全否定ってことかね
>>995
それって型指定のバグなわけで、バグを回避する為に他の言語でもソースコード全部読む必要あるのは変わらないのでは…… lud20221020033946ca
このスレへの固定リンク： http://5chb.net/r/tech/1524746903/ヒント：5chスレのurlに
http://xxxx.5ch
b.net/xxxx のように
bを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「TypeScript part3 」を見た人も見ています：
・TypeScript part4
・TypeScript part2
・次世代言語Part8[Haskell Rust Kotlin TypeScript]
・次世代言語11[Rust Swift TypeScript Dart]
・次世代言語9[Haskell Rust Kotlin TypeScript Dart]
・次世代言語12 Go Rust Swift Kotlin TypeScript
・次世代言語14 Go Rust Swift Kotlin TypeScript
・次世代言語15 Go Rust Swift Kotlin TypeScript
・次世代言語15 Go Rust Bosque Kotlin TypeScript
・次世代言語22 Go Nim Rust Swift Kotlin TypeScript
・次世代言語29 TypeScript Swift Go Kotlin Rust Nim
・次世代言語28 TypeScript Swift Go Kotlin Rust Nim
・次世代言語24 Go Nim Rust Swift Kotlin TypeScript
・次世代言語23 Go Nim Rust Swift Kotlin TypeScript
・次世代言語25 TypeScript Swift Go Kotlin Rust Nim
・次世代言語21 Go Nim Rust Swift Kotlin TypeScript
・次世代言語Part7[Go Rust Swift Kotlin TypeScript]
・CoffeeScript、他AltJSは死んだ。TypeScript以外は
・もうプログラミング言語はTypeScriptだけやっとけばいいだろ 何でもできるし
・【純粋関数型AltJS】PureScript
・【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ54【php,py,pl,rb】
・【Trading View】Pineスクリプト【Pine Script】
・【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ55【php,py,pl,rb】
・【LX】氷室京介 ～KYOSUKE HIMURO～ Part981 【POSTSCRIPT】
・【LX】氷室京介 ～KYOSUKE HIMURO～ Part982 【POSTSCRIPT】
・Kava script
・JavaScript 4
・ECMAScript デス 4
・ECMAScript デス 6
・+ JavaScript の質問用スレッド vol.127 +
・+ JavaScript の質問用スレッド vol.123 +
・+ JavaScript の質問用スレッド vol.131 +
・+ JavaScript の質問用スレッド vol.134 +
・+ JavaScript の質問用スレッド vol.124 +
・+ JavaScript の質問用スレッド vol.129 +
・ActionScript 3.0 とか絶対ﾑﾘｗｗｗPart2
・JavaScript の質問用スレッド vol.123
・JavaScript の質問用スレッド vol.125
・氷室京介 ～KYOSUKE HIMURO～ Part917 POSTSCRIPT
・JavaScript ライブラリ総合質問所 vol.5
・+ JavaScript の質問用スレッド vol.122 +
・+ JavaScript の質問用スレッド vol.131 + [無断転載禁止]
・+ JavaScript の質問用スレッド vol.123 +
・+ JavaScript の質問用スレッド vol.125 +
・+ JavaScript の質問用スレッド vol.119 +
・+ JavaScript の質問用スレッド vol.129 + [無断転載禁止]
・【JavaScript系】 NILScript 【AutoHotkey風】
・【MACRO】Google Apps Script 質問スレ【DRIVE】
・Rails6でCoffeeScript廃止。見る目がなかった人達へ
・【node.js】サーバサイドjavascript 4【io.js】
・氷室京介 ～KYOSUKE HIMURO～ Part896 POSTSCRIPT [無断転載禁止]
・氷室京介 ～KYOSUKE HIMURO～ Part906 POSTSCRIPT [無断転載禁止]
・【node.js】サーバサイドjavascript 5【Nashorn】
・CoffeeScript
・【ActiveScript】RubyをWindowsで使うスレ【GUI】
・【PC】Sniper: Ghost Warrior 3人目
・JavaScript の質問用スレッド vol.126 (276)
・javascriptで質問
17:46:32 up 11 days, 18:50, 0 users, load average: 9.64, 9.79, 10.04
in 0.063798904418945 sec
@0.063798904418945@0b7 on 012507
|
