こんにちは、エビリーの新規プロダクト開発を担当しているイサミと申します。 私は、今年の６月までは Unity を用いたゲーム制作のお仕事をしておりました。 前職では、イベント通知やネットワーク処理などの非同期関連の処理において、頻繁に UniRx を使用していました。 フロントエンドでも、ゲームと似たような非同期処理はたくさんあります。 しかし、フロントエンドを勉強する過程で Rx についてほとんど聞いたことがないのが現状・・・。 本記事は、便利な機能であるはずの Rx が、なぜフロントエンドに浸透していないのかを調べてみた雑記です。 時間のない方向けに、結論を先に書いてしまいますと 「可能性はありそうだけど、まだ数年は掛かりそう。」 というものが所感でした。 便利なのは間違いないのですが、「必要性の低さ」と「学習コストの高さ」が問題だと感じました。 詳しく気になる方は、記事読んでね 😎

こんにちは、@nerusanです。 皆さんは、状態管理ツールなどは使っておられますでしょうか。 例えば、有名なところでは、Redux, Recoilなどがあります。 今回は、Reactにおける状態管理についての動向を知ることで、なぜ、Reduxが使われるようになったのか？何をReduxなどのグローバルな状態管理ライブラリで扱えばいいのか？現状どうなっているのか？を調べたので、記事にしたいと思います！ 自身の解釈なので、もしかしたら、誤ったことを言っている可能性もあるので、その際はご指摘いただければと思います m(- -)m SPAの流行り SPAとはSingle Page Applicationの略であり、新しいページに移動する際、サーバからページを再読み込みするのではなく、JavaScriptを使って、クライアント側のブラウザで動的にページを書き換えるアプリケーションを指します。ページご

本稿では Next.js アプリ設計と同時に検討しておきたい、API Mocking の設計（MSW の活用テクニック）を紹介していきます。※ 解説のなかで jest を使いますが、ここは特別こだわりがあるわけではありません。 MSW で表現する API 群 MSW は Next.js アプリのローカル開発に役立ちます。任意の API を任意のレイヤーで、個別にインターセプト可能です。 「ブラウザー → API Routes」間でインターセプト 「API Routes → API 群」間でインターセプト 「getServerSideProps → API 群」間でインターセプト また、自動テストに利用でき、フロントエンドの単体・結合テストが書きやすくなります。同一プロセスでサーバーレスポンスをモックするため、外部プロセスに依存しない、高速な自動テストを回すことができます。 MSW 高階関数

