OpenAPI & Générateur de Service

Les utilisateurs de @byeolnaerim/typed-rx-http, /next ou /rsocket n'ont pas besoin d'exécuter ce script et n'ont pas besoin d'installer openapi-typescript dans leur projet.

La génération de types OpenAPI nécessite le CLI openapi-typescript, mais le package ne l'inclut pas dans les dépendances générales. Les devDependencies.typescript de typed-rx-http maintiennent la version TypeScript 6.0.3, et n'utilisent un environnement npx temporaire que dans le script auto node OpenAPI.

À l'étape de génération OpenAPI de base, openapi-typescript et [email protected] sont exécutés ensemble, donc cela ne modifie ni n'utilise la version TypeScript/openapi-typescript installée dans le projet de l'utilisateur.

Si nécessaire, vous pouvez fixer la commande complète à openApiTypescriptCommand.

Ou vous pouvez simplement changer la version du package qui compose la commande de base.

Avant que commonServiceFile n'apparaisse dans l'exemple de générateur, vous devez comprendre ce fichier. commonServiceFile n'est pas une option pour créer un fichier, mais le chemin du fichier possédé par le projet où le service généré importera des fonctions HTTP communes. Le nom du fichier peut être librement choisi, comme rxjsHttpService.ts, commonService.ts, etc.

Code complet de la forme minimale

Le fichier ci-dessous crée une fois createHttpClient dans le projet et exporte callApi et callApiStream pour réutilisation par le service généré. Si le cache ou l'authentification de session n'est pas nécessaire, vous pouvez commencer avec cette structure.

Code complet incluant le cache de session/CSR/SSR

Pour que le service généré utilise callApiClientCache ou callApiServerCache, ou pour gérer communément les en-têtes par requête et l'authentification de session dans Next.js, étendez-le à la forme complète suivante.

Les paramètres par défaut génèrent les fichiers ci-dessous.

apiUnionArrays.tsgénère non seulement l'énumération du schéma OpenAPI, mais aussi un tableau constant en lecture seule pour les énumérations de paramètres de requête, de chemin, d'en-tête et de cookie, et traite également les items.enum des paramètres de requête en tableau.

Swagger peut être Springdoc, un autre outil OpenAPI ou un fichier écrit manuellement. Si vous utilisez un point de terminaison fonctionnel WebFlux, webflux-fe-dev-assistantVous pouvez également utiliser cette méthode pour fournir la documentation Swagger.

Vous pouvez spécifier l'endpoint backend, le swagger.json à enregistrer, le chemin de sortie des types/services et commonServiceFile selon la structure de votre projet.

Dans un environnement où la documentation ne peut pas être reçue par HTTP, vous pouvez utiliser generateSwaggerFromFileavec les mêmes options de sortie.

commonServiceFileest le chemin du fichier possédé par le projet où le service généré importera callApi, callApiStream et le wrapper de cache. Ce n'est pas une option pour que le générateur crée ou écrase ce fichier.

Le fichier public désigné par commonServiceFile, comme rxjsHttpService.ts, est géré directement par le projet. Les résultats sous auto et @types/auto sont régénérés lorsque la documentation change.

Le nom du fichier de service est déterminé par les deux premiers segments de l'URL, et le nom de la fonction est déterminé par les segments suivants à partir du troisième. Les variables de chemin sont incluses dans le nom de la fonction sous la forme By + PascalCase.

La clé du paramètre de requête du service généré est params, la variable de chemin est path, et le corps de la requête est body. À l'intérieur de la fonction de génération, ils sont convertis respectivement en ServiceArguments pour queryString, pathVariable et body.