ネイティブJavaScriptオブジェクトの拡張-それは悪ですか？ SugarJSマニフェスト

Underscore / Lo-Dashに関する投稿へのコメントで、標準JavaScriptライブラリを拡張するライブラリの中で、ほとんどのアナログとは異なり、ネイティブオブジェクトの拡張を介して機能するSugarJSを好むと述べました。



これは、ネイティブオブジェクトを拡張できるかどうかについての激しい議論を引き起こしました。 発言者のほぼ全員が反対意見を述べたことに非常に驚いた。



これにより、SugarJSマニフェストを翻訳するようになりました。 どうやら、このライブラリの作成者は非常に頻繁にそのような攻撃を聞く必要がありました。 したがって、彼は非常に慎重かつかなり公然とそれらのそれぞれにコメントしました。



この資料は、よく知られているJavaScriptの落とし穴をよく理解しており、保護方法も提供します。 したがって、この記事は、ネイティブオブジェクトを拡張する問題に対する態度に関係なく、JS開発者にとって興味深く有用なものになると思います。



私は床をアンドリュー・プラマーに渡します。

---

したがって、SugarはネイティブJavaScriptオブジェクトを変更するライブラリです。 待って、悪じゃない？ 「おねがいします」Prototypeの苦い経験から学んだことはありませんか？



これには多くの誤解があります。 砂糖は、Prototypeが偶然見つけた落とし穴を回避し、本質的に根本的に異なります。 ただし、この選択には結果がないわけではありません。 ネイティブオブジェクトの変更によって引き起こされる潜在的な問題を以下で説明し、それぞれについてのSugarの立場を説明します：

1. 環境オブジェクトの変更
2. 列挙プロパティとしての機能
3. プロパティのオーバーライド
4. グローバル名前空間での競合
5. プロパティの欠如に関する仮定
6. コンプライアンス

1.環境オブジェクトの変更

問題：

「ホストオブジェクト」という用語は、コードが実行される環境によって提供されるJavaScriptオブジェクトを意味します。 ホストオブジェクトの例：イベント、HTMLElement、XMLHttpRequest。 厳密に仕様に従うネイティブJavaScriptオブジェクトとは異なり、環境オブジェクトはブラウザー開発者の裁量で変更でき、異なるブラウザーでの実装は異なる場合があります。



詳細に触れずに、環境オブジェクトを変更すると、コードにエラーが発生しやすくなり、速度が低下し、環境の将来の変更に対して脆弱になる可能性があります。

シュガーポジション：

Sugarは、ネイティブJavaScriptオブジェクトでのみ機能します。 環境オブジェクトは彼にとって面白くない（または、より正確には、未知）。 このパスは、ホストオブジェクトに関する問題を回避するためだけでなく、ブラウザの外部で動作する環境を含む多数のJavaScript環境からライブラリにアクセスできるようにするために選択されます。



翻訳者から：NodeリポジトリのSugarモジュールは次のとおりです。

2.列挙プロパティとしての機能

問題：

最新の仕様に準拠していないブラウザでは、新しいプロパティの定義により列挙可能になります。 サイクルがオブジェクトのプロパティを横断するとき、新しいプロパティはデータを含むプロパティとともに影響を受けます。

シュガーポジション：

Sugarは、可能な限り、つまりすべての最新ブラウザーでメソッドを列挙不可能にします。 ただし、IE8が完全になくなるまで、この問題に常に留意する必要があります。 そのルートはプロパティをループすることにあり、ループすることができる2つの主なタイプのオブジェクト、つまり通常のオブジェクトと配列を個別に考慮する必要があります。



この問題のため（およびプロパティをオーバーライドする問題のため）、上記の例で行われているように、SugarはObject.prototypeを変更しません。 これは、通常のJavaScriptオブジェクトでfor..in



ループを使用しても、未知のプロパティが存在しないためにループに入ることは決してないことを意味します。



