lodash やめ方 - Qiita
みなさん、 lodash で消耗してますか？ 私は消耗しています。 なぜ lodash で消耗するかというと、とにかく思考停止でインストールされ、 node_modules 下で大量に重複します。サイズが大きいlodashが複数バンドルされてビルドされると、重篤なパフォーマンス上の問題を引き起こします。 lodash には実装上の問題もあり、異様に丁寧に、そして富豪的に作られており、その結果ビルドサイズが無駄に大きいです。丁寧に作られて入るのですが、現代のフロントエンド水準や一般的なポリフィルと噛み合っていません。というわけで、常々やめたいと思っています。 ちゃんとES201xを追ってる人からすると、ほとんどの lodash のメソッドは不要に見えるはずです。本エントリは、思考停止で lodash で実装しようとする人に、ちょっと考え直しては？ と投げつける用の記事になります。 現代におい
俺が考えた最強の Reactのステートレスコンポーネントの書き方 - Qiita
最近自分はこう書いてるという例。意見が欲しい。 この記事に redux は出てこない。 参考: https://qiita.com/mizchi/items/bcb1aef8d1f14f8d0b4a 構成要素 React flow styled-components recompose 以下 SFC = Stateless Functional Component /* @flow */ import React from "react" import styled from "styled-components" import pure from "recompose/pure" type Props = {| value: string |} export default pure(function Example(props: Props) { const { value } = p
2017末時点での React Component 設計のベストプラクティス - Qiita
どう考えているか、というのを聞かれたので、記事に起こしておきます。個人の意見です。 Prettier を使う 気づけばコードの整形を人間がやる時代は終わりました。 細かいコーディングスタイルでレビューの時間を取るぐらいだったら、一貫した自動整形ルールを適用すべきです。 人によっては細かいこだわりがあって prettier の規則が気に食わないかもしれず、僕も最初はそうでしたが、Atomで保存する度に自動整形を走らせる prettier の強烈な開発体験によって、最終的にそれらのこだわりを全て捨てることが出来ました。 生産性を求めるなら、現時点では最優先で導入すべきものです。 React.createClass を使わない v16 で削除されたのでいわずもがな。 同様に、 createClass でしか使えなかった mixin 周辺機能も丸ごと deprecated です。 「可能な限りは」
ReasonReact を使ってみる - Qiita
module App { let make = (_children) => { ...ReasonReact.statelessComponent("App"), render: (self) => <div> { ReasonReact.stringToElement("Hello") } </div> }; } /* mount */ ReactDOMRe.renderToElementWithId(<App />, "root"); このコードを見る限り、ReasonReact は make という関数を見つけて React.createElement 相当の展開をする。 文字列は ReasonReact.stringToElement("Hello") という感じで埋める。多少面倒くさい。 名前空間の話 ここで、初歩っぽい話をするが(自分はocaml詳しくないので、こういうタイミ
Hypernova/Webpacker/Turbolinks でSSRできてSPA風に動くスケルトンを作った - Qiita
対象 Rails だけどSPAっぽく画面遷移したい SEO担保しないといけない 新規設計の参考 jQuery まみれの状態からこれと同等のことをするのは、不可能じゃないけど難しいです。 単にどう導入するか知りたいだけなら https://github.com/mizchi-sandbox/packnova/commit/447a91ea3a706c0bb0aac8570d1fbbaf6c9710f1 のコミットで 目指したモノ 最小限の設定で Rails エンジニアでもメンテ出来るSSR/SPAアプリの土台。 ただし土台をハックし始めるとその限りではない。。 スタック webpacker でコンパイル 画面遷移は hypernova-react/turbolinks で自動再マウント ルーティングはRails側に寄せてます。なので react-router は入ってないです。 入れる選択肢
sourcemap を無効化して webpacker の production build を 2000% 速くする - Qiita
TL;DR プロダクションで sourcemap が有効化されていたので、関連オプションを切って回ったら 2000% 高速化した。 問題 NODE_ENV=production bundle exec rake webpacker:compile が致命的に遅かった。 エントリーポイントが17個でビルド時間が合計680s という有様で、プロダクションとはいえ デプロイ を11分遅くさせるのは、ビジネス的に致命的な感じだった。 調査 さしあたり、いつもの経験則で uglify の mangle オプションが遅いんだろう、と思って、webpacker のソースの設定を見に行ったら、うん？？？？となる設定をみつけた。 this.plugins.set('UglifyJs', new webpack.optimize.UglifyJsPlugin({ sourceMap: true, compre
AMP/PWA をどこで/いつ使うか - Qiita
某所で使った資料の公開版 用語整理 PWA: ネイティブアプリのようなUXを提供するための機能群 SPA: JSで遷移するシングルページアプリケーション AMP: 後述 PWAMP: AMPで流入させてPWAを起動する形式 MFI: モバイルファーストインデックス いまさら聞けないPWAとAMP アメブロ2017: Isomorphic Web Appの進化編 AMP とは イニシャルビューのためのHTMLの特殊なサブセット GoogleにホワイトリストされたHTML属性しか使えない GoogleにホワイトリストされたJSプラグインしか使えない CSSはHEADに全部書く AMP仕様を満たすと、Googleがキャッシュして、モバイルの検索流入ではそのキャッシュを使う HTTPS必須 必ずしも全ページをAMPに対応する必要はない PWA: ServiceWorker の機能 リソースの先読み
Expo ではじめる ReactNative 開発環境 - Qiita
某所で調べた資料 Expo とは ReactNative上で、JS のみで ios/android アプリを作る開発/ビルド環境。ネイティブプラグインが使えないという縛りを受け入れることで、アプリをQRコード経由で簡単に公開したり、共有したりできる。 ios/android のコードを書かなくていい、というか一切書けない。 参考: expo.ioを使ってリアルタイムにReact Nativeアプリを開発する http://amagitakayosi.hatenablog.com/entry/2017/04/18/120000 Hello World $ npm install -g exp $ exp init my-native-app $ exp start # 開発用ビルドの開始 $ exp build:ios # 本番用ビルド
Flowtype導入のための指針・実際の運用について - Qiita
このドキュメントの目的 自分は趣味でFlowをずっと使っていて、またプロダクションでも今まで3プロジェクトほどにFlowを導入した。その知見。 「Flow は便利そうだけど、怖い」「いれてみたら色々ハマったからクソ」「わからん、なにもかも…」という人に対し、自分がいままで出くわしたパターンや、聞かれた疑問について、メジャーな解法を提示する。 なぜFlowを導入するか Babel から段階的に導入することが出来る React の JSX にも推論を入れることができる 部分的に適用できる ASTがES準拠であり、ESLintなどがツールが使える(TSは独自AST) それ自身ランタイムに全く影響はないので落とすのも簡単 実際にはReactと一緒に使うのが、エコシステムもユースケースも揃っていて、一番効果を発揮するだろう。それか、小さい npm モジュールを自分で書くとき。 型のメリット/デメリッ
facebook の Reason という言語を調べていた - Qiita
また facebook 製の名前空間を考慮しないシリーズが増えていた。半年ぐらい前から存在は知られていたリポジトリだけど、最近ドキュメントが新しく、わかりやすくなっていた。https://facebook.github.io/reason/ Approachable syntax. Powerful, automatic source code formatting. Adopt incrementally with JavaScript/C interop. Ahead-of-time compilation to assembly - without a language level VM. Rapidly develop and share projects. Why OCaml?OCaml is a great tool for writing highly expressive,
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 のバージョンを固定したい人向
Real World React 2 - 2016/09/27 - React Meetup #4 - Qiita
About @mizchi Qiita のフロントエンドエンジニア React勝手エヴァンジェリスト 4ヶ月で14kg痩せた (80kg => 66kg) 近況 ビジネスドメインのリファクタが主でアウトプット少ない 泥臭系の知見は溜まってる 会社のメンバーが増えた + 自分以外のフロント系の人が増えたので、設計を明示しないといけない この資料は何 JSer.info 5周年記念イベント - connpass (2016/01/16) にて発表した資料を加筆したもの 如何にしてReactを「ふつうのウェブアプリ」に導入していくか ふつうのウェブアプリ NOT SPA SPA でなくともReactは使える jQuery に支配された現代のフロントエンドを改善したい => 複雑なモジュールを局所的に解決するのにReactが有用であることを示したい フロントエンドの流れ AJAX以前(~2003)
WebSocket と ActionCable - Qiita
序 Rails5 Meetup 発表資料 はじめに 学生の頃に Socket.IO でゲームを作ってた Rails は業務でコントローラに API 生やす程度 rspec が全然わからん 無茶振り yuku 「mizchi なら ActionCableでなんか作れるでしょ」 なんか作った 今日の発表内容 WebSocket の現状 ActionCable 既存機能のRails5の拡張については @takashi に任せる 1. WebSocket WebSocketとは Webブラウザで扱えるTCP Socket抽象 HTTP1.1と比べて並列/高頻度イベントの効率が良い プッシュ配信 今までWebSocket が使えなかった背景 昔話 未対応ブラウザが多すぎて、フォールバック必要 まともな Fallback は、ほぼ Socket.IO の特権 ロードバランサが辛い 二度目以降のリクエス
jQueryで楽になる部分、楽にならない部分、顧客が本当に必要だったもの - Qiita
俺も昔はお前のような jQueryスパゲッティジェネレーターだったのだが、膝にReactを受けてしまってな… 基本的な方針 とくにライブラリ設計者において、小さなモジュールを単機能で分割する以上、ライブラリ設計者は可能な限り依存を減らすことを求められます。node環境ならdependency hellの回避のため、フロントエンド環境ならファイルサイズを減らすためです。 ライブラリ設計者ならずともコードのポータビリティを維持するため、できるだけライブラリに依存しないコードを書くのが望ましいです。 Githubみてる限り、最近書かれるJSのライブラリの多くはjQuery非依存です。ユーザーから見る限りは、jQueryElement渡すかHTMLElement使うかぐらいの違いですけどね。 また、Angular, React等のSPAをスクラッチで設計する場合、気づいたらjQueryを使っていな
型なき世界のためのflowtype入門 - Qiita
http://qiita.com/mizchi/items/3bbb3f466a3b5011b509 で紹介したモダンJSスタックの上に、flowtype を導入して型をボトムアップに追加していくアプローチを紹介します。 なぜflowtypeか、そのゴールは 流行っているライブラリのみを組み合わせて使う場合や、バックエンドとの連携において型が十分に提供される環境なら、正直、flowtypeよりtypescriptでいいと思っています。flowtypeが力を発揮する環境は、既存のJSが大量に存在する環境や、railsなどの動的な型のフレームワーク環境で、静的な定義が抽出できない環境だと思います。 よほど品質が低いライブラリを使わないかぎり、バグはほとんど自分が記述したコードによって発生します。なので、まずは「自分が書いたコードのIFを明確にし、その静的なチェックを行なう」、というのを最初の目
春からはじめるモダンJavaScript / ES2015 - Qiita
春ですね！人の配置がリファクタリングされ、コードもリファクタリングの季節です。 では僕がここでモダンなJavaScriptとES2015の利点を語る役をやるので、みなさんはチームを説得する役をやってください。 JavaScriptの歴史 まず最初にJavaScriptの歴史を踏まえることで、今学ぶべきものとその理由を確認しましょう。 なぜ2016年の記事でES2016ではなく、ES2015なのか、と疑問に思った方もいるかもしれません。それは、ES2015がただの年次アップデートではなく、これから始まる毎年のメジャーバージョンアップの起点となるバージョンであり、またES5から飛躍的に仕様が増えたバージョンであるからです。 簡単に(雑な)歴史を紹介します。 ブレンダン・アイクによってNetScapeに実装/搭載された古の時代〜IE6 (1996~2005) ES3: 一時はシェア7割を誇ったレ
redux への 不満を解消する為に, flumptというFlux実装を作った - Qiita
名前はダークソウルのフラムト(frampt)から。FLux Minimum なんたらかんたら。 なんかTwitterで色々言ってたら naoyaさんにまとめられたので、ここに僕の考えを詳しく書いておく。 mizchi の Redux 考 - Togetterまとめ やりたかったこと 基本的なアイデアは、stateをpushする方式(setStateみたいな)だと非同期間で参照したときの値がズレて非同期の終わる順番次第では状態の遷移ステップが壊れてしまう可能性があるんだけど、前のstateをとって次のstateを返す非同期をキューに並べて順に実行することで、トランザクションみたいなものを保証することができるだろう、というもの。 軽量(pubsubインターフェースはEventEmitterそのまま) 複数の状態更新関数の待ち合わせ reduxで感じた不満の解消 TypeScriptフレンドリー
JS非同期脳だってclojure-script/core.asyncを理解したい - Qiita
最近、ClojureScriptに手を出してる。coffeeは手に馴染みすぎて飽きたし、TypeScriptはただのJS+ただの静的型付けで驚きがなくて刺激が足りない。 clojure-scriptが凄いのは、clojureプロジェクトとして開発されているということだ。clojureのコードが基本的にはそのまま動く。厳密にはまったく同じではないのだが、clojureサブセットだと思えば問題ない。 JVMが実装してあるわけではないので、clojure-scriptコンパイラはclojure-script -> javascriptの変換をしているわけだ。 僕は仕事で一番最初に使ったサーバー言語は実はclojureで、それなりに思い入れがあるのだが、とはいえちょっとの期間だったし、Lispに造詣が深いとも言えない。なので、勉強しながら使っている。 で、やってみたら色々問題があって、core.a
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 では毎度のビルドの遅さが問題にな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
wzrd - もっとも簡単なフロントエンドの為のbrowserifyサーバー - Qiita
