🚀 🏅 💆 スケーラブルなJavaScriptアプリケーション 🌈 🙇🏼 😡

1か月以上前、 JavaScriptに関するFAQ記事：質問するで、「かなり高いレベルでサイトにJSコードを整理するための良いアプローチの例を教えてください。 gmailなどの実装方法について詳しく知るにはどうすればよいですか？」

この質問に答える時が来ました。それ以来少し締めました Y. Subbotnikの同じトピックに関するレポートを伝えたかったのです。レポートは非常に短く、多くの重要なポイントを捨てなければなりませんでした。この記事は多かれ少なかれ完全版です。

この記事では、アーキテクチャ、アプローチ、ルールなど、大規模なWebアプリケーションを拡張可能かつサポートする方法について説明します。

Webアプリケーションで作業している場合、ほとんどの時間をコードの作成に費やし、バグを修正します。新しい機能を追加する部分はごくわずかです。高度なWebアプリケーションは常に変化しています。今日-1行、明日-20、明後日-300。

サイトにどのようなコードがあるのか見てみましょう。

$(function () { //     $('#button').click(function (event) { alert(this.innerHTML); }); $('#list').uberScrollerPluginStart({ "theme": "red" }); $('#lazy_thing').click(function () { $.get('/lazy/thing/body.html', doLazyLoad.bind(this)); }); /*       */ });

多くの場合、jQeuryであり、イベントをハングさせ、プラグインを接続し、ajaxリクエストを実行します。プラグインを削除すると、すべてが壊れます。フレームワーク、プラグイン、およびコードが混在する一種のコードのもつれを取得します。このもつれはそれほど大きくなく（100行目）、原則として1人が作成および管理します。ほとんどのサイトは1回作成されますが、まったくサポートされていないため、サイトにとってより有害なものがあり、サイト全体のコストが増加する可能性があります。

このアーキテクチャをGMail、Yandex.Mail、Yahoo！Portal！、Twitterに適用すると、コードの巨大なボール（10000行以上）が得られ、数人が作成されます。巨大なもつれを解くのは非常に難しく、何も壊さないようにさらに混乱させることは困難です。 Webアプリケーションは常に進化しているため、このような混乱は絶えず解明され、混乱しなければなりません。

サイトコードは構造化されておらず、そのアーキテクチャは高度に接続されています。 Webアプリケーションの場合、このようなアーキテクチャは使用できません。

建築

スケーラブルなアプリケーションの作成を容易にするいくつかのアーキテクチャの1つを検討してください。アーキテクチャはNC Zakasから取ったもので、本当に気に入っています（彼のプレゼンテーションを見て、それが何であったかを覚えておくと素晴らしいでしょう）、コースで少し変更し、最終結果を例で取り上げます。

枠組み

どのアプリケーションにも、原則としてフレームワークが含まれています。 jQuery、Mootools、YUI、dojoなど、すべてのクライアントフレームワークは単なるツールボックスです。ツールは、釘を打ち、ボードを切るのに役立ちます。いくつかのツールは非常に必要ですが、ほこりを集めているものもあります。基本的なツールがほとんどない場合は、Backbone.js + Underscore.jsなど、より重いツールが接続されています

人生では、jQueryボックスをMootoolsに置き換えるのは簡単です。 jQueryまたはお気に入りのライブラリを今すぐ放棄するコストについて考えてみてください。簡単に交換するには、ライブラリ関数にラッパーを追加する必要があります-それはアプリケーションのコアかもしれません。

コア

ライブラリラッパーに加えて、カーネルは他の機能を実行します。システムの一部の寿命を制御し、通信インターフェイスを提供し、アプリケーション全体のエラーを監視します。

モジュール

アプリケーションはモジュールで構成されます-これらはカーネルによって管理されるアプリケーションの独立した部分ですが、カーネル自体には直接接続されていません。重いJavaScriptアプリケーションは、宇宙ステーションと同じくらい複雑です。 ISSには、数十個のモジュールを含む拡張可能なアーキテクチャがあり、それぞれが独自の役割を果たします。ステーションモジュールはさまざまな国で作成され、さまざまな時期に配信され、多くのモジュールがありますが、それらはすべて全体として機能します。

HTML + CSS + JavaScript +リソースで構成されるWebアプリケーションモジュール

モジュールリソース-ローカリゼーション、記述子、およびその他のプライベートモジュールデータ。

各モジュールは、アプリケーション全体とは別個に存在する必要があります。各モジュールのタスクは、焦点を絞った機能を実行することです。モジュールは分離する必要があり、モジュールが他のモジュールについて知らないほど、アプリケーション全体を簡単にサポートできるようになります。新しいコードを作成して依存関係を追加するときは、明日それを捨てる必要があると考えてください。

弱い接続性を確保し、モジュールの自由度を制限するには、特別な中程度のオブジェクトであるサンドボックスで囲む必要があります。各モジュールはそのサンドボックス内にあり、それとのみ通信する必要があります。これは、モジュールが知っている唯一のオブジェクトです。サンドボックスの役割は簡単です。彼女は警備員として行動します。モジュールが何ができるか、モジュールが誰と通信できるかを知っています。サンドボックスは、モジュールとカーネル間の接続を提供します。

モジュールはそのメソッドとサンドボックスを呼び出し、独自のHTML要素を使用できます。モジュールは、アクションを実行する前に許可を求める必要があります。モジュールは、グローバルの作成、非標準グローバルの使用、他のモジュールとの直接通信を禁止されています。

サブモジュール

各モジュールは、独自のルールを持つことができるマイクロアプリケーションとして機能します;ルールはグローバルなルールと矛盾するべきではありません。各モジュールは、そのサンドボックスをそのパーツに委任し、他のモジュールを接続できます（プロジェクトのアセンブリ中）。

カーネルは、モジュールがそのパーツをどのように管理するかを気にしません。各モジュールのグローバルルールが尊重されることが重要です。

劣後

システム内の接続数を減らすには、厳格な従属が必要です

-ライブラリーのみがブラウザーと既存のAPIについて知っている

-コアのみがライブラリについて知っている

-サンドボックスのみがカーネルを認識します

-各モジュールは、サンドボックスについてのみ知っています

どのオブジェクトもアプリケーション全体を認識すべきではありません。

アプリケーションは常に変化している必要があります。ユーザーは新しい機能を必要としています-それを追加します。ブラウザに新しい機能が追加されました-それを固定します。

したがって、各オブジェクトは変更する必要があります

-プラグインが原因でライブラリが拡張されている-ブラウザが新しいAPIを取得する-プラグインを追加する

-拡張によりカーネルが更新されます-プロトコルをXMLからJSONに置き換え、送信されるデータの形式を変更し、AJAXトランスポートを変更しました-拡張を追加しました

-モジュールが原因でアプリケーション全体が拡大しています-ユーザーは新しい機能が必要です-モジュールを追加します

コミュニケーション

HTML DOMがイベントであふれていることは誰もが知っています。イベントはどこにでもあります-要素にはそれがあり、API（XHR、ワーカー）にあります。 DOMのイベントにより、ドキュメントオブジェクトモデルを無期限に拡張し、拡張可能なアプリケーションを作成できます。イベントはWebアプリケーションの最適なベースであると考えています。

例を考えてみましょう：

 var Module1 = { "someAction": function () { Module2.getSomeValue(); } }; var Module2 = { "getSomeValue": function () { return 'data'; } };

通常のスキームでは、モジュールは互いに直接通信します。モジュール1は、モジュール2とそのgetSomeValue()

メソッドに依存します。モジュール2を削除すると、すべてが壊れます。

メソッド呼び出しがイベントに置き換えられた場合、モジュールは独立します（疎結合されます）。

 //   var Module1 = { "init": function ($) { $.on('event', function (e) { // $ -  jQuery,   sandbox console.log(e.data); }); } }; var Module2 = { "someAction": function ($) { // $ -  jQuery $.trigger('event', 'data'); } };

モジュール1では、イベントイベントをリッスンします。モジュール2は、いくつかのデータでイベントイベントを発生させ、イベントハンドラーはデータをコンソールに描画します

はい、アーキテクチャは大きく変化していますが、強力な接続を取り除きつつあります。

非同期関数

イベントには必然的に非同期性が伴うため、HTML DOMには非同期メソッドが豊富であることは誰もが知っていると思います。 XHR、JSONP、フレームからフレームへのデータの送信、ワーカーへのデータの送信、およびその逆。非同期プログラミングはより複雑であり、その使用が常に正当化されるとは限りません。しかし、この場合、非同期関数は非常に便利です。

例を見てみましょう：

 //   var Storage = { "read": function (key) { return localStorage[key]; } }; var data = Storage.read('key'), pData = process(data); $.trigger('data', pData);

いくつかのユーザーデータをlocalStorage

に保存し、それを同期的に操作し、すべてがうまくいくと仮定しlocalStorage

。まあ、同じデータをサーバーに保存するまでは、何かを変更する可能性が非常に高いです。同期コードを非同期に変換することは、イベントモデルであっても大きな問題になる可能性があります。

localStorageを置き換えてコードをやり直しましょう：

 //   var Storage = { "read": function (key, cb) { $.get('/read/' + key, cb); } }; Storage.read('key',function(data) { var pData = processData(data); $.trigger('data', pData); }.bind(this));

シンプルなデータ収集機能と10行のソースコードがありました。 1行追加し、4行変更しました。変更のほぼ50％を受け取りました（括弧を考慮しました）。イベント用でない場合は、ストレージを使用するコードを変更する必要がありました。データの取得と保存の機能で非同期アプローチを使用すると、将来のいくつかの問題から身を守ることができます。

原則として、すべての非同期メソッドはデータの送受信（XHR、ロケーションAPI、ファイルAPI）に関連付けられているため、データを保存および受信するすべての機能を非同期にするか、イベントを接続することをお勧めします。

そのようなアーキテクチャの利点

結果のフレームワーク、モジュールとプラグインのセットに基づいて、いくつかのアプリケーションを作成できます
各モジュール、各プラグインを個別にテストできます。これは、アプリケーション全体をテストするのに比べて非常に有益です。
アプリケーションを柔軟にスケーリングできます-アプリケーションのいくつかの重要な部分が変更されることを恐れずにモジュールを変更、追加します
イベントはアプリケーションの接続性を低下させます
データを処理し、将来のグローバルな変更に備える非同期機能

これらは、 J。Subbotnikのレポートからの抜粋です。サブボトニックでは、理論を実践で説明することを約束しました。理論的にはすべて美しいですが、実践のない理論はほとんど価値がないので、アーキテクチャに基づいてアプリケーションを作成しましょう。

例：保守が簡単なスケーラブルなJavaScriptアプリケーション

アプリケーションを作成するか、アプリケーションのスタブを作成します（記事は非常に大きいため、この部分を減らします）。モジュール性を示します。アプリケーションが含まれます：

コア
サンドボックス
モジュール：テキストを表示するモジュール。タイマーイベントを生成するモジュール。このイベントをフィルタリングするモジュール。いくつかのイベントをコンソールに記録するモジュール。

記事が過負荷にならないように、プロジェクトのアセンブリ、単体テストの自動生成、単体テストに関連する例の一部を示します。

図書館とテクノロジー

いつものように、jQueryがあります。レイアウトを整理するために、単純化されたBEMテクノロジー（ブロック、要素、修飾子）を使用します。スクリプトの動的な読み込みには、$ script.jsを使用します。テンプレート-Rezigから変更されたテンプレートエンジン。

プロジェクト構造

  /app /css -        /blocks /b-module-name /b-module-name.css ... ... /pages /index.css ... /descriptors -   /ModuleName.json ... /locales -   /ModuleName.json ... /modules -   /ModuleName.js ... /templates -   /ModuleName.html ... /views -   /ModuleName.html ... /build -    /lib -   /Core.js /test -  /lib /qunit.css /qunit.js /ModuleName -   ModuleName /index.html /index.js /TestData.js -     /vendors -   /Script.js /jQuery.js ... /index.html -   /index.js -  js ,    /index.json -   ...

モジュール

最初にモジュールから始めましょう。モジュールの各部分は、動的および静的に接続する必要があります（1つのファイルにアセンブルする場合）、またはその両方。開発者にとってすべてが可能な限り透過的である必要があります。モジュールがあります-それを使用します、いいえ-ダウンロードして使用します。

私たちのモジュールはいくつかの部分で構成されます：

サンプルレイアウト：スタイルが接続されたHTMLファイル。このファイルは単体テストで使用され、サンプルを取得してテンプレートを作成できるようにモジュールがどのように見えるかを示します。
テンプレート：モジュールが使用するHTMLブロック。
スタイルと画像：単純なCSSファイルまたは画像ファイル
JavaScript：モジュールコード
記述子：モジュールの名前、設定、およびリッスンして生成できるイベントのリストを含むJSONファイル。単体テストを自動生成するために使用され、権利を区別するためにサンドボックスによって使用されます。
ローカリゼーション：異なる言語のテキストを含むJSONファイル

各モジュールには適切な名前があり、モジュールの各部分は個別のディレクトリにあり、モジュールと同じ名前を持っています。モジュールのすべての論理部分（レイアウト/テンプレート、ビュー、ロジック、説明と構成、テキスト）を可能な限り分離しました。各モジュールは、initとdestroyの2つのメソッドのみをエクスポートします。

モジュールの例（DataGeneratorモジュール）

 (function(global){ "use strict"; var intervalId; var DataGenerator = { init: function (sandbox) { intervalId = setInterval(function () { sandbox.trigger('newData', Math.random()); }, sandbox.getResource('interval')); }, destroy: function () { clearInterval(intervalId); } }; //  if (!global) { return DataGenerator; } if (!global.exports) { global.exports = {}; } global.exports.DataGenerator = DataGenerator; }(this)) // ;  !

コードに多くのゴミがあることに同意します。モジュールの要件のために、まさにそのような形式があります。権威主義カーネルは、モジュール自体を接続し、静的および動的の両方に接続できます。 JavaScript自体にはモジュールがないため、それぞれが独自の外観を作成します。「標準的な」ものもいくつかありますが、多くの場合、特定のタスク用の自転車です。

記述子の例（DataGeneratorモジュール）

 { "name": "DataGenerator", "acl": { "trigger:newData": true //     newData }, "resources": { "interval": 1000 } }

ロケールの例（MessageViewモジュール）

 { "text_label": { "ru": " : ", "en": "He said: " } }

サンプルテンプレート（MessageViewモジュール）

 <div class="b-message-view"> <span class="b-message-view__label">{%=label%}</span> <span class="b-message-view__value">{%=value%}</span> </div>

この形式の長所

各論理部分は個別です。すべてのパーツを繰り返し使用できます。たとえば、記述子を使用して、単体テストのスケルトンを自動的に生成できます。

コア

モジュールをダウンロードして登録する必要があります。これは、アセンブリ中と動的の両方で実行できる必要があります。 jQuery Defferedは非常に役立ちます。モジュールの1つの部分のロードプロセスは実際には他の部分と変わらないため、多くの部分があるため、ロード機能の生産用の工場を選択する必要があります。

  var loaderFactory = function (cacheObject, method, format, methodOwner, type) { return function (name) { var dfd = $.Deferred(), self = this; if (cacheObject[name]) { dfd.resolve(); return dfd.promise(); } function successOrFail(object) { var camelCasedType = type.slice(0, 1).toUpperCase() + type.slice(1); self['push' + camelCasedType](name, object); dfd.resolve(); if (object) { // if fail EventManager.trigger(type + ':loaded', {name: name}); EventManager.trigger(type + ':' + name + ':loaded'); } } var path = Core.descriptor.path[type] + format.replace('$0', name); if (type === 'module') { method.call(methodOwner, path, successOrFail); } else if (type === 'template') { method.call(methodOwner, path, successOrFail, 'html').error(successOrFail); } else { method.call(methodOwner, path, successOrFail).error(successOrFail); } return dfd.promise(); } };

モジュールマネージャー

モジュールマネージャは、単にモジュールの一部をロードしてキャッシュします。ロードせずにモジュールを登録するための多くのメソッドがあります（静的アセンブリ）。

  var ModuleManager = { modules: {}, descriptors: {}, locales: {}, templates: {}, pushModule: function (name, module) {}, pushDescriptor: function (name, descriptor) {}, pushLocale: function (name, locale) {}, pushTemplate: function (name, template) {}, load: function (name) {} }; ModuleManager.getModule = loaderFactory(ModuleManager.modules, require, '$0.js', this, 'module'); ModuleManager.getDescriptor = loaderFactory(ModuleManager.descriptors, $.getJSON, '$0.json', $, 'descriptor'); ModuleManager.getLocale = loaderFactory(ModuleManager.locales, $.getJSON, '$0.json', $, 'locale'); ModuleManager.getTemplate = loaderFactory(ModuleManager.templates, $.get, '$0.html', $, 'template');

オブジェクトのスケルトンを残して、スペースをあまり使用しないようにしました。 いずれにしても、誰も読まない。 ソースにフルバージョン。

テンプレートエンジン

John Resigのシンプルなテンプレートエンジンを使用します

 var templateFactory = function(str, data) {}

イベントマネージャー

イベントマネージャは、イベントの登録、削除、呼び出しを行います。アプリケーションのすべてのグローバルイベントが通過します。私たちは車輪を再発明しません。 EventManagerは、標準メソッドに加えてjQuery.bind jQuery.trigger jQuery.unbind

jQuery.unbindを使用します。 jQuery.bind jQuery.trigger jQuery.unbind

があり、フック関数をイベントにフックします。フック関数は、イベントパラメータの内容を変更できます。また、イベントが呼び出されるのを防ぐこともできます。

  var EventManager = { $: $('<div/>'), hooks: {}, trigger: function (event, data) { if (this.hooks[event]) { // Update event data var result = this.hooks[event](data); // Don't trigger event if (result === false) { return this; } // Trigger with new data data = result || data; } this.$.trigger.apply(this.$, [event, data]); return this; }, bind: function () {}, unbind: function () {}, hook: function (event, hookFunction) { // One hook for example this.hooks[event] = hookFunction; return this; }, unhook: function (event) { delete this.hooks[event]; return this; } };

グローバルイベントマネージャーの使用には1つの重要な利点があります。イベントログを記録し、ログからイベントのコースを復元できます（ユーザー側でバグをキャッチするのに便利です）。

コア

  var Core = { descriptor: {}, runningModules: {}, //  ,   init: function (descriptorOrFileName, callback) {}, //    _initModules: function (callback) {}, //      initModule: function (name, callback) {}, //   destroyModule: function (name) {}, //  HTMLElement    getBox: function (name) {}, //      getTemplateFunction: function (moduleName, templateSelector) {} };

関数本体とJSDocブロックを削除しました。

外部からは、すべてのカーネルモジュールのメソッドのみが必要です。それらのみをエクスポートします。

  var CorePublic = { trigger: $.proxy(EventManager.trigger, EventManager), bind: $.proxy(EventManager.bind, EventManager), unbind: $.proxy(EventManager.trigger, EventManager), on: $.proxy(EventManager.bind, EventManager), getModule: $.proxy(ModuleManager.getModule, ModuleManager), getDescriptor: $.proxy(ModuleManager.getDescriptor, ModuleManager), getLocale: $.proxy(ModuleManager.getLocale, ModuleManager), getTemplate: $.proxy(ModuleManager.getTemplate, ModuleManager), pushModule: $.proxy(ModuleManager.pushModule, ModuleManager), pushDescriptor: $.proxy(ModuleManager.pushDescriptor, ModuleManager), pushLocale: $.proxy(ModuleManager.pushLocale, ModuleManager), pushTemplate: $.proxy(ModuleManager.pushTemplate, ModuleManager), init: $.proxy(Core.init, Core), destroyModule: $.proxy(Core.destroyModule, Core), initModule: $.proxy(Core.initModule, Core), getTemplateFunction: $.proxy(Core.getTemplateFunction, Core) };

サンドボックス

各モジュールには独自のサンドボックスがあるため、サンドボックスを生成するサンドボックスコンストラクターを作成します。サンドボックスは引数としてモジュール記述子を受け取ります。すべてのサンドボックスメソッドでモジュールを使用できます。

  var Sandbox = function (descriptor) { this.descriptor = descriptor || {}; }; Sandbox.prototype.getBox = function () {}; //      -  Sandbox.prototype.is = function (role) {}; Sandbox.prototype.bind = function (event, callback) {}; Sandbox.prototype.unbind = function (event, callback) {}; Sandbox.prototype.trigger = function (event, data) {}; Sandbox.prototype.hook = function (event, hookFunction) {}; Sandbox.prototype.unhook = function (event) {}; Sandbox.prototype.getText = function (message) {}; Sandbox.prototype.getResource = function (resource) {}; Sandbox.prototype.getTemplate = function (templateSelector) {};

他のオブジェクトに影響を与える可能性のある関数（ bind, trigger, hook,

）では、サンドボックスはこのモジュールで（モジュール記述子を使用して）この関数を実行できるかどうかをチェックします。

カーネルアセンブリ

カーネルの各部分は別々のファイルに置かれ、プリプロセッサによって一緒にアセンブルされる必要があります。この例ではプリプロセッサを使用していません（真空状態では球状です）。

 (function(global, $, require, undefined){ "use strict"; var templateFactory = function(str, data){}; var loaderFactory = function (cacheObject, method, format, self, type) {}; var ModuleManager = {}; var Sandbox = function (descriptor) {}; var EventManager = {}; var Core = {}; var CorePublic = {}; if (!global) { return CorePublic; } if (!global.exports) { global.exports = {}; } global.exports.Core = CorePublic; }(this, jQuery, $script));

アプリケーション記述子

また、アプリケーションには、アプリケーションに含まれるモジュール、モジュールの各部分の配置、現在のロケールの決定、基本的なマークアップの記述を記述する記述子があります。異なるアセンブリに対して複数の記述子が存在する場合があります。

 { "modules": ["MessageView", "DataGenerator", "Logger", "Hook"], "layout": { "MessageView": ".b-message-view" }, "locale": "ru", "path": { "descriptor": "./app/descriptors/", "module": "./app/modules/", "locale": "./app/locales/", "template": "./app/templates/" } }

アプリケーション：index.js

アプリケーション記述子から理解できるように、4つのモジュールがあります。アプリケーションは、サーバーとの対話なしで最もシンプルであることが判明しました。記事にモジュールコードを添付しません。リポジトリにあります。

MessageView-newDataイベントでメッセージを表示します

DataGenerator-1秒に1回、データMath.random()

newDataイベントを生成します

ロガー-newDataイベントをリッスンし、

フックが到着したことをコンソールに書き込みます-newDataイベントにフックを掛けます。文字列がイベントに到着すると、フックはイベントを中止します。0.5未満の数値が入力されると、100倍されます。

組立

各ステージ（dev、test、prod）には、独自のコレクター（または独自の構成）が必要です。開発のために、ドキュメントを収集する必要があり、ファイルを圧縮する必要はありません。テストと実稼働では、ファイルへのパスが異なる場合があります。ファイルを圧縮および収集し、コードのエラーをチェックする必要があります（静的チェック）。多くのビルド戦略とツールがあります。最も簡単なものを説明します。アセンブリ中に、アプリケーション記述子を使用しますindex.json

。

アセンブリindex.js

index.jsをビルドするには、require、buildFromの機能を持つ真空球プリプロセッサを使用します。プリプロセッサ関数はブロックコメントで囲まれているため、アプリケーション全体の動作を妨げることはありません（JavaScriptとCSSの両方に適しています）。index.jsはプリプロセッサに渡され、プリプロセッサはファイルをスキャンしてプロジェクトをコンパイルします。

 /*$require: ./lib/Core.js */ (function (Core) { "use strict"; /*$buildFrom ./index.json */ Core.on('ready', function () { Core.trigger('newData', 'Pewpew'); }); Core.init(/*$require*/'./index.json'/*$*/); }(this.exports.Core))

アセンブリ後、ファイルは次のようになります。

 //   Core.js (function (Core) { "use strict"; // + descriptors/Logger.json Core.pushDescriptor("Logger", { "name": "Logger", "acl": { "listen:newData": true, "listen:ready": true } }); // - descriptors/Logger.json // + modules/Logger.js Core.pushModule("Logger", (function(global){ // ... }(this))); // - modules/Logger.js // + locales/Logger.js Core.pushLocale("Logger", {}); // - locales/Logger.js // ...  -  .... Core.on('ready', function () { Core.trigger('newData', 'Pewpew'); }); Core.init({ "modules": ["MessageView", "DataGenerator", "Logger", "Hook"], "layout": { "MessageView": ".b-message-view" }, "locale": "ru", "path": { "descriptor": "./app/descriptors/", "module": "./app/modules/", "locale": "./app/locales/", "template": "./app/templates/" } }); }(this.exports.Core))

Cはrequire

すべて明確ですが、buildFrom

もう少し複雑です。この関数は、アプリケーション記述子を使用して特定のファイルを添付します。この例では、モジュールを組み立てましたLogger

（残りの部分も何らかの方法で接続されています）。ロジックbuildFrom

はもう少し複雑になる可能性があり、ローカライズをクリーンにする（この場合は削除する"en": "He said: "

）、予備チェックを実行するなどができます。

開発環境では、アプリケーションがビルドされない場合があります-モジュールはカーネルによって動的にロードされます。

アセンブリindex.css

この例では、単純なモジュール構造があります。各モジュールには1つのブロックがあるため、真空中で同じ球状のコレクターに制限します。

 /*$buildFrom: ../../index.json */ /* app/css/blocks/b-message-view/b-message-view.css */ .b-message-view { color: green; font-family: monospace; }

buildFrom

コンテキストのロジックはcss

次のとおりです。彼はレイアウトのアプリケーション構成を見て、各レイアウトについて、対応するブロックを私たちに接続しb-message-view

ます。それはすべて簡単です。これはアセンブリの非常に単純化されたバージョンであり、より複雑なアプリケーションには適さない可能性がありますが、例としてはこれで十分です。たとえば、BEMビルダーは、アプリケーションのブロックを記述するjsonファイルを使用します。

アセンブリindex.html

がindex.css

ありindex.js

ます。アセンブリには同じプリプロセッサを使用しますindex.html

 <!DOCTYPE HTML> <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title></title> <!--$require: index.css--> <link rel="stylesheet" href="app/css/pages/index.css" /> <!--$--> </head> <body> <!--$buildFrom: index.json--> <div class="b-message-view"></div> <!--$--> <script type="text/javascript" src="http://yandex.st/jquery/1.6.1/jquery.js"></script> <!--$require: index.js--> <script type="text/javascript" src="./vendors/Script.js"></script> <script type="text/javascript" src="./lib/Core.js"></script> <script type="text/javascript" src="./index.js"></script> <!--$--> </body> </html>

buildFrom

htmlのコンテキストでのロジックは次のとおりです（cssに似ています）：レイアウトのアプリケーション構成を調べ、各レイアウトで対応するdivを作成しますb-message-view

。繰り返しますが、これはアセンブリの最も単純なバージョンです。よりスマートなxsltコレクターを使用できます。

出力では次のようになります。

 <!DOCTYPE HTML> <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title></title> <link rel="stylesheet" href="/index.css" /> </head> <body> <div class="b-message-view"></div> <script type="text/javascript" src="http://yandex.st/jquery/1.6.1/jquery.js"></script> <script type="text/javascript" src="/index.js"></script> </body> </html>

Makefile-一般アセンブリ

コレクターの機能：

プリプロセッサを実行してindex.cssを構築します
index.cssを最適化します：data / uriなど。
index.cssを圧縮します（gzはオプション）
index.cssリソースをビルドします：写真
自動化された単体テストを実行します（下）
プリプロセッサを実行して、index.jsをビルドします
index.jsを検証します
index.jsを圧縮します（gzオプション）
OS .deb .rpmのパッケージをビルドします
パッケージをリポジトリに配置します
パッケージをインストールします

単体テスト

もう一度痛みについて。多くの人は、テストはフレームワークにのみ必要であると考えていますが、アプリケーションはフレームワークでもあり、ターゲットは狭く、特定のタスク用に作成され、他の開発者が使用します。

アプリケーション記述子とモジュール記述子を使用して、単体テストの自動作成を使用できます。ジェネレーター（真空でも球状）は必要なモジュールリソースを収集し、モジュール記述子でaclを使用して、モジュールが生成およびリッスンするイベントのテストスケルトンを作成します。それ以外はすべてハンドルです。

原則として、各イベントには独自の形式があります。テストタスクを簡素化するために、イベントサンプラーを作成します。

 var TestData = { "newData": function () { var data = [NaN, Infinity, window, Error, 'pewpewpew', '<b>Pewpew</b>', '"', '\'', new Date, Date, Math, 42, 8, -1, 0, false, true]; return data; } };

テストには、QUnitを使用します。MessageViewの例を考えてみましょう。単体テストジェネレーターは、1つのMessageViewモジュールからテストを（自動的に）作成し、テストスケルトンを作成してモジュールインターフェイス（リッスンして生成するイベント）を確認します。これは、確認する必要のある最小値です。

テストコード：index.js

 // MessageView test (function (Core, $, TestData, ok, test, module, equals, expect, asyncTest, start, stop) { "use strict"; //    var ApplicationEnvironment = { "modules": ["MessageView"], "layout": { "MessageView": ".b-message-view" }, "locale": "ru", "path": { "descriptor": "../../app/descriptors/", "module": "../../app/modules/", "locale": "../../app/locales/", "template": "../../app/templates/" } }; Core.on('ready', function () { module("MessageView"); //  1 test("listen:newData", function() { var testItems = TestData["newData"](), $MessageView = Core.getBox("MessageView"), template = Core.getTemplateFunction("MessageView", '.b-message-view'), label = Core.getText("MessageView", "text_label"); expect(testItems.length); // >>> put your code $.each(testItems, function (index, text) { Core.trigger("newData", [text]); // >>> put your code var expected = template({label: label, value: text}); // <<< equals(expected, $MessageView.html(), 'Should be "text_label: value"'); // <<< }); }); //  2 test("trigger:newData:display", function() { var testItems = TestData["newData"](), $MessageView = Core.getBox("MessageView"), template = Core.getTemplateFunction("MessageView", '.b-message-view'); expect(testItems.length); // >>> put your code Core.on("newData:display", function () { // <<< ok(true); // <<< }); // <<< $.each(testItems, function (index, item) { Core.trigger("newData", [item]); // >>> put your code }); }); }); Core.init(ApplicationEnvironment); }(this.exports.Core, jQuery, TestData, ok, test, module, equals, expect, asyncTest, start, stop))

このような大量のコードのうち、開発者が追加する必要があるのは5行のみで、「<<<

」でマークしました。

テストコードindex.htmlは明らかです-適用しません。

テスト自動化とテストによるコードカバレッジ

, 60 ( , ). , ( ). , ( , ):

— js-test-driver — QUnit, .

— TestSwarm ( ) — Mozilla Labs

— JSCoverage

テストを実行して、実際に機能し、タスクを実行するようにします。what-ifテストを実行しないでください。自動化とコードカバレッジを導入したくない場合は、単体テストの必要性について考えることをお勧めします。

コード検証とドキュメントのアセンブリ

また、この記事のトピックではありませんが、言及する価値があります。ドックが必要な場合、指定された構成に従って、プロジェクトビルダーはDox、jsdoc-toolkitなどを使用してドキュメントを収集できます。センチ。ドキュメントを書く

リポジトリにコミットする前に、テストにとのプロジェクトのアセンブリの前には、バリデータのコードでチェックする必要があります。事前コミット中にコードをチェックしない場合（アセンブリの前または必要に応じてチェックする）、手遅れになる可能性があります-大量のコードが蓄積し、大量のコードを修正するのが難しくなり、遅かれ早かれ検証のためにスコアを付けることができます。ビルドエラーを防ぐには、プロジェクトをビルドした後にコードをチェックする必要があります（厳密ではありません）。

一般的なポイント

この部分を要約の形で作成します。Webアプリケーションだけでなく有効です。

他の人があなたと一緒に働いています-彼らの仕事を尊重し、時間を大切にしています
( ). JSLint, JSHint !
.
, , ! $textarea.val($textarea.val())
: . — ! — . — . : foo, temp. , ( tmp), , — !
JavaScript, HTML CSS ( ). HTML — , . CSS — . JavaScript — .
. Element.style. , html ( FTW!). CSS Expressions!
. 2-3 !
, . — ! (Array.prototype, Function.prototype)
, — , !
instanceof, typeof, Object.prototype.toString magic
! URL ; ; , ,
開発プロセスの自動化：自動化されたテストツール（js-test-driver）、コード検証（JSLint、JSHint）、コードビルドとドキュメント（JSDocToolkit、Dox）を使用します。テストサーバーがリモートにある場合は、Ctrl + Sで自動ファイルアップロードを構成します。コードジェネレーターを使用します：テスト、モジュールスケルトン。

サンプルアプリケーションコード

ソースはGitHub scalable-js-app（モジュールの全文、コメント）

にあります。アプリケーションにはないもの：自動アセンブリ、単体テストの自動生成、すべてのテスト（MessageViewを除く）、自動ドキュメントアセンブリ。

読む/見る

Andrew Dupont（Gowalla、Prototype.js、S2）- メンテナンス可能なJavaScript
Nicholas Zakas (Yahoo!, YUI, YUI Test) — Writing Maintainable JavaScript . ,
Nicholas Zakas — Scalable JavaScript Application Architecture
" JavaScript " .

PSそして、あなたはすべてのコードを書き直し、JSHint / JSLintを使用してコードをきれいにすることにしました。やめて！リメイクには多くの時間がかかります。リメイクをテストしてリメイクするにはさらに時間がかかります。少なくとも何かが壊れるのは確かです（ユニットテストがない場合、これは必ず発生します）。新しい標準に従って新しいコードを作成し、一部を変更する場合は必要に応じて古いコードを変更します。

面白かったと思います。提案、希望、批判は大歓迎です！将来の記事では、プロジェクトの組み立てと自動化されたテストのプロセスをさらに詳しく説明します。質問がある場合は、質問してみましょう。

スケーラブルなJavaScriptアプリケーション

建築

枠組み

コア

モジュール

サブモジュール

劣後

コミュニケーション

非同期関数

そのようなアーキテクチャの利点

例：保守が簡単なスケーラブルなJavaScriptアプリケーション

図書館とテクノロジー

プロジェクト構造

モジュール

モジュールの例（DataGeneratorモジュール）

記述子の例（DataGeneratorモジュール）

ロケールの例（MessageViewモジュール）

サンプルテンプレート（MessageViewモジュール）

コア

モジュールマネージャー

テンプレートエンジン

イベントマネージャー

コア

サンドボックス

カーネルアセンブリ

アプリケーション記述子

アプリケーション：index.js

組立

アセンブリindex.js

アセンブリindex.css

アセンブリindex.html

Makefile-一般アセンブリ

単体テスト

テストコード：index.js

テスト自動化とテストによるコードカバレッジ

コード検証とドキュメントのアセンブリ

一般的なポイント

サンプルアプリケーションコード

読む/見る

More articles: