「後付の型システム」の活用について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にしか
Yarnファーストインプレッション - Qiita
Yarn とは 名前から yet another ... な雰囲気を漂わせてますが、 npm互換 です。(追記: 正確にはnpmの生成するpackage.jsonと互換とのことだった)。各所から node連中はまたツール増やしやがって！という雰囲気を感じるので、ここは明確にした方がいい。(techcrunchの記事とかそういう印象を与える書き方になってる) npm install 時のディレクトリ配置への介入 npm install 時のより賢いローカルキャッシュ yarn.lock ファイルでバージョン固定 yarn 環境下で yarn add, yarn install などを行った場合、 yarn.lock と package.json に同時に書き込み、 その環境で生成されたファイルは yarn なしでも動きます。つまり、yarn はより厳密に npm のバージョンを固定したい人向
MobXでReactのステート管理をする - Qiita
MobXはSimple, scalable state management を謳うステート管理マネージャ。 最近Hacker NewsやEchoJSで、にわかにMobXがフィーチャーされている。 3 Reasons why I stopped using React.setState — Medium この記事を読んで、そんなにいいもんかなと思い、試してみることにした。 mobxjs/mobx: Simple, scalable state management. カウンター 簡単なカウンターを作ってみる。一秒で1インクリメンタルされるやつ。 import ReactDOM from "react-dom"; import React from "react"; import {observable} from "mobx"; import {observer} from 'mobx-r
型なき世界のためのflowtype入門 - Qiita
http://qiita.com/mizchi/items/3bbb3f466a3b5011b509 で紹介したモダンJSスタックの上に、flowtype を導入して型をボトムアップに追加していくアプローチを紹介します。 なぜflowtypeか、そのゴールは 流行っているライブラリのみを組み合わせて使う場合や、バックエンドとの連携において型が十分に提供される環境なら、正直、flowtypeよりtypescriptでいいと思っています。flowtypeが力を発揮する環境は、既存のJSが大量に存在する環境や、railsなどの動的な型のフレームワーク環境で、静的な定義が抽出できない環境だと思います。 よほど品質が低いライブラリを使わないかぎり、バグはほとんど自分が記述したコードによって発生します。なので、まずは「自分が書いたコードのIFを明確にし、その静的なチェックを行なう」、というのを最初の目
Reactサブセット実装の preact で、ライフゲームのアニメーション書いて使い方を確認した
厳密なサブセットかは要確認な気がするが、まあそういうコンセプトのライブラリがある。 で、使ってみた。 preact とは reactのサブセット実装。reactと比較してかなり小さい(圧縮して3kb)。contextとかpropTypesとかはない。いらないと思う。 reactとの互換をもたせるレイヤーは本体を小さくするために外部パッケージに切り出されている。 https://github.com/developit/preact-compat コード量が少ないので、迷ったら元のコード読めるという安心感がある。 個人的にReactは過剰な抽象化の迷宮だと思っていて、あんまり読みたくない。 最初に ライフゲームのアニメーションしたかったわけで、ライフゲームを書きたかったわけではないので、ライフゲームのロジック部分はnpmから適当に持ってきた。 動いてるコードはここ http://mizchi
babel-plugin-typecheck を使って flowtype 文法で書かれたJSをランタイムチェックする - Qiita
https://github.com/codemix/babel-plugin-typecheck を使ってみた。 これは何 babelでflowtypeの構文を使って型エラーのランタイムチェックを行う。静的解析ではない。（自分がドキュメントから見落としてるだけで静的解析を行う方法がある？） 興味を持った理由 既存コードに対してtypescriptを導入するのは大変 flowtypeは既存コードからの乗り換えは簡単だが、型チェッカの挙動が未だに不審 コード上のドキュメントとしての型 + ランタイムチェックというアプローチなら十分では ESdoc等で型を書いてもあくまでドキュメント上の指定だが、flow syntax とこれなら実行可能という点が大きい。最悪動かなくてもランタイムチェックを外せば良い。型指定はドキュメントとして残る。 Install すでにbabel環境があることを想定 np
redux への 不満を解消する為に, flumptというFlux実装を作った - Qiita
名前はダークソウルのフラムト(frampt)から。FLux Minimum なんたらかんたら。 なんかTwitterで色々言ってたら naoyaさんにまとめられたので、ここに僕の考えを詳しく書いておく。 mizchi の Redux 考 - Togetterまとめ やりたかったこと 基本的なアイデアは、stateをpushする方式(setStateみたいな)だと非同期間で参照したときの値がズレて非同期の終わる順番次第では状態の遷移ステップが壊れてしまう可能性があるんだけど、前のstateをとって次のstateを返す非同期をキューに並べて順に実行することで、トランザクションみたいなものを保証することができるだろう、というもの。 軽量(pubsubインターフェースはEventEmitterそのまま) 複数の状態更新関数の待ち合わせ reduxで感じた不満の解消 TypeScriptフレンドリー
今一番JSで熱いゲームエンジン、RPGツクールMVのランタイムコードを読んでみた - Qiita
一昔前にCanvasが実用段階になった頃、JSのゲームエンジンが大量に出てきたことがありました。それらは大抵DOM/CanvasのFallbackを持っていたのですが、今現在の状況は、実際には非効率なメモリ消費やモバイルのブラウザのフラグメント化で実用に足るものがなかった、という辛い現状があります。 そんな中pixi.jsという描画ライブラリが台頭してきました。このエンジンは webglとcanvasの fallbackを持ち、(いくらかのバグはありつつも)DOMを切ったことで現実的なパフォーマンスの課題をクリアできるのでは？という期待感が高まっています。 Pixi.js - 2D webGL renderer with canvas fallback http://www.pixijs.com/ そして 2015年、RPGツクールMVが発表され、ブラウザ吐き出し対応がアナウンスされました
仮想DOMで魂が震えてから一年、仮想DOMとFluxの今 - Qiita
なぜ仮想DOMという概念が俺達の魂を震えさせるのか から一年、みなさまどのようなフロントエンドをお過ごしでしょうか。 僕はひたすら過去資産をリファクタしています。 需要の雰囲気 色んな所に書きましたが、去年僕が仮想DOM AdventCalendar をやったのは、「僕自身がproductionで使いたい」ので、「Reactまあいいよね」的な雰囲気を作って外堀埋めるのが目的でした。そして、その目的はおおよそ果たされたと言ってもいいでしょう。ご協力ありがとうございました。 僕自身はKobito for Windows でReactを使ってみて、そのノウハウを公開したり、今年前半は色々とアウトプットをしていましたが、後半はSpecificなアプリケーションドメインを記述することが多くて、あまりアウトプットする内容がなくなってました。 取り敢えずは、新規のプロダクトなら採用してもよい、という雰囲
ES async/awaitを全力で使ってみて発見したイディオム - Qiita
// 注意: 最初のバージョン、async function がundefinedを返すと思い込んでて、色々間違えてた 手元の趣味コード(諸事情により未公開)に向けて全力で適用してみた結果学びがあった。以下babel。 事前に確認 async/await は Promise と Generator の糖衣構文である await は Promiseのインスタンスの式を与えると(見た目上)停止する await するには async functionで囲う必要がある async function は必ず非同期で実行され undefinedPromise を返す 以下イディオム とりあえず実行したい (async () => { await new Promise(done => { setTimeout(1000, done); }) })(); 解説: async ブロック作ってからの即時実行
Reactでサーバーサイドで生成したHTMLに対してDOMを初期化せずにReactComponentとして状態を更新する - Qiita
この記事は VirtualDOM Advent Calendar 2014 - Qiita のネタが切れた時にどこからか指定されるやつです。中の人なんであんまり行儀悪いことすると怒られるんだけどな！ やりたいこと UXとSEOのためにイニシャルビューはサーバーサイドで生成し、再描画時にクライアントで同じテンプレートから生成するも、一旦画面を捨てて再構築するのを避けたい。 具体的には、サーバーサイドで何かしらの方法(nodeやreact-railsを想定)で実行して生成されたReactのId付きのDOM React.renderToString(Component({})) して生成したreactId付きHTMLに対して、再描画せずにReactを適用できるようにする(イベント注入含む) 手法 reactのid付きDOMはこんなもの。 > React.renderToString(React.
npm v3.x 試してみた & 注意する点 - Qiita
ふと思い立って npm install -g npm@3 した。3.1.2 は VERY BETA とのこと(ニュアンスがよくわからん。アルファとの対比なのか、アルファ相当なのか) ので、そのうち出るでしょう。 node_modulesのフラットな展開 npm@3 だとnode_modulesの依存がパッケージ間のバージョンが衝突しない限り、トップレベルのnode_modulesにフラットに展開される。これによって同一のモジュールを依存ツリー間でモジュールが重複した時にnode_modules以下のサイズが膨らむのを抑えることができる。 衝突した場合はそのモジュールの子のnode_modulesに格納されて衝突は回避される。 気になるrequireの仕様 とはいえ、requireの仕様が変わってるわけじゃないので、トップレベルから子だけじゃなく孫モジュールも直接requireできてしまう。
Watchifyでbrowserifyを差分ビルド - Qiita
https://github.com/maxogden/wzrd はアクセスする度に変更を吐き出すのだが、watchify は差分を管理してくれる。 reactとか無駄に巨大なんで、require('react') しただけで1.2秒ぐらい待たないといけなくなって辛かった。そういう問題を解決できる。 簡単な使い方 npm install -g watchify これだけ。-v で verboseみないと動いてるのかよくわからなかったので付けたほうがよさそう。 某アプリのビルドが3.8秒から0.3秒になって最高 自分の使い方 一旦すべてをjsにして吐き出す。 gulpで src/**/* -> lib/**/*.js lib/index.js を基準にbrowserify する gulp-watchify を使った。 arda-starter-project では毎度のビルドの遅さが問題にな
browserifyでビルドした時のgitのコミットハッシュを埋め込む - Qiita
$ npm install -g browserify envify $ broserfy -t [envify --GIT_HASH $(git rev-parse HEAD)] index.js > bundle.js Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up
リアルタイムウェブな観点からElixir / Phoenix について - Qiita
ここ最近、 [翻訳] Elixir - 次に来る大物Web言語 - Qiita とか 超高速なJSON APIをElixirフレームワークのPhoenixでビルドしてテストしよう | POSTD を読んで気になっていたので、勉強していた。 前提: 自分はシングルページアプリケーションに特化したフロントエンドエンジニアであり、サーバサイドのプロダクション運用にはそこまで強くない。あとこれはここ2日の勉強した日記でもあり誤解や勘違いも多々あると思う。 リアルタイムウェブアプリケーションのためのサーバー Railsの次の時代、リアルタイムウェブの為のウェブフレームワークがあるとしたら、次のような特長をもつと思う。 HTTP, HTTP/2. WebSocket等のプロトコル対応と抽象化 JSON APIに特化 認証系 キャッシュ管理 Viewに関心がない リアルタイムウェブは、その言葉をどう定義
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
vk - CoffeeScript DSLでVirtual DOM をテンプレーティングする - Qiita
ワ～スゴ～イ 実態はただのReactのラッパーです。 開発経緯 その昔、coffeekupというテンプレートエンジンがありまして、開発が止まってしまったのですが個人的には結構気に入ってたテンプレートエンジンでした。ただのDSLとしてDOMを生成する、という設計です。 mauricemach/coffeekup で、reactはjsxというAltjs泣かせな独自シンタックスを持っていて、APIを直接叩いてもいいのですが、どうせなら、ラップしたい。Virtual DOM は DOMとJSが密結合することを厭わない設計思想で、今こそCoffeekup的なDSL設計が生きるのでは？と思い、さっくり移植しました。 コンセプト実装的なノリで作ったので、まだコンポーネントの埋め込みとかは細かいのは対応してないです。 JSXのつらさ 次のようなDOMを出力したいとします。
React0.13.0-beta.1でのComponentのES6 classでの継承とmixinが使えない理由 - Qiita
(訳) 残念ながらReactではES6 class向けにmixinをサポートするつもりはありません。これはJavaScriptの文法的なコンセプトの目的を台無しにしたくないからです。 (訳注: JavaScriptでは)普遍的なmixinの実現方法がありません。実際、いくつかのmixinをサポートする方法が、今のES6の仕様からはドロップしています。いろんなライブラリが様々なセマンティクスを持っています。私達はES6のクラスにmixinを実装するためにはあなたができることは一つだけであるべきだと考えています。Reactは、(訳注: 他のライブラリと違って)なにもしないことを決めました。 React v0.13.0 Beta 1 | React http://facebook.github.io/react/blog/2015/01/27/react-v0.13.0-beta-1.html
Promiseに関するパターンや命名規則 - Qiita
やや自己流含む。 getXxx/fetchXxx getXxxは同期、fetchXxxはPromiseということにしている。とくに非同期の取得系はfetchということに決め打ってる。 GETリクエストであることを明示したいときにややこしいという問題はあるが、そのケースは少なく、JS内で同期/非同期を明示したいことの方が多い。 例: 非同期の副作用系はput/post/sync/send/uploadとかそのあたりを適当に使う。 Promise( (done, reject) => {..}) 恐らく仕様的に正しいワードは fulfill, reject なのだが、fulfillはタイプ数が妙に多いのと、llが多くタイポしやすく、またタイポが発見しづらいので、自分は慣習的にdoneを使っている。 追記: fulfillよりもresolveの方が仕様に沿ってるっぽいhttp://people.
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
