Download the PHP package velt/preview without Composer
On this page you can find all versions of the php package velt/preview. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Package preview
Short Description Module Preview pour VeltPHP - Prévisualisation mobile via QR code
License MIT
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package preview
Velt Preview
Velt Preview définit le protocole qui permet à une application Velt en cours de développement d’exposer ses écrans à un client de prévisualisation. Le package gère les sessions temporaires, la représentation JSON versionnée des interfaces, les erreurs de protocole et les informations encodées dans le QR code.
Ce dépôt ne prétend pas, à lui seul, être l’équivalent de l’application Expo Go. Il constitue la couche serveur et contractuelle consommée par velt-mobile-preview. Le rendu Android natif, la découverte réseau, la signature des sessions et le transport temps réel doivent être validés conjointement avant une version stable.
Statut : préversion. Le stockage fichier et le transport HTTP actuel conviennent au développement local, pas à une exposition sur Internet.
Pourquoi ce package existe
Une page Velt doit pouvoir être rendue sans envoyer de HTML à l’application mobile. Preview transforme une vue déclarative en un arbre portable : le client Android lit les composants, vérifie la version du schéma, puis les associe à ses composants natifs. Cette séparation évite de cacher une WebView derrière une API dite « native ».
Capacités actuelles
- création, lecture et expiration logique de sessions de preview ;
- registre de pages indépendant du contrôleur HTTP ;
- réponses JSON pour une session ou une route connue ;
- erreurs structurées pour les sessions et pages inconnues ;
- génération d’URL et de QR codes SVG ;
- schéma JSON explicite avec
schemaVersion,screen,metaetcomponents; - parser expérimental de fichiers
.veltindentés et AST minimal ; - tests unitaires des stores, endpoints et contrats.
Installation
Pour contribuer au dépôt :
La ligne de commande publique destinée aux applications reste velt. Le binaire interne velt-preview est un outil de package et ne remplace pas la CLI officielle.
Démarrage rapide
Dans une application créée par le skeleton :
L’adresse doit être accessible depuis le téléphone. 127.0.0.1 et localhost désignent le téléphone lorsqu’ils sont utilisés dans l’application mobile et ne peuvent donc pas joindre le poste de développement.
Une session associe au minimum :
- un identifiant imprévisible ;
- une vue ou route Velt ;
- une URL réseau joignable ;
- une date de création et, à terme, une expiration ;
- la version du protocole et les capacités proposées.
Contrat JSON
Exemple simplifié :
Règles de compatibilité :
- le client refuse une version majeure de schéma inconnue ;
- les champs obligatoires ne changent pas silencieusement de type ;
- un composant inconnu produit un diagnostic visible, jamais une exécution arbitraire ;
- les événements utilisent des identifiants stables et des payloads validés ;
- le JSON ne contient ni PHP exécutable, ni HTML à charger dans une WebView ;
- chaque évolution incompatible exige une nouvelle version du schéma et des fixtures de compatibilité.
Endpoints applicatifs
Le skeleton expose actuellement les routes de démonstration suivantes :
| Méthode | Route | Responsabilité |
|---|---|---|
GET |
/api/preview/{id} |
retourne l’arbre UI de la session |
GET |
/api/session/{id} |
retourne les métadonnées de session |
GET |
/api/preview-route/{path} |
rend une route Velt connue en JSON |
Les erreurs doivent conserver une forme déterministe :
Les statuts HTTP attendus sont notamment 400 pour une requête invalide, 404 pour une ressource inconnue, 410 pour une session expirée, 422 pour un payload incompatible et 500 pour une erreur serveur masquée au client.
Architecture du dépôt
| Dossier | Rôle |
|---|---|
preview-contracts/ |
contrats partagés et types d’erreur |
preview-session-store/ |
persistance des sessions de développement |
preview-endpoints/ |
contrôleur et réponses HTTP découplés |
preview-qr-cli/ |
URL de connexion et QR SVG |
preview-json-contract/ |
sérialisation et validation du protocole |
preview-flow-e2e/ |
scénario d’intégration entre les couches |
velt-ast/ |
arbre syntaxique expérimental |
velt-parser/ |
parser expérimental du format .velt |
velt-view/ |
chargement des vues et adaptation en page Preview |
Le package conserve actuellement plusieurs espaces de noms historiques. Leur consolidation sous Velt\Preview\ doit faire l’objet d’une migration documentée afin de ne pas casser les consommateurs existants.
Format .velt expérimental
Ce format n’est pas encore déclaré stable. La syntaxe PHP .velt.php de velt/ui reste la voie applicative documentée tant que le parser texte ne possède pas de grammaire formelle, de diagnostics de position et de stratégie de migration.
QR code et connexion
Le QR code encode une URL de session ; il ne doit pas contenir de secret permanent. En développement local, le SVG est écrit dans storage/qrcodes. Ces artefacts ne doivent pas être versionnés ni réutilisés comme identifiants de production.
La cible de sécurité comprend :
- jeton éphémère, signé et à usage limité ;
- durée de vie courte et révocation explicite ;
- négociation de version et de capacités avant le rendu ;
- HTTPS/WSS dès que la connexion sort du réseau local contrôlé ;
- absence de chargement de code arbitraire depuis le serveur ;
- liste fermée des événements et API appareil autorisés ;
- logs expurgés des jetons et données sensibles.
Preview temps réel : cible
Le polling actuel prouve le flux mais ne représente pas l’expérience finale. La cible prévoit :
- ouverture d’une session signée depuis la CLI ;
- lecture du QR ou du deep link par le companion ;
- négociation du schéma et des capacités ;
- snapshot initial complet ;
- mises à jour par WebSocket sous forme de diffs ordonnés ;
- accusés de réception des événements utilisateur ;
- reconnexion avec backoff et reprise à partir d’un numéro de séquence ;
- diagnostic clair si un rebuild du client est nécessaire.
Relation avec le runtime Android
Preview et le runtime embarqué sont deux chemins différents :
- le companion Preview exécute le kernel sur l’ordinateur et reçoit un arbre UI par le réseau ;
- l’APK final embarque PHP et appelle les composants Android via
nativephp_call()et JNI ; - aucun des deux chemins ne doit utiliser une WebView comme rendu principal ;
- une fonctionnalité native absente du companion standard nécessite un client de développement personnalisé ;
- le faux bridge de
velt/nativeest réservé aux tests PHP.
La spécification complète est maintenue dans velt-mobile-architecture.
Tests et qualité
Avant une version stable, la CI doit également couvrir :
- PHP 8.2, 8.3 et 8.4 sur Linux et Windows ;
- fixtures valides et invalides pour chaque version du schéma ;
- concurrence, corruption et nettoyage du store de sessions ;
- tests E2E contre le vrai
velt/uiet le vrai routeurvelt/http; - reconnexion, ordre des événements et expiration ;
- tests de sécurité des URL, jetons et payloads ;
- matrice de compatibilité avec chaque version publiée du companion Android.
Limites connues avant stabilité
- stockage fichier non adapté à plusieurs processus ;
- protocole temps réel et authentification signée non finalisés ;
- parser
.veltencore expérimental ; - compatibilité ascendante non automatisée sur plusieurs versions ;
- pas encore de suite Android instrumentée exécutée avec ce dépôt ;
- artefacts de démonstration historiques présents dans certains dossiers de stockage.
Ces limites sont des gates de release : elles ne doivent pas être masquées par un tag stable.
Contribution
Une modification de protocole doit inclure : tests, fixture JSON, documentation de compatibilité, impact sur velt-ui, velt-mobile-preview et velt-native, ainsi qu’une note de migration lorsque le changement est incompatible. Les issues du dépôt et les milestones de l’organisation indiquent les priorités et échéances.
Licence
Velt Preview est distribué sous licence MIT.
