加速するコンポーネント設計入門 / Component Design as an Accelerator社内勉強会用 デザイナーとフロントエンドエンジニアの境界をなくし、UI開発を加速させるためのコンポーネント設計入門 ※フロントエンドエンジニア視点 [Keywords] - 共通認識としてのデザインシステム - 共通認識としてのコンポーネント設計
AtomicDesign 境界線のひき方
AtomicDesign はコンポーネント粒度の指標として共有し易く、多くのプロジェクトで採用されています。しかしながら、その設計概念が先立ってしまい、いくらかの課題を抱えている場合があります。 1.影響範囲が特定しにくい 2.依存関係が特定しにくい 3.汎用性が低くなりがち 4.汎用性の高低が判別できない 多くの場合「粒度」だけを基準にしてしまい、横断的コンテキストに「早期区分」 してしまっていることが直接的原因です。 「関心範囲の広さ」区分 アプリケーションを構成するモジュールは「関心範囲の広さ」で区分を行うことが鉄則です。次の２つのhelper.tsを見てください。全く同じ関数が定義されていたとしても、どこで利用される想定のものなのか、すぐに判別できますね。utilsは、プロジェクト内で横断的に再利用される可能性が高い（関心範囲が広い）ものが集約されます。 AtomicDesign
React Component Composition Explained | Felix Gerschau
reactReact Component Composition ExplainedLearn how to use component composition to organize your code and improve performance. Component composition is a powerful pattern to make your components more reusable. If you are already familiar with React, you're probably already using it (maybe without knowing its name). This article will explain what component composition means and how to use it. Afte
React components composition: how to get it right
12-04-2022Nadia Makarevich React components composition: how to get it right What is components composition? How do you know when to start splitting a big component into smaller pieces and how to compose them properly? What makes a good component? Community-supported translations : 汉语 One of the most interesting and challenging things in React is not mastering some advanced techniques for state ma
Flexible Design System Components With "as/is" Props
The "as" prop causes a component to render using the specified element Background Implementing a high-quality design system requires clear goals, common shared values and a consistent approach that strikes a fine balance between flexibility and a constrained design. The components in a design system are built upon these patterns and standards. While a full discussion on building design systems is
Atomic Designをやめてディレクトリ構造を見直した話｜食べログ フロントエンドエンジニアブログ
こんにちは。フロントエンドチームの金野と申します。 食べログでは現在、React+TypeScriptでフロントエンドのリプレースを進めています。 以前の記事で、食べログではAtomic Designをどのように取り入れているかの紹介をしました。 しかし、最近のリプレース作業では、Atomic Designとは異なるディレクトリ構造を採用しています。 今回の記事では、「なぜAtomic Designをやめたのか」という理由と、「どのようなディレクトリ構造にしたのか」を紹介します。 Atomic Designを導入したねらいと導入した結果 上記の記事で言及した通り、当初Atomic Designを導入したねらいは以下になります。 1. コンポーネントの責務がより明確になる 2. 見た目の粒度だけでなく、ロジックの責務も明確にできる 3. 「ドメインが入るか／入らないか」。「抽象的か／そうでな
SPA Componentの推しディレクトリ構成について語る
こんにちは、よしこです。 この記事は 2020年に立ち上げたWebフロントエンド構成の振り返り の「Componentのディレクトリ構成」項の詳細記事です。単体でも読めますが、よければ元記事もあわせてどうぞ！ この記事では、今わたしが 株式会社ナレッジワーク というスタートアップで開発・運用しているプロジェクトにおいてうまくいっていると感じているComponentのディレクトリ構成についてご紹介していきます。 ディレクトリ構成 Componentは src/components の中にまとめていて、その下に以下の4種類の分類ディレクトリを切っています。 src/components/page src/components/model src/components/ui src/components/functional 分類ディレクトリを考えるにあたって重視したポイントは以下。 新しくco
CSSとコンポーネント設計に対する考察 - uhyo/blog
近年のフロントエンド開発にはコンポーネントという概念が付いて回ります。React・Vue・AngularといったViewライブラリでは、コンポーネントを定義してそれを組み合わせてアプリを作ります。また、いわゆるWeb Componentsとして知られる仕様群により、ライブラリに依存せずに“コンポーネント”を作ることもできるようになってきています。 コンポーネントは、何らかの機能（あるいは責務）を持った部品です。また、コンポーネントによっては再利用される（アプリ内の複数の箇所から利用される）ことを意図しているものや、そもそもライブラリとして配布されているようなものもあります。アプリの機能の一部分を抜き出したものという見方をすれば、コンポーネントというのは関数にとても類似した概念であることが分かります。 コンポーネント設計によって、言い換えればアプリがどのような機能を持ったコンポーネントたちに
CSS設計における、すべてがコンポーネントであるという誤謬
後日追記: WEB+DB PRESS Vol.133でさらに詳しく書いた。 BEMによってもたらされた、コンポーネントベースのアプローチでは、「ページはコンポーネントの集合によって表現されるべきであり、ページに含まれるのはすべてがコンポーネントである」と考える。しかしこれまでCSSを書いてきた経験から、これではデザイン意図をまともに表現することができないと感じ始めた。なぜなら、普通デザイナーはページのすべてがコンポーネントであるとは考えないからだ。 もちろんページの構成要素のなかには、明らかにそれが「コンポーネント」であると意識して作られたものもある。ただしそれは一部であり、全部ではない。「コンポーネントもあれば、コンポーネントではないものもある」という感覚のほうが普通なのだ。 典型的なUIライブラリにある、「ザ・コンポーネント」みたいなものだけではページは完成しない。例として、一貫してB
Overview
Why use ViewComponents? TL;DR ViewComponents work best for templates that are reused or benefit from being tested directly. Partials and templates with significant amounts of embedded Ruby often make good ViewComponents. Single responsibility Rails applications often scatter view-related logic across models, controllers, and helpers, diluting their intended responsibilities. ViewComponents consoli
Encapsulating Ruby on Rails views
EngineeringEncapsulating Ruby on Rails viewsLearn more about how we are bringing encapsulation to our views as we scale to over 4,500 templates in our Ruby on Rails monolith. With the recent release of version 6.1, Ruby on Rails now supports the rendering of objects that respond to render_in, a change we introduced to the framework. It may be small (the two pull requests were less than a dozen lin
Introduce support for 3rd-party component frameworks by joelhawksley · Pull Request #36388 · rails/rails
Note: This PR initially was titled: Introduce support for ActionView::Component. I've updated the content to better reflect the changes we ended up shipping, to use the new name of GitHub's library, ViewComponent, and to remove mentions of validations, which we no longer use. - @joelhawksley, March 2020 Introduce support for 3rd-party component frameworks This PR introduces structural support for
VueコンポーネントのState管理を考える - 一休.com Developers Blog
この記事は一休.comアドベントカレンダー2018の3日目の記事です。 qiita.com 宇都宮です。宿泊事業本部でWebフロントエンドの開発をしています。 一休.comにVue.jsを導入して、約1年が経ちました。スマートフォン版の予約入力画面から始まり、PCとスマートフォン版のホテルページほか、さまざまなUIコンポーネントがVue.jsで実装されるようになってきています。 また、予約入力画面のような複雑な状態管理を伴う画面の実装のため、Vuexを導入しています。 ここ1年ほどVue.js + Vuexというスタックで開発を行ってきて、アプリケーションの設計について色々と思うところがあったので、今回は現状でどういう構成が最適と考えているか、紹介します。 Vue.jsアプリケーションのState Vueコンポーネントには、親から受け取るpropsと、自分自身で保持するstate(data
フロントエンドのコンポーネント設計に立ち向かう - Qiita
ReactやVueなどコンポーネントベースで作っていくViewのライブラリが普及したことで、コンポーネント指向での開発が一般化してきた昨今のフロントエンドですが、このコンポーネントの設計に悩まれる方も多いのではないでしょうか。 コンポーネントをどの粒度、どんな状態で分割するのが良いのか、などなど、特にチームで開発する時に認識が揃っていないとカオスになりがちな部分であると思うので、自分なりの設計をする際の指針を言語化しようというのが本記事の目的です。同じように悩まれている方にも何らか示唆を提供することができたら嬉しいです。 想定読者 「コンポーネント設計？なにそれ？おいしいの？」という方 初めてコンポーネント設計でアプリ作ってみたけど、本当にこれでいいのか自信の無い方 はじめに: "コンポーネント"とは まず最初に"コンポーネント"という言葉についてですが、ここでは「GUIのパーツをモジュー
Composable な UI 設計を目指したフロントエンド開発 | MEDLEY Developer Portal
2018-02-27Composable な UI 設計を目指したフロントエンド開発こんにちは、開発本部の舘野です。医療介護の求人サイト「ジョブメドレー」の開発を担当しています。 昨年、ジョブメドレーでは事業所が利用する採用管理画面の UI リニューアルを行いました。ユーザが使いやすい UI づくりを目指すために、長期間にわたり誰が開発しても一貫性ある UI を実現できるようなシステムが必要です。そこで今回は「Composable」な UI システムの実現をテーマに、どのように開発を行ったのかについて、共有させていただきます。 背景：画面や機能追加のたびに UI の一貫性がなくなっていたジョブメドレーの採用管理画面とは、医療機関や介護施設の採用担当者が求人情報の管理や応募者の選考状況の管理などを行う画面です。 この採用管理画面ですが、リニューアル以前はAngularをフレームワークとして採
2017末時点での React Component 設計のベストプラクティス - Qiita
どう考えているか、というのを聞かれたので、記事に起こしておきます。個人の意見です。 Prettier を使う 気づけばコードの整形を人間がやる時代は終わりました。 細かいコーディングスタイルでレビューの時間を取るぐらいだったら、一貫した自動整形ルールを適用すべきです。 人によっては細かいこだわりがあって prettier の規則が気に食わないかもしれず、僕も最初はそうでしたが、Atomで保存する度に自動整形を走らせる prettier の強烈な開発体験によって、最終的にそれらのこだわりを全て捨てることが出来ました。 生産性を求めるなら、現時点では最優先で導入すべきものです。 React.createClass を使わない v16 で削除されたのでいわずもがな。 同様に、 createClass でしか使えなかった mixin 周辺機能も丸ごと deprecated です。 「可能な限りは」
これからのCSSはmargin禁止！？CSSグリッドレイアウトやコンポーネント指向なCSSについて、矢倉さんに聞いてきた！
これからのCSSはmargin禁止！？CSSグリッドレイアウトやコンポーネント指向なCSSについて、矢倉さんに聞いてきた！ 白石 俊平（HTML5 Experts.jp編集長） こんにちは、編集長の白石です。 この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に語っていただこうとういものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。 今回お話を伺ったのは、ピクセルグリッドの矢倉眞隆さんです。 矢倉さんのセッション「まあまあ最近のCSSとつらくならないための書き方」に関するスライド資料は、こちらで公開されています。 インパクト大！CSSグリッドレイアウト概要 白石: では、まずは簡単に自己紹介をお願いできますか？ 矢倉: 昨年（2
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Don't overabstract your components
How I Would Use a UI Library | Kyle Shevlin
Building component-driven UIs at Spotify