React+Fluxで正しく設計するためのFlux見直しガイド
Reactの良さを活かしやすいFluxは、Webアプリケーションの設計手法としてずいぶん馴染みのあるものになったように感じます。私もFluxを取り入れた開発を2年近く経験し、知見も溜まり、使い慣れたような気持ちでいました。 が、使い始めた頃はもちろん、今でも何となく分かったつもりでいる部分があったり、複雑な実装が必要な場面で悩むことがあったりします。「Fluxはダメだ！うまく実現できない！」と投げ出したくなるときもありますが、そんなときこそ基礎へ立ち返る機会。 そんなわけでFluxに再入門し、Fluxとは何なのか、どう実装するのが適切なのかを公式ドキュメントに則って整理してみようと思います。 Fluxとは Dispatcher 要件1 イベントが発生したらすべてのCallbackを実行すること 要件2 Callbackの実行順序を制御できること Action Actionに必要なたった2つ
React の Higher-order Components の利用方法 - Qiita
前書き この資料は2016/12/15 に行われた【ランサーズ×Mozilla×freee】React実践！勉強会で発表した際の資料を改修したものです。 (qitta に投稿するのが初めての場合、2MBまでしか画像をアップできないので、編集してます) 間違いなどがあれば、コメントや編集リクエストなどをいただければありがたいです。 目次 対象読者 HOC とは何か？ HOC の基礎 実際に利用されているライブラリについて HOC の具体的な実装例 対象読者 Reactを利用してアプリケーションを作成したことがある人 ReduxやFluxなどのフレームワークを利用したことがある人 HOC とは何か？ A higher-order component is just a function that takes an existing component and returns another c
2017末時点での React Component 設計のベストプラクティス - Qiita
どう考えているか、というのを聞かれたので、記事に起こしておきます。個人の意見です。 Prettier を使う 気づけばコードの整形を人間がやる時代は終わりました。 細かいコーディングスタイルでレビューの時間を取るぐらいだったら、一貫した自動整形ルールを適用すべきです。 人によっては細かいこだわりがあって prettier の規則が気に食わないかもしれず、僕も最初はそうでしたが、Atomで保存する度に自動整形を走らせる prettier の強烈な開発体験によって、最終的にそれらのこだわりを全て捨てることが出来ました。 生産性を求めるなら、現時点では最優先で導入すべきものです。 React.createClass を使わない v16 で削除されたのでいわずもがな。 同様に、 createClass でしか使えなかった mixin 周辺機能も丸ごと deprecated です。 「可能な限りは」
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
