みなさん、 lodash で消耗してますか？ 私は消耗しています。 なぜ lodash で消耗するかというと、とにかく思考停止でインストールされ、 node_modules 下で大量に重複します。サイズが大きいlodashが複数バンドルされてビルドされると、重篤なパフォーマンス上の問題を引き起こします。 lodash には実装上の問題もあり、異様に丁寧に、そして富豪的に作られており、その結果ビルドサイズが無駄に大きいです。丁寧に作られて入るのですが、現代のフロントエンド水準や一般的なポリフィルと噛み合っていません。というわけで、常々やめたいと思っています。 ちゃんとES201xを追ってる人からすると、ほとんどの lodash のメソッドは不要に見えるはずです。本エントリは、思考停止で lodash で実装しようとする人に、ちょっと考え直しては？ と投げつける用の記事になります。 現代におい

import UniversalRouter from 'universal-router' const routes = [ { path: '', // optional action: () => `<h1>Home</h1>`, }, { path: '/posts', action: () => console.log('checking child routes for /posts'), children: [ { path: '', // optional, matches both "/posts" and "/posts/" action: () => `<h1>Posts</h1>`, }, { path: '/:id', action: (context) => `<h1>Post #${context.params.id}</h1>`, }, ], }, ] co

どう考えているか、というのを聞かれたので、記事に起こしておきます。個人の意見です。 Prettier を使う 気づけばコードの整形を人間がやる時代は終わりました。 細かいコーディングスタイルでレビューの時間を取るぐらいだったら、一貫した自動整形ルールを適用すべきです。 人によっては細かいこだわりがあって prettier の規則が気に食わないかもしれず、僕も最初はそうでしたが、Atomで保存する度に自動整形を走らせる prettier の強烈な開発体験によって、最終的にそれらのこだわりを全て捨てることが出来ました。 生産性を求めるなら、現時点では最優先で導入すべきものです。 React.createClass を使わない v16 で削除されたのでいわずもがな。 同様に、 createClass でしか使えなかった mixin 周辺機能も丸ごと deprecated です。 「可能な限りは」

注意。実装はまだないです。思考実験的な意味合いが強いです。 持論 Reactやredux/Rxのデータモデリング手法の発達で、ツリー構造の末端に渡すまでのデータモデリングが主戦場になりつつあります。これはロジックを注入する部分と、プレゼンテーショナルなものが明確に分離されてきたことを意味します。 僕は個人的に、 GUI にまつわるものは、本来GUIで設計したい、という気持ちがあります。そう、僕が作りたいと思っているのは、悪名高きホームページビルダーです。 とはいえ、プログラミング抜きでxxxできる！というものではありません。むしろプログラミングとGUIを横断するイメージで、Unity や UnrealEngine のような開発環境を想定しています。 今やりたい理由 ブラウザの仕様が安定してきた 色々と使えるパーツが増えた JS で複雑なツールを作れるようになり、インブラウザな開発ツールが作

ふとログインすると beta 版UIってのが使えた。完全に dev.to 意識してて笑った。 実際には自分が残してきたロードマップや、Component が使われているのであろうのがわかって、そうそうこれがやりたかったんだよって感じで、とはいえまだ改善点がたくさんって、今の中の人達もわかってると思うけど、元中の人として dev.to ぐらいやるにはどうすればいいってのを残しておきます。 わかる変更点 CSSの脱bootstrap色が強くなった トップ画面が、ユーザーごとのカスタムフィードから beta版 の人気の投稿が主になった 元々そういう目的で企画を起こした記憶がある… フレンドフィードもうあんまり使われてないよね クエリが重いフレンドフィードより、静的にキャッシュできるランキングがトップにあるのはチューニングしやすい 改善案 やや無理難題だったり、中の都合も察してるけど、できるだけ目

メインの開発者として、備忘録を残しておく。 どんなものか試したい人は、 https://mizchi.github.io/kobito-oss/ で、IndexedDBの許す5MBぐらいまでは試せる。 一応言っておくと、これは僕が退職するんでOSS化ってわけではなく、元々あった計画の前倒しです。時期が早まったのはある。 以下、どのようにコードを読むか。 念頭に置くこと 2年前 の技術選定のスタック Mac版Kobitoと仕様が違う。Kobitoと同期しない、Inboxという仮グループがある。 mizchi/arda electron 以前の atom-shell 時代の互換コードが一部残ってる 細々とバグ対応はしつつ、あんまり依存パッケージのメンテ出来てなかった 公開にあたって、個別のタスクの綺麗さより、ビルドできるの優先した とりあえず yarn で固定して yarn upgrade-i

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 のバージョンを固定したい人向

暇というか日常的にやってること https://news.ycombinator.com/ と http://www.echojs.com/ と http://b.hatena.ne.jp/efcl/ をフィードリーダーに突っ込んでいて、面白そうなのをメモっておく 暇なとき 日頃メモってたライブラリの試し切りをする 面白かったら紹介記事を書く 多少やる気リソースが多めだと新しい言語(最近はRustかElixir)の勉強を進める http://codepen.io/ で面白い動きするやつのコードを探してコード読む とくにCodePenがオススメで、割とゲラゲラ笑いながら読めるやつが多いので楽しい。CodePenのテクニックはそのまま自分の業務に持ち込むと悪目立ちするので控えているが、Webでもこういう演出ができる、と頭の片隅にいれておくことで、いずれ何かに役立ったりする。たとえば昨日読んだ奴

前提 MacOSX HHK TypeS(無刻印) => ErgoDoxEZ(無刻印) Dvorak歴半年程度 もともと無刻印ユーザーなので、レイアウトが動的に切り替わるのは違和感がない。 雑感 セパレートはやはり肩こりに効く感じがある。これが収穫大。(これだけだったらKinesisでもいいんだが) Mac/Dvorak/ErgoDoxEZという組み合わせで、あんまり参考になる設定がないので、とりあえず毎日ガチャガチャキーマップを書き換えている。デフォルトキーマップはかなり癖があるので、書き換えないと辛い。 生産性は使い始めた初日で30%程度。 3日経過で60%。 一週間経過(今)で80%。 まだまだ伸びしろあるはず。 周辺ツールの設定 KarabinerでDvorakに設定したが、多段変換される都合でErgoDoxの設定が複雑になるので、KarabinerでQwertyのプロファイルをもう

フロントエンドとしては絶対に避けて通れないWASM、そろそろエッジ環境なら試せるツールが揃ってきたということで、手を出してみた。 自分がどうしてもローレベルに弱いので、たぶん色々間違ってるんだけど、識者各位は指摘お願いします。 現在の仕様はここ https://github.com/WebAssembly/spec Chrome Canary と Firefox Beta で動作可能 WASMのゴール asm.jsに比べてサイズが小さく高速にデコード可能なバイナリフォーマット 将来的な目標として、DOMアクセスとそのGCインテグレーション これが達成されれば、ブラウザにおいて JS がファーストプライオリティな言語という状態ではなくなる とはいえ既存の資産が多いのでなくなることはないだろうが wasmのスペック自体は小さいのでおそらくブレようがないが、DOMの実装とGCは各ベンダごとに別々

問題意識 eslint-babel とか使ってると コマンドラインで渡すと, 都度 babel の初期化に引っ張られて遅い 監視するファイルが多くなるとパースだけでも重くなりそう --cache オプションあるけどbabel の問題は解決しなさそう これが実現出来そうな gulp-eslint は1件ずつlintする方法がなかった 解決策 gulp eslint を生で使って自分でタスクを書いた。プロセスが温まったままなので、babel の初期化は最初の一回だけ。 var gulp = require('gulp'); var CLIEngine = require('eslint').CLIEngine; var fs = require("fs"); var linter = new CLIEngine(); var formatter = linter.getFormatter();

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 春ですね！人の配置がリファクタリングされ、コードもリファクタリングの季節です。 では僕がここでモダンなJavaScriptとES2015の利点を語る役をやるので、みなさんはチームを説得する役をやってください。 JavaScriptの歴史 まず最初にJavaScriptの歴史を踏まえることで、今学ぶべきものとその理由を確認しましょう。 なぜ2016年の記事でES2016ではなく、ES2015なのか、と疑問に思った方もいるかもしれません。それは、ES2015がただの年次アップデートではなく、これから始まる毎年のメジャーバージョンアップの起点

'use strict'; // nightmare const Nightmare = require('nightmare'); const path = require('path'); const TEST_HTML_PATH = "file://" + path.join(__dirname, "test.html"); // create global.browser = null; let startBrowser = function * (){ global.browser = Nightmare({ show: false, nodeIntegration: true }); yield browser .goto(TEST_HTML_PATH) .wait('body') .evaluate(() => { require("babel-register"); //

Qiita:Teamに投げた社内ドキュメントだったけど、特に問題ないのでQiitaにも投げる。 前提として browserify-rails とbabelify が導入されている状況を想定してる。 基本方針 新規コードはES2015で書く 本番はbrowserify(-rails)でコンパイルする。 単体テストは node 環境下で走らせる テスト環境下では jsdom で window, document をモックする 単体テストでは ブラウザ特有の挙動はテストしない 裏側の環境(browserifyやspec-helper)は難しくして良いが、利用者からみえる範囲は複雑にしない(npm install; npm testで走る) Universal JavaScript に寄せることでコードのポータビリティを上げる 事前準備 browserify-railsを導入する。 .babelr

名前はダークソウルのフラムト(frampt)から。FLux Minimum なんたらかんたら。 なんかTwitterで色々言ってたら naoyaさんにまとめられたので、ここに僕の考えを詳しく書いておく。 mizchi の Redux 考 - Togetterまとめ やりたかったこと 基本的なアイデアは、stateをpushする方式(setStateみたいな)だと非同期間で参照したときの値がズレて非同期の終わる順番次第では状態の遷移ステップが壊れてしまう可能性があるんだけど、前のstateをとって次のstateを返す非同期をキューに並べて順に実行することで、トランザクションみたいなものを保証することができるだろう、というもの。 軽量(pubsubインターフェースはEventEmitterそのまま) 複数の状態更新関数の待ち合わせ reduxで感じた不満の解消 TypeScriptフレンドリー

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? なぜ仮想DOMという概念が俺達の魂を震えさせるのか から一年、みなさまどのようなフロントエンドをお過ごしでしょうか。 僕はひたすら過去資産をリファクタしています。 需要の雰囲気 色んな所に書きましたが、去年僕が仮想DOM AdventCalendar をやったのは、「僕自身がproductionで使いたい」ので、「Reactまあいいよね」的な雰囲気を作って外堀埋めるのが目的でした。そして、その目的はおおよそ果たされたと言ってもいいでしょう。ご協力ありがとうございました。 僕自身はKobito for Windows でReactを使って

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

土日でreact-railsとturbolinksを勉強してみた成果です やりたいこと 画面遷移するときは<div id='content'></div> の中身だけ入れ替えて、pushStateで行き来できるようにしたい reactを使ったリッチなページでも、イニシャルロードやSEOの為にサーバーサイドでレンダリングしておきたい サーバーサイドレンダリングした要素を破棄することなくReactで初期化してsetStateでガンガンViewを書き換えたい 結果どうなったか サーバーサイドでReactComponentをレンダリングしてクライアントのReact.renderで初期化情報を揃えて引き継ぎ どんな画面でもapp.component.setState({})が反映されて最高 TurbolinksでReactComponentをマウントしたルート要素だけ入れ替え その為にTurboli

npm install babel -g experimentalオプション必須なので コンパイルは babel -e foo.es6 > foo.js みたいな感じ 適当に試してみた。 import "babel/polyfill"; let wait = function(n: number){ return new Promise(done => setTimeout(() => done(n), n)); }; let main = async function(){ await wait(50); console.log('await done'); } // async promise nomally wait(100).then(() => console.log('promise normaly done')); // await main(); 最初awaitブロックがa

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