feat: runtime npm registry fetching for lynx-example versions#23
Open
feat: runtime npm registry fetching for lynx-example versions#23
Conversation
✅ Deploy Preview for lynx-go-web ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
- New npm-registry.ts module provides runtime example discovery and version selection via jsdelivr CDN, replacing build-time prepare-examples.js - ExamplePreview accepts optional version prop to fetch from CDN instead of local static files - Example app now displays runtime example list from npm registry and version selector dropdown - Example packages no longer need to be pre-downloaded at build time, enabling zero-install and support for any published version This enables browsing any version of any @lynx-example/* package directly in the browser without requiring a rebuild.
…ntext Remove the global Version dropdown from the toolbar to avoid the confusion of a unified version control across packages that have independent version histories. Instead, show the version selector in the Entries column header (clearly scoped to the selected example) and display the current version as a badge on the active example list item.
The jsdelivr data API (/v1/packages/npm/...) does not support dist-tags like 'latest' — it requires exact semver versions. Passing 'latest' caused file listing and metadata fetches to silently fail. Compute effectiveVersion by resolving 'latest' against the already-fetched examplePackages (npm search result) or packageVersions[0] (fallback). Pass effectiveVersion to ExamplePreview and fetchExampleMetadata instead of the raw version state.
…validate - Initialize useExamplePackages from build-time EXAMPLES env var so the list renders immediately on first paint with zero network latency - Background-fetch from npm registry replaces the list once resolved - Replace loading: boolean with source: 'build'|'fetching'|'live'|'error' for precise state semantics - Add SourceBadge component in the Examples panel header showing current data source with color-coded states and a pulsing dot during fetch
5fcb8a2 to
63a146d
Compare
…stead Root cause of missing loading overlay: effectiveVersion started as undefined (while examplePackages loaded), causing ExamplePreview to mount twice — first with useCdn=false (local static files), then remount with a real semver (CDN). During the CDN remount's metadata fetch window there was no WebIframe and therefore no loading overlay visible. Fix: remove the 'latest' virtual version entirely. version state defaults to undefined; a new useEffect auto-pins it to packageVersions[0].version once the version list loads. effectiveVersion falls back to currentPkg.version from the already-loaded examplePackages, so the CDN path is taken immediately on example switch (single mount, single loading overlay).
The runtime fetch layer only searched @lynx-example/* and hardcoded that scope everywhere, breaking vue-lynx-example support added in cecc9a0. Introduce EXAMPLE_SCOPES as a shared source of truth for scope metadata (prefix, git base URL) and update all consumers: - searchExamplePackages() now searches all configured scopes in parallel - fetchExampleMetadata() derives git URL and shortName from scope config - Build-time init in main.tsx maps vue- prefixed names back to their scope - Package name derivation uses currentPkg instead of hardcoded scope
… load
Root cause: the LoadingOverlay lives inside WebIframe, which only mounts
after defaultWebPreviewFile is set (i.e. after metadata finishes fetching).
During the CDN metadata fetch window there is no WebIframe in the tree at
all, so no loading indicator is visible. Additionally, once the CDN bundle
is browser-cached the template renders in ~2 rAFs which is imperceptible.
Fix: import LoadingOverlay into ExampleContent and render it directly on
the preview-wrap-content panel with visible={!initState}. This covers the
entire metadata-fetch phase. The WebIframe's own overlay continues to
handle the subsequent template-load phase, giving a seamless indicator
from the moment the CDN version is requested until the frame is painted.
Two distinct loading phases, clearly separated:
1. **App-level (example app):** Don't render Go until effectiveVersion is
resolved. This avoids the useCdn=false → useCdn=true double-mount when
effectiveVersion transitions from undefined to a real semver. Show a
simple "Resolving package version…" placeholder instead.
2. **Go library (ExampleContent):** The LoadingOverlay with
visible={!initState} covers the CDN metadata fetch phase. This is Go's
own universal loading state — it works wherever Go is embedded, not just
in this example app.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Implemented runtime npm registry discovery for @lynx-example packages, enabling browsing any version directly from the CDN without build-time preparation.
versionprop to fetch from CDNTest Plan