Tslintを実行すると、以前は取得できなかった次のエラーが表示されます。
ERROR: C:/...path..to../observable-debug-operator.ts[27, 13]: Shadowed name: 'Observable'
Observableにデバッグ演算子を追加するために tutorial に従いましたが、このlintエラーが発生する以外は正常に動作しています。私はしばらくの間、lintエラーを取得せずにこのデバッグ演算子を使用していましたが、なぜ今それを取得しているのかわかりません。
Debugメソッドで型定義を修正する27行目のコードを次に示します。
declare module 'rxjs/Observable' {
interface Observable<T> { // line 27
debug: (...any) => Observable<T>;
}
}
誰も私がこのリントエラーをクリアする方法を知っていますか?ありがとうございました!
以下は、警告を明確にするための変数シャドウイングの簡単な例です。
var x = 4;
function example() {
var x = 5; // x is shadowing the outer scope's x variable
}
インターフェースの拡張を宣言している場合(つまり、Observable
の両方のインスタンスが同じ共通ルートを持っている場合)、技術的にはシャドウイングしていませんが、複数のレベルでObservable
がある場合、どちらを参照しているかは不明です。
次のオプションを使用して、シャドウ警告をオフに切り替えることができます。
"no-shadowed-variable": [
true,
{
"class": true,
"enum": true,
"function": true,
"interface": false,
"namespace": true,
"typeAlias": false,
"typeParameter": false
}
]
インターフェイスのシャドウイングはTypeScriptの問題ですか?
実際にはそうではありません-インターフェイスが宣言されている状況をキャッチします関数内、もしそれが問題であれば、TypeScriptコンパイラーがすでに問題があると言っているため...つまり、メンバーリストには、両方のスコープの正しいメンバーが表示されます。
インターフェイスも消去されます。たとえば、JavaScriptプログラムでTypeScriptライブラリを使用する場合など、コンパイル後の混乱はありません。
インターフェースのシャドーイングが問題を引き起こす場所の現実的な例を誰かが提供できるなら、私は自分の意見を変えてうれしいです。
基本的に、 Fenton は彼の例で非常にうまく説明しています。シャドウイングは、名前の衝突で発生します。
それでは、ネストされた変数/パラメータにx以外の名前を付けないのはなぜですか? ;)
私の例:
...
.retryWhen(error => {
return error
.mergeMap((error: any) => {
if (error.status === 500) {
...
たくさんのerror
パラメーターがあります。
これがどのように修正されたかはわかりませんが、tslintを含むパッケージの依存関係を再インストールしたため、エラーは発生しなくなりました。助けようとするあなたの時間をありがとう:)