* docs: comprehensive audit and fix of hallucinated v3 documentation Three-pass audit of all v3 documentation against source code on v3-alpha, fixing hundreds of hallucinated API patterns, fabricated CLI flags, wrong method signatures, and incorrect struct fields across 59 files. Pass 1: Pattern-matched sweep for known wrong API names Pass 2: Source-code-first specialist agents (6 agents by area) Pass 3: Deep field-by-field verification (7 specialist agents) Key fixes: - Removed fabricated OnStartup/OnBeforeClose hooks, replaced with ServiceStartup interface, ShouldQuit, RegisterHook patterns - Removed fabricated window convenience methods (OnClose, OnFocus, etc.), replaced with OnWindowEvent(events.Common.*, ...) pattern - Removed fabricated CLI flags (-platform, -o, -ldflags, -icon, etc.), documented actual Taskfile-based build system with GOOS/GOARCH - Fixed package-level dialog functions to Manager API - Fixed JS runtime imports (OnEvent/Emit -> Events.On/Events.Emit) - Fixed platform option struct names (MacOptions->MacWindow, etc.) - Fixed Screen struct fields, WebviewWindowOptions fields - Added missing documentation for 20+ window methods, 30+ platform option fields, complete Application Options table, missing CLI commands - Fixed event callback signatures, event constant names - Fixed ServiceShutdown signature, OnClick callback signatures Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * docs: apply PR review principles - JS event objects, directives, lifecycle Address feedback from PR #4975 review by fbbdev and Copilot: JS event callbacks (Principle 3 - 14 fixes across 10 files): - All JS event callbacks now correctly receive event object, access payload via event.data instead of receiving data directly - Fixed in: reference/window, concepts/bridge, concepts/architecture, migration/v2-to-v3, guides/gin-routing, guides/gin-services, features/dialogs/custom, features/bindings/best-practices Wails directives (Principle 2 - 2 files): - Fixed //wails:internal semantics: IS exported to frontend but kept module-private (not re-exported from index), NOT "prevents export" - Fixed //wails:ignore description: completely excluded from JS bindings - Added new "Internal + Inject Pattern" section with real SQLite service example showing how //wails:internal + //wails:inject work together ContextMenu.Update() (Principle 5): - Added missing Update() call in guides/menus.mdx image gallery example Lifecycle patterns verified correct - ServiceStartup usage is for business logic init, not lifecycle hooks. EventManager.Emit confirmed to return bool per source (Principle 4 in audit doc was incorrect). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * docs: fix lifecycle docs - use events not services for lifecycle hooks ServiceStartup is for service resource initialization (DB, config), NOT for application lifecycle hooks. Application lifecycle events (events.Common.ApplicationStarted, ThemeChanged) are the correct mechanism for reacting to lifecycle stages. - architecture.mdx: replace misleading "Lifecycle hooks" section - lifecycle.mdx: add Application Lifecycle Events section (new §3) - lifecycle.mdx: rename "Service Startup" to "Service Initialisation" - lifecycle.mdx: categorize reference table (events/services/options) - lifecycle.mdx: update d2 diagram with ApplicationStarted stage - lifecycle.mdx: update best practices to distinguish init vs lifecycle Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * docs: fix issues from PR review comments - menus.mdx: add Update() call after adding items to context menu snippet - application.mdx: fix Emit() signature — remove fabricated bool return - events-reference.mdx: fix files-dropped JS example to account for variadic wrapping (event.data[0] is the files array) - bridge.mdx: fix progress event example — use variadic args directly and destructure event.data array in JS Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| .vscode | ||
| public | ||
| src | ||
| .gitignore | ||
| .npmrc | ||
| astro.config.mjs | ||
| build-output.txt | ||
| bun.lock | ||
| CNAME | ||
| create-dirs.ps1 | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| Taskfile.yml | ||
| tsconfig.json | ||
Wails v3 Documentation
World-class documentation for Wails v3, redesigned following Netflix documentation principles.
📚 Documentation Redesign (2025-10-01)
This documentation has been completely redesigned to follow the Netflix approach to developer documentation:
- Problem-first framing - Start with why, not what
- Progressive disclosure - Multiple entry points for different skill levels
- Real production examples - No toy code
- Story-Code-Context pattern - Why → How → When
- Scannable content - Clear structure, visual aids
Status: Foundation complete (~20%), ready for content migration
See IMPLEMENTATION_SUMMARY.md for full details.
🚀 Project Structure
Inside of your Astro + Starlight project, you'll see the following folders and files:
.
├── public/
├── src/
│ ├── assets/
│ ├── content/
│ │ ├── docs/
│ │ └── config.ts
│ └── env.d.ts
├── astro.config.mjs
├── package.json
└── tsconfig.json
Starlight looks for .md or .mdx files in the src/content/docs/ directory.
Each file is exposed as a route based on its file name.
Images can be added to src/assets/ and embedded in Markdown with a relative
link.
Static assets, like favicons, can be placed in the public/ directory.
🧞 Commands
All commands are run from the root of the project, from a terminal:
| Command | Action |
|---|---|
npm install |
Installs dependencies |
npm run dev |
Starts local dev server at localhost:4321 |
npm run build |
Build your production site to ./dist/ |
npm run preview |
Preview your build locally, before deploying |
npm run astro ... |
Run CLI commands like astro add, astro check |
npm run astro -- --help |
Get help using the Astro CLI |
👀 Want to learn more?
Check out Starlight’s docs, read the Astro documentation, or jump into the Astro Discord server.