JSDocで型チェックする - Qiita
JavaScriptでも静的な型が求められるようになりTypeScriptやFlowが使われるようになってきました。 しかし、それらが無かったころのJavaScriptのコードやトランスパイラを使わずに開発している人はいてると思います。 この記事はコードの変更なしでJSDocのみで型検査をする方法を紹介します。 TL;DR JSDocの型定義で型チェックをする TypeScriptのallowJsとcheckJsを使う 必要に応じてd.tsをインストールする JSDocの型定義 TypeScriptやFlowが登場するより前からJSDocは存在します。JavadocやPHPDocのJavaScript版のようなものです。 そのJSDocは型定義が書けるようになっています。 エディタによってはJSDocの型定義で型のチェックを行ってくれることもあります。 JSDocについては@use JSD
🚀 Introducing Akita: A New State Management Pattern for Angular Applications
Every developer knows state management is difficult. Continuously keeping track of what has been updated, why, and when, can become a nightmare, especially in large applications. In the Angular world, the most popular solution is ngrx/store, which was inspired by the famous Redux model. Personally, I’m a big fan of Redux and worked a lot with ngrx; However, both as a developer and as a consultant,
素のJavaScriptプロジェクトにtsconfig.jsonを置いといてVSCodeの便利さを享受する - Qiita
VSCodeの便利さを使いたいがTypeScript化するほど手間かけれない、みたいなときにtsconfig.jsonだけ作っておくとちょっと便利になりそうだったのでメモる。 追記： TypeScriptへ移植する予定が無い場合であれば、jsconfig.jsonを配置するでも十分そうです（違いはallowJSがdefaultでtrueなこととぐらい。あとはtsconfig.jsonは後述のコマンドでボイラープレートを生成できるという点ぐらいと思われます） 具体的にはこのへんとか使える 未使用のimport検出 ライブラリの型情報を利用した検出 JSDocがあればそれを利用した型検証 やり方 まずtsconfig.jsonを生成する。npx使う
Flow から TypeScript に移行しました - てくすた
こんにちは、開発部の id:yszk0123 です。最近、フロントエンドで使っていたツールを Flow から TypeScript に移行したので、そのお話をしたいと思います。 背景 一年半ほど前にとあるページを React に移行したのですが、その際に、型チェックツールとして Flow を採用しました。 採用の理由は、簡単に導入できて、いざとなれば簡単に捨てられるからです。 それからしばらく運用する中で、ある程度の規模であれば型の有用性を実感できたため、本格導入することになりましたが、次に挙げるような理由により、Flow をやめて TypeScript に移行しました。 理由 Flow の問題 1. 型定義ファイルの管理が複雑 ライブラリの型定義ファイルの管理がそこそこ複雑です。 flow-typed という型定義の管理ツールを使えば管理はできますが、インストールしたファイルを git
Type-Safe Object Merging (TypeScript 2.8 Edition)
There are times when you want to merge two generic types in TypeScript, and type inference just isn’t doing it for you. Object.assign’s typing isn’t as precise as it could be, and spreading generics still doesn’t work. I’ve found a way to implement typing when merging objects using some of the new features in TypeScript 2.8. A Sample Problem Let’s start by defining some types we can use as example
Strongly Typed Event Emitters with Conditional Types
Event emitters are a common pattern in the Node.js world, but for TypeScript developers, they can carry some woe. TypeScript allows us to type “stringly-typed” APIs like event emitters and the web’s EventTarget interface (addEventListener and friends), but without more advanced type operators we’re stuck manually specifying every event name for every API that handles them. This works fine when som
TypeScriptの型入門 - Qiita
TypeScriptは型がついたJavaScriptです。プログラミングにおいて型があることの恩恵は大きく、近頃AltJSの代表格として人気を集めています。TypeScriptはもともと型のないJavaScriptで書かれるコードに型を付けることを使命としていることもあり、たまに変な型が追加されます。例えばTypeScript2.8で追加されたconditional typesはずいぶん注目を集めました。これによってTypeScriptの型システムの表現力が広がりましたが、一方でTypeScriptを書いている人の中には、よく分からない型が増えてついて行けない、一部の人たちが長くてよく分からない型定義を書いて喜んでいるだけと思っている方もいるのではないでしょうか。実際、健全にJavaScriptを書いていれば、自分でそのような変な型を書くことはあまり多くありません。 そこで、この記事ではT
TypeScript 2.8 の Conditional Types について - Qiita
今日はTypeScript2.8で導入されたConditional typesについて書きます。 TypeScriptの型システムへの機能追加という意味では、keyofやMapped Types以来の変更と言ってよいでしょう。 お察しのとおり、こういう機能追加をぶち込んでくるのはAnders Hejlsberg御大です1。
Patterns for designing flexible architecture in node.js (CQRS/ES/Onion)
In this post, I’ve presented a project that is using CQRS and Event Sourcing patterns. It’s organized using onion architecture and written with TypeScript. “flexible” —a free stock photo I found which makes this blog post much nicer and artistic.“flexible” how?I’m using the term flexible to promote an architecture which is able to adapt to different kind of environments. More precisely, I’m trying
TypeScript at Lyft
In my early days as a JavaScript developer, when I learned about efforts to add types to JavaScript projects, the first question I asked myself was: why? Now, as a seasoned JavaScript veteran, I cannot imagine writing JavaScript without support of a type system. Large JavaScript applications need type information for scalability and maintainability. Our numerous JavaScript projects at Lyft are no
To type or not to type: quantifying detectable bugs in JavaScript | the morning paper
the morning paper a random walk through Computer Science research, by Adrian Colyer Made delightfully fast by strattic To type or not to type: quantifying detectable bugs in JavaScript Gao et al., ICSE 2017 This is a terrific piece of work with immediate practical applications for many project teams. Is it worth the extra effort to add static type annotations to a JavaScript project? Should I use
がんばらないTypeScriptのはじめ方 - 角待ちは対空
追記 2019/04/16に以下の記事が公開されました。 employment.en-japan.com gfxさんによる記事です。この記事自体2017年の若干古い記事なので、新しく読む方は最新版である上記の記事を読んだほうがいいでしょう。 このエントリは2017/07/12に行われたHatena Engineer Seminar #8 @ Tokyoの発表内容をブログ向けに書き直したものです。 事前の通知では「CoffeeScript脱出にみるTypeScript2.4時代のベストプラクティス」がタイトルだったのですが、主題を変えたためタイトルも「がんばらないTypeScriptの始め方」に変更させていただきました。CoffeeScript脱出の話は一応出てきます。 社内のTypeScript事情 その後のTypeScript 現在の様子 TypeScriptのがんばらないはじめ方
Type-Checking JavaScript Files with --checkJs in TypeScript
June 16, 2017Up until TypeScript 2.2, type checking and error reporting were only available within .ts files. Starting with TypeScript 2.3, the compiler can now type-check and report errors for plain .js files as well: let foo = 42; // [js] Property 'toUpperCase' does not exist on type 'number'. let upperFoo = foo.toUpperCase();There's a new --checkJs flag which enables type checking for all .js f
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Definitive TypeScript Guide - Blog | SitePen
