:: ng-deepの代わりに使用するもの


98

ルーターのコンセントによって配置された要素を角度でスタイリングしようとしていますが、生成された要素の幅が100%になるようにします

ほとんどの返信から、::ng-deepセレクターを使用する必要があることがわかりましたが、Angularのドキュメントからは非推奨になっています。に代わるものはあり::ng-deepますか?


2
::ng-deepどこにも行きません。常に有効にできる設定になります。大規模なコミュニティの反発なしに、彼らが今それを取り除くことができる方法は絶対にありません。どのように多くの結果は、この検索に戻ってきて見github.com/search?q=%3A%3Ang-deep&type=Codeそれは、CSSと言ってようなものだ-!importantプロパティが消えるために起こっている
Simon_Weaver

わかりません-私はモノレポ(複数のかなり大規模なエンタープライズアプリ)で好奇心からプロジェクト全体の検索を行いましたが、69件の参照しかありませんでした。私は、それが非推奨から抜け出すための間違いなく許容できるリファクタリングであり、彼らが代替案を出すときはいつでも喜んでそれを行うだろうと感じています。その上、!importantCSS仕様で重要な位置を占めています::deepが、常に提案にすぎませんでした。
dudewad

回答:


109

FWIW私の調査では、ng-deepやその他の適用可能な代替手段に代わるものは見つかりませんでした。これは、AngularチームがShadow domのW3C仕様を延期しているためdeepです。これには、当初はなどのセレクターがありました。ただし、W3cはその後、推奨事項を削除しましたが、新しい推奨事項に置き換えていません。それが起こるまで、Angularチームは維持し::ng-deep、代替手段を利用できると思いますが、W3Cのドラフトの保留状態のため、非推奨の状態になっています。現在、これをバックアップするためのドキュメントを見つけるのに時間がかかりませんが、最近見ました。

簡単に言う::ng-deepと、代替品が作成されるまで、その代替手段を使い続けてください。実際の変更が実現するたびに人々が盲目的になることがないように、非推奨は単なる早期通知です。

-更新-

https://drafts.c​​sswg.org/css-scoping-1/ 興味があれば、ここにドラフト提案があります。彼らはシャドウDOMツリー内の要素の強力なセレクターのセットに取り組んでいるようです。この仕様が承認されると、Angularクローンが存在する場合でも通知されると思います(つまり、ブラウザーで公開された後、Angularは独自のセレクターを実装する必要がない場合があります)。


私はこれに同意しますが、非推奨のフレームワーク(およびブラウザー)機能を使用して意図的に新しいコードを作成することはお勧めしません。
MT_

7
私もそうでしょう。しかし、ここで明確に概説されていると私が思う代替手段はありません。それを助けるための提案はありますか?
dudewad

1
私がすぐに考えることができる唯一の代替案は、コンポーネントのネストをリファクタリングすることです。これは、時間よりも手間がかかる可能性がありますが、他の利点が得られる可能性があります...
MT_ 2018年

36
サードパーティのライブラリを使用する::ng-deepと、角張った素材のようなものであっても、たまに使用する必要がなくなることは事実上不可能です(サイトの外観をまったく気にしない場合)。それらには数ヶ月間修正されないバグがあり、回避策にはしばしばng-deepが含まれます。また、非推奨のさまざまな「ディープ」セレクターを混同しないでください::ng-deep。これは間違いなく非推奨の最も少ないセレクターです。
Simon_Weaver

1
ええ、これはシステム全体の中で最も醜い部分の1つです。しかし、カプセル化はカプセル化とは何かです。cssで:: ng-deepを明示的に使用して境界を破る必要があるか、プログラムで行う必要があります。私たちは時々成分(すなわちコンテキスト)にあるもの「モード」を示すために、コンポーネントタグの属性を使用して、スタイルは、子コンポーネントに生きることができるW / O :: NG-深いような属性セレクタ経由::host[some-context] {}-それを必要な柔軟性/移植性の種類によって異なります。どちらの方法もあまり好きではありませんが、これがカプセル化の世界です。
dudewad

22