Atomic Design でいう Atoms に相当する、汎用コンポーネントについての小話です。次の様に Props 型定義を用意し、解説している記事をよく見かけます。<input />タグを使わずコンポーネント化している理由は style を施すためかと思いますが、このコンポーネントが受け取れる Props は限定的で、メンテナンスコストが高いためお勧めできません。 type Props = { value: string; onChange?: React.ChangeEventHandler<HTMLInputElement> onBlur?: React.FocusEventHandler<HTMLInputElement> } export const Input = ({ value, onChange, onBlur }: Props) => ( <input value=

daisyUIとは The most popular, free and open-source Tailwind CSS component library Tailwind CSSをベースとしたCSSライブラリで、No JavaScriptでかわいくて機能的な見た目を実現できるスグレモノ。 Bootstrapのような使い勝手でいろんなコンポーネントを実現できる。実態はTailwind CSSなので拡張も簡単。 今回はこちらのライブラリをReact（Next.js）で色々触ってみましたので、感想などをお伝えします。 なぜ興味を持ったか 最近プロジェクトでChakra UIを触っている。かなり便利なのだが、機能もスタイリングも提供されたものを使っているゆえにロックインされている感じが少し怖い。 特に機能（ロジック）面の実装においては思うところが色々あって、 慣れていないときにあらゆるコンポ

はじめに この記事は、バックエンドエンジニアとして仕事をしている著者が、個人でサービスを作った記録です。 使用している技術は以下になります。 Go (gqlgen) - バックエンド TypeScript (React) - フロントエンド Dart (Flutter) - モバイル(ios, Android) GraphQL - API Firebase - 認証 MySQL - DB ConoHa - サーバー GCS - ストレージ CLIP STUDIO - 画像編集 土日を中心に、気が向いたら平日の夜も書く、という時間の使い方をして、ブラウザで動くようになるまでに1ヶ月、アプリを作るのに２週間 (Appleとのやり取りで更に2週間)程度かけて作りました。 iosの審査が終わって公開されたので、今は「これから何をしようかな」と考えているところです。 作ったもの Rabbytという、

Reactアプリケーションのアーキテクチャの一例として公開されているGitHubリポジトリ「bulletproof-react」が大変勉強になるので、私自身の見解を交えつつシェアします。 ※2022年11月追記 記事リリースから1年ほど経過して、新しく出てきた情報や考え方を盛り込んだ続編記事を書いていただいているので、こちらも併せて読んでいただければと想います（@t_keshiさんありがとうございます！）。 ディレクトリ構造が勉強になる まずはプロジェクトごとにバラつきがちなディレクトリ構造について。 ソースコードはsrc以下に入れる bulletproof-reactでは、Reactに関するソースコードはsrcディレクトリ以下に格納されています。逆に言えば、ルートディレクトリにcomponentsやutilsといったディレクトリはありません。 たとえばCreate Next Appで作成

When does react component re-render? What can cause the re-render, and how to prevent unnecessary renders? Here is a quick cheat sheet you can refer to whenever you find yourself asking these questions. This article serves as a table of contents for a Visual Guide to React Rendering series. Every section of the cheat sheet links to the correspondent chapter of the guide that explores a topic in de

GraphQL クライアントの選び方について 現状大きく次のような選択肢があります。 Apollo Client Relay Urql 他に react-query や SWR などの GraphQL に特化していないものを使うこともできるらしいがあまりメリットがピンときていない GraphQL クライアントにやってもらいたいこと 上記は Web の GraphQL クライアントの比較しか書いておらず、他のプラットフォーム(Flutter とか)でも選定軸が持てるように、もう少し "GraphQL クライアント" と呼ばれるものに何を期待しているのかを書き出してみる。 graphql リクエストを送れる 最低限の機能です。 エンドポイント、認証トークン は共通のものとして準備して、あとはクエリをのっけたらリクエストが作れたらいいでしょう。 キャッシュを保ってくれる キャッシュの正規化ってな

As we continue to grow here at Netflix, the needs of Revenue and Growth Engineering are rapidly evolving; and our tools must also evolve just as rapidly. The Revenue and Growth Tools (RGT) team decided to set off on a journey to build tools in an abstract manner to have solutions readily available within our organization. We identified common design patterns and architectures scattered across vari

１．getInitialPropsの終焉 1.1. Next.jsではgetInitialPropsのSSRが終わったことにされている Next.jsの9.3以降、getStaticPropsやgetServerSidePropsが登場し、現在ではgetInitialPropsを使ったSSRが終焉を迎えたかのような風潮となっています。しかしgetStaticPropsとgetServerSidePropsは、実際の所で大きな欠点を抱えています。 getStaticPropsはSSG前提で使うなら全く問題ありません。しかし、ある程度の更新頻度をもつシステムやリアルタイムな編集機能と相性が悪いです。ISRで使う場合も有効期限後の一回目で古いデータが表示される仕様があるので、タイミングが悪いと、せっかっく訪れた人に古いデータを渡してしまうことがあります。使いどころによっては強力ですが、用途は限定

こんにちはかみむらです。 先日柴田さんが公開していた、Reactのモーダルコンポーネントを簡単に作成できるライブラリ react-hooks-use-modal をmicroCMSのOrganizationに移行しました。 こちらがGitHubのリポジトリです。 https://github.com/microcmsio/react-hooks-use-modal こちらはデモになります。 https://microcmsio.github.io/react-hooks-use-modal/ react-hooks-use-modalはmicroCMSの管理画面内部にも使われています。例えばWebhook追加時のモーダルコンポーネントです。 モーダルのコンポーネントは1から実装すると非常に工数がかかりますが、react-hooks-use-modalを使えば少ない工数で実装することができま

ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、フロントエンドエンジニアの近藤です。Yahoo! JAPANのスマートフォンのウェブトップページのフロントエンド開発業務と、社内で利用されているデザインシステムの開発に携わっています。 近年、デジタルプロダクトを持つ多くの企業で、デザインシステムが活用されています。デザインシステムには、ビジュアルとしてのデザインの規定だけでなく、実際のプロダクトに利用できるUIライブラリやコンポーネントライブラリなどが含まれます。そのため、デザインシステムの構築にはデザインとエンジニアリングの両方の力が不可欠です。 本記事では、私が開発に携わっているデザインシステム「Riff」の紹介とともに、フロントエンド部分におけるデザインシステム

こんにちは。ソウゾウの Software Engineer の hiroppy です。「連載：「メルカリ Shops」プレオープンまでの開発の裏側」 の最後は、Web フロントエンドの紹介をしたいと思います。メルカリ Shops は既存のメルカリアプリの中に独立した Web アプリケーションとして動いています。本記事では、どのようなライブラリを選定し、どのようにアーキテクチャを設計してきたかを解説します。 なぜ Web なのか？ アプリの上で動いているのであれば、WebView ではなくても良いと感じる人はいると思います。今回採用した 1 つの理由としては、リリースが柔軟な点が挙げられます。iOS/Android の両方に対して開発サイクルを早めることが可能であり、また機能追加やバグ修正が容易です。どのように WebView で動いているかについては、6 日目のメルカリ Shops のため

ZennではフロントエンドにNext.jsを使っています。もともとはVercelで動かしていたのですが、2021年3月にGoogle Cloudに移行しました。今回は移行を決めた理由や、具体的な構成、移行作業などについて書きたいと思います。 なぜ移行したのか Next.jsのデプロイ先としてVercelは圧倒的に優れています。ISRやImage OptimizationといったNext.jsの強力な機能をサーバー側の追加設定なしで使用できますし、CDNでの静的ファイルのキャッシュなども特に意識しなくてもいい感じにやってくれます。 Vercel以外にデプロイするとなると、Next.jsの一部の機能がうまく動かなかったり、パフォーマンス・チューニングを自分で頑張る必要があったりと自分で面倒を見なければならない部分が多くなります。 しかし、Zennのケースでは以下のような理由からVercelから

小さくてもインパクトのある変更で、あなたのアプリを競合他社から引き離します。 1. React Loader Spinner 待つのが好きな人はいません。今やユーザーは最低限の条件として、ウェブサイトが高速であることを求めています。アプリが重いか遅い場合は、コンテンツの読み込み中、この最新のローディングアニメーションを表示しましょう。アプリの美観を向上させるだけでなく、ユーザーを維持するのにも役立ちます。 このパッケージで提供する全ローディングアニメーション npmまたはyarnから直接インストールします。

技術について思っている印象とかを、定期的にまとめておくとあとで見直したときに良い振り返りになるかもしれないなと思ったのでまとめておく。 上記の目的でやるので思い切り主観で書く。 Vue について思うこと composition-api がとてもいい。 composition-api で頑張るなら React 使えよみたいな意見を耳にしたことがあるが、Vue の良いところは、template と style が JS と別個で動くというところだと思っているので、composition-api の前身である Option API が改善したところで、React と比較してどうこうみたいな見解の変化はない。 Vue を使っている限りは、基本的には CSS in JS 戦争に巻き込まれないので平和。 Vue3 をまださほどキャッチアップしていないので適当な意見になるが、SFC の書き方自体が結構変

この記事は Front-End Study #3 で発表されたライブコーディングの内容を記事にしたものです。記事中のソースコードは GitHub でご覧いただけます。 この記事は、これまで一般的なフロントエンドエンジニアだった私が一年ほどアクセシビリティーについて勉強する上で 「最初に教えてくれればよかったのに〜！」と思った内容 を React と Next.js を用いて紹介するものとなっています。 読み終わった後に次にコードを書く際にふと意識できるようなアクセシビリティーの普遍的な事実を紹介し、最後に今後の React の動きについて軽く触れるものになっています。目次は次のとおりです： 基本事項 SPA のルーティングによる問題 リッチなコンポーネントでの例 Jest + React Testing Library でのテスト Reactとアクセシビリティーの今後の動き 役に立つweb

「Redux は学習コストが高い」などと言って useState（または useReducer）と useContext を組み合わせ 劣化 オレオレ Redux を作ってしまうのを見かけます[1]。よくないことだと思いますが、気持ちは非常にわかります。Redux エコシステムがそういう気持ちにさせてしまう部分は大いにあります。 Redux は それ単体なら 学習コストは useReducer + useContext と同等であることを示してこの気持ち（誤解）を解かしつつ、なぜそういう気持ちになってしまうのか考察してみます。 まず useState と useReducer の違いを押さえておく 知っている方はスキップしてください。 useState と useReducer は本質的には同等で、どちらもコンポーネントにステート（状態）を持たせる役割があります。次のようなカウンターアプリ