配列の場合、状況はやや複雑です。 配列をトラバースする標準的な方法は、単純なfor



ループを使用することです。これは、反復ごとにカウンターを1つずつ増やし、それをプロパティ名として使用します。 この方法は安全であり、問​​題も発生しません。 for..in



ループを使用して配列を走査することもできますが、これは良い方法とは見なされません。 この方法を使用する場合は、 hasOwnProperty



メソッドを使用して、プロパティがオブジェクトに直接属しているかどうかを確認してください（上記のドロップダウンの最後の例を参照）。



for..in



配列を走査し、 hasOwnProperty



チェックを行わないことは、悪い習慣の中では悪い習慣であることがfor..in



ました。 そのようなコードが古いブラウザー（IE8以前）で実行されると、Sugarメソッドを含むオブジェクトのすべてのプロパティがクロールされるため、問題が存在することに注意することが重要です。 Sugarが含まれているときにプロジェクトが壊れた場合、最初に確認する必要があるのは、ループ内のオブジェクトのプロパティを正しくバイパスするかどうかです。 この問題は、Sugarだけの問題ではなく、配列メソッドにポリフィルを提供するすべてのライブラリの場合に当てはまることも注目に値します。



おわりに 配列を横断するための問題のあるコードを書き換えることができず、IE8以下のサポートが重要である場合、SugarライブラリのArrayパッケージを使用することはできません。 このパッケージを除外して、Sugarアセンブリをビルドします 。

3.プロパティのオーバーライド

問題：

JavaScriptでは、ほとんどすべてのエンティティがオブジェクトです。つまり、キーと値のペアの形式でプロパティを持つことができます。 JavaScriptでは、「ハッシュ」（ハッシュテーブル、辞書、連想配列）は通常のオブジェクトであり、「メソッド」はデータではなくオブジェクトのプロパティに割り当てられた関数です。 良くも悪くも、オブジェクトに対して宣言されたメソッド（プロトタイプチェーンに沿って直接またはさらに）もプロパティであり、データと同じ方法でアクセスされます。



問題が明らかになりつつあります。 たとえば、すべてのオブジェクトに対してcount



メソッドを定義し、一部のオブジェクトに対して同じ名前のプロパティにデータを書き込むと、メソッドは使用できなくなります。

 Object.prototype.count = function() {}; var o = { count: 18 }; o.count // => 18
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

オブジェクトに対して直接定義されたcount



プロパティは、プロトタイプチェーンのさらに下にある同じ名前のメソッドを覆い隠します（オリジナルでは「シャドウをキャスト」-「シャドウイング」です）。 その結果、このオブジェクトのメソッドを呼び出すことができなくなります。

シュガーポジション：

列挙型プロパティの問題とともに、これがSugarがObject.prototype



変更しない主な理由Object.prototype



。 使用するオブジェクトのメソッドを事前に知っていて、同じ名前のプロパティの使用を避けることにしたとしても、コードは依然として脆弱であり、オーバーライドされたプロパティのデバッグは楽しいタスクではありません。



代わりに、SugarはObject



クラスの静的メソッドとして単純なオブジェクトのすべてのメソッドを表すことを好みます。 JavaScriptがプロパティとメソッドを区別するまで、このアプローチは変わりません。



翻訳者から：



必要に応じて、通常のオブジェクトを操作するためのSugarメソッドを特定のオブジェクトのプロパティに転送できます。 これはObject.extended()



を使用して行われます：

 var foo = {foo: 'foo'}, bar = {bar: 'bar'}; foo = Object.extended(foo); foo.merge(bar); console.log(foo); // => {foo: 'foo', bar: 'bar'}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

4.グローバル名前空間での競合

問題：

グローバルな名前空間に存在する場合、ストレスの主な原因は再定義されるという懸念です。 コードを書くとき、他の人の方法を破る方法のリスクと、誰かがあなたの方法を破るという事実が常にあります。

シュガーポジション：

