「後付の型システム」の活用についてFlowtypeとReduxから考える - Qiita
FlowtypeやTypeScriptは静的解析によって事前に型違反を検知することができる。JavaScriptは動的型付けの言語であり、本来はランタイムにしか型が出現しない。 FlowtypeとTypeScript、ともに「それ自身がランタイムではない」というのが特徴であり、一種のLintツールだと言うことができる。ランタイムではないがゆえに、嘘の事前条件を与えることでそれらを騙すことができるし、自らに有利な制約を追加できるという柔軟性を持つ。 JavaScriptの現実においての型 例を出そう。 type MyUtil = { foo(v: string): number; }; const util: MyUtil = new HogeUtil(); util.foo(1) //=> type error HogeUtil は何かしらのユーティリティ関数の詰め合わせだが、fooにしか
react-dispatcher-decorator で PubSub な Flux - Qiita
コンセプト 昔作ったArdaのPubSub部分をDecoratorで表現した。https://github.com/mizchi/arda EventEmitterバケツリレースタイル/フレームワークなしで小さくFluxする - Qiita React の Context を使って Flux を実装する - Qiita この2つを使ってバケツリレーを隠蔽することで、デコレータでPub側とSub側を自然に繋げられるようにした。 hokaccha/react-micro-container: Micro framework for React も多少参考にした。 Example import React from "react"; import {dispatcher, subscriber} from "react-dispatcher-decorator"; // This compone
Elm v0.17の時点の学習メモ 1日目 - Qiita
モチベーション Evan Czaplicki「脱FRP。またはThe Elm ArchitectureからSignalを消した件」 - 以下斜め読んだ内容 を読んで、関数型のおもちゃから、かなり実用指向な舵取りをしているようにみえ、現時点でどれぐらい使い物になるか試してみよう、という気になった。 いつもの言語(JS)から距離があるので、徳が積めそう。 前提: 定期的にハローワールド程度はどう書くのか、ということは調べていたので、まったくの初見ではない。 読んだ資料 http://guide.elm-lang.org/ 基本的な概念 http://www.elm-tutorial.org/en/ ユースケースごとの例 https://qiita.com/tags/elm 実際どういうコードが書かれているかの雰囲気を見ていた guide~ は適当に読み飛ばした部分が多いので、詰まったらまた読み
jQueryで楽になる部分、楽にならない部分、顧客が本当に必要だったもの - Qiita
俺も昔はお前のような jQueryスパゲッティジェネレーターだったのだが、膝にReactを受けてしまってな… 基本的な方針 とくにライブラリ設計者において、小さなモジュールを単機能で分割する以上、ライブラリ設計者は可能な限り依存を減らすことを求められます。node環境ならdependency hellの回避のため、フロントエンド環境ならファイルサイズを減らすためです。 ライブラリ設計者ならずともコードのポータビリティを維持するため、できるだけライブラリに依存しないコードを書くのが望ましいです。 Githubみてる限り、最近書かれるJSのライブラリの多くはjQuery非依存です。ユーザーから見る限りは、jQueryElement渡すかHTMLElement使うかぐらいの違いですけどね。 また、Angular, React等のSPAをスクラッチで設計する場合、気づいたらjQueryを使っていな
Nightmare v2(Electron) でブラウザ上でES2015のコードを個別にrequireしてユニットテストを書く - Qiita
Nightmare v2(Electron) でブラウザ上でES2015のコードを個別にrequireしてユニットテストを書くNightmareElectron 自分の開発環境では, nodeで単体テストと分離してモデル層を抽出出来たが、e2eほどではないがブラウザ上でテストしたいコードというのは結構ある。モーダル制御とか、ブラウザ上のイベントに依存する奴とか。 それらを Nightmare でテストするアプローチを紹介する。 概要 Nightmare はヘッドレステストランナーとそのDSLを提供する。v2でランナーがphontomjsから Electronになった。 コードはbabel/commonjsで書かれており、本番環境でJSは1つにまとまっているが、Electron の nodeIntegration を有効化して走らせることで、ビルド前のコードを個別にrequireできる。グロ
babel-plugin-typecheck を使って flowtype 文法で書かれたJSをランタイムチェックする - Qiita
https://github.com/codemix/babel-plugin-typecheck を使ってみた。 これは何 babelでflowtypeの構文を使って型エラーのランタイムチェックを行う。静的解析ではない。（自分がドキュメントから見落としてるだけで静的解析を行う方法がある？） 興味を持った理由 既存コードに対してtypescriptを導入するのは大変 flowtypeは既存コードからの乗り換えは簡単だが、型チェッカの挙動が未だに不審 コード上のドキュメントとしての型 + ランタイムチェックというアプローチなら十分では ESdoc等で型を書いてもあくまでドキュメント上の指定だが、flow syntax とこれなら実行可能という点が大きい。最悪動かなくてもランタイムチェックを外せば良い。型指定はドキュメントとして残る。 Install すでにbabel環境があることを想定 np
JSDOMとReact.addons.TestUtilsでReactをヘッドレスにテストする - Qiita
JSDOMはnode環境でDOMをシミュレートするやつ。React.addons.TestUtilsはReactに同梱されているテストツール。この2つがあわさり最強に見える。 今作ってるライブラリのために、しばらくブラウザ使わずにテストしてたけど、ブラウザ立ち上げる必要なくて非常に快適。これ https://github.com/mizchi/arda/tree/master/test JSDOM、昔はとにかく不安定な印象だったけど、最近はよくできてる印象。見なおした。 コード # globalにdocumentとwindowを定義することで、DOM環境を参照できるようにする # 必ずReactの前に読み込むこと jsdom = require('jsdom').jsdom global.document = jsdom('<html><body></body></html>') # gl
redux への 不満を解消する為に, flumptというFlux実装を作った - Qiita
名前はダークソウルのフラムト(frampt)から。FLux Minimum なんたらかんたら。 なんかTwitterで色々言ってたら naoyaさんにまとめられたので、ここに僕の考えを詳しく書いておく。 mizchi の Redux 考 - Togetterまとめ やりたかったこと 基本的なアイデアは、stateをpushする方式(setStateみたいな)だと非同期間で参照したときの値がズレて非同期の終わる順番次第では状態の遷移ステップが壊れてしまう可能性があるんだけど、前のstateをとって次のstateを返す非同期をキューに並べて順に実行することで、トランザクションみたいなものを保証することができるだろう、というもの。 軽量(pubsubインターフェースはEventEmitterそのまま) 複数の状態更新関数の待ち合わせ reduxで感じた不満の解消 TypeScriptフレンドリー
Reactに最適化したテンプレートエンジンを作り始めた - Qiita
Reiny, 名前の由来は、一昨日の木曜日に作り始めて、その日雨が降ってたから。 最近react-jadeに不満を持ってて、自分はコンパイラというかプリプロセッサを作るノウハウはあるので、だったら自分で作ればいいじゃん、といった感じで作り始めた。(typed coffee を作り直すためのAST操作の勉強も兼ねてた) 何ができるか 今これが動いてる - let i = () => {}; div(hoge='fuga') { backgroundColor = 'red' } // unicode span( key="--🐑--" ) // ref with & span&foo() // for syntax ul for i in @items li(key=i) = i // if syntax if false a hoge fuga aaa // inline express
markdownを直接ReactElementに変換するコンパイラを書いた - Qiita
mizchi/md2react デモページはここ md2react playground 作った目的 巨大なmarkdownをリアルタイムプレビューする際、ただの文字列をinnerHTMLとかで更新したりしていると、更新の度にパース処理が走ってどんどん重くなってくる。 React には dangerouslySetInnerHTML というプロパティがあって、一応それっぽい感じで差分管理してくれるが、名前の通り色々怪しい挙動をする。 なのでmarkdownのASTから直接ReactElementを吐けるようにするとReactの差分計算で描画高速化されて良いのでは、というわけで作った。これはMarkdownPreview界にとって救いとなるであろう。 どこで使う目的かはお察しください 使い方 global.React = require('react'); var md2react = re
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
