L'identification du module GitHub SeaJS a été relativement claire. Mais il n'est pas couvert dans tout, surtout lorsque vous avez besoin de rédaction de [ID de module] et de [dépendance du module], ou lorsque vous écrivez votre propre outil d'automatisation pour transporter (PS: SPM ne semble pas très adaptable et pas facile à Utiliser, après tout, chaque structure de répertoire du projet peut varier considérablement et n'est pas facile à changer. Et les règles d'analyse d'identification doivent être complètement comprises.
Notes:
1. L'identifiant de niveau supérieur est toujours analysé par rapport au chemin de base de base.
2. Le chemin absolu et le chemin racine sont toujours analysés par rapport à la page actuelle.
3. Les chemins relatifs dans les exigences et les exigences. Async sont analysés par rapport au chemin du module actuel.
4. Le chemin relatif de Seajs.Use est toujours analysé par rapport à la page actuelle.
Dans les SeaJS, l'ID du module peut être à peu près divisé en trois types: [identifiant relatif], [identifiant de niveau supérieur] et [chemin normal].
Les chemins ordinaires incluent le «chemin absolu», le «chemin racine», etc.
Ici, nous nous concentrons sur [Logo relatif] et [logo supérieur].
Les identifiants relatifs se réfèrent à "./", "../", comme: "./othermodule", "../lib/base".
Les identificateurs de niveau supérieur se réfèrent aux fichiers ou répertoires (peuvent contenir: lettres, -, _), telles que: "app / widget / select"
Il y a trois endroits où l'ID du module est requis:
La copie de code est la suivante: Define ("id (1)", ["../ id2 (2)"], fonction (require, exports, module) {
var modulea = requis ('./ modulea (3)');
})
Remarque: qu'il s'agisse du premier paramètre [ID du module] ou du deuxième paramètre [ID du module] ou du [ID du module fiable], la norme de comparaison finale est [Fichier Analysé URI].
Par conséquent, ces trois endroits où les ID doivent être écrits peuvent être écrits de quelque manière que ce soit, et tant qu'ils sont finalement analysés dans le même URI, ils sont considérés comme le même module.
Pendant le processus d'analyse de l'ID, il sera traité à l'avance par les alias et les chemins définis dans Seajs.config.
Règles de résolution de chemin de base
(La couche 1, le chemin lui-même ne dépend d'aucun paramètre)
1. [Identification de niveau supérieur] ne peut pas être utilisée, car l'identification du niveau supérieur est analysée par rapport au chemin de base de la base, de sorte que la base elle-même ne peut utiliser que [l'identification relative] ou [chemin racine], etc.
2. Le chemin par défaut de la base est le répertoire SEAJS.
3. [Identification relative]: Analyser par rapport à la page actuelle.
Règles de résolution de chemin dans les chemins
(La couche 1, le chemin lui-même ne dépend d'aucun paramètre)
1. [Identification relative]: Où être cité, l'emplacement analytique relatif dépend de l'endroit cité et suit les règles locales.
2. Les champs des chemins seront remplacés sous la forme de variables où ils sont utilisés puis analysés.
Par exemple:
Copiez le code comme suit: // Bloc de code (1)
// Définition du chemin:
Seajs.config ({
base: "./ app / src",
chemin:{
"A": "../ lib", // (1) chemin relatif
"lib": "chemin / vers / lib", // (2) logo de niveau supérieur
"l2": "/ lib" // (3) chemin racine
}
});
// module mod / m / m.js:
...
require ("a / jQuery");
// => Convertir en: "../../lib/jquery"
// => Chargement: mod / lib / jQuery (note spéciale 1)
...
// module mod / f.js:
...
require ("a / jQuery");
// => Convertir en: "../../lib/jquery"
// => Chargement: Lib / jQuery (note spéciale 2)
...
Règles de résolution de chemin à alias
(Dans la couche 2, le chemin lui-même peut dépendre des paramètres de chemin)
1. Les règles d'alias sont similaires aux chemins, et le chemin d'alias peut également utiliser des "variables" dans les chemins
2. Rappel: Essayez d'utiliser [l'identification de niveau supérieur], [chemin racine] et [chemin absolu] dans les chemins et les alias, et n'utilisez pas [identification relative], car les modules de différentes profondeurs seront analysés en différents chemins.
3. [Identification relative]: Où être cité, l'emplacement analytique relatif dépend de l'endroit cité et suit les règles locales.
SeaJs.User les règles de résolution de chemin
[Identification relative]: Analyser par rapport à la page actuelle.
Définir les règles d'analyse du module de module (1)
(Dans la couche 3, le chemin peut être défini par rapport aux alias ou aux chemins)
Vous pouvez utiliser: [Identification relative], [identification de niveau supérieur], [chemin racine]
Il est recommandé d'utiliser [identification de niveau supérieur].
【Identification relative】: Analyse par rapport à la page actuelle
Copiez le code comme suit: // Bloc de code (2)
// Config - Utilisez également la configuration dans [Bloc de code (1)]
// Module 1, pas d'ambiguïté, analyse du chemin racinaire
définir ("/ app / src / module / base", ..);
// Module 2, identification sans ambiguïté, de haut niveau, analysé par rapport au chemin de base de base
définir ("app / src / module / base", ..);
// Module 3, avec ambiguïté et identification relative, ici par rapport à la page actuelle (reportez-vous à la page HTML de ce module)
// mais même si [superficiellement le même "id"] est utilisé ailleurs, différents modules peuvent être analysés
définir ("./ app / src / module / base", ..);
Règles de résolution de la dépendance à la dépendance du module (2)
(Dans la couche 3, le chemin peut être défini par rapport aux alias ou aux chemins)
【Identification relative】: Analyse de chemin de base de base relative
Copiez le code comme suit: // Bloc de code (3)
// Config - Utilisez également la configuration dans [Bloc de code (1)]
// pas d'ambiguïté, par rapport à la résolution du chemin racine
définir ("..", ["/ app / src / module / base"], ..)
// pas d'ambiguïté, identification de niveau supérieur, par rapport à l'analyse de chemin de base de base
définir ("..", ["app / src / module / base"], ..)
// Il y a une ambiguïté, par rapport au module actuel.
// La dépendance ici semble dépendre du `module 3` dans [Bloc de code (2)]
// Mais si le module actuel et la page actuelle ne sont pas dans le même répertoire de niveau, il ne sera pas analysé dans le «module 3»
définir ("..", ["./app/src/module/Base"], ..)
Exiger des règles de résolution d'identification pour d'autres modules dans le module (3)
(Dans la couche 3, le chemin peut être défini par rapport aux alias ou aux chemins)
【Identification relative】: Analyse de chemin de base de base relative
Copiez le code comme suit: // Bloc de code (4)
// Config - Utilisez également la configuration dans [Bloc de code (1)]
définir ("..", [..], fonction (require) {
// pas d'ambiguïté, par rapport à la résolution du chemin racine
requis ("/ app / src / module / base");
});
définir ("..", [..], fonction (require) {
// pas d'ambiguïté, identification de niveau supérieur, par rapport à l'analyse de chemin de base de base
requis ("app / src / module / base");
});
définir ("..", [..], fonction (require) {
// Il y a une ambiguïté, par rapport au module actuel.
// La dépendance ici semble dépendre du `module 3` dans [Bloc de code (2)]
// Mais si le module actuel et la page actuelle ne sont pas dans le même répertoire de niveau, il ne sera pas analysé dans le «module 3»
require ("./ app / src / module / base");
})
Rappel spécial: il y a trois endroits dans le module où les ID doivent être écrits, et il n'est pas nécessaire d'utiliser la même chaîne, tant qu'elle est analysée dans le même module.
Résumer:
1. Les paramètres des chemins et des alias sont uniquement équivalents à une variable.
2. Utilisez autant que possible [logo de niveau supérieur].
3. Si vous ne pouvez pas utiliser l'identifiant [de niveau supérieur], comme la durée du répertoire est relativement grand, essayez de définir des alias ou des chemins pour le localiser à un répertoire via un identifiant [chemin non relatif], puis définissez l'ID sous cet identifiant.