技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL はじめに 新たに書きました。 MySQLを使っても会社は潰れない 久々に記事を書いたのでどうぞお手柔らかに... 私が過去2年間で行った技術選定の成功と失敗を振り返り、その学びを共有したいと思います。 文才無いので淡々と箇条書きでいきます Twitterエンジニア垢作りました。エンジニアのお友達がいません。 @uncode_jp 注意 意見を押し付けるものではありません。ただ建設的な議論は大事だと思う。 自分の意見は明確に、歯切れのよい表現を意識している。人それぞれだよねみたいな感じに逃げたくない。技術選定に結論はある（過激）。 ただし技術選定にはコンテキストがあり、例えばプロダクトのフェーズや組織の事情によって当然結論は変わる可能性がある。 OSSの開発者さん達は偉大ですごい。あ
しずかなインターネットの技術構成
こんなWebサービスをリリースしたので、技術的な話をまとめておこうと思います。 元々このサービスは、趣味の延長線のような感じで開発を始めました。競合にあたるnoteやはてなブログなどのサービスが確固たる地位を築いているということもあり、「お金にはならないだろうけど、自分の趣味を詰め込んだものにしよう」というゆるい気持ちで開発を続けています（楽しい）。 選定の方針 趣味と言っても文章投稿サービスなので、ユーザーが少数であったとしても長期間運営しなければなりません。そのため、ユーザー数が少なければランニングコストが数千円/月以下、ユーザー数が増えたときは段階的にコストが上がるように選定を行いました。 アプリケーション フルスタックNext.jsアプリケーションをCloud Runにデプロイしています。各APIエンドポイントはNext.jsのAPI Routesで生やしています。 Next.js
MySQLを使っても会社は潰れない
MySQLを使っても会社は潰れない そんな話は聞いたことがない。AWS Lambdaが再帰実行されて潰れた会社の話は実際に聞いたことがあるが。 つい先日、私が書いた記事がとんでもなく大事になってしまい、大変な賛否を巻き起こした。 まさかこんなに読まれると思っていなかったので、大変驚いたのと同時にインターネッツの恐ろしさを体感した。 その中でも特に物議を醸したのが「MySQLを使うと会社が潰れる」というフレーズだった。 「MySQLを使うと会社が潰れる」とはなんだったのか 私がこのフレーズを選んだ理由は、言うまでもなく単に読者の注意を引く表現を使いたかったからである。 このフレーズがセクションの先頭にあったら、「なにをいってるんだこいつ？」と先を読んでみようという気になると思った。 そして続きを読んでいくと「なんだそういうことか」と意図を汲んで、それで同意するかしないかは人それぞれだろうなと
React / Remix への依存を最小にするフロントエンド設計 - 一休.com Developers Blog
CTO 室の恩田(@takashi_onda)です。 一休レストランのフロントエンドアーキテクトを担当しています。 Intro 一休レストランでは、以前ご紹介したようにフロントエンドで React / Remix を利用しています。 user-first.ikyu.co.jp 一方、設計方針としては、React / Remix への依存が最小になるように心掛けています。 今日は、そんな一見矛盾するような設計方針について、ご紹介したいと思います。 この記事を読んでいただき Remix に興味をもたれたら、明後日 2024/8/7(水) 19:00〜 のオンラインイベント offers-jp.connpass.com にもご参加いただけると嬉しいです。 この記事でご紹介している疎結合なフロントエンドアーキテクチャを実現する Remix の魅力についてお話します。 なぜ依存を最小にするのか？ R
技術選定の成功 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL
技術選定の成功 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL 技術選定に失敗はない 技術選定に失敗はありません。 仮説を立て、検証し、結果の分析からNext Actionを考える。検証の結果がどうであれ、それは過程に過ぎません。 机上の空論だけで全てを理解できるほど、我々人間は賢くないのです。（注意: これは人類全体を誹謗中傷する意味ではありません。） この記事では、この２年間で行った技術選定の成功例をその理由と共に紹介していこうと思います。 申し訳遅れましたが、私、YadaYadaKonnanYadaといいます。私は今回初めて記事を書いたので、どうぞお手柔らかに。 Twitterエンジニア垢作りました。エンジニアのお友達がいません。 @uncode_jp 前提 技術選定に結論はありません。組織毎に前提が違うのだから当然のことです。みんな違っ
小規模プロダクトにおける React 状態管理ライブラリ選定 in 2024 - バイセル Tech Blog
はじめに こんにちは！ テクノロジー戦略本部24年新卒の高橋です。 2023年の10月から内定者インターンを経験し、現在は開発3部CRMチームでフロントエンド(以後、FE)エンジニアとして働いております。 チーム内でFEの状態管理ライブラリを選定する機会があり、調査していく中で得た知見を共有したく、執筆に至りました。 少しでも状態管理ライブラリの選定に困っているFEエンジニアの参考になればと考えています。 はじめに 概要 前提 課題感 Context APIの思想とのズレ Context APIの記述量の多さ 状態管理ライブラリに求める要素 小さい単位で取り扱い可能 ボイラーテンプレートが少なく、APIが直感的で書き方の自由度が高くない 軽量 Reactアプリケーション内外での状態管理が可能 最終決定 検討候補 Redux Zustand Jotai Valtio 評価表 移行設計 既存C
2023年に使った技術・作ったもの・書いたものまとめ
2023 年に使った技術まとめ 2023 年もそろそろ終わりなので、今年のエンジニア生活のまとめです。 正直今年はほとんど仕事しかやっていないです。どうしてもお仕事だと攻めた技術選定ができなくて（記事書くには）あんまり面白くないなあ…の気持ちではあるんだけど、その分実務でこんな技術使ってますよ、ってお話としてみていただければ幸いです。 React 18 / TypeScript 去年（2022）までは Vue と React 半々くらいで生きてたんだけど、今年はどっぷり React でした。 Vue の選択肢もないわけではなかったんだけど、ある程度の規模のプロジェクトで、かつアプリケーションとしての複雑度が高いものを作る時に Vue はやっぱりちょっと怖いんですよね。。正直コントロールできる自信がちょっとない。 多分当面は、ロジックの複雑度や抽象度が高いものは React、ロジックは素直で
【2024年1月】Next.js での新規アプリの構成 & Next.js ディレクトリ構成(features)
選定の方針 ログインしての利用がメインで、ユーザーがあまり多くないサービスを想定しています。 開発効率の重視して、出来るだけWebアプリに集中できる構成を目指しています。 コスト理由で中断しないように、個人でも支払える費用感を意識しています。 Next.js ライブラリ構成 メインで使っているライブラリです。Next.js + Vercelの開発体験が良すぎるので、できる限り活用して開発することを意識して作っています。 フレームワーク Next.js メインで使うライブラリ SWR tRPC React Hook Form Jotai Style/CSS に関して Vercelがリリースしたv0をいいなと思って、v0の出力で使われているTailwind CSS + shadcn/uiを使うようにしています。(v0活用は検証中です) よく使うインフラ系サービス Vercel: Gitにpus
2024年3月15日の一粒万倍日に、mosya ReactというReactを学習できるサービスをリリースしました。 こちら1年間の開発期間を経て、ようやくリリースできました！ mosyaの開発期間と合わせると約2年間の開発期間を経てのリリースとなります。 いやー、長かった！ 良かったら下のリンクから試してみてください！ どんなサービスか mosya ReactはReactをオンライン上で学習できるサービスです。 エディターに書いたコードがリアルタイムにプレビューできるようになっていて環境構築なしでReactを学習できます！ 採点機能が搭載されているのでReactを自学習したい方におすすめです！ このサービスの開発で特に頑張ったのが以下の特徴です！ 最新の技術にキャッチアップしている ライブラリの型がエディター上で確認できる Biomeを動かしていてリントエラーがエディター上で確認できる 最
Webフロントエンドの複雑な状態同士の依存をzustandを使ってリアーキテクチャする - KAKEHASHI Tech Blog
この記事は秋の技術特集 2024の 7 記事目です。 カケハシのAI在庫管理チームでフロントエンドエンジニアをしているNokogiri です。今回はAI在庫の入庫ダイアログを zustand を使ってリアーキテクチャした事例を元に取り入れたプラクティスを紹介したいと思います。 イントロ AI在庫では、ユーザーの入力を伴うフロントエンド部分で多くのケースに React Hook Form を利用しています。 React Hook Form は、入力フォームの状態管理やバリデーションを簡単に実装でき、パフォーマンスにも優れた素晴らしいライブラリです。 しかし、ユーザーの操作に応じてインタラクティブに変化する UI では、状態管理が複雑化し、コードの可読性が低下することがあります。その結果、バグが発生し、予測しにくい動作を引き起こすことも少なくありません。 そこで今回は、 zustand を導入
フロントエンドの状態管理の改善に対する取り組み
こんにちは！株式会社COMPASSの井上です。プロダクト開発ユニット、システム開発部、アプリケーション開発チームに所属しています。普段はキュビナマネージャー（QM）のフロントエンドエンジニアとして、新規機能の開発、既存機能の改修などを行っています。海外を放浪することが好きで、コロナの時には一度断念せざるを得ませんでしたが、最近ではベトナムやタイに滞在していました。今後は東南アジアの様々な国を訪問してみたいと思っています。 本記事では、キュビナのフロントエンド開発における状態管理について、現状抱えている課題とその解決方針について書いていきます。現在取り組み中の内容になっており、ある程度大きな方針については検討をしているものの、解決までの道のりはまだ少し長いかなという状況です。ですが、少しでも共通の課題を抱えている方々の参考になればと考えています。 この記事はこんな方におすすめ キュビナ（特に
こんにちは、Jotaiの作者です。Jotaiが生まれるまでに様々な取り組みをした歴史を短い記事にしてありますのでよろしければご覧ください。今後のJotaiの発展に期待します。 以下、ChatGPTによる翻訳です。 はじめに この投稿では、なぜ私がJotaiの開発を始めたのか、その背景にあるストーリーを共有したいと思います。JotaiはしばしばRecoilと似たような解決策と見なされますが、その開発にはもっと長い歴史があります。 React Hooks React Hooksが最初に発表されたのは2018年10月のことでした。Reactコンポーネントの外でロジックを開発するというアイデアが気に入り、すぐに多くのライブラリがこのアプローチを採用するだろうと考えました。何か開発したいと思い、グローバル状態管理という分野を選びました。私のモチベーションは、Reduxのセレクター、当時「mapSta
Hanabi.REST AIにHonoJSのバックエンドを書かせて遊ぶ、Hanabi.RESTというサービスを一般公開します。それに際して、この記事では、Hanabiの紹介と簡単に技術スタックを解説していきます。 皆さんは、AIがプロンプトからUIを生成する、V0というサービスをご存じですか？僕はあれを見たときに、ある妄想が膨らみました。 「V0のAPI版があれば、プロンプトからWebアプリケーションを作れるやん！！」と。 当初はハッカソン用の小プロジェクトとして始めましたが、想定以上に面白い結果が得られたため、開発を継続することにしました。技術的な制約、様々な黒魔術による不安定な挙動、LLMの劣化など、数多くの壁を乗り越えながら、約半年をかけてようやくリリースに至りました！！ 次のリンクから実際にAIが生成したTwitter風のAPIを試すことが出来ます！ また、会員登録すれば誰でもAP
ダイアログもアラートも、Reactで子コンポーネントの開閉管理を実装する | フューチャー技術ブログ
Reactでは、画面に関わる表示の制御はかならず何かしらのステート管理を行いそれで行います。ダイアログの場合は開閉をuseState()で作ったフラグで管理するみたいな感じです。 たとえば、ウェブブラウザのJavaScriptから呼べるalert()やconfirm()は、関数を呼び出せばダイアログが表示されますし、ダイアログが閉じたら処理が戻ってきます。confirm()ならユーザーが選択したものと一緒に返ってきます。標準の<dialog>タグが今時ですが、このタグはDOMインスタンスのshowModal()やshow()メソッドを呼ぶ必要があります。命令志向ですね。 一方、Reactでダイアログを実装する場合を考えます。メソッド呼び出しが直接扱えればシンプルですが、Reactでは基本的にステート管理でやりましょう、というのが流儀です。useImperativeHandle()を使うとか
【海外記事紹介】フロントエンドの状態管理ライブラリを比較する ー Redux/MobX/NgRx/Pinia/Recoil/Jotai
2月3日、LogRocketが「TypeScriptの状態管理ソリューションを比較する」と題した記事を公開しました。この記事は海外で非常に好評を博しており、日本のエンジニアにも有益な情報となると考え、概要を紹介します。 2月3日、LogRocketが「TypeScriptの状態管理ソリューションを比較する」（Comparing TypeScript state management solutions）と題した記事を公開しました。 この記事は海外で非常に好評を博しており、日本のエンジニアにも有益な情報となると考え、概要を紹介します（詳しくは元記事をご覧ください）。 この記事では、フロントエンド開発における状態管理に焦点を当て、特にReact、React Native、Vue、およびAngularなどと合わせて使用するTypeScriptライブラリについて詳しく紹介されています。 Redux
Why Elixir Is the Best Language for Building a Bootstrapped, B2B SaaS in 2024 | SleepEasy Website Monitor
Why Elixir Is the Best Language for Building a Bootstrapped, B2B SaaS in 2024 [This article is the companion to my presentation for CodeBEAM America 2024, Elixir is the One-Person Stack for Building a Software Startup. You can download the slides as a PDF or view them in Google Slides.] I’d like to share why I chose Elixir as the programming language (and really, as we’ll discuss, the full stack)
はじめに 今フロントエンド/バックエンドの垣根を超えて巷を賑わせている T3 Stack について調べてみました。要素技術一つ一つが濃密なので、本記事ではあまり深入りはしませんが、「それらがどういう旨みを持ってT3 Stackを成しているのか」、「少し動かしたことがあるよ」と読み終わる頃には人に説明できるようまとめてみました。 キーワードは full-stack typesafety(フルスタックな型安全) です。📝 T3 Stack T3 Stack とは、Theo 氏によって提唱された Web 開発技術スタックで、以下の思想に焦点を当てています。 simplicity(シンプルさ) modularity(モジュール性) full-stack typesafety(フルスタックな型安全) The “T3 Stack” is a web development stack made by
Jotaiのatomを自由にテストしたいときに見る記事
Jotaiのテスト方法に関する記事があんまりないので書きました。 公式ドキュメントにもテストに関するページはあるのですが、わりとあっさりしていて実際テストしようと思うと手探り感が強いです。 この記事では、公式の内容に加えて、Reactに依存せず必要なatomのみをテストする方法をまとめます。 環境＆バージョン viteのテンプレでReactのアプリを作って、JotaiとVitestを入れます。すべてテンプレのデフォルトまたは執筆時の最新版です。そのほかlinter等（biome, eslint）は好きに調整してください ※ 後述しますが、テストのやり方によってはここまでフルセットに色々入れる必要はないこともあります。ここに書いたのこの記事で書かれているテストを動かすための全部入り構成です。 { "dependencies": { "jotai": "^2.10.0", "react": "
ハナユメのフロントエンドにSvelte/SvelteKitを採用しています - Ateam Tech Blog
こんにちは。エイチームライフデザインでハナユメという結婚式場情報サイトの開発を行っている大江です。 ハナユメは長い間、PHP/Symfonyを用いて開発・運用されてきました。しかし、プロダクトの成長と機能の複雑化に伴い、技術的負債が蓄積してきました。そこで、数年前からこの課題を解消するために、フロントエンドをSvelte/SvelteKitで置き換えるプロジェクトを始めました。現在では、検索ページ、式場詳細ページの一部、リングページなどいくつかのページをSvelte/SvelteKitでリリースしています。 今回は、Svelte/SvelteKitを選んだ理由や、実際に導入してみて感じたことについてお伝えします。 Svelte/SvelteKitを選んだ理由と実際に開発して良かったこと コード量が少なく書ける 以下は、ReactとSvelteで入力内容を同期してテキストを表示するコンポーネ
🥳 前置き：君は最高のバウンディングボックスを知っているか 🥳 「バウンディングボックス is 何？」って方、これです↓ 出典： 複雑GUIの会( https://scrapbox.io/guiland/ ) イラレやFigmaのようなデザイン系のアプリには100%用意されてる、あのハコです。 知らん人にはマジどうでもいい話かもなのですが、GUI沼界隈においてはこのバウンディングボックスはHelloWorldであり鬼門であり永遠に辿り着けない理想の終着駅です。 界隈の人間が新しいプロダクト作る時は、とりあえずフルスクラッチでバウンディングボックスから作り始めたりするし、勉強会で集まるとバウンディングボックスだけで2時間くらい語れる人がウヨウヨでできます。 それくらいみんな大好きバウンディングボックス。既に若干引かれていそうな気もするけど、この記事はそんな憎愛を前提に温かい目でお読みくだ
はじめに React Developer Roadmap 2024 を眺めつつ筆者の独り言を書く記事です。筆者の React 歴は 3 年ちょっとです。 Visit JavaScript Roadmap React のロードマップは JavaScript の勉強が最初。Promise を基本とした非同期処理やクロージャ周りを理解しておくと、React への理解も更に深まった記憶がある。 非同期周りはこの本に助けられた。 CLI Tools Vite Create React App 新規に CSR の SPA を作る場合 Vite 一択だと思う。理由は、設定簡単 + 早い + 拡張性 ◎ + エコシステムが大きい。Vite は SSR もできるがライブラリ作者向け。 (宣伝) Vite を使用した環境構築方法は先日記事にしました。 なぜ Create React App が使われなくなりつ
eslint-plugin-import-accessで「そこからそれはimportしないでください！！」を防ぐ
eslint-plugin-import-accessで「そこからそれはimportしないでください！！」を防ぐ この記事は 株式会社ゆめみの23卒 Advent Calendar 2023 16日目の記事です。 3行で eslint-plugin-import-accessで「ディレクトリの他の階層からimportしてほしくないメンバ」を定義できるよ！ さらに defaultImportability: "package"を指定するとちょっと初見殺し感があるけどかなり強力になるよ！ re-exportを使う場合はビルドパフォーマンスやバンドルサイズに影響する可能性があるから気をつけよう！ eslint-plugin-import-accessとは アプリケーションなどを開発しているとき、あるモジュールの範囲内でのみ使用してほしい（=あるモジュールの中に隠蔽したい）変数や関数を定義したくな
2023 / 2022 / 2021 / 2020 JavaScriptライブラリのトレンドを紹介しているbestofjs.orgが、2023年に最もホットであったJavaScriptライブラリのランキングを発表しました。 選考基準は累計スター数ではなく、『2023年の一年間で増えたスターの数』です。 過去流行っていたけど落ち目となった技術は出てこないので、最近注目されている技術がわかります。 ちなみに総合ランキング1位は2016年～2019年にVue.jsが4連覇、2020年はDeno、2021年はzx、2022年はBunでした。 以下は2023年のランキング、2023 JavaScript Rising Starsの日本語訳です JavaScript ライジングスター 2023 8回目のJavaScript ライジングスターにようこそ！ ここでは、2023年のJavaScriptエコシ
フロントエンド技術選定のヒント 【令和五年度版】 - KAKEHASHI Tech Blog
こちらの記事は カケハシ Advent Calendar 2023 の 4日目の記事になります。 こんにちは。カケハシでエンジニアをしている今川です。 今回はこれからフロントエンドの技術選定をする方向けに、どんな技術・ツールを使えばいいかのヒントになるような記事を書いていきたいと思います。 ただし、本記事では個人的な好みというよりは、npm trendsやGitHub Star Historyなど客観的な指標からどんな技術が世間に受け入れられているかの比較にしていきたいです。 もちろん数値などの比較以外に、ドキュメントを読んだり使ってみたりすることも重要だということは言うまでもないと思います。あくまでも今回の記事が知らないライブラリを知る機会だったり、ヒントになれば幸いです。 もくじ パッケージマネージャ ランタイム フロントエンドフレームワーク レンダリングフレームワーク ビルドツール
個人的にはJotaiの方が大規模開発に向いているのではないかと思うのですが、現状だと大規模開発にはZustandの方が優勢のようです。 質問は「大規模」ではなく「複雑」なので、正確性に欠けますが。 個人的に大規模に向かないと思った一つの理由はSlicingの対応です。もともと、Slicingの仕組みはZustandには備わっておらず、コミュニティによって発展した使い方です。JSの場合はそれほど困らないのですが、TSの場合は型づけが複雑でドキュメントになってはいるものの、自分ではあまり使う気になりません。また、Slicingする場合は、各Sliceが独立するようにNamespacingするのが一般的だと思いますが、それもできません。 Namespacingはだいぶ以前に求められてきた機能ですが、仕組みが複雑になりがちなのと、実現方法が複数あることから、Zustand本体では対応しないことにし
2.状態管理ライブラリとJotai JotaiはReactの状態管理ライブラリの1つです。 Reactでは規模が大きいアプリケーションを開発する際に、多くの状態管理が必要になり、結果的に状態の制御が難しくなって開発効率が低下してしまうことがあります。 この問題を解決するのが、Reactの状態管理ライブラリです。 状態管理ライブラリでは、一般的に次のことができるものがほとんどです。 グローバルに状態を管理する Propsのバケツリレーを少なくする 不要な再レンダリングを防止する 2.1.Jotaiの特徴 Jotaiは以下の特徴を持っています。 シンプルかつ柔軟に開発することできる 軽量なAPI TypeScriptで開発されている 初学者にとって最もJotaiが便利だと感じる場面は「グローバルステートとして状態をシンプルに管理できる」という点にあると思います。 JotaiはReduxやRec
はじめに はじめまして、損保ジャパンDX推進部の辻です。普段はフロントエンドでリードを担当させていただいています。 弊部は約3年前に生まれた新しい組織であり、積極的に内製開発の取り組みを行っています。そんな3年間という短い間でも、MUIを採用して乗り換えるという事象が発生しており、ライブラリ選定における失敗について振り返っていきます。 組織におけるライブラリ採用の参考にしていただければと思います。 最新の状態 ライブラリはなるべく最新に追従していく方針です 言語：TypeScript UI全般：React UIコンポーネント：Radix UI、(+MUI) スタイル：Tailwind CSS グローバルstate：TanStack Query APIキャッシュ：TanStack Query ルーティング：React Router GraphQLクライアント：graphql-request
TL;DR Recoilはもうメンテナンスされていない。理由は不明だが、このプロジェクトは死んでしまった。 メンテナンスされていないライブラリの使用はやめよう、別の選択肢を選ぼう Recoil Meta社が新規に作成した状態管理ライブラリです。この記事はRecoilの解説記事ではないので詳細は省きますが、大変な期待を抱くには十分なほど魅力的なパッケージでした。 ですが Recoilの現在のリポジトリを見ればわかると思いますが、半年以上前に更新が止まっています。 おそらく、recoilプロジェクトは凍結されました。 つまり、もう更新は期待できないということです。 どうしてこのような状況になったのか どこかの会社が所有しているOSSプロジェクトが凍結される理由は、ビジネス的な問題か、主要コントリビューターが会社を去った場合に起きると考えられます。そして、Metaは規模にかかわらずここ最近ニュー
JSer.info #709 - TypeScriptのTranspilerであるoxc-transformがαリリースされました。 Oxc Transformer Alpha | The JavaScript Oxidation Compiler Rustで書かれたTypeScript to JavaScriptのtranspilerで、isolatedDeclarationsに対応した型定義ファイルの生成にも対応しています。 The Nine Node Pillarsは、Node.jsアプリケーションの9つのプラクティスについて書かれたドキュメントです。 次のような項目について、Node.jsでのアプリケーション開発について書かれています。 イベントループをブロックしない メトリクスを監視して行動する Node.js LTSを使う テスト、レビューなどの自動化 依存関係の管理、mono
状態管理ライブラリ Jotaiの使い方
今回は React アプリケーションの状態管理ライブラリの中でも人気の高い "Jotai" の使い方を記事にしたいと思います。豊富な機能の中から本記事では以下の機能について記載しています。 atom, useAtom, useSetAtom, useAtomValue atomWithReset, atomWithLocation ( searchParams ) Read Only Atom, Write Only Atom Atom Creator 記事内に掲載しているソースコードは Github でも確認できます。 Jotai とは 🤔 Jotai は @dai_shi さんが作った React アプリケーションのための状態管理ライブラリです。軽量で使いやすく主に次のような特徴があります。 Atom（アトム）と呼ばれる小さな単位で状態を管理できる 使い方が直感的で、学習コストが低い
ReactのContextに関する内容で、stateとsetStateを1つのvalueにまとめるとパフォーマンスが悪くなるので分けたほうがいいというものがあるが、果たしてそれは本当に最善なのだろうか？ はじめに なんとなく使っていた React の Context について、ちゃんと理解できていなかったので深掘りしてみる。 検索してみるといくつかの記事で、コンテキストを使用するときのアンチパターンとして「state,setState を同じオブジェクトに入れるとパフォーマンスが悪くなる（再レンダリングが多く発生する）」というものがあった。 確かに、パフォーマンスが悪い場合にそれがボトルネックになっている可能性はあるので分ける方が良い場合もあると思うが、分けることによってコードを書く量が増えるなどデメリットもあるので、普段Contextを扱う際には何を意識するのが良いかを考えてみる。 ちな
Theme 第 137 回のテーマは 2023 年を振り返る Yearly Ecosystem です。 Show Note 今年のキーワード Jxck Rome to Biome RSC Next App Router React - Next のごちゃごちゃ感 Hono + JSX CSS in JS -> Modules Rust 化 Sakito Rome と Biome AI UI ツール周りの進化 Figma とか AI とか Storybook 連携とか Storybook コピペで利用できる UI ライブラリが増えそう Hiroppy RSC, Server Actions toolchain の変化 bundler Bun rspack turbopack vite (esbuild, rollup + rolldown) linter, fmt oxlint biome
Reactの状態管理の比較(useState, useReducer, Redux, Jotai, Zustand) - Qiita
Reactの状態管理の比較(useState, useReducer, Redux, Jotai, Zustand)JavaScriptTypeScriptReactreduxNext.js
社内の「強い思想を語るLT会」で使用した資料です。 筆者はHaskellやF#、RustなどResult型ネイティブな言語が好みの人間なので、だいぶ偏った見方になっている点はご了承ください。 はじめに みなさん、Result型(Either型)ってご存知ですか？ HaskellやElm、Rust、Kotlin、Swiftなどモダンと言われる言語には大体実装されている型です。 筆者は最近、理想のResult型ライブラリを求めて自作するに至りました。 どんな型？ ざっくり表現すると処理に失敗する可能性があることを示す型です。 （Monadとか細かい話は置いておく） 言語やライブラリによって命名などが微妙に異なりますが、TypeScriptで示すとこんな感じになります。 // どれもやってることは同じ type Result<T, U> = Success<T> | Failure<U> //
元React開発者から見たVue開発の勘所: Vue開発の現場からお届け - GROWTH VERSE TECH BLOG
はじめに 株式会社GROWTH VERSE（以下GV）でフロントエンドエンジニアをしている杉浦です。業務ではVueを利用してAIMSTARの画面を開発しています。また、新規プロダクトをNextで開発しています。GVに入社する前は業務・個人開発等で主にReactを5年ほど書いていました。 この記事では、もともとReactを書いていた私が、Vueを書き始めた際に感じた、違和感や気づきをお伝えすることで、これからVueに挑戦しようとしているReact開発者の一助になれば幸いです！ *この記事では、Next.jsやNuxt.jsなどのSSRのフレームワークについて触れていません、Viteを使ったSPAの開発を前提にお話しします。 TL;DR React開発者がVueでの開発に混ざったことで気付いた点をまとめると以下です。 コンポーネント設計で考慮することはほぼ一緒 Custom Hooksを使った
Zustand、君に決めた！！ (AI Radio Makerの状態管理にZustandを選定した経緯)
TL;DR AI Radio Makerでは画面横断での状態の管理があるのでグローバルな状態管理をしてます 以下の理由でJotaiかZustandがいいと思った。 Next.jsのApp Routerを使っていると、できればProviderを使いたくなかった。 できるだけシンプルに使えるものがいい。 useReducer+useContextはProvider使うしボイラープレートが多く使いたくなかった Atom型だとAtomを各々作りすぎて共通化するべきAtomも共通化されず、値が重複し、修正が大変になる可能性があると思い、Store型のZustandがいいとおもった。 状態が増えたらSliceをつかったモジュール化しよう。 メンタルモデルが違うだけでできることは変わらないから好みで選択してもいいと思う。 はじめに 現在私はAI Radio Makerのフロントエンド開発をお手伝いしてい
How Jotai Was Born
Introduction In this post, I would like to share the story of why I started developing Jotai. While Jotai is often seen as a similar solution to Recoil, there is a longer history behind its development. React Hooks It was October 2018 when React Hooks were first announced. I liked the idea of developing logic outside of React components, and believed that many libraries would soon adopt this appro
概要 Jotai, primitive and flexible state management for React Jotai は Recoil からインスピレーションを受けて開発されたグローバルステート管理ライブラリです。コア API が厳選されており良い意味で少なくて機能もシンプルなので Recoil を利用した事がある人であれば直ぐに理解できるでしょうし、そうでない人でも useState に近い使用感なので比較的直ぐに理解して使えるようになると思います。 他のグローバルステート管理ライブラリと共通する Context や useState だと起きやすい以下の問題を解決します。 props のバケツリレーによる依存関係や影響範囲の複雑化 多数の Provider を管理することによる複雑化 これらの影響による過剰なメモ化による再描画対策 Recoil と比較した特徴としては T
kymmtです。 一休では、技術力の底上げを目的として、さまざまな社内勉強会を開催しています。この記事では、今年2024年に入って社内で実施していた勉強会について紹介し、一休での勉強会の雰囲気を伝えられればと思います。 一休の社内勉強会 2024年にこれまで実施した勉強会 『A Philosophy of Software Design』輪読会 『Webフロントエンド ハイパフォーマンス チューニング』輪読会 フロントエンドワークショップ: Reactハンズオン 2024年の今後の勉強会 一休の社内勉強会 社内勉強会は輪読会の形式で実施することが多いです。参加意欲の高い人ができるだけ多く参加できる曜日と時間を決めて、週次で開催する形式をとっています。 読む本の決め方については、ボトムアップで決めることが多いです。先日は、次に読みたい本をSlack上でPollyを使った投票形式で募り、『なっ
Deno で本格的な Web システムを作るためテンプレートを作ってみた。 deno-vite-react-template deno-hono-api-template backend と frontend で完全に分かれていて RESTful API で通信するようにした。 仕様 deno-vite-react-template Deno, Vite, React による構成 (vite-deno-plugin を使った) Routing Library として wouter UI Library として Chakra UI 全体的に jotai, jotai-tanstack-query を活用してAPI通信のキャッシュなど行っている react-if は便利なので皆使ってほしい deno-hono-api-template Hono による RESTful API サーバー RPC
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL
Reactを学習できるサービスmosya Reactの技術的な紹介
Jotaiはどのようにして誕生したのか、単なるRecoilの代替手段なのか？
プロンプトからREST APIを作るサービス『Hanabi.REST』の技術構成
【今さら聞けない?!】T3 Stack によるフルスタックWebアプリ開発 - Qiita
🎉🎉最高にイカしたバウンディングボックスを紹介するぜ🎉🎉 - Qiita
React Developer Roadmap 2024 を眺める
【JavaScript】JavaScript ライジングスター 2023 - Qiita
Zustandって大規模な状態管理に使えるの？Zustand-Slicesを作ったワケ
初学者でも分かるようにJotaiを丁寧に解説していく - Qiita
【フロントエンドエンジニア0人スタート】組織におけるライブラリ選定と移行理由〜さよならMUI〜
Recoilは状態管理の選択肢ではなくなってしまった
2024-10-01のJS: Oxc Transformer Alpha、Node.jsの9つの柱、Express 5.0 pre-release
React Contextのアンチパターンは本当にアンチパターンなのかを考える
ep137 Yearly Ecosystem 2023 | mozaic.fm
とりあえずTypeScriptの例外処理にはResult型を使っておけ - Qiita
React の状態管理ライブラリ Jotai の詳説と Tips
一休の社内勉強会のご紹介2024 - 一休.com Developers Blog
DenoでHonoやReactを使ったテンプレートを作ってみた - ハッカーと漫画家