{"owner":"marko-js","repo":"marko","hasSkills":true,"totalSkillsCount":48,"totalTokensCount":87874,"categories":["root-instruction","claude-rule","anthropic-skill","plugin-manifest"],"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md","CLAUDE.md","packages/compiler/AGENTS.md","packages/compiler/README.md","packages/runtime-class/AGENTS.md","packages/runtime-class/README.md","packages/runtime-class/docs/10-awesome-marko-features.md","packages/runtime-class/docs/body-content.md","packages/runtime-class/docs/class-components.md","packages/runtime-class/docs/cloudflare-workers.md","packages/runtime-class/docs/compiler.md","packages/runtime-class/docs/concise.md","packages/runtime-class/docs/conditionals-and-lists.md","packages/runtime-class/docs/core-tags.md","packages/runtime-class/docs/custom-tags.md","packages/runtime-class/docs/editor-plugins.md","packages/runtime-class/docs/events.md","packages/runtime-class/docs/express.md","packages/runtime-class/docs/fastify.md","packages/runtime-class/docs/getting-started.md","packages/runtime-class/docs/http.md","packages/runtime-class/docs/installing.md","packages/runtime-class/docs/koa.md","packages/runtime-class/docs/lasso.md","packages/runtime-class/docs/marko-5-upgrade.md","packages/runtime-class/docs/marko-json.md","packages/runtime-class/docs/marko-vs-react.md","packages/runtime-class/docs/redux.md","packages/runtime-class/docs/rendering.md","packages/runtime-class/docs/rollup.md","packages/runtime-class/docs/state.md","packages/runtime-class/docs/structure.json","packages/runtime-class/docs/styles.md","packages/runtime-class/docs/syntax.md","packages/runtime-class/docs/troubleshooting-streaming.md","packages/runtime-class/docs/typescript.md","packages/runtime-class/docs/vite.md","packages/runtime-class/docs/webpack.md","packages/runtime-class/docs/why-is-marko-fast.md","packages/runtime-class/helpers/README.md","packages/runtime-tags/AGENTS.md","packages/runtime-tags/README.md","skills/README.md","skills/marko-5-to-6-migration/SKILL.md","skills/marko-5-to-6-migration/api-mapping.md","skills/marko-5-to-6-migration/interop.md","skills/marko-5-to-6-migration/patterns.md","skills/marko-best-practices/SKILL.md"],"skills":{"AGENTS.md":"# Marko Monorepo\n\nMarko compiles `.marko` templates into optimized server (streaming HTML) and client (fine-grained DOM) JavaScript. pnpm workspaces; Node >= 22.18 (native TS type stripping + module.registerHooks). Primary development happens in `packages/runtime-tags`.\n\n## Packages\n\n- [`packages/compiler`](packages/compiler/AGENTS.md) — `@marko/compiler`. Translator-agnostic: parses `.marko` into a (patched) Babel AST, then hands off to a translator for codegen.\n- [`packages/runtime-tags`](packages/runtime-tags/AGENTS.md) — `marko@6` / `@marko/runtime-tags`. The Marko 6 runtime **and** its translator. **Primary development.**\n- [`packages/runtime-class`](packages/runtime-class/AGENTS.md) — `marko@5` (private package, published only as `marko`). Marko 5, in maintenance; its translator wraps the class-API translator with runtime-tags' interop layer.\n\nA \"translator\" is the Babel-plugin half of a runtime package; the compiler loads it as `/translator`. \"Marko 6\" is the runtime-tags version — the compiler stays 5.x.\n\n## Commands\n\nAll from repo root. Tests and tooling run directly from TS source (native Node type stripping plus the `~ts` resolve hook for extensionless imports; package `exports` point at `src/` until publish), so no build step is needed to iterate.\n\n```sh\npnpm test # whole suite fanned across CPU cores (~3x faster than serial)\npnpm test -- --grep \"runtime-tags/translator \" # scoped test run\npnpm run test:serial -- --grep \"...\" # same run in one process: bail at first failure, live output, --inspect-brk\npnpm test -- # only the given spec files (dirs and globs work too)\npnpm run test:update -- --grep \"...\" # regenerate snapshots (review the diff!)\npnpm run compile -- -o dom -d foo.marko # print compiled output (-o html for SSR; omit -d for optimized)\npnpm run build # all packages -> dist/ + .d.ts\npnpm run build:sizes # bundle-size table; diffs vs .sizes.json\npnpm run lint # oxlint + oxfmt check\npnpm run format # oxlint --fix + oxfmt write\npnpm run change # add a changeset (required for user-facing changes)\n```\n\n`pnpm run compile` is the fastest way to inspect what the translator generates. It writes nothing: each compiled module, and then any module the translator generates for it, prints to stdout under a `// ` header. (Pass `-t class` for the Marko 5 translator; `-t` also accepts a full translator module id.)\n\n`pnpm run change` prompts, so write `.changeset/.md` directly, naming the package that owns the changed code: `packages/compiler` is `@marko/compiler`, `packages/runtime-tags` is `@marko/runtime-tags`, `packages/runtime-class` is `marko`. `pnpm exec changeset status` fails on a name that is no workspace package (which would break the release on `main`), but not on the wrong one: `marko` for a runtime-tags fix passes and publishes the wrong package. Restricting behavior that was already broken is a fix (`patch`), never described as a breaking change.\n\n## Repo invariants\n\n- **Dependencies are patched.** `patches/` (applied by pnpm patchedDependencies on install) adds Marko AST node types to `@babel/types`/`traverse`/`generator`, and makes mocha print the `require()` error it otherwise drops when its `import()` fallback rescues a spec. The Babel patches only add Marko AST support; never patch Babel's own behavior. Import Babel only via `@marko/compiler/internal/babel` and helpers via `@marko/compiler/babel-utils`, never `@babel/*` directly. Bumping any patched dependency requires regenerating its patch.\n- **Bundle size is a feature.** The pre-commit hook runs lint-staged, a full build, and `build:sizes`, staging `.sizes.json`/`.sizes/` — that diff is the size impact of the change. Commits are slow by design. The floor is `.sizes/counter.ssr` and `.sizes/comments.ssr` (a resumed page with no async, reorder, lazy, or dynamic html): code for an optional feature, even one `?.`, must fold out of them. Lint rules whose fix rewrites runtime code into larger output stay off in `.oxlintrc.json` (`unicorn/prefer-string-starts-ends-with`, `unicorn/no-new-array`); enabling one means checking `build:sizes` first.\n- **Snapshots and sizes are generated.** Never hand-edit _or delete_ `__snapshots__/**`, fixture `sizes.json`, or `.sizes*`; regenerate with `pnpm run test:update` (which also prunes stale snapshots after a green run) and the commit hook.\n- **CI** (`.github/workflows/ci.yml`): build + lint on Node 26; tests on Node 22/24/26 (zcov coverage). Releases go out via changesets on push to `main`.\n\n## Conventions\n\nOrganize files top-down (progressive disclosure): public API/exports first, then orchestration, helpers, and low-level detail last — use function-declaration hoisting.\n\nComments are a last resort and never exceed two lines: prefer self-describing code, and when one is needed it captures intent — never what the code was or what was removed. Wording is plain and direct, with no invented shorthand.\n\nDerive before adding. Before a new field, flag, helper, state container, parameter, test config, or module, find the existing analysis, helper, or runtime structure that already answers it and extend that. A parallel mechanism for one feature (one the rest of the code never needed) is a smell: say in the summary why nothing existing fits.\n\nEvery line needs a reason you can name. No guards, `?.`, fallbacks, casts (`as never`, `as any`, or one the type already satisfies), or parameters for states the design rules out; lean on the invariant (`!`, or a `MARKO_DEBUG` assert). Name checks, dependency method overrides, and machine heuristics are hacks: find the structural fix. A perf or config knob ships only with a measured win, and never restates a default. Measure performance on the bundled build that ships (`pnpm run build`), not the TS source that tests and tooling run: V8 inlines the bundle's module-level function declarations but not those of an ES module, so source timings can mislead.\n\nDon't bend the code around an edge case. Input the design has no reason to support (a `NaN` loop key, say) gets a compile error or a `MARKO_DEBUG` error that rules it out, not runtime handling that every caller pays for in size or speed. Harden the invariant, then rely on it.\n\nWrite the direct form. No rest or spread to copy, extend, or strip an object: share one record, or key a collection by the field it lacks. Client runtime code, where bundle size comes first, may keep a spread that `build:sizes` shows is smallest, but it is still a red flag to justify. No function that only forwards, and no type named for a single use. A helper every caller guards takes the `undefined` itself, and a flag is set as `flag ||= condition`.\n\nDon't add Babel `NodePath` helper calls (`findParent`, `find`, `getFunctionParent`, …): walk `parentPath` and compare node types directly; existing uses are migrated later.\n\nNames come from the code. Reuse the vocabulary of neighboring code, [`CONTEXT.md`](packages/runtime-tags/CONTEXT.md), and the markojs.com docs; never coin a term the codebase does not already use.\n\nTest through existing fixture families; add a test file only when no fixture can reach the behavior. A fix adds a fixture that fails without it, and so does every branch or statement a change adds: revert each one and confirm a fixture fails. Code no fixture needs is deleted, never kept behind a fixture that passes either way.\n\nMarko language reference: lists every docs page; append `.md` to any docs URL for markdown.\n\n## Agent feedback\n\nAnything actionable but out of scope for the current task (suspected bug, cleanup, perf or size win, tooling friction, confusing code) must be filed in [`agent-feedback/`](agent-feedback/README.md) before finishing. Never drop it silently. Never fix it inside an unrelated diff. In scope, so fixed rather than filed: a defect in code the diff touches or exposes, and anything in the unreleased feature a branch builds (which also takes no changesets). A deliberate limitation gets a site comment, not an item.\n","CLAUDE.md":"AGENTS.md","packages/compiler/AGENTS.md":"# `@marko/compiler`\n\nTranslator-agnostic compiler: parses `.marko` into a Babel AST (custom node types like `MarkoTag`, `MarkoAttribute` — added to Babel by the root `patches/`), runs migrate/transform passes, then hands the AST to a **translator** (`@marko/runtime-tags/translator` or `marko/translator`) for codegen. Stays at v5.x; language changes belong in the translators, not here.\n\n## Map\n\n- `src/index.js` — public API: `compile[File][Sync](src, filename, config)` → `{ code, map, meta, ast }`, `configure`, `taglib`, `types`.\n- `src/config.js` — config defaults, and the `globalConfig` that `configure()` sets (both re-exported by `index.js`); an omitted translator in `getRuntimeEntryFiles`, `getRuntimeVersion` and `taglib.buildLookup` reads it. Key options: `output` (`\"html\"` | `\"dom\"` | `\"source\"` | `\"migrate\"`), `optimize`, `translator`, `modules` (`\"esm\"`/`\"cjs\"`), `optimizeKnownTemplates`, `errorRecovery`, `cache`, `fileSystem`.\n- `src/babel-plugin/` — pipeline core. Stages: `parse → migrate → transform → analyze` (cached per template) then `translate` on a clone. Taglib visitors run in `migrate`, `transform` and `translate` — including those from the taglibs a translator registers via `taglibs`/`optionalTaglibs`, which is how a translator contributes migrators. The translator's own hooks are `transform` (optional), `analyze` and `translate`; there is no `translator.migrate` hook, and `analyze` is translator-only — a taglib-level `analyze` prop is a hard load error. Taglib `translate` is skipped for `output: \"hydrate\"`.\n- `src/taglib/` — tag registry/discovery: built-in HTML/SVG/MathML JSON taglibs, `marko.json` / `marko-tag.json` discovery walking up from the template, `buildLookup`.\n- `src/babel-utils/` — the helper API for translator authors (`assert*`, `diagnostic*`, `import*`, `parse*`, `getTagDef`, `isNativeTag`, `resolveTagImport`, ...). Exported as `@marko/compiler/babel-utils`.\n- `internal/babel/index.ts` — the single controlled Babel entry, re-exported as `@marko/compiler/internal/babel`. All Babel access (here and in translators) goes through it, never `@babel/*` directly.\n\n## Translator contract\n\nA translator module exports: `translate` (required visitor), `taglibs` (required, `[[id, props]]`), optional `transform` / `analyze` visitors, `tagDiscoveryDirs`, `optionalTaglibs`, `preferAPI` (`\"tags\"` | `\"class\"`), `getRuntimeEntryFiles(output, optimize)`, and optionally `cheatsheet` (a module-relative path to an LLM syntax reference; `tryLoadTranslator` resolves it to a cwd-relative path and `util/agent-fix-guide.js` points coding agents at it on compile errors). Loading is resolved from `config.translator` or auto-detected from the app's dependencies (`util/try-load-translator.js`, default logic in `config.js`).\n\n## Notes\n\n- `output: \"source\"` / `\"migrate\"` re-print `.marko` source (tooling/codemods) — no translator codegen.\n- Bumping any `@babel/*` version requires regenerating the corresponding patch in root `patches/` (pnpm patchedDependencies); the custom AST types and generated `dist/types.d.ts` (`pnpm --filter @marko/compiler run build-babel-types`) depend on them.\n- Adding a core tag in a translator shows up in taglib-lookup expectations here and in `packages/runtime-class/test/taglib-lookup/`.\n- `util/agent-fix-guide.js` — when a terminal coding agent is detected (env markers; `AI_AGENT=1` is the generic opt-in for harnesses not on the list) and the loaded translator declares a `cheatsheet`, thrown compile errors get a one-line pointer to it (relative to `cwd`) appended at the `compile[Sync]` boundary (to `message`, and to a `CompileError`'s `label`, which bundler plugins like `@marko/vite` print in place of the framed message), and under `errorRecovery` — where nothing throws — the same pointer is appended to the first error in `meta.diagnostics` instead. `MARKO_AGENT_FIX_GUIDE` overrides the sniff in either direction: `0` suppresses the guide, any other value forces it on (e.g. when compiling in a subprocess that drops the inherited marker). No-op for humans, for runtimes without a cheat sheet, and for inline translator objects (so error snapshots, which compile with an inline translator object, are unaffected).\n","packages/compiler/README.md":"# @marko/compiler\n\nCompiles [Marko](https://markojs.com/) templates into JavaScript modules.\n\nThe [bundler integrations](https://markojs.com/docs/introduction/integrations#bundlers) call the compiler for every template, so applications rarely use it directly. It is the API for building a bundler integration, a test transform, or other tooling around Marko templates.\n\n```sh\nnpm install @marko/compiler\n```\n\n```js\nimport * as compiler from \"@marko/compiler\";\n\nconst { code, map } = await compiler.compileFile(\"./src/card.marko\", {\n output: \"dom\",\n sourceMaps: true,\n});\n```\n\nSee the [Compiler API reference](https://markojs.com/docs/reference/compiler) for the compile functions, their options and the compile result.\n","packages/runtime-class/AGENTS.md":"# Marko 5 (runtime & translator)\n\n## Architecture\n\nThe package is organized into four layers:\n\n| Directory | Purpose |\n| ---------------------- | ---------------------------------------------------------------------- |\n| `src/runtime/helpers/` | Shared runtime helpers (class/style values, dynamic tags, attr-tags) |\n| `src/runtime/html/` | SSR runtime: streaming HTML output, helpers, hot reload |\n| `src/runtime/vdom/` | CSR runtime: virtual DOM, morphdom reconciliation, component lifecycle |\n| `src/translator/` | Babel-based compiler that transforms `.marko` into SSR/CSR JavaScript |\n\nThe compiler/translator entry is `src/translator/index.js`, but the package's exported translator (`src/translator.js`) wraps it with `createInteropTranslator` from `@marko/runtime-tags/translator`, so Marko 5 projects can mix in Marko 6 (Tags API) components. Interop behavior changes are usually made in `packages/runtime-tags/src/translator/interop/`, not here.\n\nNote: the package is private (named `marko`); `scripts/publish-alias.mts` publishes it as `marko` under the `m5` dist-tag.\n\nCompiled templates import runtime helpers by string path (`marko/src/runtime/helpers/...`, see `translator/util/load-import.js`), so a source search for importers misses those uses.\n\n`src` mixes ESM and CommonJS `.js` with no `\"type\"`, so Node warns `MODULE_TYPELESS_PACKAGE_JSON` under `-t class`. Accepted: Marko 5 is in maintenance and `src` ships in `files`, so a `{\"type\":\"module\"}` marker would force converting every CJS file.\n\n## Naming Conventions\n\n### Triple-underscore prefix (`___name`)\n\nAll internal properties and methods on runtime objects use a triple-underscore prefix:\n\n```js\nthis.___state;\ncomponent.___queueUpdate();\nexports.___batchUpdate = batchUpdate;\n```\n\nThe build step mangles these names into short single-character identifiers.\n\n### `MARKO_DEBUG` pattern\n\nDebug-only code is wrapped in string-compared conditionals that tree-shake in prod:\n\n```js\n// eslint-disable-next-line no-constant-binary-expression\nvar complain = \"MARKO_DEBUG\" && require(\"complain\");\nif (\"MARKO_DEBUG\") {\n complain(\"Deprecated: ...\");\n}\n```\n\nThe build step replaces `\"MARKO_DEBUG\"` with `false` and dead-code-eliminates the branches.\n\n## Output Modes\n\n- **HTML (SSR)** — `src/runtime/html/index.js` creates a `Template` produces `AsyncStream`. Output is HTML strings piped to a Node.js stream.\n- **VDOM (browser)** — `src/runtime/vdom/index.js` creates a `Template` produces `AsyncVDOMBuilder`. Output is a virtual DOM tree reconciled via local morphdom .\n\nBoth stacks share `src/runtime/renderable.js`, which mixes `render()`, `renderSync()`, `renderToString()`, and `mount()` into `Template.prototype`.\n\n## Error Handling\n\n- Compile-time errors use Babel's `path.buildCodeFrameError(message)` to include source locations\n- Most validation happens at compile time; runtime errors in production are minimal\n\n## Testing\n\n### Test structure\n\n```\ntest/\n translator/ # Snapshot tests for compiler output\n components-pages/ # Full page hydration (ssr + csr) tests\n components-browser/ # jsdom-based browser component tests\n components-server/ # SSR rendering tests\n morphdom/ # morphdom unit tests\n vdom-create/ # VNode construction unit tests\n async-stream/ # AsyncStream unit tests\n```\n\n### Translator tests\n\nEach fixture has a `template.marko` input and a `snapshots/` directory:\n\n```\nfixtures//\n template.marko\n snapshots/\n vdom-expected.js\n html-expected.js\n htmlProduction-expected.js\n hydrate-expected.js\n cjs-expected.js\n generated-expected.marko\n```\n\n### Running tests\n\nFrom the repo root:\n\n```sh\npnpm test # all tests\npnpm test -- --grep \" \" # specific fixture\npnpm run test:update # update snapshots\n```\n","packages/runtime-class/README.md":"
\n\n# [\"Marko\"](https://markojs.com/)\n\n**A declarative, HTML-based language that makes building web apps fun 🔥**\n\n[![NPM](https://img.shields.io/npm/v/marko.svg)](https://www.npmjs.com/package/marko)\n[![Discord Chat](https://img.shields.io/badge/discord-chat-7188da.svg)](https://discord.gg/RFGxYGs)\n[![Continuous Integration status](https://github.com/marko-js/marko/actions/workflows/ci.yml/badge.svg)](https://github.com/marko-js/marko/actions/workflows/ci.yml)\n[![Code coverage %](https://codecov.io/gh/marko-js/marko/branch/master/graph/badge.svg)](https://codecov.io/gh/marko-js/marko)\n[![# of monthly downloads](https://img.shields.io/npm/dm/marko.svg)](https://npm-stat.com/charts.html?package=marko)\n[![OpenSSF Best Practices](https://bestpractices.coreinfrastructure.org/projects/7029/badge)](https://bestpractices.coreinfrastructure.org/projects/7029)\n\n[Docs](https://markojs.com/docs/getting-started/) ∙ [Try Online](https://markojs.com/try-online/) ∙ [Contribute](#contributors) ∙ [Get Support](#community--support)\n\n
\n\n## Intro\n\nMarko is HTML _reimagined_ as a language for building dynamic and reactive user interfaces. Almost any valid HTML is valid Marko, and Marko extends HTML for building modern applications more declaratively. Among these extensions are [conditionals and lists](https://markojs.com/docs/conditionals-and-lists/), [state](https://markojs.com/docs/state/), and [components](https://markojs.com/docs/class-components/).\n\nMarko supports both single-file components and components across separate files.\n\n### Single-file component\n\nThe following renders a button and a counter of how many times the button has been pressed:\n\n**click-count.marko**\n\n```marko\nclass {\n onCreate() {\n this.state = { count: 0 };\n }\n increment() {\n this.state.count++;\n }\n}\n\nstyle {\n .count {\n color: #09c;\n font-size: 3em;\n }\n .press-me {\n padding: 0.5em;\n }\n}\n\n\n ${state.count}\n\n\n Press me!\n\n```\n\n### Multi-file component\n\nThe same component as above, but split into:\n\n- `index.marko` template file\n- `component.js` component JS logic file\n- `style.css` component styles file\n\n**index.marko**\n\n```marko\n\n ${state.count}\n\n\n Press me!\n\n```\n\n**component.js**\n\n```js\nexport default {\n onCreate() {\n this.state = { count: 0 };\n },\n increment() {\n this.state.count++;\n },\n};\n```\n\n**style.css**\n\n```css\n.count {\n color: #09c;\n font-size: 3em;\n}\n.press-me {\n padding: 0.5em;\n}\n```\n\n## Concise Syntax\n\nMarko also supports [a beautifully concise syntax as an alternative](https://markojs.com/docs/concise/) to its HTML syntax:\n\n\n
Concise syntaxHTML syntax\n
\n\n```marko\nul.example-list\n for|color| of=[a, b, c]\n li -- ${color}\n```\n\n\n\n```marko\n
    \n \n
  • ${color}
    • \n \n
\n```\n\n
\n\n## Getting Started\n\n1. `npm install marko`\n2. Read the [docs](https://markojs.com/docs/getting-started/)\n\n## Community & Support\n\n\n\n
\"Stack \n \"Discord\"\n \"Twitter\"\n
\n\nAsk and answer [StackOverflow questions with the `#marko` tag](https://stackoverflow.com/questions/tagged/marko)\n\nCome [hang out in our Discord chat](https://discord.gg/RFGxYGs), ask questions, and discuss project direction\n\n[Tweet to `@MarkoDevTeam`](https://twitter.com/MarkoDevTeam), or with the [`#markojs` hashtag](https://twitter.com/search?q=%23markojs&f=live)\n\n
\n\n### Contributors\n\nMarko would not be what it is without all those who have contributed ✨\n\n[![All marko-js/marko GitHub contributors](https://opencollective.com/marko-js/contributors.svg?width=890&button=false)](https://github.com/marko-js/marko/graphs/contributors)\n\n### Get Involved!\n\n- Pull requests are welcome!\n- Submit [GitHub issues](https://github.com/marko-js/marko/issues) for any feature enhancements, bugs, or documentation problems\n- [Read the Contribution Tips and Guidelines](.github/CONTRIBUTING.md)\n- Participants in this project agree to abide by [its Code of Conduct](https://github.com/eBay/.github/blob/main/CODE_OF_CONDUCT.md)\n","packages/runtime-class/docs/10-awesome-marko-features.md":"\n \"Marko\n
\n\n> This article was published in August 2017. You can find the original [\"10 Awesome Marko Features\" article here](https://medium.com/@austinkelleher/10-awesome-marko-features-afba9d094d42)!\n\n# 10 Awesome Marko Features\n\n[Marko](https://markojs.com/) is a friendly and super fast UI library that makes\nbuilding web apps
fun! In celebration of rapidly approaching [5,000 stars on\nGitHub](https://github.com/marko-js/marko) (the ultimate open source vanity\nmetric), here are 10 features that will make you more productive in no\nparticular order...\n\n#### 1. Shorthand Attributes\n\nTired of constantly typing out `class` and `id` attributes? No need with Marko.\nSimply utilize the shorthand based on CSS selectors:\n\n```marko\nstyle {\n .count {\n color:#09c;\n }\n}\n\n// Equivalent to
\n\n\n// Equivalent to \n\n\n// Combined\n\n```\n\n#### 2. All attribute values are Just JavaScript™\n\nUnlike with HTML, you are not limited to string attribute values when using\nMarko. Attributes can have types, which makes it really easy to pass data to\ncustom tags and it works for standard HTML tags too:\n\n```marko\n
\n\n\n\n\n\n\n\n\n\n```\n\n#### 3. Isomorphic UI components made easy\n\nTired of boilerplate code and trouble managing component input and state? Marko\nmakes it a breeze to develop self-contained and individually testable\ncomponents. Changing state is completely synchronous, so there won’t be any\nheadaches. You can also use inline styles making it very easy to develop small\ncomponents quickly.\n\n```marko\nclass {\n onInput(input) {\n this.state = {\n count: input.count || 0\n };\n }\n increment() {\n this.state.count++;\n }\n}\n\nstyle {\n .count {\n color:#09c;\n }\n}\n\n${state.count}
\n\n```\n\nDo you see references to “Marko” in the snippet above? Yeah, me neither.\n\nIs your component becoming too large? Do you prefer separating your CSS,\nJavaScript, and markup code? No problem. You can easily [rip out your code into\nmultiple files](https://markojs.com/docs/class-components/#multi-file-components):\n\n```\ncomponents/\n click-counter/\n component.js\n index.marko\n style.css\n```\n\n#### 4. Concise syntax\n\nThe DOM is just a tree structure. Indentation is a great way to describe a DOM\ntree without having to worry about matching up beginning and ending tags. Marko\nlets you choose between a concise, indentation-based syntax, and a familiar HTML\nsyntax:\n\n```marko\n\n\n

Count: ${state.count}

\n
\n\n Click me!\n\n```\n\nHere’s the same thing with the concise syntax:\n\n```marko\n// Count our clicks!\ndiv.count\n p -- Count: ${state.count}\nbutton.example-button on-click('increment') -- Click me!\n```\n\nCan’t make up your mind or just want to paste in that code snippet from\nStackOverflow? HTML syntax can be used within in the concise syntax. You’ll come\nback and make it consistent…_one day_.\n\n#### 5. Import JavaScript modules\n\nDo you have some helper JavaScript functions that you need to use in your views?\nMarko lets you import any JavaScript module into your template using the same\nsyntax as the JavaScript `import` statement without using Babel or any other\nbuild tool. No need for problematic globals (you could do that too, but please\ndon’t or your coworkers will hate you).\n\n```marko\nimport sum from './utils/sum';\n\n
The sum of 2 + 3 is ${sum(2, 3)}
\n```\n\n#### 6. No need to import custom tags (it’s a good thing, trust me)\n\nMarko uses your directory structure as a method for automatically registering\ncustom tags. This means that Marko can implicitly import tags based on where the\ntemplate is located on disk. Marko will search up the directory looking for\ncustom tags in `components/`directories similar to how Node.js discovers modules\nin `node_modules/` directories.\n\nGiven the following directory structure:\n\n```\ncomponents/\n fancy-button/\n index.marko\n fancy-container/\n index.marko\n```\n\nIf `fancy-button` is used inside of `fancy-container`, it will be implicitly
\nimported:\n\n```marko\n\n
\n \n
\n```\n\n#### 7. Use JavaScript to set CSS classes and styles\n\nSetting CSS classes and styles is made easy using JavaScript! Marko will happily\naccept simple strings, JavaScript objects and arrays (_falsy values will be\nignored)._\n\n```marko\n$ const fontColor = input.color || 'blue';\n$ const isActive = input.active === true;\n\n
\n```\n\n#### 8. Inline JavaScript Statements\n\nMarko takes HTML and makes it more like JavaScript. You can exit out of HTML\nmode to embed a JavaScript statement by starting the line with a `$`. You can\nuse this feature to embed JavaScript variables, functions, etc. where they are\nneeded (take that, “separation of concerns”).\n\n```marko\n$ const randomNumber = Math.random();\n$ const person = {\n name: 'Frank',\n age: 32\n};\n\n
Random number: ${randomNumber}
\n
${person.name} is ${person.age} years old
\n```\n\nIf you want to combine multiple JavaScript statements you can do that too:\n\n```marko\n$ {\n const randomNumber = Math.random();\n const person = {\n name: 'Frank',\n age: 32\n };\n}\n\n
Random number: ${randomNumber}
\n
${person.name} is ${person.age} years old
\n```\n\n#### 9. Async rendering with the `` tag\n\nNode.js is asynchronous. Browsers are asynchronous. Why should rendering be\nsynchronous? Pass your promise along to your template and Marko will\nasynchronously render parts of your view. Turns out, [this is good for\nperformance](https://tech.ebayinc.com/engineering/async-fragments-rediscovering-progressive-html-rendering-with-marko/).\n\n```marko\n$ const searchResultsPromise = searchService.performSearch(keywords);\n\n\n <@then|person|>\n Hello ${person.name}!\n \n <@catch|err|>\n The error was: ${err.message}.\n \n\n```\n\n#### 10. Server side rendering is easy\n\nCan’t decide if you want to do server-side rendering or client-side rendering?\nWhy are we even talking about this in 2017? It doesn’t matter. Seriously, just\ndo both. Marko makes this a no-brainer since you can render a Marko template\ndirectly to a stream (oh, and Marko will automatically mount UI\ncomponents rendered on the server when the page loads in the browser):\n\n```js\nrequire(\"@marko/compiler/register\"); // require .marko files!\n\nconst http = require(\"http\");\nconst template = require(\"./template\");\n\nhttp\n .createServer()\n .on(\"request\", (req, res) => {\n template.render(\n {\n name: \"Frank\",\n count: 30,\n colors: [\"red\", \"green\", \"blue\"],\n },\n res,\n );\n })\n .listen(8080);\n```\n\n#### Bonus: Friendly compile-time errors\n\nWe all make mistakes _every now and then_. Typo in your custom tag? Forgot an\nending tag? No worries! Marko will give you a friendly error message and point\nyou right to the problematic code.\n\n```marko\n\n\n```\n\nYou may have missed it, but it was obvious to Marko:\n\n```\nUnrecognized tag: fancy-buttn — More details: https://github.com/marko-js/marko/wiki/Error:-Unrecognized-Tag at line 2 col 1\n```\n\nComing soon: auto correction and autonomous coding\n\n---\n\n[_Cover image from Wikipedia_](https://commons.wikimedia.org/wiki/File:Amanhecer_no_Hercules_--.jpg)\n","packages/runtime-class/docs/body-content.md":"# Body content\n\nWe're used to passing body content to HTML tags. When you do this, the tag has control over where and when this content is rendered. A good example of this is the [HTML `
` element](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details):\n\n```html\n
\n Hello World\n This is some content that can be toggled.\n
\n```\n\nThis is what it renders (try clicking it):\n\n---\n\n
\n Hello World\n This is some content that can be toggled.\n
\n\n---\n\nCustom tags can also receive content in the same way. This allows a component to give its user full control over _how_ some section of the content is rendered, but control _where_, _when_, and with _what_ data it is rendered. This feature is necessary to build composable components like overlays, layouts, dropdowns, etc. Imagine a `` that didn't give you control over how its cells were rendered. That would be pretty limited!\n\n## Rendering body content\n\nWhen a custom tag is passed body content, it is received as a special `renderBody` property on the component's `input`. You can include this content anywhere in your component by using the [`<${dynamic}>` syntax](./syntax.md#dynamic-tagname).\n\n_components/fancy-container.marko:_\n\n```marko\n
\n <${input.renderBody}/>\n
\n```\n\nIf we were to use this tag like this:\n\n_Marko Source:_\n\n```marko\n\n

Content goes here...

\n\n```\n\nThe rendered output would be:\n\n_HTML Output:_\n\n```html\n

Content goes here...

\n```\n\nThis is a pretty basic example, but you can imagine how this could be incorporated into a more advanced component to render passed content where/when needed.\n\n> **ProTip:**\n> Body content can be rendered multiple times. Or not at all.\n\n## Passing attributes to body content\n\nWhen rendering body content with `<${dynamic}>`, attributes may also be passed:\n\n_components/random-value.marko:_\n\n```marko\n\n<${input.renderBody} number=1337 />\n```\n\nThese attribute values can be received as a [tag parameter](./syntax.md#parameters):\n\n```marko\n\n The number is ${number}\n\n```\n\n> **ProTip:**\n> Some tags (like the above tag) may not render anything except their body content with some data. This can be quite useful, just look at the `` and `` tags!\n\n## Named body content\n\nYou can also pass named content sections to a tag using [attribute tags](./syntax.md#attribute-tag) which are denoted by the `@` prefix.\n\n```marko\n\n <@heading>\n

Hello Marko

\n \n <@content>\n

...

\n \n\n```\n\nLike attributes, these attribute tags are received as `input.heading` and `input.content`, but they each have a `renderBody` property which we can now use:\n\n_components/layout.marko_\n\n```marko\n\n\n \n <${input.heading.renderBody}/>\n
\n <${input.content.renderBody}/>\n \n\n```\n\n> **ProTip:** The `renderBody` property can be omitted. You could use `<${input.heading}/>`, for example.\n\n### Repeated body content\n\nWhen an attribute tag is repeated, the child component can consume all instances using the [iterable protocol](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols#the_iterable_protocol).\n\nThis allows us to, for example, build a custom table component which allows its user to specify any number of columns, while still giving the user control over how each column is rendered.\n\n_Marko Source:_\n\n```marko\n\n <@column|person|>\n Name: ${person.name}\n \n <@column|person|>\n Age: ${person.age}\n \n\n```\n\n> _Note_\n> For TypeScript the [`Marko.AttrTag` helper](./typescript.md#built-in-marko-types) should be used here.\n\n> _Protip_\n> Since attribute tags are iterable you could pass `input.column` to a `for of` loop, or `[...spread]` it into an array.\n> To `.map`, `.filter` or otherwise work with attribute tags as an array you can use the following pattern:\n>\n> ```marko\n> $ const columns = [...input.column || []];\n> ```\n\nWe can then use the `` tag to render the body content into table, passing the row data to each column's body.\n\n_components/fancy-table/index.marko:_\n\n```marko {4-8}\n
\n \n \n \n \n \n \n \n
\n <${column.renderBody} ...row/>\n
\n```\n\nWe now have a working ``. Let's see what it renders:\n\n_Example Data:_\n\n```js\n[\n {\n name: \"Patrick\",\n age: 63,\n },\n {\n name: \"Austin\",\n age: 12,\n },\n];\n```\n\n_HTML Output:_\n\n```html\n\n \n \n \n \n \n \n \n \n
Name: PatrickAge: 63
Name: AustinAge: 12
\n```\n\n### Attributes on attribute tags\n\nIf you look at our previous example, we had to prefix each cell with the column label. It would be better if we could give a name to each column instead and only render that once.\n\n_Marko Source:_\n\n```marko\n\n <@column|person| heading=\"Name\">\n ${person.name}\n \n <@column|person| heading=\"Age\">\n ${person.age}\n \n\n```\n\nNow, each attribute tag in `input.column` will contain a `heading` property in addition to its `renderBody`. We can use another `` and render the headings in `` tags:\n\n_components/fancy-table/index.marko:_\n\n```marko {3-5}\n\n \n \n \n \n \n \n \n \n \n \n \n \n
${column.heading}
\n <${column.renderBody} ...row/>\n
\n```\n\nWe'll now get a row of headings when we render our ``\n\n_HTML Output:_\n\n```html\n\n \n \n \n \n \n \n \n \n \n \n \n \n
NameAge
Patrick63
Austin12
\n```\n\n### Nested attribute tags\n\nContinuing to build on our example, what if we want to add some custom content or even components into the column headings? In this case, we can extend our `` to use nested attribute tags. We'll now have `<@heading>` and `<@cell>` tags nested under `<@column>`. This gives users of our tag full control over how to render both column headings and the cells within the column!\n\n_Marko Source:_\n\n```marko {3-8}\n\n <@column>\n <@heading>\n Name\n \n <@cell|person|>\n ${person.name}\n \n \n <@column>\n <@heading>\n Age\n \n <@cell|person|>\n ${person.age}\n \n \n\n```\n\nNow instead of rendering the heading as text, we'll render the heading's body content.\n\n_components/fancy-table/index.marko:_\n\n```marko {5}\n\n \n \n \n \n \n \n \n \n \n \n \n \n
\n <${column.heading.renderBody}/>\n
\n <${column.cell.renderBody} ...row/>\n
\n```\n\nOur headings can now include icons (and anything else)!\n\n_HTML Output:_\n\n```html\n\n \n \n \n \n \n \n \n \n \n \n \n \n
Name Age
Patrick63
Austin12
\n```\n\n### Dynamic attribute tags\n\nThe flexibility of the `` is great if you want to render columns differently or have columns that display the data in a special way (such as displaying an age derived from a date of birth). However, if all columns are basically the same, the user might feel they're repeating themselves. As you might expect, you can use `` (and ``) to dynamically render attribute tags.\n\n```marko\n$ const columns = [{\n property: \"name\",\n title: \"Name\",\n icon: \"profile\"\n}, {\n property: \"age\",\n title: \"Age\",\n icon: \"calendar\"\n}]\n\n\n \n <@column>\n <@heading>\n ${title}\n \n <@cell|person|>\n ${person[property]}\n \n \n \n\n```\n","packages/runtime-class/docs/class-components.md":"# Class Components\n\nMarko makes it easy to create user interface components to use as building blocks for web pages and applications of any complexity.\n\nMarko promotes self-contained components that:\n\n- Are independently testable\n- Encapsulate the view, client-side behavior (like event handling) and styling\n- Can easily be combined to create composite UI components.\n\nMarko components compile into small, efficient JavaScript modules that hide implementation details from consumers. Components can be published to [npm](https://www.npmjs.com) for reuse across applications.\n\n## UI component diagram\n\n![Component diagram](./component-diagram.svg)\n\nIn Marko, the DOM output of a UI component is based on _input properties_ and optional _internal state_ used to control the view.\n\nIf Marko detects changes to `input` or the internal `state`, then the view (that is, the DOM) will automatically update to reflect the new input and state. Internally, Marko uses virtual DOM diffing/patching to update the view, but that’s an implementation detail that could change at any time.\n\n## Component structure\n\nMarko makes it easy to keep your component’s class and styles next to the HTML view that they correspond to. The following are the key parts of any UI component:\n\n- **View** - The HTML template for your UI component. Receives input properties and states, and renders to either server-side HTML or browser-side virtual DOM nodes.\n- **Client-side behavior** - A JavaScript `class` with methods and properties for initialization, event handling (including DOM events, custom events and lifecycle events), and state management.\n- **Styles** - Cascading StyleSheets, including support for CSS preprocessors like [Less](https://lesscss.org/) or [Sass](https://sass-lang.com/).\n\n## Server-side rendering\n\nA UI component can be rendered on the server or in the browser, but stateful component instances will be automatically mounted to the DOM in the browser for both. If a UI component tree is rendered on the server, then Marko will recreate the UI component tree in the browser with no extra code required. For more details, please see [Rendering](/docs/rendering/).\n\n## Single-file components\n\nMarko lets you define a `class` for a component right in the `.marko` file, and call that class’s methods with `on-*` attributes:\n\n```marko\nclass {\n onCreate() {\n this.state = {\n count: 0\n };\n }\n increment() {\n this.state.count++;\n }\n}\n\n\n

\n```\n\n### Styles\n\nAdding styles in your view is also made easy:\n\n```marko\nstyle {\n .primary {\n background: #09c;\n }\n}\n\n\n

+1

\n```\n\nThese styles aren’t output in a `