You Don’t Need A UI Framework — Smashing Magazine
Developers often reach for UI frameworks like Bootstrap or Material UI, hoping that they’ll save a bunch of time and quickly build a professional-looking app. Unfortunately, things rarely work out this way. Let’s talk about it. Every now and then, someone will ask for my recommendations on UI frameworks. By “UI framework”, I mean any third-party package that is focused on providing styled UI compo
Reactのディレクトリ構成でAtomicデザインをやめた話
Atomic デザインをやめた 結論から言うと Atomic デザインを React のディレクトリ構成に当て込むのをやめました。結構ツラミが出てきてしまった感じです。とはいえ、Atomic デザインを批判するわけではなく、むしろ概念というか考え方は好きな部類です。 あくまでデザインシステムであり、ディレクトリ構成に当て込むべきものではないなと。 以前までのディレクトリ構成はこんな感じ Atomic デザインが話題になった頃からそれに倣ったディレクトリ構成にしていました。Next.js のプロジェクトになってしまいますが大体こんな感じ。 ├── common │ ├── config │ ├── styles │ ├── types │ └── utils ├── components │ ├── atoms │ ├── molecules │ ├── organisms │ └── te
Design Doc for react-boilerplate-2022
これは何? React(Next.js)アプリケーションのテンプレートのための Design Doc React(Next.js)アプリケーションのテンプレートとして実装したリポジトリ shimpeiws/react-boilerplate-2022 の設計についてのDesign Docです SSR/ISRはせずnext exportしてStatic Fileを出力する構成です API Routesを使っていますが、API接続コードをローカルで動作させるためのもので本番動作させるためのものではありません Design Doc 本ドキュメントは実装したリポジトリの構成、ライブラリの選定理由など設計についての背景を示すためのドキュメントという位置づけです 「デザインドックで学ぶデザインドック」(https://www.flywheel.jp/topics/design-doc-of-desig
変更に強いコンポーネント設計の方針と規約（Webフロントエンド） - Sansan Tech Blog
技術本部 データ戦略部 Newsグループの木田です。 最近、初めて自作キーボードに挑戦しました。ちょうど２枚目のモニターも買ったので、モニター２台と自作キーボードで快適に記事を書いています。 予めお断りしておきますが、この記事は元々、社内向けに設計方針や規約・ツールなどについて共有するために書いたものでした。最近、他チームの参考資料として役立ったこともあり、社外向けに手を加えて公開する運びとなりました。 はじめに 機構改革・人事異動情報(β) とは ⚛️ Atomic Design に従う ⚛️ Atomic Design とは ⚛️ Molecules と Organisms の分け方 ⚛️ コンポーネントの設計方法 📝 規約 📝 Component と Container を分ける 📝 データの繋ぎ込みは Organisms 以上で行う 💡 Tips 💡 Atoms はタグ本
Atomic Designをやめてディレクトリ構造を見直した話｜食べログ フロントエンドエンジニアブログ
こんにちは。フロントエンドチームの金野と申します。 食べログでは現在、React+TypeScriptでフロントエンドのリプレースを進めています。 以前の記事で、食べログではAtomic Designをどのように取り入れているかの紹介をしました。 しかし、最近のリプレース作業では、Atomic Designとは異なるディレクトリ構造を採用しています。 今回の記事では、「なぜAtomic Designをやめたのか」という理由と、「どのようなディレクトリ構造にしたのか」を紹介します。 Atomic Designを導入したねらいと導入した結果 上記の記事で言及した通り、当初Atomic Designを導入したねらいは以下になります。 1. コンポーネントの責務がより明確になる 2. 見た目の粒度だけでなく、ロジックの責務も明確にできる 3. 「ドメインが入るか／入らないか」。「抽象的か／そうでな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Patterns.dev
Utopia
