はてなブックマーク

2023年現在、Reactでは多種多様なスタイリング手法が用意されています。 代表どころで言うとCSS ModulesやTailwind、CSS-in-JSなどが有名です。筆者の個人的な好みでは、これらの選択肢の中でもCSS-in-JSを用いたスタイルが特に好きですが、CSS-in-JSライブラリ群の中にはランタイムでスタイリング処理がなされる為にパフォーマンス上の問題を抱えているとの指摘を受けているものもあり、最近は人気が下火になっているように感じています。 そこで本記事では、CSS-in-JSが生まれた背景から遡り、各ライブラリの内部実装を確認しながらそれぞれのライブラリの仕組み・メリット・問題点を明らかにし、CSS-in-JSのパラダイムシフトを追ってみたいと思います。 CSS-in-JSの登場 CSS-in-JSという言葉が最初に公の場で登場したのは、2014年にFacebookの

こんにちは、THECOO株式会社のpoteboyと申します。普段は現職１人目のWEBフロントエンド開発者としてFaniconというファンコミュニティサービスの開発を行っております。 弊社では私が入社する以前までフロントエンド専任の開発者がおらず、サーバーサイドの開発者やAndroidの開発者がフロントエンドの開発業務を兼務していました。 専任がいなかったのは、Faniconが元々ネイティブベースのアプリで、WEBアプリの開発優先度を下げていたためです。 そのため、フロントエンドの開発環境に関しても万全とは言えず、2022年6月に私が入社し、9月には2人目のフロントエンド開発者となるTomoya氏が入社したタイミングで、2人で協力してFaniconフロントエンドの大改修を行なうこととなりました。 フロントエンド改修業務にはTypeScriptの導入、既存コンポーネントのVue３化、単体テスト

概要 Vueの作者であるEvan You氏は、Vueのデフォルトバージョンが2022年2月7日以降3.x系に切り替わる事を開発者ブログにおいて発表しました。 それに伴い、Vue2.x系の最後のマイナーバージョンであるVue2.7が2022年7月1日にリリースされ、こちらの LTS (long-term support)はリリースから18ヶ月であることから、Vue2.x系へのサポートは2023年12月を持って完全に打ち切られる事となりました。 以下の記事でも語られている通りVue2とVue3では破壊的変更が多く、移行コストが格段に高いことから、多くの開発チームがVue３.x系への移行を頑張るかReact等の他のフレームワークへの乗り換えをするかの選択を迫られています。 3.x系へ移行すべきかフレームワークを乗り換えるべきかの是非についてはこの記事では触れませんが、Vueの破壊的変更に伴って多

エンジニアがFigmaを学ぶ利点 ブラウザ上で共同編集ができるなどの理由から、最近では観測範囲内の多くの企業がFigmaをメインのデザインツールとして採用しています。 一般的にフロントエンドエンジニアはデザイナーがFigma上で作成したデザインファイルを元に実装を進めると思いますが、ここでエンジニア側にもFigmaの知識がある程度あればより円滑かつスピーディにUIの実装が行えるのではないかと考えています。 具体的には、エンジニアにFigmaの知識があることで以下のような利点があります。 デザイナーの意図を汲み取ることができる デザイナーと共通言語で話せる 実装の観点からデザイナーにFigmaの修正依頼ができる ↑の打ち返しを待たずに自分で軽微な修正ができる というわけで、今回はエンジニア目線で実装への応用を交えながらFigmaの基礎知識を解説していきたいと思います。 スタイル Figmaで

const MenuBox = styled.div` dispaly: flex; flex-direction: column; justify-content: center; width: 600px; @media screen and (min-width: 640px) { width: 320px; } ` そしてこれを確認し終えた後はまた次に出現するMenuTitleコンポーネントの定義元を探しに行くという手順を踏むはずです。 このように、styled-componentsでコンポーネントのスタイル定義が別でなされている場合には、逐一定義元に戻って確認作業の繰り返しを強いられることになります。また、その間は周辺コンポーネントの構造も記憶しておかなければなりません。 CSSファイルが別で存在するよりは幾分マシですが、個人的にはこれでもまだしんどい。 加えて、レスポンシブ対応

はじめに Firestore　にはリアルタイムリスナーというとても素敵な機能があり、コンテンツが更新される度に再fetchが走るので、クライアント側での状態管理は　Context API　によるグローバル　state + props　バケツリレーという形に寄せていたのですが、明示的にクリーンアップをしないと　listner　が走り続けると等色々と扱いに注意が必要だったので、最近は（リアルタイム性が必要な部分以外は）通信の状態をすべて　Apollo Client　に路線変更することにしました👶 実際の運用まではまだ行なっていないのですが、一旦　Firestore + Cloud Functions + Apollo　で作った GraphQL サーバーとクライアント側の繋ぎ込みまで成功したのでその方法を書き残してみます。 FirebaseプロジェクトにCloud Functionsを追加 f