Atomic Designをやめてディレクトリ構造を見直した話｜食べログ フロントエンドエンジニアブログ
こんにちは。フロントエンドチームの金野と申します。 食べログでは現在、React+TypeScriptでフロントエンドのリプレースを進めています。 以前の記事で、食べログではAtomic Designをどのように取り入れているかの紹介をしました。 しかし、最近のリプレース作業では、Atomic Designとは異なるディレクトリ構造を採用しています。 今回の記事では、「なぜAtomic Designをやめたのか」という理由と、「どのようなディレクトリ構造にしたのか」を紹介します。 Atomic Designを導入したねらいと導入した結果 上記の記事で言及した通り、当初Atomic Designを導入したねらいは以下になります。 1. コンポーネントの責務がより明確になる 2. 見た目の粒度だけでなく、ロジックの責務も明確にできる 3. 「ドメインが入るか／入らないか」。「抽象的か／そうでな
バックエンド Web API に管理画面/管理機能を追加するアーキテクチャパターン - valid,invalid
プレゼンテーションレイヤ、いわゆるフロントエンドがクライアントサイドで実装・実行されるアーキテクチャ (注 1) において、管理画面/管理機能をあとから追加する際にどのような実装パターンがあるのかを整理してみます。 注 1: Presentation Domain Separation の実践の中でも、物理的にプレゼンテーションロジックとドメインロジックを分離しているアーキテクチャです。 用語の整理 プレゼンテーションレイヤ 三層アーキテクチャにおける、システムの利用者へユーザインターフェイスを提供する層です。本記事では"フロントエンド"とほぼ同義で使います。 OSI 参照モデルの第六層ではないです。 バックエンド Web API とは プレゼンテーションを持たない Web API (HTTP プロトコルを用いてネットワーク越しに呼び出すアプリケーション) とします。 プレゼンテーションレ
Next.jsに「できるだけ」依存しないReactアプリケーションの構成
TL;DR 本記事で紹介するのは、Redux や React Router を使った React アプリケーション構築時のベストプラクティスを Next.js に適用した考え方です。 Next.js を外部モジュールと考え、Container/Presentation の Container を Adapter 層と見なす考え方 next/router などの Next.js の組み込みモジュール、Store、SWR（React Query） は Container（Pages） 層で利用する Storybook でコンポーネントを表示する際、Next.js 等のモックをできるだけ作らない 但し、Template 層以下の next/link や next/image への依存は制御できない なお本記事では、Next.js の依存層、Pages 層とTemplate 層という言葉は以下のこ
フロントエンドと素朴なコードベース | 雑司ヶ谷インターネット
これは SmartHR Advent Calendar 2020 の4日目に書かれた記事です。今は 12月4日の42時10分なので、ギリギリ滑り込んだ形になってしまいましたね。 React と自由 SmartHR で開発している様々なプロダクトはその大半 1 がフロントエンドに React を採用している。僕も Twitter で「React が好きだ！TypeScript 最高だ！」と叫んでいたら「弊社 React + TypeScript ですよ」というスカウトをいただいて転職に至ったという経緯があって、それぐらい全社的に React をやっていくぞという意志の統一が果たされている。 とはいえ React というのはフレームワークではなく、あくまでも JSX という記法と各種関数のバインディングを通じて宣言的な UI を構築する機能を持ったライブラリに過ぎないので、アプリケーション全体
食べログでのAtomic Design 〜どう分類しているか編〜｜食べログ フロントエンドエンジニアブログ
食べログFE（フロントエンド）チームの金野と申します。 以前の記事で、jQuery+Backbone.jsからReact/TypeScriptへのリプレースを進めていることをご紹介しました。 リプレースした部分では、Atomic Designを採用しています。 今回の記事では、採用した理由や食べログでの分類方針についてご紹介します。 Atomic Designを導入した目的Atomic Designを導入したねらいは以下になります。 ・コンポーネントの責務がより明確になる ・見た目の粒度だけでなく、ロジックの責務も明確にできる ・「ドメインが入るか／入らないか」。「抽象的か／そうでないか」の区別が明確になる ・世間的にも浸透している概念のため、デザイナー・エンジニア間の共通言語を作れる 食べログではもともとUIコンポーネントをFLOCSSの考え方に従ってレイヤー分けしていましたが、以下の課
クライアントサイドのモデルとは何か 前編 ~ クライアントサイド MVC の死 - mizchi's blog
前置き この記事、本来は Flux には Model がないのではないかと思った覚書 - ナカザンドットネット と Flux の Store が ViewModel かって話からの MVW とかどうでもいいって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く のアンサーとして書き始めた記事だが、前置きだけで別テーマとなったので、前後編に分割する。 僕は元々がゲームクライアント屋だったときの発想を引きずってるのと、既存の Web の開発の文脈に対して距離を置いていることを明言しておく。あとこういうテーマでとある原稿書いていたので、頭の整理も兼ねて。 ActiveRecord の功罪を振り返る このテーマを語るにあたって、まず Rails の MVC について述べなければならない。なぜなら、フロントエンドのアーキテクチャとは、サーバーサイドの MVC の模倣に始まり、破綻し、結果として
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
宣言的UI