TypeScript + Tynderから始める宣言的検証生活 - Qiita
皆さんは JSON Schema 使ってますか？ 現在では、Web APIのペイロード定義・検証、モックサーバー作成、ユーザー入力フォーム検証、設定ファイルのスキーマ定義・検証・IDEでのエラー表示など、多くの場面で、また多くの言語でライブラリが整備され利用されています。 JSON Schemaの強み Internet draftのフォーマットで仕様が公開されている 多くの言語での多くの実装（言語によっては複数）が存在する 1回書けば、フロントエンド、複数のバックエンドすべてで利用できる可能性が高い 代替実装が存在すると競争原理が働く JSON Schemaの嫌いなところ 見辛い 書き辛い 数行の小さなスキーマならばともかく、JSON Schemaって本当に苦痛。汎用のデータフォーマットを人が直接記述するレイヤーのDSLにするのは正直辛い。ヒューマンリーダブルだからといって人が読めるとは限
TypeScript で書く React コンポーネントを基礎から理解する - Qiita
この記事は Recruit Engineers Advent Calendar 2019 の 23日目の記事です。 TypeScript のプロジェクトで React コンポーネントを書いていると、コンパイラに怒られることがたびたびあります。ネット上にあるサンプルコンポーネントが JavaScript で書かれていると、プロジェクトにもってきたときにコンパイルできないということはよくあるんじゃないでしょうか。any でコンパイラを黙らせることもできますが、せっかく TypeScript を使っているので、安全に解決したいよねってことでこのような記事を書きました。 型定義は @types/react@16.9.17 にしたがっています。目次をみて、この程度のことはもう知っているよという方は react-typescript-cheatsheet をみてください。React + TypeScr
TypeScriptはgradual typingシステムか - Qiita
概要 TypeScriptは，動的型付けシステムであるJavaScriptに静的型システムによる検査を部分的に導入できるプログラミング言語であり，gradual typing （漸進的型付け）システムであるとされることがあります．Siekらは，動的型付けと静的型付けの融合を図るシステム全般が無闇にgradual typingを名乗ることを疑問視して，gradual typingシステムが満たすべき基準を提案しました．本稿では，この基準に照らしてTypeScriptがgradual typingの条件を満たしていないことを指摘します．特に，ランタイムの型チェックを行わないというTypeScriptのデザインが，gradual typingの意味での健全性を明らかに阻害しています． 1 背景 ソフトウェア開発が大規模化する状況において，コード品質の担保や開発速度の維持は重要な課題です．静的型付
「レガシーフロントエンド安全改善ガイド」を商業出版します #技術書典 - memo_md
※2019/11/8: 無料サンプルと目次を記事内に追加しました。 2019年4月に開催された技術書典６で頒布した「レガシーフロントエンド安全改善ガイド」ですが、このたびインプレスR&D社さまより商業版を刊行することになりました。 自分が商業版の技術書を書く日が来るとは思わなかったのでビクビクしています。 メディア: この商品を含むブログを見る nextpublishing.jp 表紙イラストは同人版と同様、鍋料理さんに描いていただきました。「安全な感じで！」という相談から、カワイイ工事現場が仕上がりました、とても気に入ってます。工事現場本と呼んでください。 タイトルに「迷わない！困らない！」という強気ワードが付いててちょっぴり恥ずかしいですが、迷わず困らない内容になってる・・はずです！ 同人版との違い / 加筆・修正した点 紙の本で比較すると、ページ数が110ページ程度→200ページ超と
TypeScript導入で得られる「変えていく勇気」 / The courage to change by TypeScript - Speaker Deck
2018/9/1、GDG DevFest Tokyo 2018にて発表した資料です。
Almin 0.17リリース – executeの型付け、新しいReact Contextのサポート
ステート管理ライブラリの[email protected]をリリースしました。 詳しい変更点は次の記事でも紹介しています。 Almin v0.17 – Support context.useCase#execute typing and new React Context · Almin ⭐ Feature Support context.useCase#execute typing #342 #107 AlminはTypeScriptを公式にサポートしています。 しかし今まではcontext.useCase(someUseCase).execute(args)のargsがany[]となっていました。 コレを解消するためにAlmin 0.13でcontext.useCase(someUseCase).executor(useCase => useCase.execute(args))という
TypeScriptの型入門 - Qiita
TypeScriptは型がついたJavaScriptです。プログラミングにおいて型があることの恩恵は大きく、近頃AltJSの代表格として人気を集めています。TypeScriptはもともと型のないJavaScriptで書かれるコードに型を付けることを使命としていることもあり、たまに変な型が追加されます。例えばTypeScript2.8で追加されたconditional typesはずいぶん注目を集めました。これによってTypeScriptの型システムの表現力が広がりましたが、一方でTypeScriptを書いている人の中には、よく分からない型が増えてついて行けない、一部の人たちが長くてよく分からない型定義を書いて喜んでいるだけと思っている方もいるのではないでしょうか。実際、健全にJavaScriptを書いていれば、自分でそのような変な型を書くことはあまり多くありません。 そこで、この記事ではT
さよならボイラープレート。s2sによる高速reduxアプリケーション構築 - Qiita
まだアクションクリエイターを自分で書いているの？ reduxとflowtypeを使ってフロントエンドアプリケーションを構築していると、ボイラープレートが多く、面倒だと感じることがありませんか？ しかし、もはや、このAST時代の前には過去の悩みでしかありません。 型を書く。それが全てです。 型を書いて、定数を書いて、アクションクリエイターを書いて、一つ変更したら全て変更して、もしくはなんらかのハックを行って型付けして、なんてものは過去のことです。 これからは、アクションクリエイターの作成に5秒以上時間をかけたら怠惰でありましょう。そして、これはs2sの1プラグインでしかありません。 プラグインを組み合わせると以下のようなこともできます。 s2s (Source to Source) これを実現している仕組みをSource to Source(s2s)といいます。 ソースコードからソースコード
CoffeeScript 2という新たなる希望 - Qiita
CoffeeScriptは滅びぬ！何度でも蘇るさ！ CoffeeScriptがいかに駄目かを理解している皆さんならご存じの通り、これまでのCoffeeScriptには重大な欠点があった。それは「CoffeeScriptはECMAScript5(ES5)のaltJSである」と言うことだ。ES5以前のJavaScriptが駄目すぎるため、そこがCoffeeScriptの限界になってしまっていた。駄目な奴は何をやっても駄目なのだ。 ECMAScript2015以降(ES2015+)において、JavaScriptは目覚ましい発展を遂げた。ジェネレーター、テンプレートリテラル、class構文、モジュールベース、async/await等多くの機能が追加された。いくつかの機能は既にCoffeeScriptに存在していたものであったが、ジェネレーターのような全く無い物は新たに追加する必要があった。しかし、
Reduxで副作用を分離して状態を不変に扱うredux-elm-middlewareを使う - Qiita
Reduxを採用しているアプリケーション向けの記事です。 Reduxの副作用処理で使われるMiddlewareといえば、公式サンプルではredux-thunkが使われていて、redux-sagaもよく使われているという印象があります。 redux-thunkよりredux-sagaが選ばれる理由の１つは、副作用処理を分離でき、ActionCreatorを純粋関数（副作用のない関数）に保てるところかと思います。 redux-thunkではこういうActionCreatorになり、redux-sagaだとこういうActionCreatorになり、加えてこういうSagaを作ります。 redux-thunkでテストを書くとActionCreatorはこういう非同期処理をモックしたコードになり、mapDispatchToPropsはこういうコードになります。 redux-sagaだとActionCr
npm-scripts で Web フロントエンド開発を管理する - アカベコマイリ
gulp なしの Web フロントエンド開発から 1 年あまり。その間、特に問題もなく npm-scripts で Web フロントエンド開発を管理できているので、この間に得られた運用知見や所感などをまとめてみる。 npm-scrips とは？ 最近の Web フロントエンド開発では AltJS/AltCSSのビルドやリリース用イメージ作成などに Node.js + npm を利用することが一般化してきた。そのためプロジェクトは package.json で管理することになる。package.json の提供する代表的な機能として プロジェクト情報の定義 プロジェクトの成果物を npm として配布するための情報 プロジェクト名、バージョン、作者などのメタデータを定義する 依存モジュール管理 プロジェクトが依存する npm とバージョンを管理する この情報へ基づき npm install コ
JavaScriptをOCamlから生成するトランスパイラ「BuckleScript 1.0」、米ブルームバーグがオープンソースで公開。TypeScriptよりタイプセーフかつ効率的で高速と
JavaScriptをOCamlから生成するトランスパイラ「BuckleScript 1.0」、米ブルームバーグがオープンソースで公開。TypeScriptよりタイプセーフかつ効率的で高速と 金融情報などの提供を行っている米ブルームバーグは、OCamlのコードからJavaScriptのコードを生成するトランスパイラ「BuckleScript 1.0」をオープンソースで公開しました。 BuckleScriptはTypeScriptやBabelJSなどからインスパイヤを得て開発されたと説明されていますが、最大の特徴はTypeScriptなどが独自の構文を備えているのに対し、BuckleScriptは既存の言語であるOCamlを採用しているところです。 OCamlはオブジェクト指向型と関数型の両方の特長を備え、特に海外では金融系システムの開発でよく使われているプログラミング言語です。 Buckl
TypeScriptを使った方がいいケースとは？ | POSTD
去年の夏、私たちは大量のコードベース（18,000行以上の コード行数 ）をJavaScriptからTypeScriptへと変更しました。この移行作業を通じて、両者の相違点や類似点について大いに学び、TypeScriptの優れたユースケースや、TypeScriptを使うべきではないケースなどについて考えてみました。 型システムとは補助輪のようなものです。転倒防止してくれる代わりに、遅くなり、操作性が制限されます。 TypeScriptのユースケース コードサイズ ：ソースコードが膨大である場合、また複数の人がプロジェクトに従事している場合、型システムは明らかなエラーを防ぐのに役立ちます。 特に SPA の場合は当てはまります。誰かが変更したコードが他の人のコードを破損させてしまう可能性があるなら、何らかの安全機構を持つ方がいいでしょう。TypeScriptの トランスパイラ は明白な誤りを
CoffeeScriptからES2015(ES6)へ移行しました - Pepabo Tech Portal
ネットショップ運営サービス カラーミーショップで「新カゴプロジェクト」と呼んでいる最高のショッピングカートの開発をしている@tsuchikazuです。 2014年に開発を開始した新カゴプロジェクトではフロントエンドをCoffeeScript + Angularで開発してきました。ES5までの時代にAltJS文化を作り、Class構文やArrow Functionを先取りしていたCoffeeScript。それらはES2015(ES6)の仕様に採用され、一方でCoffeeScript自体の開発は止まり、CoffeeScriptは役割を終えたのではないでしょうか。先月、今後も変化し続けるフロントエンドに追従するためにも、新カゴプロジェクトで200ファイル以上のCoffeeScriptをES2015へ移行しましたので、今回その方法を紹介します。 トランスパイラ 移行方法としてCoffeeScrip
gulp なしの Web フロントエンド開発 - アカベコマイリ
Web フロントエンド開発において gulp は非常に便利だ。しかしあまりにも gulp に依存しすぎており、これなしで開発できるだろうか？という不安もある。というわけで gulp を利用せず package.json と npm だけで同等の機能を実現する方法を検討してみた。 2015/11/4 追記 babelify v7.2 を試すで babelyfy 7.2 ( とその中の Babel 6.x ) について調べ、npm-scripts の変更が必要なことを確認したので追記。また Windows 環境の動作検証をおこなったところ、最新の watchify なら -o オプションが通ることを確認できた。よって本記事の最後の課題が解決したことになる。 2015/9/23 追記 cpx と rimraf を試すの内容をファイル処理に反映して簡略化。 2015/9/15 修正 Stylus
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
React 副作用分割パターン - mizdra
KotlinJSって正直どうなん
Bloomberg、OCamlのJavaScriptバックエンドであるBuckleScriptをオープンソース化
Sprocketsを捨てたい
https://gopherjs.github.io/