はじめまして!WEBチームの黒川と申します!昨年7月にaptpodに入りましてもうすぐaptpod歴1年になります! aptpodでは主にフロントエンドエンジニアとしてReact/TypeScriptを用いて、お客様向けアプリケーションのUI部分を実装しております。 ご存じの方も多いように、Reactの状態管理にはいくつか方法があり、何を用いるべきかなどでしばしば議論が起こりがちです。代表的なものだけでも、標準APIを用いるuseStateとContextやデファクトスタンダードとなってきているRedux、そして新興のRecoilがあります。 弊社のWEBチームではReduxを採用するケースが多いです。私もReduxについては一通りの知識と経験は持っていたつもりだったのですが、先日担当させていただいたプロジェクトで初めてReduxの設計に取り組んだところ、自分がReduxの思想や勘所につい
昨日、Facebook製のReact用ステート管理ライブラリRecoilが発表されました。Facebook製といってもReact公式のステート管理ライブラリとかそういう位置付けではないようですが、それでも大きな注目を集めているのは間違いありません。 そこで、筆者がRecoilに対して思ったことや、筆者の視点から見たRecoilの特徴を記事にまとめました。 なお、この記事の執筆時点では副作用の扱いなどの点はいまいち情報が揃っていません。この記事では速報性を重視し、コアのステート管理部分に絞って考えています。また、まだexperimentalなライブラリなので、今後この記事の内容からRecoilのAPIが変化したとしても悪しからずご了承ください。 この記事を書くときに筆者が色々試していたCodeSandboxはこちらです。 https://codesandbox.io/s/recoil-san
TypeScriptでReactをやるときは、小さいアプリでもReduxを最初から使ってもいいかもねというお話 前日の丸野さんがReduxを分かりやすく解説してみたというReduxの基本的な紹介を行いました。Reduxはコンパクトなライブラリながらよく考えられた仕組みです。Jetpack ComposeやらFlutterやら、ReactインスパイアなGUIフレームワークも増えているので、JavaScript(TypeScriptではなく) + Reduxをやってみるのは、ウェブに限らず、今後のユーザーインタフェース関連のコードを触るための理解力向上には良いと思います。 本エントリーは、プロダクションコードでたくさんRedux周りにもreducerなどを実装しなくてはいけなくなったときの次のステップとして、Redux Toolkitの紹介をします。 たいてい、Reduxは導入コストが大きく、
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちはお久しぶりです。岡部和昌(@kzms2)と申します。 今回お話しする内容はタイトルでほぼ全部述べているのですが、PC 版 Yahoo! JAPAN のトップページを 2019 年 10 月 1 日に刷新、主に開発環境をアップデートした経緯と採用した技術に関してのお話です。 見た目に関しては特に大きな変化はなかったので、気が付かなかった方も多いのではないでしょうか? なぜ刷新したか Yahoo! JAPAN トップページは 2008 年 1 月 1 日に大規模なリニューアルを行いました。その頃からある程度の改修はあったものの、基本的にはコードの継ぎ足しで修正を加えている状態でした。 (参照;Yahoo! JAPAN トップ
Redux Sterter KitはRedux-Toolkitに名称変更されてAPIも変更されています。本記事はそのままでは最新版redux-toolkitとして動作しません。 https://github.com/reduxjs/redux-toolkit はじめにReact-Reduxの公式から「Redux Starter Kit」というものが公開されています。 これがなにかといえば、私の理解するかぎり以下です。 React-Reduxまわりのベストプラクティス、定番拡張、定番併用ライブラリ、定番ミドルウェアを、簡単に組込むための簡単で軽めのライブラリ、メタパッケージ。 CLIコマンドではなくライブラリです。 これは良いものだと思いましたので全力でお勧めしていきます。 特徴 TypeScriptフル対応。当然ですね。 React Redux 7.1対応、つまりHooks対応。これからは
UIT とは? UIT は、 LINE のメンバーが中心となって発足した、「User Interface × Technology」を掲げるコミュニティです。 ユーザーの目に見える部分を技術で解決する開発者のための、実践的なコミュニティとして活動。JavaScript だけでなく、また、ユーザーインターフェースだけでもなく、多面的なテーマ設定が特徴となっています。 過去には BFF(Backend for Frontend) のような技術にフォーカスした勉強会や、「わたしたちにとってのVue.js」と題した様々な現場での Vue.js の事例など、トレンドを追いながらも地に足の着いた話が多い点も魅力の一つです。 当日の様子 そんな UIT ですが、今回のテーマは「進化する React.js」。 当日は三人のゲストにそれぞれ React.js をテーマに登壇いただきました。以下、登壇順にご紹
Transcript ݱ͔Βಧ͚Δ3FBDUϓϩδΣΫτͷ Έͱվળ� 6*5���ਐԽ͢Δ�3FBDU�KT wTBLJUP !@@TBLJUP@@ � w'SPOU�&OE�&OHJOFFS� w3FBDU XFCQBDL (BUTCZ+4� w&WFOU� w#POpSF�'SPOUFOE� w'SPOUFOE�5SBJOJOH�.FFUVQ� w3FBDU�NFFUVQ� w*OTJEF�'SPOUFOE� ࠂ None *OTJEF�'SPOUFOE��� �����݄��։࠵ʂ✨ IUUQT���JOTJEF�GSPOUFOE�DPN� $'1ืूͷకΊΓ ໌ �݄����࣌�� ·Ͱʂ ·ͩؒʹ߹͏ʂʂʂ ࠂऴྃ ݱҰͭҰͭʹ3FBDUʹؔ͢Δ͕͋Δͱ͓ͬͯΔ ࠙ձͰͦΜͳͰΓ্͕Γ͍ͨ ͷ3FBDUϓϩδΣΫτͷݱͰվળ
Re-ducks というディレクトリ構成のベストプラクティスについてまとめる。Re-ducksパターンを使うことで、React + Redux を用いた開発がよりメンテナンスしやすいものになる。 Ducks パターン 名前からもわかるように、Re-ducks は Ducks というパターンをベースにしている。 erikras/ducks-modular-redux Ducks パターンが解決すること: actionType、action、reducerが散らばっててつらい 結局のところ actionType、action、reducer は密結合なので、ducksパターンではこれら3つを1つのファイルにまとめる。 // widget.js // Actions const LOAD = 'my-app/widgets/LOAD'; const CREATE = 'my-app/widget
何のためにreact-router-reduxを使うのか復習しようとしたら、deprecatedになっていたJavaScriptReactreact-routerredux 概要 なんとなくの理解で使っているreact-router-reduxを復習しようと思い立ったところ、今やreact-router-reduxはdeprecatedになっていました。あらー。 今、React Routerのドキュメント(Redux Integrationのページ)を見ると、代わりにConnected React Routerというライブラリが紹介されています。 とはいえ、React RouterとReduxの統合は何のためか、という目的はどちらのライブラリもそう変わらないはずですので、この機会に復習していきます。 その上で、今度からはConnected ... の方を使おうと思います。 現状、こんな風に
一昨日、昨日の続きです。 react-routerをv4へマイグレーションすると同時に、react-router-reduxもv5に上げます。こちらはまだアルファ版ということですが、十分に機能するしとてもシンプルなためにコード読んですぐ分かる内容ですから、危険視するほどではないと思います。 $ npm install --save react-router-redux@next $ npm install --save history 5.0.0-alpha.6でした。ここ1ヶ月ぐらいはコードが動いていないし、まあほぼ完成なのでしょう。 // Root.jsx import React from 'react'; import injectTapEventPlugin from 'react-tap-event-plugin'; import { createBrowserHistory
4月14日(土)に、React x Typescriptのミートアップを実施しました! 当記事ではミートアップイベントの様子を紹介します。 イベント概要 このミートアップはReact x Typescriptのスキルアップのための会であり、 実際にReact x Typescriptを使用している方によるLTを実施しました。 現場のエンジニアの話を聞くことで、高度な技術を知ったり、 効率的な方法を知ることができるイベントでした! LT1 "ReduxからMobXへ移行した理由" - Choi Junyoung Boostnoteを開発している、弊社CTO Choi JunyoungによるLTを行いました。 ReduxからMobXに移行した話をしてもらいました。 なぜ私はReduxをやめて MobXを使うようになったのか from Junyoung Choi www.slideshare.n
エンジニアの原です。 これ、数人同じ事思ってる人いたみたいでした。よかった。 http://anect.hatenablog.com/entry/2017/06/09/151000:embed:cit ブログ内では「mapStateToPropsとmapDispatchToPropsを使う理由が分からない、mergePropsで全部やるのがシンプルで良いじゃないか」というものでしたが 今回react-reduxのソースを解説しつつそれらの役割と必要性についてと実際どうするべきか、について少し考えました。 TL;DR 結論から言うと 「場合によって(というか多くの場合)はmapStateToPropsとmapDispatchToPropsをちゃんと使わないとパフォーマンスが下がる」 です。 以下、ソースの解説と自分の意見です。 react-reduxの実装の話 ちょっとだけreact-red
オブジェクトとReactのProps向けのShallow(浅い) equalライブラリを書きました。 Shallow Equalは対象のオブジェクトのプロパティをそれぞれ1段だけ比較することを言います。 ものすごく単純に書くならば次のようなことをするライブラリです。 const object = {}, targetObject = {}; const isEqualed = !Object.keys(object).some(key => { return object[key] !== targetObject[key]; }); const { shallowEqual } = require("shallow-equal-object"); shallowEqual({ a: 1, b: 2 }, { a: 1, b: 2 }); // => true shallowEqual({
fluxもReduxもどうデータを持つかについてはあまり多く説明されてない気がします。もちろんアプリケーションによって持ち方は異なるとは思うんですが、自分用のメモとして改めて考え方を整理しておきたいと思います。 Store分割の単位:画面 vs ドメインモデル Storeを画面毎に分割すべきかドメインで分割すべきか否かという議論があると思います。個人的にはドメインモデル毎に分割して整理すべきだと考えています。過去にfluxでフルSPAを一人で開発した時は最初はある程度画面毎にStoreを分割してたんですが、すぐきつくなってきてドメインモデルで分割し直しました。 画面毎に分割すると画面が増える度にStoreを増やすことになります。しかし画面が増える度にドメインの概念やデータの種類が増えるわけではないので、この場合明らかに重複した無駄なコードを書いてる事になると思います。 もちろんアプリケーシ
スタディスト開発部、フロントエンド担当の小宮山です。走ることが楽しくなりすぎてフルマラソン完走が当面の目標です。 今回は私達が進めているUIリニューアルプロジェクトにおける、フロントエンド設計の心臓部についてご紹介したいと思います。盛り上がりつつあるものの、まだまだ実践的な情報が少ないVue界隈に少しでも貢献できましたら幸いです。 画面駆動Vuexの頃プロジェクト始動当時は私含め大規模プロダクトにVuex(さらにその他Flux状態管理も)を導入して開発を進める経験も知見もほぼない状況でした。 そして開発していく画面デザインの大枠は出揃っている状態だったので、計画も実装も画面単位で区切って進みだしていきます。 こうした状況でVuexのstoreはどのような方針で実装されていくか。正確に表現するなら、特に方針なく実装していくとどうなるか。画面ファーストで、画面から使いやすく、画面ごとに専用なs
背景:React-Reduxを使うときに、メモ化が重要だと理解したので情報発信することにした 開発現場にReact-Reduxを導入しておきながら、チームメンバーから「 俺の実装したコンポーネントの描画遅いんだけどどうにかしてくれ 」と言われたので、「どうにかするのはお前の仕事だぞ♡」、と思いつつ、そうも言ってはいられない状況になったので、本腰入れてドキュメント読みました。React-Reduxのパフォーマンス改善にはどうやらメモ化が重要であると思ったので説明します。色々なサイトやドキュメントは明らかに冗長な説明が多いので、極限までエッセンシャルを絞って説明することで、ゼロ知識からでもある程度、理解できるレベルの説明に落とし込むことに挑戦しました。うちの開発チームで知見として残すために作成したものですが、需要がありそうかなと思ったので、公開します。需要がなければすみませんでした。おかしな点
import React from 'react' import { render } from 'react-dom' import { createStore } from 'redux' import { Provider } from 'react-redux' import Button from './components/Button' import rootReducer from './reducers' const store = createStore(rootReducer) render( <Provider store={store}> <Button /> </Provider>, document.getElementById('root') ) connect of React-Redux connectの主な役割は、Providerにセットされた、Red
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く