hooks が発表されてから趣味でも現場でもずっと hooks を使っています。おかげでだいぶこなれてきて、だいたいなんのライフサイクルでも表現できるようになってきました。 最初は単に useState が state を、 useEffect が componentDidMount/componentDidUpdate を置き換えるもの、と説明を済ますつもりでしたが、 useEffect についてはライフサイクルのモデルがぜんぜん違うので、別の説明をする必要があるように感じていました。 で、その結果 React Hooks を理解するには、関数のメモ化を理解するのが最も簡単だと思ったので、その説明をしつつ、イディオムを解説していこうと思います。 最初に: React Hooks は何であり、何ではないか 関数コンポーネントが状態を持てるようにするもので、関数のメモ化のテクニックを多用しま

界隈の雑な会話です。注意点として、フロントエンドガチ勢寄りの方面なので、一般的な感覚とは乖離してる可能性があります。 基本的には http://www.s-arcana.co.jp/blog/2016/12/12/3438 や kikuchi1201.hateblo.jp を念頭に。 動き早いって言われるフロントエンド界隈、この1年何も進んでないからな— 現場の声 (@mizchi) 2016年12月14日 今年のフロントエンドの統括、es2016でしょぼかったので皆es2015+ みたいなノリが抜けなかったのと、redux以外のfluxが脱落したのと、angular2+今年も出なかったねというのと、たぶん eslint の採用が増えてそう(肌感)のと、flowの採用が増えたぐらい— 現場の声 (@mizchi) 2016年12月14日 実際browserify/webpackは先行実装だ

基本的に、ReactのpropsはImmutable, stateはmutableという扱いです。 storeはストレージ抽象じゃない— 賢さを上げて法で殴る (@mizchi) 2015, 8月 24 rootComponent以外のComponentで参照するプロパティは基本的に全てpropsになるしstoreからの関数読み出しみたいな動的な状態決定は行わない— 賢さを上げて法で殴る (@mizchi) 2015, 8月 24 そもそもViewを論理的に分割しても人間のよくわからん都合でしっぺ返し食らうだけなんでコンポーネントが独立して稼働するなんて状態になりにくくて、一意な状態を作るのに一旦一箇所に集約した上で各コンポーネントに発散するのがいい— 賢さを上げて法で殴る (@mizchi) 2015, 8月 24 @r7kamura 親が正しいprops持ってれば、結果として正しいpr

ぼくのフロントエンドの情報収集ソース | Yuhiisk みたけど多すぎて逆に機能不全になると思う。 自分が主に見てるのは次の2つ。 efclのはてなブックマーク JSer infoのazuさんのはてブ。 Echo JS - JavaScript News Hacker News のJS版みたいなもの これを読み流すんじゃなくて、LDRで一件一件丁寧にみてる。日本語圏で再生産され続ける情報に意味があるもの少ないので、上流とまとめだけみればよい。

最近フロントエンドでfacebook/reactをずっと使っている。世界的には一部のエンジニアの間で流行っているのだが、国内だとqiitaのタグ等を見てもどうも少ない。みんなもっと使うべきだと思うので、宣伝かねて意見をまとめてみる。 複雑化するデータバインドに対する懸念 MVWのVに対して思いを馳せると、だいたい次のことに行き着く。すなわち、「ある構造体の入力に対して、必ず一意なビューを生成したい」 {items: [1, 2, 3]} を入力とすると、 1, 2, 3のli要素になってほしい。これは単純な例だから問題に成り得ないように見えるが、アプリケーション全体の状態を一つのjsonとして定義し、 そこから常に0から組み立てればアプリケーションの健全性が確保できると考えたことはないだろうか？ 現実の問題 UIのだいたいの状態は遷移で表現される。遷移の差分をプログラマが記述する。jQue

追記：冷静になるとこの記事なんか変なので、あとで修正します。参照しないように。 forやめろ -- LL Diver 2014 LT枠 forを使わないループ、簡単な例はみんな思いつくからいいとして、一番ややこしいやつ考えてたんだけど、やっぱり無駄にPromise酷使する例だと思った。 追記：この例はちょっとミスってた。正しいコードを末尾に載せる CoffeeScript # Serialized Sync Promise [1..100] .map (i) -> new Promise (d) -> console.log i; d() .reduce ((l, p) -> l.then p), Promise.resolve() JavaScript (function() { _results = []; for (_i = 1; _i <= 100; _i++){ _results

を晒すことで俺以外が試してくれるかもしれない！というのは置いといて、現在の知見です。 MV* React | A JavaScript library for building user interfaces Facebook製データバインディング。jsxという謎拡張子に目をつむれば未来を感じる設計。とにかく生DOM触りたくないという気概を感じる。 Welcome - Polymer Google製WebComponent。WebComponent使うならこれが有望株っぽい。 component/component MV* とはちょっと違うけどCSS/JavaScript/HTML まとめてライブラリにできる。JavaScript以外もライブラリに含む際は有望。 何がしたいかはt_wadaさんがまとめてくれたtogetterみてください。Web フロントエンド開発用パッケージマネージャ c