非推奨をバイパスするために::ng-deep、私は通常無効にしViewEncapsulationます。これは最善のアプローチではありませんが、私には役立っています。

を無効にするViewEncapsulationには、コンポーネントで次の手順を実行します。

import { Component, ViewEncapsulation } from '@angular/core';

@Component({
  selector: 'app-header',
  templateUrl: './header.component.html',
  styleUrls: ['./header.component.scss'],
  encapsulation: ViewEncapsulation.None
})

export class HeaderComponent {

}

これにより、このコンポーネントの.scssスタイルがアプリケーション全体に対してグローバルになります。スタイルが親コンポーネントと兄弟コンポーネントにチェーンを上ることを許可しないようにするには、次のようにセレクターでscss全体をラップします。

app-header {
  // your styles here and any child component styles can go here
}

ここで指定するスタイルは子コンポーネントに分類されるため、CSSセレクターを特に具体的に指定し、CSSを追加するときにpとqに注意する必要があります(Angularアプリで指定した子セレクターを追加してからそのスタイルを追加する場合があります)。

上記の段落のため、これは最善のアプローチではないと言いますが、これは私に役立ちました。


12
これは単なる回避策であり、巨大なプロジェクトがある場合、スイッチをオフViewEncapsulationにすると、それらのスタイルがすべてのコンポーネントに漏れる可能性があるため、多くの損害が発生します。この機能は、賢明かつ十分に理解して使用する必要があります
MPRO

5
@mpro私が理解しているのは、それが私が警告を与えた理由であり、これは最善のアプローチではなく、あなたはあなたのpとqを気にし、特別に具体的にしなければならないと言います。私にとって、このアプローチはこれまでうまく機能してきました。:: ng-deepは非推奨としてマークされており、これは回避策です。
AliF 5019年

1
正直なところ、これは、非推奨の脅威があるためにこれを行った場合に到達する恐ろしい結論だと思います。はい、私はあなたが多くを認めていることを知っています、しかし私はあなたがこれをすることによってあなた自身を足で撃っていると本当に思います。ビューのカプセル化は、多くの理由で非常に便利です。ただし、角度のあるチームの誰もが論理的な回避策なしにそれを非推奨にし、多くの人を混乱に導くほど悪くはありません。結局のところ、あなたはまだWebブラウザ用のコードを書いています-ある種の独自のAngularエンジンではありません。
Simon_Weaver

2
@Simon_Weaver私はあなたの意見を尊重し、共有してくれてありがとう。これは、非推奨を回避するために使用したものであるため、私はそれを表面化しています。また、警告を明らかにしました。
AliF 5019

3
@ AliF50「回避の逸脱」は実際には問題ではありません。ここでの本当の問題は、これを私の人生でこれまで見たことがないということです。彼らは代替案に名前を付けずに非推奨にしました。私の答え(上記で受け入れられたもの)は、なぜ彼らが仕様に合わせるために(W3Cはそれを非推奨にした)したのかについての私の仮説を説明しています。ただし、提案を読むと、:: ng-deepが適切な代替手段に置き換えられるように見えます。つまり、利用可能になったときに、文字通り必要なアプローチではなく、:: ng-deep参照を更新するだけです。アプリケーション全体を再構築します。
dudewad

19

ディープスタイルのシンプルで簡単な代替手段は、親コンポーネントの要素セレクターを使用する一般的なスタイルです。したがって、これがhero-details.component.cssにある場合:

:host ::ng-deep h3 {
  font-style: italic;
}

styles.cssでは次のようになります。

app-hero-details h3 {
  font-style: italic;
}

基本的に、ディープスタイルはカプセル化されていないスタイルであるため、概念的には、コンポーネントスタイルというよりも一般的なスタイルのように見えます。個人的にはもうディープスタイルは使いません。メジャーバージョンのアップデートでは重大な変更は正常であり、非推奨の機能の削除は公正なゲームです。


1
うわー、今は馬鹿げている。ありがとう!他のフロントエンドフレームワークから来て、これは不可能だと思いました
RafaelVidaurre20年

