経年劣化に耐える ReactComponent の書き方 - Qiita
「経年劣化に耐えるコード」というのは、だれもが目指すものでしょう。「そもそもフロントエンドのコードは、今ある技術で最良のものを書き捨てるべき」という意見も理解できますが「備えあれば憂いなし」ということもありますので、ここにメモを残します。あくまで、私なりのベストプラクティスですのでご了承ください。 5層に別れた SFC 私はレイヤーによる技術の分離で、ReactComponent の経年劣化に備えています。ここでいうSFCとは「Stateless Functional Component」の略称ではありません。Vue.js の文脈にある「Single File Component」を指します。 // (1) import層 import React from 'react' import styled from 'styled-components' // (2) Types層 type
React Hooks で作る GUI - Qiita
当カレンダーの対象読者は Hooks API を少しでも触ったことがあり、公式ドキュメントを確認された方です。Hooks API で、従来の Stateful Component 相当のものが書きやすくなりました。まずは Hooks を利用するモチベーションを、Dan の記事で再確認してみましょう。 Huge components that are hard to refactor and test. Duplicated logic between different components and lifecycle methods. Complex patterns like render props and higher-order components. HOC や render props は complex pattern として、ネガティブに捉えられている様です。HOCを利用
雰囲気で使わない @types/react - Qiita
@types/react の型定義を雰囲気で使っている皆さん、こんにちは。React コンポーネントを書くときはどの型を使い、どう書くべきか？という疑問を Twitter でお見かけし、雰囲気で使っていた私も気になったので @types/react の中身を覗いてみました。 master に入り、いよいよリリース間近な Hooks。本稿は FC(旧SFC) の話が前提です。VScode で型付けをしようとすると、似たような型が山ほど出てきて、どれを使うのが適切なのか・違いが何なのか…パッと見分かりませんね。 ReactNode ReactChild ReactElement StatelessComponent FunctionComponent JSX.Element SFC FC という訳で、こんな Props を持っているコンポーネントの各種書き方を比較、白黒ハッキリさせていきたいと
Reduxにドメイン層を導入する - Qiita
【2018/6/18更新】immutable.js を利用せずに、当エントリー同等以上の開発が可能な、FP・型推論の強いモジュールを公開しました。https://qiita.com/Takepepe/items/a79e767b38981c910c3f ドメインモデルの需要 フロントエンドフレームワークでプロダクトを作り込んでいくと、ビジネスロジックが view に介入しすぎてしまうことが少なからずあります。下記の様なビジネスロジックが散在しているコードに、スケール耐性があるとは思えません。リリース当時は単純だったものが、複雑に変化していくケースは往々にしてあります。 function TodoItems (props) { const { todos, updateTodo, deleteTodo } = props const items = todos.map(item , i) =
redux-saga で DOMからアニメーションを分離した話 - Qiita
DOMアニメーションをredux-sagaに乗せる React + Redux でアニメーションといえば CSSアニメーションをマルチクラスでトリガーするものが殆どかと思いますが、要件によってはそれだけでは十分ではない場合があります。jQuery.animateでやっていた様に、インラインスタイルをゴリゴリ書き換えるものを React + Redux でも実現したいです。 しかし、多くのアニメーションライブラリはDOM参照する実装都合上、ref参照が必要になりStatelessを諦めなければいけなくなります。また、Presentational層にアニメーション終了などの action を発行する様なロジックを記述しなければいけません。 そこで、 Redux の副作用を扱う redux-saga を用いて実装したいと思います。動かすDOMは Store.state を参照するアプローチ。アニ
次のReact状態管理はMobXにする理由 - Qiita
2017/12/29更新： ReduxとMobXの選定観点 も併せて見ていただければ幸いです front-end-handbook-2017 に名前が挙がっていた MobX に興味が湧き調べてみました。その結果、掲題のとおりの記事を書きたくなるまでに至ったので、個人的にReduxより優れていると感じた点を挙げたいと思います。 記述量が圧倒的に減る Store概念のわかり易さ バケツリレーが実質不要になる injectを活用するとjsxが純粋になる デコレーター層の存在 記述量が圧倒的に減る 一つの双方向な値をコンポーネントに表示するために、Reduxでは以下の作業が必要でした。 Reducer に initialState として値を追加 Reducer で Object.assign した新しい State を生成 ActionType を追加 ActionCreator を追加 Act
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
React Redux テスト考察 - Qiita