こんな記事があった。 My ECMAScript 7 wishlist | NCZOnline 大雑把にいうと、制限されたgetterがほしいという意見に記事のほとんどが割かれてる。 JavaScriptのデバッグ中、一番つらいものの一つに、未定義値にアクセスしたときにundefinedが代入されており、その結果が次のアクセスにならないとわからないという点だと思う。 o = { a: () => 1, b: () => 2, c: () => 3, d: () => 4 } f = o.e // ここでエラーにならない // 30行ぐらいのコードがあって忘れるとする f() // エラー これが辛い。これを回避するためにどんな仕様が必要か。 というわけで、自分がほしいものはなんだろうと考えてみた。(注意：この記事は上の記事の翻訳記事ではない) 僕自身があんまりES harmonyの議論追っ

vvakameさんに誘われて、どのAltjsが最強か殴りあう会合に参加してきた。 当日の資料やどんな様子だったかはこちら。 天下一altJS武闘会 - 資料一覧 - connpass 天下一altJS武闘会 - Togetterまとめ で、TypedCoffeeScriptについて発表してきた。自分の発表資料はこれ。 基本的な思想とコードを載せてるので、TypedCoffeeScript気になる人はここに載ってるとおりに遊んだらいいと思う。 小学生並みの感想 遅刻しました(完) 自分の発表は淡々としすぎてたのでもっとネタに走ればよかった。でも Altjsのモチベーションは型システムへ ぶっちゃけ構文拡張程度のAltjsはもう皆飽きてて、coffeeでお腹いっぱい感があった。動的型付けのaltjsは、他の動的型付け言語の変換ぐらいしかもう目がないような気がする。 で、後半のパネルディスカッシ

とりあえずThe Swift Programming Language読んで、実際に自分で少し書いてみた感想。 諸事情でAppleにiOSデベロッパーとしてお布施していたので Xcode6beta落として少し書いてみた。プロジェクトスケルトンをswiftで生成できるので、そのコードを眺めたりしていた。 ファーストインプレッション Immutable脳の人が設計したっぽい。 スクリプト言語っぽい構文に、型注釈。これはGoとシンタックス上の設計思想が似ているんだと思う。 基本的にImmutableな設計でありながら、オブジェクト指向を採用しており、Scalaっぽいマルチパラダイム感がある。Scalaの人は好きになりそう。 型推論のおかげで動的型付け言語触ってきた人にも抵抗がない感じになってる。推論のおかげで静的型付け言語が動的型っぽくみえるのはHaskellとかOCaml方面の雰囲気。 LLV

面白かったので紹介。 Mika Raento's Tech Blog: innerHTML vs appendNode vs DocumentFragment - Optimizing bulk DOM operations for mobile まあ正確に言うとDocumentFragmentの比較もあるんだけど、ベンチ上appendNodeと違いはないのでタイトルからは割愛。 結論 普通はappendNodeが速いけど、要素数を多くすると徐々にinnerHTMLに分がでてくる。均衡点は1000ノード。 ベンチマーク 上の記事から図を引用 これは自分の予想だけど、要素が多くなるにつれappendNodeのDOMとのネイティブのブリッジを経由するのがボトルネックになる。innerHTMLはパーサのコスト+appendNode一回分。 誰が気にするの テンプレートエンジン作者は気にすると良さ

土日使って気合で作った。 mizchi/dts-parser とりあえずlib.d.tsがパースできたのでだいたいのものはパースできると思う。 パース結果のファイルサイズが大きすぎてバイナリ扱いされてて笑った。 https://raw.githubusercontent.com/mizchi/dts-parser/master/lib.d.ts.parsed 使い方 こんな型定義dummy.d.tsが declare module Foo { export function fun(str: string):void; export function funfun(str: string):void; export var a:number, b: Object; export var c: Object; export class Bar { f():string; x: any; }

JavaScriptの悪魔的な振る舞いの一つにundefinedがあると思う。 javascriptには存在するundefinedと存在しないundefinedがあるし、それはつまり [undefined].length => 1 だ— 俺は平気だよ (@mizchi) 2014, 4月 22 JavaScript、[undefined].length => 1 で arr = []; arr[0] = undefined; だけど、このとき前者のundefinedと後者のundefinedは性質的には別物ですよ— 俺は平気だよ (@mizchi) 2014, 4月 22 もう一つの例として、 obj = {}; のとき obj[‘a’] = undefined したとき、for i in obj するとイテレータが一回だけ回る。obj[‘a’] = undefined しても キーは消え

