forked from cms/tibi-svelte-starter
.vscode | ||
api | ||
cypress | ||
public | ||
scripts | ||
src | ||
types | ||
.drone.yml | ||
.gitignore | ||
.prettierrc | ||
babel.config.cypress.json | ||
babel.config.json | ||
cypress.json | ||
docker-compose.cypress.yml | ||
esbuild.config.cypress.js | ||
esbuild.config.js | ||
esbuild.config.legacy.js | ||
esbuild.config.server.js | ||
LICENSE | ||
package.json | ||
README.md | ||
svelte.config.js | ||
tsconfig.json | ||
yarn.lock |
wmbasic-svelte-starter
Starter Kit für SPAs(s) ;)
mit Svelte und WMBasic-Backend ink. SSR
Wozu?
Via Svelte wird eine SPA (Single-Page-App) programmiert. Dazu wird der Code einmal für den Browser aufgebreitet und außerdem für den Server kompiliert und transpiliert. Der Server-Code wird in einem WMBasic-API SSR-Hook (server side renering) eingebunden und generiert dort fertiges HTML anhand der aktuelle Route für SEO und optimierte Ladezeiten.
Die Navigation innerhalb der APP im Browser löst dagegen nur API-Aufrufe aus ohne jedesmal einen SSR-Prozess anzustoßen.
Um die SSR-Last so gering wie möglich zu halten, wurde ein Caching in der "ssr"-Collection der API implementiert.
Toolchain
Abhängigkeiten laden
yarn install
Entwickeln mit dev-Webserver
yarn start
oder mit abweichender API für "/api"-Proxy
API_BASE=https://login.wmbasic.de/api/v1_/__NAMESPACE__ yarn start
Entwickeln mit externem Webserver (z.B. vscode live server)
yarn dev
Testen
yarn build:istanbul # instrumentiert Code für coverage-Report
yarn cy:docker:run # oder mit Xserver und UI cy:docker:open
Bauen
# moderne Browser
yarn build
# alte Browser (IE11)
yarn build:legacy
# serverseitiges Rendering
yarn build:server