まず、この問題の本質を正確に特定することが重要です。それは認識の問題です。 あなたがプロジェクトの唯一の開発者である場合、プロトタイプの変更は最小限のリスクしか伴いません。何をどのように変更するかを知っているからです。 チームで作業している場合、すべてを認識しているとは限りません。



開発者VasyaとPetyaが、同じことをするが名前が異なる2つのメソッドを同じプロトタイプで定義する場合、それらは一貫して動作しますが、犯罪者はいません。 異なるタスクを実行する同じ名前の2つのメソッドを定義すると、プロジェクトが中断されます。



Sugarの価値は、とりわけ、プロトタイプに小さなヘルパーメソッドを追加することを唯一の目的とする単一の標準APIを提供することです。 理想的には、このタスクは1つのライブラリ（Sugarまたは他のライブラリ）に対してのみ信頼されるべきです。 あなたが初めてで、タスクがあまり明確ではないグローバル名前空間の分野に新しいプレーヤーを紹介することは、リスクを高めることを意味します。 これは、もちろん、すぐに問題に遭遇するという意味ではありません。 リスクの程度は、あなたの認識の程度と相関する必要があります。



ライブラリ、プラグイン、およびその他のミドルウェアは同じ理由でSugarを使用しないでください 。 グローバルオブジェクトの変更は、エンドユーザーが意識的に決定する必要があります。 ライブラリの作成者がまだSugarを使用することに決めた場合、ユーザーにこれを非常に目に見える場所で知らせる必要があります。



翻訳者から：特に、Sugar、Underscore、および同様のライブラリなどのオプションの依存関係をできるだけ少なくするように、どのライブラリも努力すべきだと思います。 純粋なJavaScriptで書き換えることができないものは何もしません。 ライブラリの作成者によるこのルールの乱用は、プロジェクトに重複した完全に冗長な機能を持つ依存関係の混乱が生じるという事実につながる可能性があります：Lazy.js、Underscore、Lo-Dash、wu.js、Sugar、Linq.js、JSLINQ、From .js、IxJS、Boiler.js、sloth.js、MooTools ...したがって、「ミドルウェアでSugarを使用しない」という推奨事項は、他のライブラリでも有効です。

5.プロパティの欠如に関する仮定

問題：

グローバル名前空間での競合はどれほど危険なのか、グローバル名前空間に含まれる（または含まれない）ものに関する仮定も同様です。



