通常のCSS
Remixは、ネストされたルートとlinks
を使用して、通常のCSSでアプリをスケールアップするのに役立ちます。
CSSのメンテナンスの問題は、いくつかの理由でWebアプリに忍び寄ってくる可能性があります。次のように知ることは困難になる可能性があります。
- CSSをいつどのようにロードするか。そのため、通常はすべてのページにロードされていました
- 使用しているクラス名とセレクターがアプリの他のUIを誤ってスタイル設定しているかどうか
- CSSソースコードが時間の経過とともに増加するにつれて、一部のルールがもはや使用されていないかどうか
Remixは、ルートベースのスタイルシートでこれらの問題を軽減します。ネストされたルートはそれぞれ、独自のスタイルシートをページに追加することができ、Remixは自動的にそれらをプリフェッチ、ロード、アンロードします。懸念範囲がアクティブなルートのみに限定されている場合、これらの問題のリスクは大幅に軽減されます。競合が発生する可能性があるのは、親ルートのスタイルだけです(それでも、親ルートもレンダリングしているので、競合が表示される可能性があります)。
Classic Remix CompilerではなくRemix Viteを使用している場合は、CSSインポートパスの末尾から?url
を削除する必要があります。
ルートスタイル
各ルートは、ページにスタイルリンクを追加できます。たとえば、
これらのルートを考えると、この表は、特定のURLでどのCSSが適用されるかを示しています。
URL | スタイルシート |
---|
/dashboard | dashboard.css |
/dashboard/accounts | dashboard.css accounts.css |
/dashboard/sales | dashboard.css sales.css |
これは微妙なことですが、この小さな機能は、プレーンなスタイルシートを使用してアプリをスタイル設定する場合の多くの難しさを解消します。
共有コンポーネントスタイル
大小さまざまなWebサイトは通常、アプリの残りの部分で使用される共有コンポーネントセット(ボタン、フォーム要素、レイアウトなど)を持っています。Remixでプレーンスタイルシートを使用する場合、推奨される2つのアプローチがあります。
共有スタイルシート
最初の方法は非常に簡単です。それらをすべてapp/root.tsx
に含まれるshared.css
ファイルに入れます。これにより、コンポーネント自体がCSSコードを共有することが容易になり(そして、エディターがカスタムプロパティなどのインテリセンスを提供することもできます)、各コンポーネントはすでにJavaScriptで一意のモジュール名が必要なので、スタイルを一意のクラス名またはデータ属性にスコープできます。
このファイルは大きくなる可能性がありますが、アプリのすべてのルートで共有される単一のURLになります。
これにより、ルートがコンポーネントのスタイルを調整することも容易になり、コンポーネントに公式の新しいバリアントを追加する必要はありません。あなたは、それが/accounts
ルート以外ではコンポーネントに影響を与えないことを知っています。
スタイルの露出
2番目のアプローチは、コンポーネントごとに個別のCSSファイルを作成し、それらのスタイルをそれらを使用するルートに「公開する」ことです。
おそらく、app/components/button/index.tsx
にapp/components/button/styles.css
にあるスタイルの<Button>
と、それを拡張する<PrimaryButton>
があります。
これらはルートではないことに注意してください。ただし、ルートのようにlinks
関数をエクスポートします。これを使用して、それらのスタイルを使用するルートに公開します。
そして、それを拡張する<PrimaryButton>
:
プライマリボタンのlinks
には、ベースボタンのリンクが含まれていることに注意してください。このようにして、<PrimaryButton>
のコンシューマーは、その依存関係を知る必要はありません(JavaScriptインポートと同じです)。
これらのボタンはルートではなく、URLセグメントに関連付けられていないため、Remixはスタイルをいつプリフェッチ、ロード、またはアンロードするかを認識しません。コンポーネントを使用するルートにリンクを「公開する」必要があります。
app/routes/_index.tsx
がプライマリボタンコンポーネントを使用することを考えてみましょう。
これで、Remixはbutton.css
、primary-button.css
、およびルートのindex.css
のスタイルをプリフェッチ、ロード、およびアンロードできます。
これに対する最初の反応は、ルートが望んでいるよりも多くのことを知っておく必要があるということです。各コンポーネントはすでにインポートする必要があるため、新しい依存関係を導入しているわけではなく、単にアセットを取得するためのボイラープレートです。たとえば、次のような製品カテゴリページを考えてみましょう。
コンポーネントのインポートはすでにそこにあり、アセットを公開するだけです。
これは少しボイラープレートですが、次のようなことが可能になります。
- ネットワークタブを制御でき、CSS依存関係がコードで明確になります
- コンポーネントと共存するスタイル
- ロードされるCSSは、現在のページで使用されるCSSのみ
- ルートでコンポーネントが使用されない場合、そのCSSはページからアンロードされます
- Remixは、
<Link prefetch>
を使用して次のページにリンクすると、CSSをプリフェッチします
- コンポーネントのスタイルが変更されても、他のコンポーネントのブラウザとCDNキャッシュは、すべて独自のURLを持っているため壊れません
- コンポーネントのJavaScriptが変更されてもスタイルが変更されない場合、スタイルのキャッシュは壊れません
アセットプリロード
これらは単なる<link>
タグなので、スタイルシートリンク以上のことができます。たとえば、要素のSVGアイコンの背景用のアセットプリロードを追加できます。
これにより、ネットワークタブでアセットが優先順位付けされるだけでなく、<Link prefetch>
を使用してページにリンクすると、Remixはpreload
をprefetch
に変換するため、SVGの背景は、次のルートのデータ、モジュール、スタイルシート、およびその他のプリロードと並行してプリフェッチされます。
リンクメディアクエリ
プレーンなスタイルシートと<link>
タグを使用すると、ユーザーのブラウザが画面をペイントする場合に、ブラウザが処理する必要があるCSSの量を減らすこともできます。リンクタグはmedia
をサポートしているので、次のようなことができます。