ウェブアプリ、とくに滞在時間が長いSNSやゲームだと、なんかいろいろあって裏側で大量のデータを初期化しないといけないケースがよくある。 そういうときに誤魔化し方を考えてたりする。 保存先 localStorage IndexedDb WebSQL(deprecated) ネイティブ側のSQLite(ガワアプリ) 事前に初期化したいデータ マスターデータの類 月1で更新されるぐらいのやつ 更新頻度化が低く、かつ頻繁にアクセスするデータ たとえばショップのアイテム一覧とか UI関連の画像 汎用ボタンの画像とか、絶対に読み込むことがわかってる画像にprefetchかけておく 初期化したくないデータ 更新頻度が高いソーシャル関連 タイムラインとか 基本的に同期でとるけど、こういう場面の初期化でユーザーの操作はブロックしないでいいようにする ユーザーに閲覧させたくないデータ ゲームならモンスターのス

mocha-phantomjsは、その名前の通りmochaとphantomjsを使ってクライアントJSのテストができるヘッドレステストランナー。長く使ってるけど特に不満はないので使えばいいと思う。 metaskills/mocha-phantomjs https://github.com/metaskills/mocha-phantomjs スケルトンを作った クライアントJSのテスト書かれない理由として、環境構築の難しさがあると思う。 そこで怠惰な人たちの為にGruntでプロジェクト用スケルトンを作った。ごじゆうにおつかいください 使い方 git clone git@github.com:mizchi/client-app-skeleton.git cd client-app-skeleton npm install bower install grunt test 結果 Running

ってsinonのスタブ漏れを探しながら何度目かわからない感じにキレてた。 とにかく仕事でJSのテスト書くのが辛いので考えてみる。比較的JSのテストに慣れてる自分ですら辛いのだから、世界はもっと辛いに間違いない。サーバーサイドのnode.jsの話ではない。 JavaScriptで完結しない 構造がHTMLの構造と密結合している。装飾や位置、表示/非表示はCSSによって制御されている。 クライアントJSはHTMLと密結合しており、CSSからビューは影響を受ける。それらがネットワークの結果を受け非同期に振る舞いを帰る。その最終的な値を取得するのが難しい。 もちろんサーバーサイドだってDBやネットワークという外部リソースを扱うが、モックの手法が確立しているし、局所的な複雑度は、JSの方がはるかに多い。 言語仕様が貧弱 mochaやjsmineはrspecを真似てるけど、本質的にJavaScript

lodash.js moment.js mocha.js sinon.js chai.js es5-shim どんなにライブラリを導入しても、顧客との心の距離は一ミリも縮まりませんでした。

卒論書き上がったので環境を後続の人類のためにどうやって作ったかメモっておく。 環境はMacだったけどMacTeX以外たぶんLinuxでもいける。その指導教員に入れられたmacportsのTeXとTeXShopを窓から投げ捨てろ。というのが要旨。 MacTeX MacTeX - TeX Users Group http://tug.org/mactex/ 2014年において他の環境を入れる必然性は殆ど無い。これ一本。 iconv この時代sjisを扱うのは人生をムダにするだけなので、研究室の秘伝タレたるtexもまずutf8に変換。 その後 ¥ を \ に置換するのは必要だったけどオプションでどうにかなるのかもしれない。 iconv -s -f SHIFT_JIS -t UTF-8 hoge.sty > hoge.utf8.sty pandoc markdownをtexに変換できるツール。革命

JavaScriptでリアクティブっぽくとにかく短くシンプルにビューが書けるライブラリを作った。 mizchi/horn.js https://github.com/mizchi/horn.js 名前は背骨とか角とかっぽければ何でもよかった。 方針 Angularっぽいユーザー定義のdirective Knockout.js っぽいデータバインド Backbone風の軽量なAPI 依存はjQueryのみ とにかく短くビューのコンポーネントの塊を書けるのを目的とした。UnityとかFlashのコンポーネントに影響を受けている気がする。 HTMLのテンプレートによって、ビューがどういう属性を持つか決定される。それをJavaScriptから使う。 インストール bower install horn 使い方 こんな感じでテンプレートを用意する <div data-template-name="st

TypedCoffeeScriptでsuperの型検査書くかーと思って試してみたら、パースに失敗する。 class X f: -> class Y extends X f: (args...) -> super こんなの。 理由 Fork元のcoffeescriptreduxで実装されてない。 代替手段 親のプロトタイプをメソッドをapplyする class X f: -> class Y extends X f: (args...) -> X::f.apply @, args まあどうせそういう風に展開されるわけだけど、super使ってるコードをこういう風に置き換えるのめんどい。一応元のjashkenas/coffee-scriptを置換しつつ型を付けられる！ってのを目的にしているわけなので。 いつ実装されるの 作者が実装しようとした痕跡がある。ただ作者はこのプロジェクトに飽きつつある。