俺が考えた最強の 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 です。 「可能な限りは」
React とGUI 設計論、あるいは新世代のホームページビルダー - Qiita
注意。実装はまだないです。思考実験的な意味合いが強いです。 持論 Reactやredux/Rxのデータモデリング手法の発達で、ツリー構造の末端に渡すまでのデータモデリングが主戦場になりつつあります。これはロジックを注入する部分と、プレゼンテーショナルなものが明確に分離されてきたことを意味します。 僕は個人的に、 GUI にまつわるものは、本来GUIで設計したい、という気持ちがあります。そう、僕が作りたいと思っているのは、悪名高きホームページビルダーです。 とはいえ、プログラミング抜きでxxxできる！というものではありません。むしろプログラミングとGUIを横断するイメージで、Unity や UnrealEngine のような開発環境を想定しています。 今やりたい理由 ブラウザの仕様が安定してきた 色々と使えるパーツが増えた JS で複雑なツールを作れるようになり、インブラウザな開発ツールが作
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 の機能 リソースの先読み
kobito-oss のソースの読み方 - Qiita
メインの開発者として、備忘録を残しておく。 どんなものか試したい人は、 https://mizchi.github.io/kobito-oss/ で、IndexedDBの許す5MBぐらいまでは試せる。 一応言っておくと、これは僕が退職するんでOSS化ってわけではなく、元々あった計画の前倒しです。時期が早まったのはある。 以下、どのようにコードを読むか。 念頭に置くこと 2年前 の技術選定のスタック Mac版Kobitoと仕様が違う。Kobitoと同期しない、Inboxという仮グループがある。 mizchi/arda electron 以前の atom-shell 時代の互換コードが一部残ってる 細々とバグ対応はしつつ、あんまり依存パッケージのメンテ出来てなかった 公開にあたって、個別のタスクの綺麗さより、ビルドできるの優先した とりあえず yarn で固定して yarn upgrade-i
最強のフロントエンドの雛形作った (2016/12/31) - Qiita
yarn とりあえず yarn install と yarn start だけで動く npm(yarn) scripts babel/webpack での多段ビルド build:js はChromeでだけで動くビルドを吐く（デバッグを容易にするため） build:js:production はIE11+ ava/nyc/istanbul でテストとカバレッジ postcssでCSSのビルド uglify-js/csswring で圧縮 CircleCI eslint, flow, ava release ブランチに push で gh-pages にデプロイ ## やってないこと React も Angular も jQuery も何も入ってない。あくまでそれ以前にやることをまとめた。 参考になるだろうけど、人によっては使わないツールも多いと思われるので、適当に削ってください。 こういうの
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)
フロントエンドエンジニア(mizchi)が暇な時にやること - Qiita
暇というか日常的にやってること https://news.ycombinator.com/ と http://www.echojs.com/ と http://b.hatena.ne.jp/efcl/ をフィードリーダーに突っ込んでいて、面白そうなのをメモっておく 暇なとき 日頃メモってたライブラリの試し切りをする 面白かったら紹介記事を書く 多少やる気リソースが多めだと新しい言語(最近はRustかElixir)の勉強を進める http://codepen.io/ で面白い動きするやつのコードを探してコード読む とくにCodePenがオススメで、割とゲラゲラ笑いながら読めるやつが多いので楽しい。CodePenのテクニックはそのまま自分の業務に持ち込むと悪目立ちするので控えているが、Webでもこういう演出ができる、と頭の片隅にいれておくことで、いずれ何かに役立ったりする。たとえば昨日読んだ奴
React on 現場 ~ あるいは Modern JavaScript on Rails ~ - Qiita
これは何 JSer.info 5周年記念イベント - connpass (2016/01/16) にて発表した資料。特に理由はないが公開するのを忘れていた。 スライドモードのリリースにあたって公開する 近況(2016/01/16) 昨年9月 Kobito for Windows => Qiita開発チーム モダンなJS(当社比)を導入しようとした モダンなJSとは(mizchi主観2016版) npm/browserifyで依存を解決 Babel/ES2015 React/Flux Testable No More jQuery plugins ※これらの基準について今回は割愛 現実(2015) CoffeeScript Sprockets / グローバル名前空間渡し Backbone JSのテストはjasmineで数件 (※request specは豊富) jQuery plugins
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割を誇ったレ
テストがないJS環境にモダンなテスト環境を導入していく - Qiita
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
redux への 不満を解消する為に, flumptというFlux実装を作った - Qiita
名前はダークソウルのフラムト(frampt)から。FLux Minimum なんたらかんたら。 なんかTwitterで色々言ってたら naoyaさんにまとめられたので、ここに僕の考えを詳しく書いておく。 mizchi の Redux 考 - Togetterまとめ やりたかったこと 基本的なアイデアは、stateをpushする方式(setStateみたいな)だと非同期間で参照したときの値がズレて非同期の終わる順番次第では状態の遷移ステップが壊れてしまう可能性があるんだけど、前のstateをとって次のstateを返す非同期をキューに並べて順に実行することで、トランザクションみたいなものを保証することができるだろう、というもの。 軽量(pubsubインターフェースはEventEmitterそのまま) 複数の状態更新関数の待ち合わせ reduxで感じた不満の解消 TypeScriptフレンドリー
仮想DOMで魂が震えてから一年、仮想DOMとFluxの今 - Qiita
なぜ仮想DOMという概念が俺達の魂を震えさせるのか から一年、みなさまどのようなフロントエンドをお過ごしでしょうか。 僕はひたすら過去資産をリファクタしています。 需要の雰囲気 色んな所に書きましたが、去年僕が仮想DOM AdventCalendar をやったのは、「僕自身がproductionで使いたい」ので、「Reactまあいいよね」的な雰囲気を作って外堀埋めるのが目的でした。そして、その目的はおおよそ果たされたと言ってもいいでしょう。ご協力ありがとうございました。 僕自身はKobito for Windows でReactを使ってみて、そのノウハウを公開したり、今年前半は色々とアウトプットをしていましたが、後半はSpecificなアプリケーションドメインを記述することが多くて、あまりアウトプットする内容がなくなってました。 取り敢えずは、新規のプロダクトなら採用してもよい、という雰囲
react-railsでサーバーサイドレンダリングしつつクライアントでsetStateできて最高になった - Qiita
土日でreact-railsとturbolinksを勉強してみた成果です やりたいこと 画面遷移するときは<div id='content'></div> の中身だけ入れ替えて、pushStateで行き来できるようにしたい reactを使ったリッチなページでも、イニシャルロードやSEOの為にサーバーサイドでレンダリングしておきたい サーバーサイドレンダリングした要素を破棄することなくReactで初期化してsetStateでガンガンViewを書き換えたい 結果どうなったか サーバーサイドでReactComponentをレンダリングしてクライアントのReact.renderで初期化情報を揃えて引き継ぎ どんな画面でもapp.component.setState({})が反映されて最高 TurbolinksでReactComponentをマウントしたルート要素だけ入れ替え その為にTurboli
リアルタイムウェブな観点からElixir / Phoenix について - Qiita
ここ最近、 [翻訳] Elixir - 次に来る大物Web言語 - Qiita とか 超高速なJSON APIをElixirフレームワークのPhoenixでビルドしてテストしよう | POSTD を読んで気になっていたので、勉強していた。 前提: 自分はシングルページアプリケーションに特化したフロントエンドエンジニアであり、サーバサイドのプロダクション運用にはそこまで強くない。あとこれはここ2日の勉強した日記でもあり誤解や勘違いも多々あると思う。 リアルタイムウェブアプリケーションのためのサーバー Railsの次の時代、リアルタイムウェブの為のウェブフレームワークがあるとしたら、次のような特長をもつと思う。 HTTP, HTTP/2. WebSocket等のプロトコル対応と抽象化 JSON APIに特化 認証系 キャッシュ管理 Viewに関心がない リアルタイムウェブは、その言葉をどう定義
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ページを開く
Railsのrakeでasset:precompile前に任意のタスクを流してをjsをビルドする - Qiita