1
これは本当に便利です。:: ng-deepが置き換えられることなく長い間非推奨にされたのは残念です(:host :: ng-deepは期待どおりに機能しますが、非推奨のものは使いたくありません)。
アレクセイ

8

誰かが前に述べたように、サードパーティのライブラリを使用している場合、たまに使用しなければならないことを避けることは事実上不可能::ng-deepです。しかし::ng-deep、ブラウザでサポートされなくなったとき、以前のプロジェクトについてどうしますか?

その瞬間に備えるために、私は次のことを提案します:

  1. ViewEncapsulation.Noneを賢く使用してください。これは、より深いコンポーネントにアクセスする必要があるコンポーネントにのみ変換されます。
@Component({
      selector: 'app-example',
      templateUrl: './example.component.html',
      styleUrls: ['./example.component.scss'],
      encapsulation: ViewEncapsulation.None
    })
  1. さて、衝突とCSSの奇妙さを避けるために、(原則として)常にコンポーネントのテンプレートをクラスでラップする必要があります。したがって、example.component.htmlは次のようになります。
<section class="app-example-container">
<!-- a third party component -->
<mat-tab-group>
<mat-tab label="First"></mat-tab>
<mat-tab label="Second"></mat-tab>
</mat-tab-group>
</section>
  1. 繰り返しますが、原則として、すべての単一のSCSSファイルの最初の行はコンポーネントコンテナを対象とします。カプセル化がないため、クラスをターゲットにすることでサードパーティコンポーネントを変更できます。そうは言っても、example.component.scssは次のようになります
.app-example-container {
/* All the CSS code goes here */
.mat-tab-group .mat-tab-label {color: red;}
}

将来への自己メモ:https//angular.io/guide/component-styles
それは公式の代替案/ ways-to-goを探す最初の場所でなければなりません


But what are you going to do about your previous projects when the ::ng-deep became no longer supported by browsers?それはangularcliによってコンパイル/ポリフィルされていないので、ブラウザーの関与はありませんか?ところで素晴らしい答え。
beppe90 0020

これは実際にCSSファイルにレンダリングされ、ブラウザーはそれに応じてスタイルを適用します。:host /deep/ .mat-tab-labelこれを使用してエイリアシングは可能です(私は思います)::ng-deep。に変換する必要があります。正直なところ、CLIはコンパイル時にエイリアスを変更できるため、エイリアスを使用する方が便利なようですが、それでも、エイリアスを実行しng buildて再度デプロイする必要があります。私の決意は避けることでした::ng-deepすべての私のプロジェクト:)上のすべてで
guzmanoj

ええ、再デプロイを避けるのは理にかなっています
beppe90 0020

1

これは:: ng-deepの一般的な置き換えではありませんが、質問の作成者が説明したユースケースの場合です。

router-outletによって挿入された要素のスタイルを設定する特別な場合には、CSSの隣接するネイバーセレクターを使用する洗練されたソリューションがあります。

router-outlet+* {
  /* styling here... */
}

これは、ルーターアウトレットの直接の隣接要素であるすべての要素に適用されます。

参考文献:
https //developer.mozilla.org/en-US/docs/Web/CSS/Adjacent_sibling_combinator
https://angular.io/guide/router#router-outlet


1
このセレクターの使用はお勧めしません。これは、特にアプリケーションが大きくなると、文字通りの衝突の悪夢を引き起こしているように見えます。その上、*セレクターは文字通りCSSの存在の中で最も遅いセレクターです。
dudewad

@dudewad *セレクターは最も遅いセレクターですが、チェーン/ツリー全体ではなく、文字通り次の兄弟(+)にのみ適用されるため、わずかな違いしか生じません。
ErikPhilips20年

@ErikPhilips CSSセレクターは右から左に解析されるため、これは実際には最悪のシナリオです。
dudewad

@dudewad何かが足りないと思います。 *最悪のシナリオは、僅差で続くんですelement *が、element + *何の場所最初の2近くです。
ErikPhilips20年

私は知りません...私はそれをテストしていません、これはCSSパーサーが彼らのことをどのように行うかについて私が知っていることに基づいています。
dudewad

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.