wix-headless-templates

Par wix · skills

Le code livré et vérifié derrière les sites Wix Headless, un dossier par solution métier Wix : boutique en ligne, réservations, locations, blog, collections CMS, formulaires, membres, événements, restaurants, dons, plans tarifaires, portfolio, FAQ. Chaque dossier embarque une couche de données typée et indépendante du framework reposant sur @wix/sdk, des hooks React et des composants de référence, des pages Astro avec SEO modifiable par le propriétaire, un équivalent REST pour les sites sans bundler, un script de seed qui alimente le site à partir d'un plan, un reader qui recense ce que le site contient déjà, ainsi qu'un playbook (INSTRUCTIONS.md) définissant les contrats. Éléments partagés entre eux : socles de design et de contenu, les capabilities (recherche sur le site, upload de médias), les helpers de seed, et un projet composé avec dépendances verrouillées par solution qu'une commande `create` copie intégralement. Utilisé par wix-headless-kit, qui récupère, déploie et seed depuis ce dossier ; lisible de manière autonome pour comprendre ce que fait le code d'une solution et comment elle est seedée.

npx skills add https://github.com/wix/skills --skill wix-headless-templates

Wix Headless Templates

Le code à partir duquel un site Wix Headless est construit, un dossier par Wix Business Solution. wix-headless-kit est la skill qui exécute un build : son install/templates.mjs récupère ce dossier une fois dans le templates/ du kit (un clone sparse de skills/wix-headless-templates/, ou le checkout quand le kit s'exécute à partir de celui-ci) et le kit copie, déploie et remplit à partir de là. Cette skill ne possède aucun flux propre ; c'est la matière, conservée en tant que skill pour qu'elle soit publiée, mirrorée et lisible comme telle.

Layout

chemin description
<solution>/INSTRUCTIONS.md le playbook de la solution : ce qui est livré, les contrats de chaque hook, store et DTO, les pages, les liens du dashboard
<solution>/app/ le cœur agnostique du framework : wix/<solution>/*-core.ts (logique pure), le transport SDK, les machines d'état *-store.ts, types.ts ; hooks/ (liaisons React) et components/ (implémentations de référence, correctes et simples)
<solution>/app-astro/ pages et layouts Astro avec SEO modifiable par le propriétaire pré-câblé
<solution>/rest/ la couche de données à nouveau sur fetch pur, mêmes exports, pour un site sans bundler
<solution>/seed/ SEED.md (la forme du plan et les pièges), seed-<solution>.mjs (remplit le site à partir d'un plan, idempotent), read-site.mjs (rapporte ce que le site contient déjà)
<solution>/project/ le projet composé : l'échafaudage vierge du CLI avec la solution déployée et un package-lock.json, copié entièrement à la création ou l'attachement pour que npm ci installe sans résoudre
shared/ DESIGN.md et CONTENT.md (les base que tout site rencontre), CUSTOM_OPERATIONS.md (travail côté serveur nécessitant des appels élevés), app/ et rest/ (le client, les soudures média et config), capabilities/ (recherche de site, upload média), seed/ (le resolver CLI, token, resolver d'image et contexte de site que chaque seed utilise)
blank/ l'échafaudage CLI pristine à partir duquel les projets composés commencent
compose.mjs outillage du repository : reconstruit le project/ d'une solution à partir de blank/ plus un deploy, et son lock

Les solutions : storefront, bookings, rentals, blog, cms, forms, members, events, restaurants, donations, pricing-plans, portfolio, faq.

Le lire de façon autonome

  • Ce qu'une solution fait et comment ses pièces s'assemblent : <solution>/INSTRUCTIONS.md, puis app/wix/<solution>/types.ts.
  • Comment un site est rempli et ce que le seed refuse : <solution>/seed/SEED.md.
  • Ce qu'un site existant contient avant quoi que ce soit soit écrit : node <solution>/seed/read-site.mjs --site <siteId> (un CLI Wix connecté).
  • Un seed à la main, à partir d'un dossier projet avec un wix.config.json : node <solution>/seed/seed-<solution>.mjs plan.json.

Le modifier

Le code sous app/, app-astro/, rest/ et seed/ est la source ; project/ est généré à partir de celui-ci avec node compose.mjs <solution> à partir d'un checkout du repository (il réinstalle les dépendances du projet, donc exécutez npm ci dans le projet avant une vérification de type). Un projet composé est vérifié avec tsc sur son propre tsconfig.json. Les locks sont résolus localement, jamais sur un mirror sandbox.

Skills similaires