CSS in JSとしてVanilla-Extractを選んだ話と技術選定の記録の残し方
インクリメンタルに新しい技術を取り入れる方法では、VueからReactへ段階的に移行していったという話を紹介していました。 このReactの採用を決定してから大きな論点となったのは、ReactでCSS(スタイル)をどのように書くかについてです。 Reactのスタイリング方法には、デファクトと言えるものはありません。 Styling and CSS – React CSSファイルとclassNameを使う方法、CSSファイルをimportするCSS Modules、JavaScriptでCSSを書くCSS in JSなどさまざまな方法があります。 スタイリングライブラリの選定は、表現力はそこまで大きく変わりませんが選択肢が多過ぎます。 そのため、VueやReactを選ぶといった技術選定よりも難しい部分があります。 KARTE Blocks(以下、Blocks)では、最終的にReactのスタイ
Utility First な CSS in JS フレームワークの導入と３ライブラリの比較 - JX通信社エンジニアブログ
JX 通信社のフロントエンドでは React TypeScript や Emotion のような CSS in JS を技術選定することが多いです。弊社 SaaS の FASTALERT、新型コロナ関連情報などでも同様の技術選定で、過去にもエンジニアブログで紹介してきました。 tech.jxpress.net tech.jxpress.net 今日は、Emotion の活用の極地「Utility First な CSS in JS フレームワーク」についてご紹介します。 Emotion で開発する悩み 素の Emotion や類似の CSS in JS ライブラリでは、 1 つの TS/JS ファイル内に CSS を書くような感じでスタイル設定を行っていきます*1。CSS in JS ライブラリに概ね共通しているのが、 styled.タグ名 でスタイリングすることです。 const Tit
レシピサービスのフロントエンドに CSS in JS を採用した話 - クックパッド開発者ブログ
こんにちは。技術部クックパッドサービス基盤グループのkaorun343です。我々のチームでは レシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話 にて紹介したとおり、レシピサービスを Next.js ベースの新システムへと移行しています。今回はこの新システムの CSS の話 です。 背景 クックパッドのレシピサービスを Next.js と TypeScript で置き換えはじめた当初、CSS については Next.js に標準で組み込まれているCSS in JS ライブラリである styled-jsx を使っていました。プロジェクトが大きくなりはじめたタイミングで 「CSS の技術選定を考えなおしてもいいかもしれない」とチームの中で話し合い、改めて技術選定をしました。 技術選定 結論として、本システムでは CSS in JS ライブラリのem
CSSとコンポーネント設計に対する考察 - uhyo/blog
近年のフロントエンド開発にはコンポーネントという概念が付いて回ります。React・Vue・AngularといったViewライブラリでは、コンポーネントを定義してそれを組み合わせてアプリを作ります。また、いわゆるWeb Componentsとして知られる仕様群により、ライブラリに依存せずに“コンポーネント”を作ることもできるようになってきています。 コンポーネントは、何らかの機能（あるいは責務）を持った部品です。また、コンポーネントによっては再利用される（アプリ内の複数の箇所から利用される）ことを意図しているものや、そもそもライブラリとして配布されているようなものもあります。アプリの機能の一部分を抜き出したものという見方をすれば、コンポーネントというのは関数にとても類似した概念であることが分かります。 コンポーネント設計によって、言い換えればアプリがどのような機能を持ったコンポーネントたちに
ReactやAngular、VueなどでComponentのスタイリング時に抑えておきたいこと
なんとなく自分の中で言語化しておきたかったので、整理も兼ねて記載しておきます🙆🏻♂️ 普段仕事で様々なAngular、またはReactのコンポーネントを作ったりメンバーから出るPRを読む中で、コンポーネントのスタイルはどういうふうに当てるのが破綻しにくいんだろうと考えていました🤔 Angularは良くも悪くも一つのComponentが結構おっきくなりがちだったのでそこまで意識しなかったですが、Reactは何なら分割しないと気持ち悪いとすら思えるくらいにコンポーネントを分割しやすいです。 コンポーネントを分割することは各ファイルごとに把握すべき事柄が減るので基本的にはいいことだと思っていますが、スタイリングについては意識しないと破綻してしまうなーと思っています。 （もちろん、スタイリングに限らず意識しないと破滅するんだけど、今回はスタイルについての話です） スタイルの破綻っていうのは
まとまったCSSを別のコンポーネントに分けないでほしい話 - uhyo/blog
この記事は、ReactでCSSを書くときに関連したCSSを別々のコンポーネントに分けるのをやめようという記事です。主な理由は、スタイリングという機能が複数コンポーネントに分散するのを防ぐためです。これには修正時に複数コンポーネントにまたがって修正が必要になるのを防ぐという意味もあります。 Flexboxの例関連したCSSが複数の要素に分かれることはよくあります。その代表例がdisplay: flexです。例えばこんなレイアウトを考えてみましょう。左側のボックスの幅が決まっていて右側の幅が可変の2カラムレイアウトです。 左のカラム (100px)右のカラムこのレイアウトはおおよそ次のように実現できます。 /* 親要素 */ display: flex; /* 子要素（左） */ flex: 100px 0 0; /* 子要素（右） */ flex: auto 1 0;では、Reactではどの
Webサイト開発にCSS in JavaScriptを使うのはやめよう | POSTD
9つのおとぎ話 CSSは迷走しています。JavaScriptでドキュメントをスタイリングしているプロジェクトでは、多くの場合誤った理由からその方式を選択しています。本稿では、よくある誤解（神話）を列挙し、そうした問題に対するCSSソリューションを紹介します。 本稿は、特定のプロジェクトや人物への攻撃を意図するものではありません。ここでは、“CSS in JavaScript”(CSS in JS)を styled-components を使用することと定義します。これは、Reactのコンポーネントをスタイリングする最近のトレンドとなっています。 styled-components の作者である Max Stoiber と Glen Maddern 、また彼らに協力した人々は皆、卓越したアイデアと善意にあふれる優秀な人々です。 完全な透明性のために断っておくと、私は react-css-mo
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
