問題タブ [commonjs]

実装 (node.js、rhino など) を検出する標準的な方法と、CommonJS でのその実装の理想的なバージョンはありますか。

そうでない場合、人々はそれを得るために何をしますか?

HTTP User-Agentブラウザの世界のヘッダーに似たものを考えています。

私にとって、クラスは NodeJS (CommonJS) モジュールに非常に似ています。それらの多くを持つことができ、それらは再利用でき、相互に使用でき、通常はファイルごとに 1 つです。

モジュールとクラスの違いは何ですか? それらの使用方法は異なり、名前空間の違いは明らかです。それに加えて、それらは私には非常に同じように見えるか、おそらくここで明らかな利点が見られないだけです.

ブラウザで commonjs モジュールを使用するために modulr を使用しています。目標は、これらのモジュールの一部をサーバー環境でも再利用できるようにすることです。

これらの「共有」モジュールは、次のようにする必要があります。

意味：

• _ がグローバル var (ブラウザ環境) として存在する場合は、それを使用します
• それ以外の場合は、「アンダースコア」モジュール (サーバー) をロードし、代わりにそれを使用します

ここで、modulr はすべてのコードで静的分析を行い、最終的な js ファイルを生成するために必要な呼び出しを探しているため、ビルドに失敗します。

この問題を回避する方法はありますか?

(たとえば、modulr が--ignore=<module_list>パラメーターのようなものをサポートしていれば、すべて正常に動作します。)

Node.js モジュールで次のコントラクトを見つけました。

module.exportsここでととの違いは何なのだろうかexports。

関数/オブジェクト表記を使用して新しい「クラス」を作成する代わりに、すべてのJavaScript「クラス」を Appcelerator Titanium Mobile アプリ内の CommonJS モジュールとして記述することをお勧めします (または、とにかく JavaScript でそれらを呼び出す方法) 。

それ以外の

デメリットはありますか？

CommonJS promise ( QdownloadAsync()を使用) を返す関数があります。次の 2 つの方法で失敗する可能性があります。

1. ファイルはすでにダウンロードされている可能性があり、その場合はすぐにわかります。
2. ダウンロード プロセスが失敗する可能性がありますが、その場合はしばらくしてからわかります。

(1) の場合、非同期が発生する前にわかっているため、例外をスローできます。(2)の場合、私は約束を拒否しなければなりません。

私の質問は、API を統一し、約束を拒否することで常にエラーを通知する必要があるかどうかです。または、すぐに判断できる無効な状態条件に対して例外をスローする必要がありますか? 別の例として、ユーザーが無効な引数を渡した場合、promise を拒否するよりもエラーをスローする方が賢明に思えます。

「例外的な」約束の拒否が実際にどのように行われるかについての明確さも同様に素晴らしいでしょう。そこでの使用法は、例外的な使用法と 1 対 1 で対応していますか?それとも例外的でない障害にも使用しますか?

CommonJSモジュールをクライアント側のJavaScriptコードとしてブラウザーにロードする最良の方法は何ですか？

CommonJSモジュールは、その機能をmodule.exports名前空間に配置し、通常require(pathToModule)、サーバー側スクリプトで使用して含まれます。それらをクライアントにロードすることは同じように機能することはできません（requireを置き換える必要がある、非同期性を考慮する必要があるなど）。

私はモジュールローダーと他の解決策を見つけました：Browserify、RequireJS、yabbleなどまたは単にモジュールを変更する方法。最善の方法とその理由は何だと思いますか？

promises パターンと同様に、addEventListener/etc メソッドでオブジェクトを汚染する必要を回避するイベント パターンを探しています。オブジェクトを返すことができるようにしたいと考えています。このオブジェクトは、複数回「解決」するだけでなく、キャンセルすることもできます。

たとえば、次のような「間隔」オブジェクトを返すメソッドを作成する場合があります。

ここでの主な違いは、promise と同様にイベントが標準化されているため、イベント名を知らなくてもサブスクライブできますが、promise とは異なり、「完了」は複数回発生する可能性があり、キャンセルされることもあります (これはremoveEventListener と同等です)。

プログレスハンドラーを複数のコールバックに使用でき、完全なハンドラーが使用されないなど、これがプロミスで合法であるかどうかを確認することに興味がありますが、さらに重要なのは、プロミスからのサブスクライブを解除するという概念があることです。

これが当てはまらず、約束がこのシナリオに特化している場合、私が説明したことを行うための標準化されたパターンはありますか?

Appceleratorを使用してモバイルアプリケーションを開発しており、commonJSを使用していくつかの構成関数を組み込んでいます。

私が実行しているコードは次のとおりです。

app.js

config.js

コードを実行しようとすると、次のエラーが発生します。

モジュールを含めるために何か間違ったことをしていますか？