動機 外界のデータに対して、どのように型付けを行うか - これは人類の当面の課題である。外界からアプリケーションに取り込んだデータに対して、内部で扱いやすいようにnon-nullの型を書くと、予期しないクラッシュを引き起こしてしまった、というような経験を誰しもお持ちではないだろうか。一方で、外界の状況と一致した型を書くと、冗長にnullチェックを書く羽目になり、デベロッパー・エクスペリエンスがよろしくない。このジレンマから逃れるために、外界からデータを取り込む境界部分で包括的なアサーションを施して、アプリケーション内部では対応する型をもっているものとして扱いたい。 JavaScriptでJSON Schemaを用いてアサーションを行うライブラリは知っていたので、うまい具合にJSON Schemaとコードを同期させるソリューションがあれば、JSON Schemaとアプリケーションのコードを同
Kaizen Platformでフロントエンド開発をやっているlacoです。 新規アプリケーション開発において、API仕様中心の開発スタイルを検討し、実験的に取り入れました。 本記事ではその概要と効果を紹介します。 API仕様中心開発 API仕様中心開発を取り入れようと思ったきっかけは、2017年のNode学園祭でpika_shiさんが発表した「JSON Schema Centralized Design」です。 JSON Schema Centralized Design - Speaker Deck Kaizen Platformではリモートワークで開発しているメンバーが多く、非同期にコミュニケーションをすることが多いので、生産性を高めるためには互いの作業を待たずに独立して分業できるワークフローが必要でした。 バックエンドAPIの実装を待たないとフロントエンドが実装できないような依存関
最近のフロントエンドの流れから取り残されている感じがしたので、一念発起して React で小さなアプリを作ろうと思いました。 せっかくなので、 React 関連ツールはなるべく統合して使うようにし、コード本体は TypeScript を使って開発しようと設定を始めました。 ( webpack 4 が出てきてしまいましたので、まだ周回遅れです。) 残念ながら、 create-react-app でテンプレートを作成してからツールを追加していくたびにエラーに見舞われたので、メモ書きとして記録しておきます。 執筆に長い期間かかってしまいましたので、もしその間にライブラリがアップデートされ、動かなくなっていたら申し訳ありません。 目次と使用ツール (以下のリンクは関係する部分へジャンプします。) TL;DR create-react-app React 16 TypeScript webpack
gas-clasp-starter という Google Apps Script を ローカル環境で開発するためのテンプレートを作りました。 2018年に登場した、google/clasp をベースに webpack, TypeScript, TSLint, Prettier, Jest を利用したテンプレートになっています。 GAS って新しい構文で書けないしソース管理もできないから微妙 もっと便利に利用できないかな みたいな方に読んでもらえれば幸いです。 本記事では、gas-clasp-starter を使うことによるメリットや、利用する際の流れを解説します。 ブラウザ上のスクリプトエディタで開発するのではだめなの? 小さなコードならスクリプトエディタで十分です。 ただし、ある程度のコードになる場合はローカル環境に切り替えたほうが良いでしょう。 GAS は JavaScript ベース
Typescript is a powerful way to build applications. It offers type checking to catch errors before they make it to the browser. On top of just utilizing typescript to catch bugs, it's still important to make sure Typescript code is tested. Facebook released a testing framework called Jest a while ago as that contains many built in features. You can kind of compare Jest to Mocha in saying that Jest
TypeScriptには似たような型としてObject型とobject型と{}型が存在します。 let o1: Object; let o2: object; let o3: {}; 今回はこの3つの使い分け、あるいはobject型導入の経緯についてです。 JavaScriptのデータ型 JavaScript のデータ型とデータ構造 - JavaScript | MDNを読めば分かるように、 Boolean Null Undefined Number String Symbol の6種のプリミティブ型を持つプリミティブ値とオブジェクトでJavaScriptは成り立っています。 TypeScriptにおけるobject型とはここでいうプリミティブ型以外を表現しています。 object型はいつ使われるのか いつ役に立つかというとObject.create()の定義です。 TypeScript/
React x MobXでできてる自分専用の音楽ストリーミングサービスがありまして。 冬休みなのでTypeScriptで書き直したりしてみようかなと思ってちまちまやってた。 ただ結局は自分一人しかコード書かないので、コスパに見合わないと判断して採用は見送った。 https://github.com/leader22/mmss-client/tree/topic/ts まあその過程で色々学びはあったので、忘れないようにメモっとく。 環境構築編 Webpackでコンパイル なにはともあれ開発環境を。 元がBabel x Webpackだったので、そこをまず変える。 npm install -D typescript awesome-typescript-loader そして`babel-loader`と差し替えるだけ。 TSはReactのJSXにも対応してるので、特に困る点はない。 ただWeb
JavaScriptのモジュール管理(CommonJSとかAMDとかBrowserifyとかwebpack) | tsuchikazu blog AMD & RequireJS - Qiita RequireJS使い方メモ - Qiita CommonJSは(Webpack等を使用した)ビルド時に依存関係を解決する方式だが、AMD(RequireJS)は実行時に依存関係を解決する方式である。 CommonJSはツールやライブラリではなく仕様のため、ビルド時に依存関係を解決する何らかのツールが必要となる。それが後述するBrowserifyやWebpackである。 AMDも仕様のため、それに対応するライブラリが必要である。それがRequireJSであり、さらにRequireJSはAMDには存在しない便利記法を導入している。 コードの中でmodule.exportsとrequireが使われていた
TypeScriptで作成したライブラリをrequireで読み込めるようにするには.d.tsをreference pathで参照する。 ただし、普通に.tsを–declarationでtscした結果では参照できないので、以下のような内容を手書きする。 declare module "Hoge" { export var huga: String; export var gege: Number; }上記の内容をnpm install Hogeで入れている場合、以下のような形式で読み込める。 (dtsmで入れている場合、reference pathで直接node_modulesを参照する必要はない) /// <reference path="../node_modules/Hoge.d.ts" /> import Hoge = require('Hoge'); console.log(Hog
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く