文字列とオブジェクトの2種類の引数を取ることができる関数があると想像してください。 オブジェクトが関数に渡される場合、オブジェクトが持つ特定のプロパティから文字列を取得する必要があります。 したがって、引数にこのプロパティがあるかどうかを確認します。

 function getName(o) { if(o.first) { return firstName; } else { return lastName; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この一見単純なコードは、 first



プロパティがオブジェクトのプロトタイプチェーン内のどこでも（文字列であっても）定義されないという暗黙の仮定をしています。 もちろん、 Object.prototype



とString.prototype



はグローバルオブジェクトであり、誰でも変更できるため、誰もこれを保証しません。



ネイティブオブジェクトの変更に反対する場合でも、上記の例のように、グローバルネームスペースの内容について想定するコードを書く余裕はありません。 このようなコードは脆弱であり、問​​題を引き起こす可能性があります。

シュガーポジション：

最後の例のコードを修正することはまったく難しくありません。 あなたはすでにソリューションに精通しています：

 function getName(o) { if(o.hasOwnProperty('first')) { return firstName; } else { return lastName; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、関数は、プロトタイプチェーン内のすべてのプロパティではなく、渡されたオブジェクトに対して直接宣言されたプロパティのみをチェックします。 さらに進んでさまざまなデータ型の転送を防ぐこともできますが、そのような単純なチェックでさえ、グローバル名前空間の変更に関連する問題を回避するのに十分です。



Sugarは、その存続期間中に、 jquery＃1140とmongoose＃482の 2つの大きなライブラリのコードでこの問題を引き起こしました。 両方の場合の犯人は、成功しなかったシュガーメソッドでした。 喜んで名前を変更したので、問題を解決しました。 さらに、ライブラリーの1つ（jQuery）は、その側の欠陥を排除するために、私たちと一緒に問題に取り組みました。



Sugarはグローバルな範囲で非常に正確に動作しようとしますが、ライブラリの作成者間の協力なしに行う方法はありません。 問題の根本はJavaScript自体の性質であり、プロパティとメソッドを区別しません。

6.仕様への準拠

問題：

ECMAScript仕様は、ネイティブメソッドの動作を定義する標準です。 JavaScriptランタイム開発者は、ネイティブメソッドが正確かつ最新であることを望んでいます。 したがって、2つのことが重要です。メソッドは常に仕様に従って動作し、将来仕様に変更が加えられても回帰が発生しないことです。

シュガーポジション：

当初から、私たちはSugarを開発し、仕様に準拠するだけでなく、仕様とともに進化することを目指しました。



ES5パッケージでは、Sugarは現在の仕様で説明されているポリフィルメソッドを提供します。 もちろん、実行環境にメソッドのネイティブ実装がある場合は、ネイティブメソッドが使用されます。 Sugarには広範なテストセットがあり、すべてのポリフィルが仕様に完全に一致することを確認できます。 さらに、必要に応じて、ES5パッケージを拒否し、他のES5ポリフィルを使用できます。



仕様に準拠するとは、仕様の変更に適応することを意味します。 常に標準の最前線にいることは、Sugarの責任です。 新しいドラフト仕様への対応をすぐに開始すればするほど、将来の仕様に切り替えるのは簡単になります。 バージョン1.4以降、SugarはECMAScript 6標準に準拠しています（開発のごく初期の段階である7を参照）。 仕様の変更に伴い、Sugarは競合を避けるために調整を続け、実用性とネイティブ実装への準拠のバランスをとるよう努めます。



もちろん、依存関係を定期的に更新したいユーザーには適応が適しています。 しかし、環境が仕様の次のバージョンに切り替わると、古いバージョンのSugarにあるプロジェクトはどのように動作しますか？ 状況を想像してみてください。あなたのサイトへの訪問者のブラウザが更新され、サイトがそこに侵入します。 Sugarは最近、仕様で明示的に説明されていないメソッドを再定義するという難しい決定を下しました。 if (!Object.prototype.foo) Object.prototype.foo = function(){};



、ECMAScriptにないメソッドはすべて無条件で再定義されます。



逆に思えるかもしれませんが、この決定はサイトサポートの改善を目的としています。 仕様を更新した結果、ネイティブメソッドが変更され、Sugarと競合する場合でも、Sugarはそれらをオーバーライドします。 したがって、メソッドは以前と同じように機能し続けます-サイトの更新を手に入れるまで。 しかし、すでに述べたように、私たちはこの必要性を最小限に抑え、仕様よりもはるかに先を行くよう努めています。

TL / DR

すべての問題とそれに関連するリスクを見てみましょう。

1. 問題： 環境オブジェクトの変更
   
   リスク：なし。
2. 問題： 列挙プロパティとしての機能
   
   リスク：最小限。 安全な方法で配列をトラバースするのと同様に、通常のオブジェクトをトラバースするときにリスクはありません。 安全でない方法で配列を移動する場合、IE8以下では問題が発生します。
3. 問題： プロパティのオーバーライド
   
   リスク：なし。
4. 問題： グローバルネームスペースの競合
   
   リスク：最小限ですが、プロジェクトのグローバルな名前空間で何が起こっているかを認識すると逆に成長します。 理想的には、プロジェクトにはSugarのような複数のライブラリを含めるべきではなく、その使用を文書化する必要があります。 自分でライブラリを作成している場合は、Sugarを使用しないでください。 ピンチで、できるだけ大声でユーザーにSugarアプリケーションを報告してください。
5. 問題： プロパティが欠落しているという仮定
   
   リスク：最小限。 この問題は、Sugarの歴史の中で2回発生し、両方のケースはすぐに解決されました。
6. 問題： コンプライアンス
   
   リスク：非常にわずか。 Sugarは、ネイティブオブジェクトの修正に可能な限り注意を払おうとします。 しかし、それで十分ですか？ この質問に対する答えは、ユーザーの信念とプロジェクトの構造に依存し、時間とともに変化します（より良いため）。

これらの結論は、現実の世界でSugarを使用した経験とユーザーのフィードバックに基づいて、私たち自身で決定しました。 疑わしい場合は、記事の各ポイントを詳細に説明しました。これが、Sugarがプロジェクトに適しているかどうかについて独自の結論を導き出すのに役立つことを期待しています。

翻訳者から

パフォーマンスSugarJS

より使いやすく、SugarはLo-Dashのパフォーマンスを著しく失います。 ただし、パフォーマンスの問題は、私の意見では、大量のデータの処理でのみ問題になります。 フロントエンドを使用する場合、これらのライブラリの速度に違いは見られません。



パフォーマンスが重要な人には、 LazyJSをお勧めします 。 オブジェクト/配列のプロパティを走査した後、すべてのプロパティを含む新しいオブジェクトを返す必要がない場合、LazyJSはLo-Dashよりもパフォーマンスが優れています。 複合操作では、ギャップが大きくなります。 たとえば、 map -> filter



操作では、LazyJSはLo-Dashの5倍、SugarJSの15倍高速です。 プロパティ値を調べるだけでなく、新しいオブジェクト/配列を組み立てる必要がある場合、LazyJSはその利点を失います。 StreetStrider は 、遅延チェーンコンピューティングがLoDashバージョン3で計画されていることを示唆しています。



ここ （英語）では、さまざまな一般的な操作で10個の類似ライブラリのパフォーマンスをブラウザーで直接比較できます。

失った利便性

ネイティブオブジェクトの拡張の問題がRubyでどれほどエレガントに解決されたのか疑問に思われるかもしれません。 それは、Ruby 2.1で実験的ステータスから抜け出した改良メカニズムを提案しました。



Vasyaライブラリを作成する開発者Vasyaがおとりパッチを作成することに恥ずかしくないと仮定します。彼は、reineコンストラクトを使用しrefine



、ライブラリから標準オブジェクトのメソッドを定義します。

 refine String do def petrovich "Petrovich says: " + self end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

開発者のPetyaは、多くのプログラマーが取り組んでいる大規模プロジェクトの一部の1つを彫刻します。 PetyaがVasyaライブラリを接続すると、Vasinsの独創的なパッチはプロジェクト全体に適用されず、残りのコーダーに干渉しません。 ライブラリを接続するとき、ネイティブオブジェクトの再定義はまったく発生しません。



新しいメソッドを使用するために、Petyaのコードでは、どのデコイパッチからどのライブラリが必要かを示しています。

 using Vasya using HollowbodySixString1957
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのライブラリから作成されたグローバルオブジェクトの再定義の結果として、それらはPetyaが要求したクラス、モジュール、またはソースコードファイルにのみ適用されます。

UPD1：なぜこれがすべて必要なのですか？

コメントから、これが私だけに明らかであることが明らかになりました。 コメントから答えを出します。



これはおそらく、Rubyで真剣にプログラミングを始めた人にとってはもっと明らかでしょう。 彼らが言うように、あなたはすぐに良いことに慣れます：リッチで非常に機能的な標準ライブラリ、動的言語でメソッドを呼び出すメソッドの自然な方法、メソッドを連鎖する能力。



このコードが表示されたら（抽象的な例）：

 var result = Math.floor( MyArray.last( arr ) ); if (debug) console.log( "result:", result ); return result;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

...これの代わりに：

 return arr.last().floor().debug();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

...それはどういうわけか、あなたが知っている、退屈になります。