NgSysV.A Serious Svelte InfoSys : une version conviviale

Cette série d'articles est indexée sur NgateSystems.com. Vous y trouverez également une fonction de recherche par mot-clé très utile.

Dernière révision : 24 novembre

1. Présentation

Cette série a déjà décrit comment vous pouvez utiliser le framework Svelte en conjonction avec l'API client de la base de données Firestore de Google pour développer des systèmes d'information utiles rapidement et de manière agréable. Malheureusement, cependant, la publication 3.3 a révélé comment l'excellent système d'authentification de Firebase ne prend pas en charge l'activité Firestore dans les fonctions load() et actions() côté serveur où les règles de base de données font référence à l'objet d'authentification.

Ignorer vos règles d'autorisation Firestore n'est pas une option - sans celles-ci, votre base de données est grande ouverte à quiconque peut détourner les clés FirebaseConfig de votre application Web. Cet article décrit les moyens de retravailler le code côté serveur Svelte afin qu'il s'exécute côté client tandis que les règles Firestore restent fermement en place.

2. Retravailler les fonctions load() « compromises »

Toutes les fonctions load() ne seront pas affectées par la présence des règles Firestore. Ceux qui font référence aux collections Firestore publiques fonctionneront toujours avec plaisir côté serveur. L'API client est toujours disponible dans les fichiers page.server.js - elle ne fonctionnera tout simplement pas si on lui demande d'utiliser des collections protégées par authentification.

Si votre fonction Load() traite des fichiers publics et que vous souhaitez simplement éviter le débogage côté serveur, vous pouvez envisager de déplacer votre fonction Load() dans un fichier page.js. Cela fonctionne exactement comme un fichier page.server.js - Svelte exécutera toujours la fonction automatiquement au moment du chargement. Mais cela se produit maintenant côté client où il peut être débogué dans le navigateur. Voir la documentation Svelte sur Chargement des données pour plus de détails

Cependant, une fonction load() « compromise » (généralement dans laquelle les règles Firestore sont utilisées pour garantir que les utilisateurs ne peuvent accéder qu'à leurs propres données) doit être déplacée dans le code côté client. En règle générale, cela serait retravaillé comme une nouvelle fonction, correctement nommée, dans le