Use when building a React frontend that dynamically loads independent bundles sharing a single React instance via import maps, needs frecency-based autocomplete, dynamic schema-driven forms, or Zustand state with localStorage.
复制安装指令,让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "react-microfrontend-patterns" 技能: 1. 下载 https://raw.githubusercontent.com/microsoft/amplifier-bundle-skills/main/skills/react-microfrontend-patterns/SKILL.md 2. 保存为 ~/.claude/skills/react-microfrontend-patterns/SKILL.md 3. 装好后重载技能,告诉我可以用了
Problem: You have multiple independently-built UI bundles that must share React at runtime, a form system driven by server-side schemas that change dynamically, and state that needs to persist in the browser and sync across tabs.
Approach: Import maps with Vite's rollupOptions.external for shared React, a useFrecency hook with exponential decay scoring, schema-to-React rendering with action-triggered schema refinement, and Zustand stores with localStorage sync.
Pattern proven in production across multiple React frontends and web services.
rollupOptions.external for shared ReactWhen multiple independently-built bundles run on the same page, each gets its own copy of React. This causes the "dual React instance" bug: hooks break because the React instance that rendered the component is different from the one providing useState.
The fix: externalize React in every bundle's Vite config and provide it via an import map in the HTML:
<!-- index.html -->
<script type="importmap">
{
"imports": {
"react": "https://esm.sh/[email protected]",
"react-dom": "https://esm.sh/[email protected]",
"react-dom/client": "https://esm.sh/[email protected]/client",
"react/jsx-runtime": "https://esm.sh/[email protected]/jsx-runtime"
}
}
</script>
// vite.config.ts
export default defineConfig({
build: {
rollupOptions: {
external: ['react', 'react-dom', 'react-dom/client', 'react/jsx-runtime'],
},
},
})
Vite's dev server ignores browser import maps — it pre-bundles CJS modules and serves them from /.vite/deps/. This means dynamically-loaded bundles that use bare import React from 'react' will resolve via the import map to a different React instance than the host app.
Solutions: Use @vitejs/plugin-react with careful configuration, or write a custom Vite plugin that serves shim modules redirecting bare specifiers to Vite's pre-bundled paths during dev. This is inherently complex — consult your Vite config documentation for the specifics of your setup.
Frecency (frequency + recency) ranks autocomplete results by how often AND how recently a user selected them:
// hooks/useFrecency.ts
const DECAY_HALF_LIFE_MS = 7 * 24 * 60 * 60 * 1000 // 1-week half-life
const STORAGE_KEY = 'frecency-data'
const _suggestionCache = new Map<string, string[]>() // module-level perf cache
interface FrecencyEntry {
score: number
lastUsed: number // timestamp ms
}
function computeScore(entry: FrecencyEntry, now: number): number {
const ageFraction = (now - entry.lastUsed) / DECAY_HALF_LIFE_MS
return entry.score * Math.pow(0.5, ageFraction)
}
function useFrecency(namespace: string) {
const [entries, setEntries] = useState<Record<string, FrecencyEntry>>(() => {
const stored = localStorage.getItem(`${STORAGE_KEY}:${namespace}`)
return stored ? JSON.parse(stored) : {}
})
const getSuggestions = useCallback((fieldKey: string, allValues: string[]) => {
const cacheKey = `${namespace}:${fieldKey}`
if (_suggestionCache.has(cacheKey)) return _suggestionCache.get(cacheKey)!
const now = Date.now()
const sorted = [...allValues].sort((a, b) => {
const sa = entries[a] ? computeScore(entries[a], now) : 0
const sb = entries[b] ? computeScore(entries[b], now) : 0
return sb - sa
})
_suggestionCache.set(cacheKey, sorted)
return sorted
}, [namespace, entries])
const recordValue = useCallback((fieldKey: string, value: string) => {
_suggestionCache.clear()
setEntries(prev => {
const now = Date.now()
const existing = prev[value] ?? { score: 0, lastUsed: now }
const updated = { ...prev, [value]: { score: existing.score + 1, lastUsed: now } }
…
Guide for creating new Amplifier modules including protocol implementation, entry points, mount functions, and testing patterns. Use when creating new modules or understanding module architecture.
Python coding standards for Amplifier including type hints, async patterns, error handling, and formatting. Use when writing Python code for Amplifier modules.
Adapt a skill written for another AI coding assistant (Claude Code, Cursor, etc.) into a properly structured Amplifier SKILL.md file. Reads the source skill, identifies platform-specific conventions, researches the source platform if needed, and produces an Amplifier-native skill conforming to the Agent Skills specification with Amplifier extensions. Use when the user wants to adapt a skill, port a skill, convert a skill to amplifier, translate a skill, or has a SKILL.md from another platform they want to bring into Amplifier.
Use when your service needs authentication that works without friction locally but secures remote access, automatic TLS certificate setup, or token-based auth with auto-generation and localhost bypass.
Use when building a new CLI tool that needs one-line install via uv or npm, subcommand dispatch with a default action, or 3-tier config resolution (CLI flags, config file, hardcoded defaults).
Amplifier design philosophy using Linux kernel metaphor. Covers mechanism vs policy, module architecture, event-driven design, and kernel principles. Use when designing new modules or making architectural decisions.