-
Maptiler SDK & Vue JS
Bonjour,
Je débute avec VueJS, et j'essaye de me rapprocher au mieux des bonnes pratiques.
Ce que je veux
Pour une application cartographique, je voulais connaître la meilleure pratique entre celle-ci ([https://docs.maptiler.com/vuejs/]) et celle-ci ([https://dev.to/mug-jp/building-a-map...pt-setup-4mim])
Ce que j'obtiens
Les deux méthodes fonctionnent, je veux juste connaître la différence entre les deux codes.
Merci pour vos retours.
Sylvain
-
Salut Sylvain,
Petit disclaimer: je travaille pour MapTiler, je suis le développeur du SDK et de pas mal d'autres plugins qui composent cet écosystème.
Je ne suis pas super familier avec VueJS, donc à prendre avec des pincettes, par contre je sais que les differents "boilerplates" de la section "Learn the basics" sur notre site ont était réalisés à partir des boilerplates officiel de ViteJS (https://vite.dev/guide/). Ils ont l'avantage d'ètre relativement simples et minimalistes pour ce qui est de la config de Vite et TypeScript. Ensuite, la principale differences entre les deux approches réside dans le fait que l'exemple MapTiler utilise une reference (shallowRef) qui pointe vers l'instance de la classe Map, avec l'utilisation de MarkRaw pour éviter d'en faire une propriété "reactive" (https://vuejs.org/api/reactivity-advanced.html#markraw), alors que l'approche sur Dev.to ne fait rien de cette instance de Map et n'offre pas la possibilité de l'exposer à d'autre composants, ce qui pose certaines limitations pour la souscription à des évènements ou ajouts de plugins. L'approche de Dev.to ne permet pas non plus de "libérer" la map (c'est à dire désalouer la mémoire GPU utilisée principalement pour stoquer des textures), du fait du "scoping" de la variable "map". Il faut savoir que même si JS propose un garbage collector, celui-ci ne viendra pas nettoyer la mémoire GPU, il faut donc faire un appel explicite. Dans le tuto MapTiler, tu peux voir un appel à la methode ".remove()" lors du démontage du composant Vue, c'est un des avantage à utiliser une ref: on peut la réutiliser plus tard dans le cycle de vie du composant.
De manière générales, tout dépend de ton besoin. Comme souvent, l'important est de bien comprendre en quoi les deux approches sont différentes afin de prendre une décision qui t'évitera de faire un refactoring plus tard. Selon si tu construis une librarie qui va être utilisée par la communauté ou si tu construis un site web complet pour toi ou un client, alors le soin que tu vas devoir apporter à ta config Vite et TypeScript ne sera peut étre pas le même. Faire une lib demande à ètre plus rigoureux car elle peut etre utilisées dans plein de conditions que tu ne controles pas, c'est donc primordial dans ce cas de partir d'une base Vite saine.
Bon courage à toi!