Bon retour dans la deuxième partie ! Dans la première partie, nous avons exploré les bases de la création d'un plugin Obsidian. Si vous l'avez manqué, je vous recommande de le lire d'abord. Nous allons maintenant améliorer l'architecture globale et la disposition des fichiers du plugin, ainsi qu'ajouter la gestion des erreurs de base. De plus, je partage mes apprentissages depuis la sortie des premières versions de patch, commençons !

Le point de départ

À partir du modèle de plugin mentionné, la structure globale du plugin est constituée d'un ensemble de fichiers situés tous dans le dossier racine du référentiel :

Sans afficher les fichiers de configurations techniques tels quepackage.json. L'intégralité du code source des plugins, y compris ses paramètres, son interface utilisateur et sa logique, est contenu dans un seul fichier,main.ts. Bien qu'il serve de point de départ et de modèle, cela ne représente pas une bonne structure pour le développement ultérieur de fonctionnalités.

L'état souhaité

Avant de décrire la disposition et l'architecture actuelles, récapitulons d'abord quelques directives générales utilisées dans...
[Courte citation de 8% de l'article original]