Gestion des Chemins
m.route
et m.request
utilisent tous deux la notion de "chemin" (path). Ce chemin sert à générer l'URL de destination pour le routage ou la récupération de données.
Types de Chemins
Il existe deux types principaux de chemins : les chemins bruts et les chemins paramétrés.
- Les chemins bruts sont de simples chaînes de caractères utilisées directement comme URL. Aucune substitution ni division n'est effectuée. Le chemin est simplement normalisé, et les paramètres sont ajoutés à la fin.
- Les chemins paramétrés permettent d'insérer des valeurs dans les chemins, avec un échappement par défaut pour plus de commodité et de sécurité contre l'injection d'URL.
Pour m.request
, les chemins peuvent être n'importe quelle URL. Cependant, pour les routes, seuls les noms de chemins d'URL absolus, sans schémas ni domaines, sont autorisés.
Paramètres de Chemin
Les paramètres de chemin sont relativement simples. Ils se présentent sous deux formes :
:foo
- Insère la valeur deparams.foo
dans l'URL, après l'avoir échappée.:foo...
- Insère la valeur brute deparams.foo
dans l'URL, sans échappement.
L'objet params
auquel il est fait référence est celui utilisé dans m.route.set(path, params)
et m.request({url, params})
.
Lors de la définition de routes via m.route(root, defaultRoute, routes)
, vous pouvez utiliser ces paramètres pour extraire des valeurs des routes. Le mécanisme est similaire à la génération de chemins, mais dans le sens inverse.
// Modifier un seul élément
m.route(document.body, '/edit/1', {
'/edit/:id': {
view: function () {
return [m(Menu), m('h1', 'Modification de l'utilisateur ' + m.route.param('id'))];
},
},
});
// Modifier un élément identifié par le chemin
m.route(document.body, '/edit/pictures/image.jpg', {
'/edit/:file...': {
view: function () {
return [m(Menu), m('h1', 'Modification du fichier ' + m.route.param('file'))];
},
},
});
Dans le premier exemple, si vous naviguez vers la route par défaut, m.route.param("id")
renverra "1"
. Dans le second exemple, m.route.param("file")
renverra pictures/image.jpg
.
Les paramètres de chemin peuvent être délimités par un /
, un -
ou un .
. Cela permet de créer des segments de chemin dynamiques, offrant plus de flexibilité qu'un simple nom de chemin. Par exemple, vous pouvez faire correspondre des routes telles que "/edit/:name.:ext"
pour la modification en fonction de l'extension de fichier, ou /:lang-:region/view
pour une route localisée.
Les paramètres de chemin sont considérés de manière "gloutonne" (gourmande) : étant donné une route déclarée "/edit/:name.:ext"
, si vous naviguez vers /edit/file.test.png
, les paramètres extraits seront {name: "file.test", ext: "png"}
, et non {name: "file", ext: "test.png"}
. De même, étant donné "/route/:path.../view/:child..."
, si vous allez à /route/foo/view/bar/view/baz
, les paramètres extraits seront {path: "foo/view/bar", child: "baz"}
.
Normalisation des Paramètres
Les paramètres de chemin interpolés dans les noms de chemin sont omis de la chaîne de requête, par souci de clarté et pour maintenir la lisibilité du nom de chemin. Par exemple, cela envoie une requête serveur GET /api/user/1/connections?sort=name-asc
, évitant ainsi la duplication de id=1
dans la chaîne d'URL.
m.request({
url: 'https://example.com/api/user/:userID/connections',
params: {
userID: 1,
sort: 'name-asc',
},
});
Vous pouvez également spécifier des paramètres explicitement dans la chaîne de requête elle-même, comme dans l'exemple suivant, qui est équivalent au précédent :
m.request({
url: 'https://example.com/api/user/:userID/connections?sort=name-asc',
params: {
userID: 1,
},
});
Et bien sûr, vous pouvez les combiner. Cela envoie une requête vers GET /api/user/1/connections?sort=name-asc&first=10
.
m.request({
url: 'https://example.com/api/user/:userID/connections?sort=name-asc',
params: {
userID: 1,
first: 10,
},
});
Cela s'applique également à la correspondance de route : vous pouvez faire correspondre une route avec des chaînes de requête explicites. Le paramètre correspondant est conservé pour plus de commodité, vous pouvez donc toujours y accéder via les paramètres vnode ou via m.route.param
. Notez que bien que cela soit possible, il est généralement déconseillé de procéder ainsi. Il est préférable d'utiliser les chemins pour définir les pages. Cela peut parfois être utile si vous devez générer une vue légèrement différente pour un type de fichier particulier, mais il s'agit toujours logiquement d'un paramètre de type requête, et non d'une page distincte entière.
// Remarque : ceci n'est généralement *pas* recommandé - il est préférable d'utiliser les chemins pour la déclaration de route, et non les chaînes de requête.
m.route(document.body, '/edit/1', {
'/edit?type=image': {
view: function () {
return [m(Menu), m('h1', 'Modification de la photo')];
},
},
'/edit': {
view: function () {
return [m(Menu), m('h1', 'Modification de ' + m.route.param('type'))];
},
},
});
Les paramètres de requête sont consommés implicitement : il n'est pas nécessaire de les nommer pour qu'ils soient acceptés. Vous pouvez faire correspondre en fonction d'une valeur existante, comme dans "/edit?type=image"
, mais vous n'avez pas besoin d'utiliser "/edit?type=:type"
pour accepter la valeur. En fait, Mithril.js traiterait cela comme si vous essayiez littéralement de faire correspondre m.route.param("type") === ":type"
, ce qui n'est probablement pas ce que vous voulez. En bref, utilisez m.route.param("key")
ou les attributs de composant de route pour lire les paramètres de requête.
Normalisation des Chemins
Les chemins analysés sont toujours renvoyés avec tous les paramètres en double et les barres obliques supplémentaires supprimés, et ils commencent toujours par une barre oblique. Ces légères différences peuvent être gênantes et compliquent inutilement le routage et la gestion des chemins. Mithril.js normalise en interne les chemins pour le routage, mais n'expose pas directement la route normalisée actuelle. (Vous pouvez la calculer via m.parsePathname(m.route.get()).path
.)
Lors de la déduplication des paramètres lors de la correspondance, les paramètres dans la chaîne de requête sont préférés aux paramètres dans le nom du chemin, et les paramètres vers la fin de l'URL sont préférés aux paramètres plus proches du début de l'URL.
Échappement des Chemins
Certains caractères doivent être échappés si vous souhaitez les utiliser littéralement. Heureusement, encodeURIComponent
les encode (ainsi que de nombreux autres caractères). Lors de la substitution de paramètres et de l'ajout de paramètres de requête, ils sont encodés si nécessaire grâce à cette fonction. Voici les caractères que Mithril.js interprète :
:
=%3A
/
=%2F
(requis uniquement dans les chemins)%
=%25
?
=%3F
(requis uniquement dans les chemins)#
=%23
Bien sûr, il existe d'autres caractères que vous devez échapper selon la spécification URL, comme les espaces. Mais comme déjà noté, encodeURIComponent
le fait pour vous, et Mithril.js l'utilise implicitement lorsque vous substituez des paramètres. Il est donc uniquement nécessaire de s'en soucier lors de la spécification explicite de paramètres, comme dans l'exemple suivant : m.request("https://example.com/api/user/User%20Name/:field", {params: {field: ...}})
.