Showing preview only (3,663K chars total). Download the full file or copy to clipboard to get everything.
Repository: preactjs/preact-www
Branch: master
Commit: f62390987974
Files: 553
Total size: 2.8 MB
Directory structure:
gitextract_65jqq7az/
├── .editorconfig
├── .github/
│ └── workflows/
│ └── ci.yml
├── .gitignore
├── .npmrc
├── .prettierignore
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── LICENSE
├── README.md
├── content/
│ ├── de/
│ │ ├── 404.md
│ │ ├── about/
│ │ │ ├── browser-support.md
│ │ │ ├── demos-examples.md
│ │ │ ├── libraries-addons.md
│ │ │ ├── project-goals.md
│ │ │ └── we-are-using.md
│ │ ├── guide/
│ │ │ └── v8/
│ │ │ ├── api-reference.md
│ │ │ ├── differences-to-react.md
│ │ │ ├── extending-component.md
│ │ │ ├── external-dom-mutations.md
│ │ │ ├── forms.md
│ │ │ ├── getting-started.md
│ │ │ ├── linked-state.md
│ │ │ ├── progressive-web-apps.md
│ │ │ ├── switching-to-preact.md
│ │ │ ├── types-of-components.md
│ │ │ └── unit-testing-with-enzyme.md
│ │ └── index.md
│ ├── en/
│ │ ├── 404.md
│ │ ├── about/
│ │ │ ├── browser-support.md
│ │ │ ├── demos-examples.md
│ │ │ ├── libraries-addons.md
│ │ │ ├── project-goals.md
│ │ │ └── we-are-using.md
│ │ ├── blog/
│ │ │ ├── introducing-signals.md
│ │ │ ├── preact-x.md
│ │ │ ├── prerendering-preset-vite.md
│ │ │ ├── signal-boosting.md
│ │ │ └── simplifying-islands-arch.md
│ │ ├── blog.md
│ │ ├── branding.md
│ │ ├── guide/
│ │ │ ├── v10/
│ │ │ │ ├── api-reference.md
│ │ │ │ ├── components.md
│ │ │ │ ├── context.md
│ │ │ │ ├── debugging.md
│ │ │ │ ├── differences-to-react.md
│ │ │ │ ├── forms.md
│ │ │ │ ├── getting-started.md
│ │ │ │ ├── hooks.md
│ │ │ │ ├── no-build-workflows.md
│ │ │ │ ├── options.md
│ │ │ │ ├── preact-custom-element.md
│ │ │ │ ├── preact-iso.md
│ │ │ │ ├── preact-root-fragment.md
│ │ │ │ ├── preact-testing-library.md
│ │ │ │ ├── refs.md
│ │ │ │ ├── server-side-rendering.md
│ │ │ │ ├── signals.md
│ │ │ │ ├── typescript.md
│ │ │ │ ├── unit-testing-with-enzyme.md
│ │ │ │ ├── upgrade-guide.md
│ │ │ │ ├── web-components.md
│ │ │ │ └── whats-new.md
│ │ │ ├── v11/
│ │ │ │ ├── api-reference.md
│ │ │ │ ├── components.md
│ │ │ │ ├── context.md
│ │ │ │ ├── debugging.md
│ │ │ │ ├── differences-to-react.md
│ │ │ │ ├── forms.md
│ │ │ │ ├── getting-started.md
│ │ │ │ ├── hooks.md
│ │ │ │ ├── no-build-workflows.md
│ │ │ │ ├── options.md
│ │ │ │ ├── preact-custom-element.md
│ │ │ │ ├── preact-iso.md
│ │ │ │ ├── preact-root-fragment.md
│ │ │ │ ├── preact-testing-library.md
│ │ │ │ ├── refs.md
│ │ │ │ ├── server-side-rendering.md
│ │ │ │ ├── signals.md
│ │ │ │ ├── typescript.md
│ │ │ │ ├── unit-testing-with-enzyme.md
│ │ │ │ ├── upgrade-guide.md
│ │ │ │ └── web-components.md
│ │ │ └── v8/
│ │ │ ├── api-reference.md
│ │ │ ├── differences-to-react.md
│ │ │ ├── extending-component.md
│ │ │ ├── external-dom-mutations.md
│ │ │ ├── forms.md
│ │ │ ├── getting-started.md
│ │ │ ├── linked-state.md
│ │ │ ├── progressive-web-apps.md
│ │ │ ├── switching-to-preact.md
│ │ │ ├── types-of-components.md
│ │ │ └── unit-testing-with-enzyme.md
│ │ ├── index.md
│ │ ├── repl.md
│ │ └── tutorial/
│ │ ├── 01-vdom.md
│ │ ├── 02-events.md
│ │ ├── 03-components.md
│ │ ├── 04-state.md
│ │ ├── 05-refs.md
│ │ ├── 06-context.md
│ │ ├── 07-side-effects.md
│ │ ├── 08-keys.md
│ │ ├── 09-error-handling.md
│ │ ├── 10-links.md
│ │ └── index.md
│ ├── es/
│ │ ├── 404.md
│ │ ├── about/
│ │ │ ├── browser-support.md
│ │ │ ├── demos-examples.md
│ │ │ ├── libraries-addons.md
│ │ │ ├── project-goals.md
│ │ │ └── we-are-using.md
│ │ ├── blog/
│ │ │ ├── introducing-signals.md
│ │ │ ├── preact-x.md
│ │ │ ├── prerendering-preset-vite.md
│ │ │ ├── signal-boosting.md
│ │ │ └── simplifying-islands-arch.md
│ │ ├── blog.md
│ │ ├── branding.md
│ │ ├── guide/
│ │ │ ├── v10/
│ │ │ │ ├── components.md
│ │ │ │ ├── forms.md
│ │ │ │ ├── getting-started.md
│ │ │ │ ├── hooks.md
│ │ │ │ ├── upgrade-guide.md
│ │ │ │ └── whats-new.md
│ │ │ ├── v11/
│ │ │ │ ├── api-reference.md
│ │ │ │ ├── components.md
│ │ │ │ ├── context.md
│ │ │ │ ├── debugging.md
│ │ │ │ ├── differences-to-react.md
│ │ │ │ ├── forms.md
│ │ │ │ ├── getting-started.md
│ │ │ │ ├── hooks.md
│ │ │ │ ├── no-build-workflows.md
│ │ │ │ ├── options.md
│ │ │ │ ├── preact-custom-element.md
│ │ │ │ ├── preact-iso.md
│ │ │ │ ├── preact-root-fragment.md
│ │ │ │ ├── preact-testing-library.md
│ │ │ │ ├── refs.md
│ │ │ │ ├── server-side-rendering.md
│ │ │ │ ├── signals.md
│ │ │ │ ├── typescript.md
│ │ │ │ ├── unit-testing-with-enzyme.md
│ │ │ │ ├── upgrade-guide.md
│ │ │ │ └── web-components.md
│ │ │ └── v8/
│ │ │ ├── api-reference.md
│ │ │ ├── differences-to-react.md
│ │ │ ├── extending-component.md
│ │ │ ├── external-dom-mutations.md
│ │ │ ├── forms.md
│ │ │ ├── getting-started.md
│ │ │ ├── linked-state.md
│ │ │ ├── progressive-web-apps.md
│ │ │ ├── switching-to-preact.md
│ │ │ ├── types-of-components.md
│ │ │ └── unit-testing-with-enzyme.md
│ │ └── index.md
│ ├── fr/
│ │ ├── 404.md
│ │ ├── about/
│ │ │ ├── browser-support.md
│ │ │ ├── demos-examples.md
│ │ │ ├── libraries-addons.md
│ │ │ ├── project-goals.md
│ │ │ └── we-are-using.md
│ │ ├── guide/
│ │ │ └── v8/
│ │ │ ├── api-reference.md
│ │ │ ├── differences-to-react.md
│ │ │ ├── extending-component.md
│ │ │ ├── external-dom-mutations.md
│ │ │ ├── forms.md
│ │ │ ├── getting-started.md
│ │ │ ├── linked-state.md
│ │ │ ├── progressive-web-apps.md
│ │ │ ├── switching-to-preact.md
│ │ │ ├── types-of-components.md
│ │ │ └── unit-testing-with-enzyme.md
│ │ └── index.md
│ ├── it/
│ │ ├── blog/
│ │ │ └── introducing-signals.md
│ │ ├── guide/
│ │ │ └── v8/
│ │ │ └── getting-started.md
│ │ └── index.md
│ ├── ja/
│ │ ├── 404.md
│ │ ├── about/
│ │ │ ├── browser-support.md
│ │ │ ├── project-goals.md
│ │ │ └── we-are-using.md
│ │ ├── guide/
│ │ │ └── v10/
│ │ │ ├── api-reference.md
│ │ │ ├── components.md
│ │ │ ├── context.md
│ │ │ ├── debugging.md
│ │ │ ├── differences-to-react.md
│ │ │ ├── forms.md
│ │ │ ├── getting-started.md
│ │ │ ├── hooks.md
│ │ │ ├── options.md
│ │ │ ├── preact-testing-library.md
│ │ │ ├── refs.md
│ │ │ ├── server-side-rendering.md
│ │ │ ├── unit-testing-with-enzyme.md
│ │ │ ├── upgrade-guide.md
│ │ │ ├── web-components.md
│ │ │ └── whats-new.md
│ │ └── index.md
│ ├── kr/
│ │ ├── 404.md
│ │ ├── about/
│ │ │ ├── browser-support.md
│ │ │ ├── demos-examples.md
│ │ │ ├── libraries-addons.md
│ │ │ ├── project-goals.md
│ │ │ └── we-are-using.md
│ │ ├── guide/
│ │ │ └── v10/
│ │ │ └── differences-to-react.md
│ │ ├── index.md
│ │ └── tutorial/
│ │ ├── 01-vdom.md
│ │ ├── 02-events.md
│ │ └── index.md
│ ├── pt-br/
│ │ ├── 404.md
│ │ ├── about/
│ │ │ ├── browser-support.md
│ │ │ ├── demos-examples.md
│ │ │ ├── libraries-addons.md
│ │ │ ├── project-goals.md
│ │ │ └── we-are-using.md
│ │ ├── guide/
│ │ │ ├── v10/
│ │ │ │ ├── api-reference.md
│ │ │ │ ├── components.md
│ │ │ │ ├── context.md
│ │ │ │ ├── debugging.md
│ │ │ │ ├── differences-to-react.md
│ │ │ │ ├── forms.md
│ │ │ │ ├── getting-started.md
│ │ │ │ ├── hooks.md
│ │ │ │ ├── refs.md
│ │ │ │ ├── server-side-rendering.md
│ │ │ │ ├── signals.md
│ │ │ │ ├── unit-testing-with-enzyme.md
│ │ │ │ ├── upgrade-guide.md
│ │ │ │ ├── web-components.md
│ │ │ │ └── whats-new.md
│ │ │ └── v8/
│ │ │ ├── api-reference.md
│ │ │ ├── differences-to-react.md
│ │ │ ├── extending-component.md
│ │ │ ├── external-dom-mutations.md
│ │ │ ├── forms.md
│ │ │ ├── getting-started.md
│ │ │ ├── linked-state.md
│ │ │ ├── progressive-web-apps.md
│ │ │ ├── switching-to-preact.md
│ │ │ ├── types-of-components.md
│ │ │ └── unit-testing-with-enzyme.md
│ │ └── index.md
│ ├── ru/
│ │ ├── 404.md
│ │ ├── about/
│ │ │ ├── browser-support.md
│ │ │ ├── demos-examples.md
│ │ │ ├── libraries-addons.md
│ │ │ ├── project-goals.md
│ │ │ └── we-are-using.md
│ │ ├── blog/
│ │ │ ├── introducing-signals.md
│ │ │ ├── preact-x.md
│ │ │ ├── prerendering-preset-vite.md
│ │ │ ├── signal-boosting.md
│ │ │ └── simplifying-islands-arch.md
│ │ ├── blog.md
│ │ ├── branding.md
│ │ ├── guide/
│ │ │ ├── v10/
│ │ │ │ ├── api-reference.md
│ │ │ │ ├── components.md
│ │ │ │ ├── context.md
│ │ │ │ ├── debugging.md
│ │ │ │ ├── differences-to-react.md
│ │ │ │ ├── forms.md
│ │ │ │ ├── getting-started.md
│ │ │ │ ├── hooks.md
│ │ │ │ ├── no-build-workflows.md
│ │ │ │ ├── options.md
│ │ │ │ ├── preact-custom-element.md
│ │ │ │ ├── preact-iso.md
│ │ │ │ ├── preact-root-fragment.md
│ │ │ │ ├── preact-testing-library.md
│ │ │ │ ├── refs.md
│ │ │ │ ├── server-side-rendering.md
│ │ │ │ ├── signals.md
│ │ │ │ ├── typescript.md
│ │ │ │ ├── unit-testing-with-enzyme.md
│ │ │ │ ├── upgrade-guide.md
│ │ │ │ ├── web-components.md
│ │ │ │ └── whats-new.md
│ │ │ ├── v11/
│ │ │ │ ├── api-reference.md
│ │ │ │ ├── components.md
│ │ │ │ ├── context.md
│ │ │ │ ├── debugging.md
│ │ │ │ ├── differences-to-react.md
│ │ │ │ ├── forms.md
│ │ │ │ ├── getting-started.md
│ │ │ │ ├── hooks.md
│ │ │ │ ├── no-build-workflows.md
│ │ │ │ ├── options.md
│ │ │ │ ├── preact-custom-element.md
│ │ │ │ ├── preact-iso.md
│ │ │ │ ├── preact-root-fragment.md
│ │ │ │ ├── preact-testing-library.md
│ │ │ │ ├── refs.md
│ │ │ │ ├── server-side-rendering.md
│ │ │ │ ├── signals.md
│ │ │ │ ├── typescript.md
│ │ │ │ ├── unit-testing-with-enzyme.md
│ │ │ │ ├── upgrade-guide.md
│ │ │ │ └── web-components.md
│ │ │ └── v8/
│ │ │ ├── api-reference.md
│ │ │ ├── differences-to-react.md
│ │ │ ├── extending-component.md
│ │ │ ├── external-dom-mutations.md
│ │ │ ├── forms.md
│ │ │ ├── getting-started.md
│ │ │ ├── linked-state.md
│ │ │ ├── progressive-web-apps.md
│ │ │ ├── switching-to-preact.md
│ │ │ ├── types-of-components.md
│ │ │ └── unit-testing-with-enzyme.md
│ │ ├── index.md
│ │ ├── repl.md
│ │ └── tutorial/
│ │ ├── 01-vdom.md
│ │ ├── 02-events.md
│ │ ├── 03-components.md
│ │ ├── 04-state.md
│ │ ├── 05-refs.md
│ │ ├── 06-context.md
│ │ ├── 07-side-effects.md
│ │ ├── 08-keys.md
│ │ ├── 09-error-handling.md
│ │ ├── 10-links.md
│ │ └── index.md
│ ├── tr/
│ │ ├── 404.md
│ │ ├── about/
│ │ │ ├── browser-support.md
│ │ │ ├── demos-examples.md
│ │ │ ├── libraries-addons.md
│ │ │ ├── project-goals.md
│ │ │ └── we-are-using.md
│ │ ├── guide/
│ │ │ └── v8/
│ │ │ ├── api-reference.md
│ │ │ ├── differences-to-react.md
│ │ │ ├── extending-component.md
│ │ │ ├── external-dom-mutations.md
│ │ │ ├── forms.md
│ │ │ ├── getting-started.md
│ │ │ ├── linked-state.md
│ │ │ ├── progressive-web-apps.md
│ │ │ ├── switching-to-preact.md
│ │ │ ├── types-of-components.md
│ │ │ └── unit-testing-with-enzyme.md
│ │ └── index.md
│ └── zh/
│ ├── 404.md
│ ├── about/
│ │ ├── browser-support.md
│ │ ├── demos-examples.md
│ │ ├── libraries-addons.md
│ │ ├── project-goals.md
│ │ └── we-are-using.md
│ ├── blog/
│ │ ├── introducing-signals.md
│ │ ├── preact-x.md
│ │ ├── prerendering-preset-vite.md
│ │ ├── signal-boosting.md
│ │ └── simplifying-islands-arch.md
│ ├── blog.md
│ ├── branding.md
│ ├── guide/
│ │ ├── v10/
│ │ │ ├── api-reference.md
│ │ │ ├── components.md
│ │ │ ├── context.md
│ │ │ ├── debugging.md
│ │ │ ├── differences-to-react.md
│ │ │ ├── forms.md
│ │ │ ├── getting-started.md
│ │ │ ├── hooks.md
│ │ │ ├── no-build-workflows.md
│ │ │ ├── options.md
│ │ │ ├── preact-iso.md
│ │ │ ├── preact-testing-library.md
│ │ │ ├── refs.md
│ │ │ ├── server-side-rendering.md
│ │ │ ├── signals.md
│ │ │ ├── typescript.md
│ │ │ ├── unit-testing-with-enzyme.md
│ │ │ ├── upgrade-guide.md
│ │ │ ├── web-components.md
│ │ │ └── whats-new.md
│ │ ├── v11/
│ │ │ ├── api-reference.md
│ │ │ ├── components.md
│ │ │ ├── context.md
│ │ │ ├── debugging.md
│ │ │ ├── differences-to-react.md
│ │ │ ├── forms.md
│ │ │ ├── getting-started.md
│ │ │ ├── hooks.md
│ │ │ ├── no-build-workflows.md
│ │ │ ├── options.md
│ │ │ ├── preact-iso.md
│ │ │ ├── preact-testing-library.md
│ │ │ ├── refs.md
│ │ │ ├── server-side-rendering.md
│ │ │ ├── signals.md
│ │ │ ├── typescript.md
│ │ │ ├── unit-testing-with-enzyme.md
│ │ │ ├── upgrade-guide.md
│ │ │ └── web-components.md
│ │ └── v8/
│ │ ├── api-reference.md
│ │ ├── differences-to-react.md
│ │ ├── extending-component.md
│ │ ├── external-dom-mutations.md
│ │ ├── forms.md
│ │ ├── getting-started.md
│ │ ├── linked-state.md
│ │ ├── progressive-web-apps.md
│ │ ├── switching-to-preact.md
│ │ ├── types-of-components.md
│ │ └── unit-testing-with-enzyme.md
│ ├── index.md
│ ├── repl.md
│ └── tutorial/
│ ├── 01-vdom.md
│ ├── 02-events.md
│ ├── 03-components.md
│ ├── 04-state.md
│ ├── 05-refs.md
│ ├── 06-context.md
│ ├── 07-side-effects.md
│ ├── 08-keys.md
│ ├── 09-error-handling.md
│ ├── 10-links.md
│ └── index.md
├── index.html
├── jsconfig.json
├── package.json
├── plugins/
│ ├── generate-llms-txt.js
│ ├── html-routing-middleware.js
│ ├── netlify.js
│ ├── precompile-markdown/
│ │ ├── gh-emoji/
│ │ │ ├── emoji.json
│ │ │ └── index.js
│ │ └── index.js
│ ├── rss-feed.js
│ └── spa-fallback-middleware.js
├── src/
│ ├── analytics.js
│ ├── assets/
│ │ ├── .well-known/
│ │ │ └── traffic-advice
│ │ ├── _headers
│ │ ├── _redirects
│ │ ├── contributors.json
│ │ └── robots.txt
│ ├── components/
│ │ ├── app.jsx
│ │ ├── blog-meta/
│ │ │ ├── index.jsx
│ │ │ └── style.module.css
│ │ ├── blog-overview/
│ │ │ ├── index.jsx
│ │ │ └── style.module.css
│ │ ├── branding/
│ │ │ ├── index.jsx
│ │ │ └── style.module.css
│ │ ├── code-editor/
│ │ │ ├── code-mirror.css
│ │ │ ├── index.jsx
│ │ │ └── style.module.css
│ │ ├── content-region/
│ │ │ └── index.jsx
│ │ ├── controllers/
│ │ │ ├── blog-page.jsx
│ │ │ ├── guide-page.jsx
│ │ │ ├── markdown-region.jsx
│ │ │ ├── not-found.jsx
│ │ │ ├── page.jsx
│ │ │ ├── repl/
│ │ │ │ ├── error-overlay.jsx
│ │ │ │ ├── error-overlay.module.css
│ │ │ │ ├── errors.js
│ │ │ │ ├── examples/
│ │ │ │ │ ├── context.txt
│ │ │ │ │ ├── counters/
│ │ │ │ │ │ ├── counter-hooks.txt
│ │ │ │ │ │ ├── counter-htm.txt
│ │ │ │ │ │ ├── counter-signals.txt
│ │ │ │ │ │ └── counter.txt
│ │ │ │ │ ├── github-repo-list.txt
│ │ │ │ │ ├── index.js
│ │ │ │ │ ├── spiral.txt
│ │ │ │ │ ├── style.css
│ │ │ │ │ └── todo-lists/
│ │ │ │ │ ├── todo-list-signals.txt
│ │ │ │ │ └── todo-list.txt
│ │ │ │ ├── index.jsx
│ │ │ │ ├── query-encode.js
│ │ │ │ ├── repl.setup.js
│ │ │ │ ├── repl.worker.js
│ │ │ │ ├── runner.jsx
│ │ │ │ ├── style.module.css
│ │ │ │ └── window.js
│ │ │ ├── repl-page.jsx
│ │ │ ├── style.module.css
│ │ │ ├── tutorial/
│ │ │ │ ├── contexts.jsx
│ │ │ │ ├── index.jsx
│ │ │ │ └── style.module.css
│ │ │ └── tutorial-page.jsx
│ │ ├── doc-version/
│ │ │ ├── index.jsx
│ │ │ └── style.module.css
│ │ ├── edit-button/
│ │ │ ├── index.jsx
│ │ │ └── style.module.css
│ │ ├── footer/
│ │ │ ├── index.jsx
│ │ │ └── style.module.css
│ │ ├── gh-emoji/
│ │ │ └── index.js
│ │ ├── github-repos.jsx
│ │ ├── header/
│ │ │ ├── corner.jsx
│ │ │ ├── corner.module.css
│ │ │ ├── gh-version.jsx
│ │ │ ├── index.jsx
│ │ │ ├── search.jsx
│ │ │ └── style.module.css
│ │ ├── jumbotron/
│ │ │ ├── index.jsx
│ │ │ └── style.module.css
│ │ ├── logo.jsx
│ │ ├── routes.jsx
│ │ ├── sidebar/
│ │ │ ├── index.jsx
│ │ │ ├── sidebar-nav.jsx
│ │ │ ├── sidebar-nav.module.css
│ │ │ └── style.module.css
│ │ ├── splitter/
│ │ │ ├── index.jsx
│ │ │ └── splitter.module.css
│ │ ├── sponsors/
│ │ │ ├── index.jsx
│ │ │ └── style.module.css
│ │ ├── tab-group/
│ │ │ ├── index.jsx
│ │ │ └── style.module.css
│ │ ├── table-of-contents/
│ │ │ └── index.jsx
│ │ ├── time/
│ │ │ ├── index.jsx
│ │ │ └── time.module.css
│ │ ├── todo-list.jsx
│ │ ├── we-are-using/
│ │ │ ├── index.jsx
│ │ │ └── style.module.css
│ │ └── widgets.js
│ ├── config.json
│ ├── index.jsx
│ ├── lambda/
│ │ ├── release.js
│ │ └── repos.js
│ ├── lib/
│ │ ├── content.js
│ │ ├── cx.js
│ │ ├── frontmatter.js
│ │ ├── github.js
│ │ ├── i18n.jsx
│ │ ├── localstorage.js
│ │ ├── page-title.js
│ │ ├── prerender-data.jsx
│ │ ├── repl.js
│ │ ├── toggle-overlay.js
│ │ ├── use-content.js
│ │ ├── use-delegated-prefetch.js
│ │ └── use-resource.js
│ ├── locales/
│ │ ├── de.json
│ │ ├── en.json
│ │ ├── es.json
│ │ ├── fr.json
│ │ ├── it.json
│ │ ├── ja.json
│ │ ├── kr.json
│ │ ├── pt-br.json
│ │ ├── ru.json
│ │ ├── tr.json
│ │ └── zh.json
│ ├── route-config.js
│ ├── style/
│ │ ├── buttons.css
│ │ ├── docsearch.css
│ │ ├── home.css
│ │ ├── index.css
│ │ ├── list-view.css
│ │ ├── markdown.css
│ │ ├── prism.css
│ │ └── variables.css
│ └── types.d.ts
└── vite.config.js
================================================
FILE CONTENTS
================================================
================================================
FILE: .editorconfig
================================================
root = true
[*]
indent_style = tab
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
[{*.json,.*rc,*.yml}]
indent_style = space
indent_size = 2
[*.md]
trim_trailing_whitespace = false
================================================
FILE: .github/workflows/ci.yml
================================================
name: CI
on:
push:
branches:
- master
pull_request:
branches:
- master
jobs:
build:
name: Build
runs-on: ubuntu-latest
timeout-minutes: 5
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version-file: 'package.json'
cache: 'npm'
cache-dependency-path: '**/package-lock.json'
- uses: preactjs/compressed-size-action@v2
with:
pattern: 'build/**/*.{js,css}'
exclude: 'build/assets/{prerender,xmldom,release,repos}-*.js'
strip-hash: '-(.{8})\.'
minimum-change-threshold: 100
================================================
FILE: .gitignore
================================================
/node_modules
/npm-debug.log
/build
.DS_Store
dist
*.sw[op]
================================================
FILE: .npmrc
================================================
; Allow installs to proceed even when peer dependency versions don't align
legacy-peer-deps=true
================================================
FILE: .prettierignore
================================================
package.json
package-lock.json
================================================
FILE: CODE_OF_CONDUCT.md
================================================
# Contributor Covenant Code of Conduct
## Our Pledge
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at hello@preactjs.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
[homepage]: http://contributor-covenant.org
[version]: http://contributor-covenant.org/version/1/4/
================================================
FILE: CONTRIBUTING.md
================================================
# Contributing
Thanks for contributing to Preact's documentation!
## Repo Setup
To work on the site locally, you'll want to fork the `preact-www` repository and clone it to your local machine. Once cloned, you can get up and running with the following:
```bash
$ npm install
$ npm run dev
```
At this point, you should have the site running at `http://localhost:8080`, ready for you to make any changes.
## Application Structure
This website is built as a [prerendered static app](https://developers.google.com/web/updates/2019/02/rendering-on-the-web#static-rendering), following the [Application Shell pattern](https://developers.google.com/web/fundamentals/architecture/app-shell).
### Content
Content is fetched and rendered on the fly from Markdown documents, similiar to how Jekyll and many other static site generators work. Each page on the site is a separate Markdown file, with optional YAML FrontMatter for specifying page metadata or layout information. Once fetched, the markdown content is then parsed using [`marked`](https://github.com/markedjs/marked) and rendered via [`preact-markup`](https://github.com/developit/preact-markup) to create the HTML you can read and interact with.
### Custom Elements
Since [`preact`](https://github.com/preactjs/preact) is used to render the Markdown content, we can make use of Custom Elements in our Markdown content to easily allow for dynamic or repated content, such as a generated Table of Contents or the Preact logo. These Elements are defined in [`src/components/widget.js`](./src/components/widget.js) and can be used like so:
```md
## Example Page
<!-- Jumbotron and Logo are actually Preact components! -->
<jumbotron>
<h1><logo text>Preact</logo></h1>
</jumbotron>
```
### Navigation
The navigation menu and route handling are controlled by [`src/config.json`](./src/config.json). Any new documents would need to be added to this file to be accessible via the site's navigation.
## Writing Content
The written content on the site is authored in Markdown, found in the [`content`](./content) directory and split up by language. Additionally, [`src/config.json`](./src/config.json) contains some i18n labels which you may need to alter if you were adding a new translated page.
Any and all content contributions are greatly appreciated, be that typo fixes or completely new translations.
Please author and submit content **only in one language** _(generally your primary written language)_ to facilitate translation. English is the site's default language and is generally the source for translations. Try to follow the existing formatting where possible and treat it (English) as the source of truth in most cases.
### German Version
* German translations can be approved by @marvinhagemeister
================================================
FILE: LICENSE
================================================
The MIT License (MIT)
Copyright (c) 2016-present Jason Miller
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
================================================
FILE: README.md
================================================
# Preact Documentation Website
[](https://chat.preactjs.com/)
> :rocket: `master` is automatically deployed to [preactjs.com](https://preactjs.com)
---
## Chat with Us
We have a [Slack community](https://chat.preactjs.com/) where you can chat with the Preact team and the wider Preact community. Come stop by to get support, ask questions, or just to introduce yourself!
## Issues
If something doesn't look quite right, or maybe the wording is confusing, please let us know by opening an issue!
## Contributing
Check out the [Contributing Guide](./CONTRIBUTING.md) for information on how to contribute to the site and work on it locally.
## License
[MIT](./LICENSE)
================================================
FILE: content/de/404.md
================================================
---
title: Not Found
---
# Error
Oh, diese Seite gibt es wohl nicht mehr.
Zeit [nach Hause](/) zurückzukehren!
================================================
FILE: content/de/about/browser-support.md
================================================
---
title: Browserunterstützung
---
# Browserunterstützung
Prect unterstützt moderne Browser (Chrome, Firefox, Safari, Edge) und IE9+. Es sollte in IE7 sowie IE8 funktionieren, setzt allerdings einige Polyfiller voraus. Wenn es beabsichtigt ist, Preact zu benutzen und diese älteren Browser zu unterstützen, wird empfohlen, einen Polyfiller wie zum Beispiel [es5-shim] oder [babel-polyfill] zu verwenden.
[es5-shim]: https://github.com/es-shims/es5-shim
[babel-polyfill]: https://babeljs.io/docs/usage/polyfill/
================================================
FILE: content/de/about/demos-examples.md
================================================
---
title: Demos & Beispiele
---
# Demos & Beispiele
Diese Seite zeigt einige Demos und Beispiele, die zum Erlernen von Preact benutzt werden können.
> :information_desk_person: _Eigenes Beispiel erstellt?
> [Einfach hinzufügen!](https://github.com/preactjs/preact-www/blob/master/content/de/about/demos-examples.md)_
## Vollständige Apps
**[Preact Website (preactjs.com)](https://preactjs.com)**<br>
Natürlich ist diese Website mit Preact erstellt.<br>
[GitHub Projekt](https://github.com/preactjs/preact-www)
**[ESBench](http://esbench.com)** :alarm_clock:<br>
Erstellt mit Preact & Material Design Lite.
**[GuriVR](https://gurivr.com)** :eyeglasses:<br>
Web VR-Geschichtenersteller basierend auf natürlicher Sprache.<br>
[GitHub Projekt](https://github.com/opennewslabs/guri-vr)
**[BigWebQuiz](https://bigwebquiz.com)** :game_die:<br>
Die progressive Web App für Publikumspartizipation vom Chrome Dev Summit 2016!<br>
[GitHub Projekt](https://github.com/jakearchibald/big-web-quiz)
**[Nectarine.rocks](http://nectarine.rocks)** :peach:<br>
Open-Source peach.cool App.<br>
[GitHub Projekt](https://github.com/developit/nectarine)
**[Dropfox](https://github.com/developit/dropfox)** :wolf:<br>
Desktop-App für Dropbox, erstellt mit Preact, Electron und Photon.
**[Connectivity Index](https://cindex.co)** :iphone:<br>
Eine Seite, die das Durchsuchen von Daten, geordnet nach Land, des [Akamai State of the Internet Connectivity Report](https://content.akamai.com/PG7010-Q2-2016-SOTI-Connectivity-Report.html) ermöglicht.
**[Drag & Drop file upload (webpack 2)](https://contentful-labs.github.io/file-upload-example/)** :rocket:<br>
Desktop App zum Hochladen auf Contentful (API based CMS)<br>
[GitHub Projekt](https://github.com/contentful-labs/file-upload-example)
**[Embed Hacker News](https://github.com/TXTPEN/hn)** :kissing_closed_eyes:<br>
Kommentarbaum für die Embed Hacker News unter dem eigenen Blogeintrag.
**[ColoGuessr](https://cologuessr.com)** :rainbow:<br>
Testen Sie, wie gut Sie Ihre Farben kennen<br>
[GitHub Project](https://github.com/jackpordi/cologuessr)
## Vollständige Demos & Beispiele
**[Documentation Viewer](https://documentation-viewer.firebaseapp.com)**<br>
Onlineansicht der Ausgabe von documentation.js.<br>
[GitHub Projekt](https://github.com/developit/documentation-viewer)
**[TodoMVC](http://developit.github.io/preact-todomvc/)**<br>
Inoffiziell schnellste TodoMVC-Implementierung.<br>
[GitHub Projekt](https://github.com/developit/preact-todomvc)
**[TodoMVC+PouchDB](http://katopz.github.io/preact-todomvc-pouchdb/)** :floppy_disk:<br>
Synchronisiere TodoMVC offline mit [PouchDB](https://pouchdb.com/).<br>
[GitHub Projekt](https://github.com/katopz/preact-todomvc-pouchdb)
**[Hacker News Minimal](https://developit.github.io/hn_minimal/)** :newspaper:<br>
Kleine Hacker News-App.<br>
[GitHub Projekt](https://github.com/developit/hn_minimal)
**[Preact Boilerplate](https://preact-boilerplate.surge.sh)** :zap:<br>
Anfängerprojekt mit zwei Befehlen. Preact + Webpack + LESS + CSS Modules.<br>
[GitHub Projekt](https://github.com/developit/preact-boilerplate)
**[Preact Offline Starter](https://preact-starter.now.sh)** :100:<br>
Vereinfachter Webpack2-Starter für progressive Web Apps mit Offlinesupport.<br>
[GitHub Projekt](https://github.com/lukeed/preact-starter)
**[Preact Redux Example](https://preact-redux-example.surge.sh)** :repeat:<br>
Preact + Redux-Beispielprojekt, das eine einfache To-Do-Liste implementiert.<br>
[GitHub Projekt](https://github.com/developit/preact-redux-example)
**[Preact Without Babel](https://github.com/developit/preact-without-babel)** :horse:<br>
Wie man Preact gänzlich ohne Babes, ES2015 oder JSX benutzt.
**[preact-minimal](https://github.com/aganglada/preact-minimal)** :rocket:<br>
Kleine Preact-Struktur mit allen nötigen Werkzeugen um direkt mit seinem Projekt zu Starten.
## Codepens
- [Flickr-Browser](http://codepen.io/developit/full/VvMZwK/) _(@ CodePen)_
- [Text animieren](http://codepen.io/developit/full/LpNOdm/) _(@ CodePen)_
- [60FPS-Regenboxenspirale](http://codepen.io/developit/full/xGoagz/) _(@ CodePen)_
- [Simple Uhr](http://jsfiddle.net/developit/u9m5x0L7/embedded/result,js/) _(@ JSFiddle)_
- [3D + ThreeJS](http://codepen.io/developit/pen/PPMNjd?editors=0010) _(@ CodePen)_
## Vorlage
:zap: **[JSFiddle Template](https://jsfiddle.net/developit/rs6zrh5f/embedded/result/)**
:zap: **[CodePen Template](http://codepen.io/developit/pen/pgaROe?editors=0010)**
================================================
FILE: content/de/about/libraries-addons.md
================================================
---
title: Bibliotheken & Add-ons
---
# Bibliotheken & Add-ons
Eine Auswahl an Modulen, die nahtlos mit Preact funktionieren.
> :information_desk_person: _Eigenes Modul erstellt?
> [Einfach hinzufügen!](https://github.com/preactjs/preact-www/blob/master/content/de/about/libraries-addons.md)_
### Add-Ons
- :raised_hands: **[preact-compat](https://github.com/preactjs/preact-compat)**: Jegliche React-Bibliothek mit Preact benutzen *([Vollständiges Beispiel](https://github.com/developit/preact-compat-example))*
- :repeat: **[preact-cycle](https://github.com/developit/preact-cycle)**: Funktionalreaktives Paradigma für Preact
- :page_facing_up: **[preact-render-to-string](https://github.com/preactjs/preact-render-to-string)**: Universelles Rendering.
### Komponenten
- :earth_americas: **[preact-router](https://github.com/preactjs/preact-router)**: URL-Routing für eigene Komponenten
- :bookmark_tabs: **[preact-markup](https://github.com/developit/preact-markup)**: HTML & eigene Elemente als JSX & Komponenten rendern
- :satellite: **[preact-portal](https://github.com/developit/preact-portal)**: Rendern von Preact-Komponenten im (Welt-)Raum :milky_way:
- :pencil: **[preact-richtextarea](https://github.com/developit/preact-richtextarea)**: Simple HTML-Editor-Komponente
- :bookmark: **[preact-token-input](https://github.com/developit/preact-token-input)**: Textfeld, dass Eingabe für Zwecke wie z.B. Tags in Tokens übersetzt
- :card_index: **[preact-virtual-list](https://github.com/developit/preact-virtual-list)**: Listen mit Millionen Reihen einfach rendern([demo](https://jsfiddle.net/developit/qqan9pdo/))
- :triangular_ruler: **[preact-layout](https://download.github.io/preact-layout/)**: Kleine und simple Layout-Bibliothek
- :construction_worker: **[preact-helmet](https://github.com/download/preact-helmet)**: Ein Dokumentenkopf-Manager für Preact
- :floppy_disk: **[preact-boot](https://gitlab.com/cromefire_/preact-boot)**: Einfache, deklarative [Bootstrap 4](https://getbootstrap.com/) Komponenten für preact ([Lies die Dokumentation!](https://preactboot.rtfd.io) (Englisch)).
### Integrationen
- :thought_balloon: **[preact-socrates](https://github.com/matthewmueller/preact-socrates)**: Preact-Plugin für [Socrates](http://github.com/matthewmueller/socrates)
- :rowboat: **[preact-flyd](https://github.com/xialvjun/preact-flyd)**: [flyd](https://github.com/paldepind/flyd) FRP-Streams in Preact + JSX benutzen
- :speech_balloon: **[preact-i18nline](https://github.com/download/preact-i18nline)**: Das [i18n-js](https://github.com/everydayhero/i18n-js)-Ökosystem mit Preact mithilfe von [i18nline](https://github.com/download/i18nline) integrieren.
- 🧩 **[ziko-wrapper](https://github.com/zakarialaoui10/ziko-wrapper)**: Wrap your [zikojs](https://github.com/zakarialaoui10/zikojs) components inside a Preact app — and vice versa.
### GUI Toolkits
- :white_square_button: **[preact-mdl](https://github.com/developit/preact-mdl)**: [MDL](https://getmdl.io) als Preact-Komponenten benutzen
- :rocket: **[preact-photon](https://github.com/developit/preact-photon)**: Schöne Desktop UIs mit [photon](http://photonkit.com) erstellen
### Testen
- :microscope: **[preact-jsx-chai](https://github.com/developit/preact-jsx-chai)**: JSX-Behauptungen testen _(kein DOM, direkt in Node)_
- :white_check_mark: **[unexpected-preact](https://github.com/bruderstein/unexpected-preact)**: JSX-Behauptungen, Ereignisse, Momentaufnahmen in Jest _(DOM, funktioniert mit Node jsdom oder direkt von der Stange mit Jest)_ - [docs](https://bruderstein.github.io/unexpected-preact/)
### Dienstprogramme
- :tophat: **[preact-classless-component](https://github.com/ld0rman/preact-classless-component)**: Preact-Komponenten ohne Klassenschlagwörter erstellen
- :hammer: **[preact-hyperscript](https://github.com/queckezz/preact-hyperscript)**: Hyperscript-ähnliche Syntax zum Erstellen von Elementen
- :white_check_mark: **[shallow-compare](https://github.com/tkh44/shallow-compare)**: Vereinfachtes `shouldComponentUpdate` Hilfsprogramm.
================================================
FILE: content/de/about/project-goals.md
================================================
---
title: Projektziele
---
# Preacts Ziele
## Ziele
Preact zielt darauf ab, Leistung aufgrund folgender Ziele zu liefern:
- **Leistung:** Schnell und effizient rendern
- **Größe:** Leichtigkeit und kleine Größe _(ungefähr 3.5kb)_
- **Effizienz:** Effektive Speichernutzung _(Wiederverwendung, GC-Müll verhindern)_
- **Verständlichkeit:** Die Grundlagen des Codes zu Verstehen sollte nicht länger als ein paar Stunden dauern
- **Kompatibilität:** Preact zielt darauf ab, _Kompatibilität im großen Rahmen_ mit der React API zu erreichen. [preact-compat] versucht, die größtmögliche Kompatibilität mit React zu erzielen.
## Nicht-Ziele
Einige Features von React wurden absichtlich nicht in Preact integriert, da sie entweder mit Berücksichtigung der oben genannten primären Projektziele nicht umsetzbar sind oder aber nicht in den Umfang von Preacts Grundausstattung an Funktionalitäten passen.
- Die beabsichtigten Artikel unter [Was fehlt?](/guide/v8/differences-to-react#whats-missing):
- PropTypes, die leicht als separate Bibliothek verwendet werden können
- Children, da Preact immer children als Array verpackt
- Synthetic Events, da Preact nicht versucht, Fehler in älteren Browsern (z.B. IE8) zu beheben
[preact-compat]: https://github.com/preactjs/preact-compat/
================================================
FILE: content/de/about/we-are-using.md
================================================
---
title: Wer benutzt Preact?
---
# We Are Using
Preact wird von einem breiten Spektrum von Webseiten verwendet: von Open Source-Projekten bis hin zu großen multinationalen Unternehmen.
Nachfolgend ist ein kleiner Auszug von Unternehmen, die Preact für öffentliche Projekte benutzen:
Benutzt Ihr Unternehmen Preact? [Fügen Sie es zur Liste hinzu!](https://github.com/preactjs/preact-www/blob/master/src/components/we-are-using/index.jsx)
<div class="breaker">
<we-are-using></we-are-using>
</div>
================================================
FILE: content/de/guide/v8/api-reference.md
================================================
---
title: API-Referenzierung
---
# API-Referenzierung
---
<toc></toc>
---
## `Preact.Component`
`Component` ist eine Basisklasse, die normalerweise als Subklasse zum Erstellen von kraftvollen Preact-Komponenten verwendet wird.
### `Component.render(props, state)`
Die `render()`-Funktion ist voraussetzend für alle Komponenten. Sie kann die props und states der Komponente inspizieren und sollte ein Preact-Element oder `null` zurückgeben.
```jsx
import { Component } from 'preact';
class MeineKomponente extends Component {
render(props, state) {
// props === this.props
// state === this.state
return <h1>Hello, {props.name}!</h1>;
}
}
```
### Lebenszyklusmethoden
> _**Tipp:** Wenn du eigene HTML5-Elemente verwendert hast: diese ähneln sich mit den `attachedCallback`- und `detachedCallback`-Lebenszyklusmethoden._
Preact ruft die nachfolgenden Lebenszyklusmethoden auf, falls sie für eine Komponente definiert sind:
| Lebenszyklusmethoden | Wann sie aufgerufen wird |
|-----------------------------|--------------------------------------------------------------|
| `componentWillMount` | bevor die Komponente an das DOM eingehanden wird |
| `componentDidMount` | nachdem die Komponente an das DOM eingehanden wird |
| `componentWillUnmount` | vor dem Entfernen vom DOM |
| `componentWillReceiveProps` | bevor neue props angenommen werden |
| `shouldComponentUpdate` | vor `render()`. `false` ausgeben, um Rendern zu überspringen |
| `componentWillUpdate` | vor `render()` |
| `componentDidUpdate` | nach `render()` |
Alle Lebenszyklusmethoden und ihre Parameter werden in der folgenden Beispielkomponente angezeigt:
```js
import { Component } from 'preact';
class MeineKomponente extends Component {
shouldComponentUpdate(nextProps, nextState) {}
componentWillReceiveProps(nextProps, nextState) {
this.props // Previous props
this.state // Previous state
}
componentWillMount() {}
componentWillUpdate(nextProps, nextState) {
this.props // Previous props
this.state // Previous state
}
componentDidMount() {}
componentDidUpdate() {}
componentWillUnmount() {
this.props // Current props
this.state // Current state
}
}
```
## `Preact.render()`
`render(component, containerNode, [replaceNode])`
Rendere eine Preact-Komponente in den `containerNode` DOM-Knoten. Gibt eine Referenz zum gerenderten DOM-Knoten aus.
Wenn der optionale `replaceNode` DOM-Knoten gegeben ist und ein Child von `containerNode` ist, wird Preact dieses Element aktualisieren oder mit seinem Differenzierungsalgorithmus ersetzen. Andernfalls wird Preact das gerenderte Element zu `containerNode` hinzufügen.
> ⚠️ Das `replaceNode`-Argument wird in der zukünftigen Preact `v11` Version entfernt. Es führt zu zu vielen Extrawürsten und Fehlern, die in anderen Teilen des Preact Codes berücksichtigt werden müssen. Dieser Teil der Dokumentation dient mehr zu historischen Zwecken, daher empfehlen wir die `render`-Funktion ohne dieses Argument zu benutzen.
```js
import { render } from 'preact';
// Diese Beispiele zeigen, wie sich render() in einer Seite mit folgendem Inhalt verhält:
// <div id="container">
// <h1>My App</h1>
// </div>
const container = document.getElementById('container');
render(MeineKomponente, container);
// MeineKomponente zu Container hinzufügen
//
// <div id="container">
// <h1>My App</h1>
// <MeineKomponente />
// </div>
const existingNode = container.querySelector('h1');
render(MeineKomponente, container, existingNode);
// MeineKomponente gegen <h1>Meine App</h1> differenzieren
//
// <div id="container">
// <MeineKomponente />
// </div>
```
## `Preact.h()` / `Preact.createElement()`
`h(nodeName, attributes, [...children])`
Gibt ein Preact Virtual DOM-Element mit den gegebenen `Attributen` wieder.
Alle verbleibenden Argumente werden in einem `Children`-Array gesammelt. Dies können folgende Argumente sein:
- Skalarwerte (string, number, boolean, null, undefined, etc)
- Weitere Virtual DOM-Elemente
- Grenzenlos verschachtelte Arrays der oberen Fälle
```js
import { h } from 'preact';
h('div', { id: 'foo' }, 'Hallo!');
// <div id="foo">Hallo!</div>
h('div', { id: 'foo' }, 'Hallo', null, ['Preact!']);
// <div id="foo">Hallo Preact!</div>
h(
'div',
{ id: 'foo' },
h('span', null, 'Hallo!')
);
// <div id="foo"><span>Hallo!</span></div>
```
================================================
FILE: content/de/guide/v8/differences-to-react.md
================================================
---
title: Unterschiede zu React
---
# Unterschiede zu React
Preact selbst soll keine Neuimplementation von React sein. Es gibt durchaus Unterschiede. Viele dieser Unterschiede sind trivial oder können mit der Nutzung von [preact-compat] komplett entfernt werden. Preact-compat ist eine dünne Schicht, die über Preact liegt und versucht, die 100%ige Kompatibilität mit React herzustellen.
Preact ist nicht darauf ausgelegt, jede einzelne Funktion von React zu übernehmen, um **klein** und **fokussiert** zu bleiben - andernfalls würde es mehr Sinn ergeben, simple Optimierungen für das React-Projekt, welches bereits über eine sehr komplexe und gut architektierte Codebasis verfügt, einzureichen.
---
<toc></toc>
---
## Versionenkompatibilität
Für Preact und [preact-compat] gilt: Versionenkompatibilität wird gegen die _aktuellen_ und _vorherigen_ Hauptveröffentlichungen von React gemessen. Wenn neue Funktionen vom React-Team angekündigt werden, werden sie, sollten sie mit den [Projektziele]n im Hinterkopf nutzvoll sein, zu Preacts Kern hinzugefügt. Dies ist ein recht demokratischer Prozess, der von sich konstant entwickelnden Diskussionen und Entscheidungen der Masse gezeichnet ist. Er lebt von Issues und Pull Requests.
> Daher ist von React `0.14.x` und `15.x` gemeint, wenn auf der Website oder in der Dokumentation von Kompatibilität oder Vergleichen die Rede ist.
## Was ist inbegriffen?
- [ES6 Class Components]
- _Klassen ermöglichen einen expressiven Weg, zustandsorientierte Komponenten zu definieren_
- [High-Order Components]
- _Komponenten, die andere Komponenten von `render()` ausgeben, effektiv sind dies Wrapper_
- [Stateless Pure Functional Components]
- _Funktionen, die `props` als Argumente empfangen und JSX/VDOM ausgeben_
- [Contexts]: Support for `context` was added in Preact [3.0].
- _Kontext ist eine experimentelle React-Funktion, wurde aber von anderen Bibliotheken adoptiert._
- [Refs]: Support for function refs was added in Preact in [4.0]. String refs are supported in `preact-compat`.
- _Refs bieten einen weg, gerenderte Elemente und Child-Komponenten zu rendern._
- Virtual DOM Diffing
- _Quasi unabdingbar - Preacts Differenzierung ist simpel, aber effektiv und **[extrem](http://developit.github.io/js-repaint-perfs/) [schnell](https://localvoid.github.io/uibench/)**._
- `h()`, eine mehr generalisierte Version von `React.createElement`
- _Diese Idee hieß ursprünglich [hyperscript] und war weit über das React-Ökosystem hinaus wertvoll, daher bewirbt Preact den originalen Standart. ([Lies: warum `h()`?](http://jasonformat.com/wtf-is-jsx))_
- _Außerdem ist lesbarer: `h('a', { href:'/' }, h('span', null, 'Home'))`_
## Was ist hinzugefügt?
Preact fügt durchaus vereinzelt nützliche Funktionen hinzu, die von dem Schaffen der React-Gemeinde inspiriert sind.
- `this.props` und `this.state` werden an `render()` weitergegeben
- _Man kann sie immer noch manuell referenzieren. Dieses Vorgehen ist einfach sauberer, insbesondere bei der [Destrukturierung]_
- Gestapelte Aktualisierungen des DOM, die mit `setTimeout(1)` zurückgegeben und verglichen werden, _(können außerdem requestAnimationFrame verwenden)_
- Man kann einfach `class` für CSS-Klassen verwenden. `className` wird zwar immer noch unterstützt, `class` wird aber präferiert.
- Komponenten- und Elementenwiederverwendung- und pooling.
## Was fehlt?
- [PropType] Validierung: Nicht jeder benutzt PropTypes, daher gehören sie nicht Preacts Kern an.
- _**PropTypes sind vollständig durch** [preact-compat] **unterstützt**, können aber auch manuell verwendet werden._
- [Children]: Nicht notwendig in Preact, da `props.children` _immer ein Array_ ist.
- _`React.Children` ist vollständig in [preact-compat] unterstützt._
- Synthetisch Ereignisse: Preacts Ziel in der Browserunterstützung setzt diesen zusätzlichen Mehraufwand nicht voraus.
- _Preact nutzt das native `addEventListener` des Browsers für Ereignishandhabung. Unter [GlobalEventHandlers] ist eine vollständige Liste an DOM Ereignishandhabungen zu finden._
- _Eine vollständige Ereignisimplementierung würde mehr Wartung, Leistungseinbußen und eine größere API bedeuten._
## Was ist anders?
Preact und React haben einige feinere Unterschiede:
- `render()` akzeptiert ein drittes Argument, welches der Grundknoten zu _replace_ ist, andernfalls fügt es es hinzu. Dies könnte sich in einer zukünftigen Version ein wenig ändern, vermutlich durch automatische Erkennung der Angemessenheit eines Ersatzrenders mithilfe einer Inspizierung des Grundknoten.
- Komponenten implementieren `contextTypes` oder `childContextTypes` nicht. Children empfangen alle `context`-Einträge von `getChildContext()`.
[Projektziele]: /about/project-goals
[hyperscript]: https://github.com/dominictarr/hyperscript
[3.0]: https://github.com/preactjs/preact/milestones/3.0
[4.0]: https://github.com/preactjs/preact/milestones/4.0
[preact-compat]: https://github.com/preactjs/preact-compat
[PropType]: https://github.com/developit/proptypes
[Contexts]: https://facebook.github.io/react/docs/context.html
[Refs]: https://facebook.github.io/react/docs/more-about-refs.html
[Children]: https://facebook.github.io/react/docs/top-level-api.html#react.children
[GlobalEventHandlers]: https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers
[ES6 Class Components]: https://facebook.github.io/react/docs/reusable-components.html#es6-classes
[High-Order Components]: https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750
[Stateless Pure Functional Components]: https://facebook.github.io/react/docs/reusable-components.html#stateless-functions
[Destrukturierung]: http://www.2ality.com/2015/01/es6-destructuring.html
[Linked State]: /guide/v8/linked-state
================================================
FILE: content/de/guide/v8/extending-component.md
================================================
---
title: Kompontente erweitern
---
# Komponente erweitern
Es besteht die Möglichkeit, dass manche Projekte eine Komponente mit zusätzlichen Funktionalitäten erweitern wollen.
Der Stellenwert von Vererbung in JavaScript ist umstritten, wenn man allerdings eine eigene "Basisklasse" erstellen will, von der alle anderen Komponenten erben, ist Preact genau richtig.
Möglicherweise ist das Erstellen von automatischen Verbindungen zu Stores/Reducers in einer Flux-ähnlichen Architektur gewünscht. Vielleicht mag man es auch, Eigentums-basierte Mixins hinzuzufügen, damit es sich mehr wie `React.createClass` anfühlt _(Anmerkung: der [@`bind` decorator](https://github.com/developit/decko#bind) ist bevorzugt)_.
In jedem Fall ist die Klassenvererbbarkeit aus ES2015 anwendbar, um Preacts `Component`-Klasse zu erweitern:
```js
class BoundComponent extends Component {
// example: Gebundene Methoden erfassen
binds() {
let list = this.bind || [],
binds = this._binds;
if (!binds) {
binds = this._binds = {};
for (let i=list.length; i--; ) {
binds[list[i]] = this[list[i]].bind(this);
}
}
return binds;
}
}
```
Anwendungsbeispiel:
```js
class Link extends BoundComponent {
bind = ['click'];
click() {
open(this.props.href);
}
render({ children }) {
let { click } = this.binds();
return <span onClick={ click }>{ children }</span>;
}
}
render(
<Link href="http://example.com">Click mich</Link>,
document.body
);
```
Die Möglichkeiten sind unendlich. Hier ist eine erweiterte `Component`-Klasse, die rudimentäre Mixins unterstützt:
```js
class MixedComponent extends Component {
constructor() {
super();
(this.mixins || []).forEach( m => Object.assign(this, m) );
}
}
```
---
> **Fußnote:** Man sollte anmerken, dass Vererbung in zerbrechliche parent-child-Beziehungen mit ihren entsprechenden Problemen führen kann. Für eine Programmieraufgabe, die adäquat mit Vererbung gelöst werden kann, gibt es oftmals einen funktionaleren Weg um das gleiche Ziel zu erreichen. Dies macht das Erstellen solcher Beziehungen unnötig.
================================================
FILE: content/de/guide/v8/external-dom-mutations.md
================================================
---
title: Externe DOM-Mutationen
---
# Externe DOM-Mutationen
---
<toc></toc>
---
## Übersicht
Manchmal ist es nötig, mit Drittanbieterbibliotheken zu arbeiten, die erwarten, frei im DOM mutieren zu können, in einem Stadium zu verharren oder überhaupt gar keine Komponentengrenzen zu haben. Es gibt viele großartige UI-Toolkits und wiederverwendbare Elemente, die so funktionieren. In Preact, ähnlich wie auch React, setzt das Arbeiten mit diesen Bibliotheken voraus, dass man dem Rendering oder der Differenzierungsalgorithmus des Virtual DOM befiehlt, keine externen DOM-Mutationen innerhalb einer bestimmten Komponente (oder seinem DOM-Element) _rückgängig_ zu machen.
## Technik
Dies funktioniert ganz einfach indem man eine `shouldComponentUpdate()`-Methode in einer Komponente definiert und diese `false` zurückgeben lässt.
```js
class Block extends Component {
shouldComponentUpdate() {
return false;
}
}
```
... oder in Kurzform:
```js
class Block extends Component {
shouldComponentUpdate = () => false;
}
```
Mit diesem Eingriff in den Lebenszyklus und der Anweisung an Preact, die Komponente nicht zu rendern, wenn sich etwas im VDOM-Baum ändert, hat die Komponente nun eine Referenz in seinem DOM-Stammelement, das solange als statisch angesehen werden kann, bis die Komponente unmounted ist. Genau wie bei jeder Komponente wird diese Referenz einfach `this.base` genannt. Sie korrespondiert mit dem JSX-Stammelement, das von `render()` zurückgegeben wurde.
## Beispieldurchlauf
Hier wird beispielhaft gezeigt, wie das Rerendern einer Komponente "ausgeschaltet" wird. Es muss beachtet werden, dass `render()` immer noch im Zuge von Erstellung und Mounten der Komponente aufgerufen wird, damit seine ursprüngliche DOM-Struktur generiert werden kann.
```js
class Beispiel extends Component {
shouldComponentUpdate() {
// Nicht via diff rerendern:
return false;
}
componentWillReceiveProps(nextProps) {
// Irgendetwas mit eingehenden props kann hier erledigt werden, falls benötigt
}
componentDidMount() {
// jetzt gemounted, kann das DOM frei modifizieren:
let thing = document.createElement('maybe-a-custom-element');
this.base.appendChild(thing);
}
componentWillUnmount() {
// Komponente ist kurz davor, vom DOM entfernt zu werden. Aufräumarbeiten sind hier möglich.
}
render() {
return <div class="beispiel" />;
}
}
```
## Beispiele aus der realen Welt
Alternativ kann diese Technik bei [preact-token-input](https://github.com/developit/preact-token-input/blob/master/src/index.js) im Einsatz bewundert werden - es benutzt eine Komponente als Halt im DOM, umgeht aber Aktualisierungen und lässt [tags-input](https://github.com/developit/tags-input) von dort aus übernehmen. Ein komplexeres Beispiel wäre [preact-richtextarea](https://github.com/developit/preact-richtextarea). Es benutzt diese Technik, um das Rerendern eines bearbeitbaren `<iframe>`-Elementes zu umgehen.
================================================
FILE: content/de/guide/v8/forms.md
================================================
---
title: Eingabemasken
---
# Eingabemasken
Eingabemasken funktionieren in Preact fast genauso wie in React, allerdings gibt es keine Unterstützung für "statische" (Ausgangswert) props/Attribute.
**[React Eingabemasken-Doku](https://facebook.github.io/react/docs/forms.html)**
---
<toc></toc>
---
## Kontrollierte & Unkontrollierte Komponenten
Reacts Dokumentation zu ["Kontrollierten" Komponenten](https://facebook.github.io/react/docs/forms.html#controlled-components) und ["Unkontrollierten" Komponenten](https://facebook.github.io/react/docs/forms.html#uncontrolled-components) ist ungemein nützlich, wenn man verstehen möchte, wie man HTML-Eingabemasken mit bidirektionalem Datenfluss benutzt und sich diese im Kontext eines komponentenbasierten DOM-Renderer, welche normalerweise unidirektionale Datenflüsse haben, zu Nutze macht.
Generell sollte man versuchen, immer _Kontrollierte_ Komponenten zu verwenden. Trotzdem kann es beim Erstellen von unabhängigen Komponenten oder umschließenden Drittanbieter-UI-Bibliotheken sehr nützlich sein, die Komponente einfach als Mount-Punkt für Non-Preact-Funktionalitäten zu verwenden. In diesen Fällen sind _Unkontrollierte_ Komponenten genau richtig für die Aufgabe.
## Kontrollboxen & Radio Buttons
Kontrollboxen und Radio Buttons (`<input type="checkbox|radio">`) können anfänglich für Verwirrung sorgen, wenn man kontrollierte Eingabemasken erstellt. Dies ist damit zu begründen, dass man in einer unkontrollierten Umgebung normalerweise dem Browser erlauben würden, eine Kontrollbox oder einen Radio Button für uns "umzuschalten" oder "anzukreuzen", auf Änderungsereignisse zu warten und auf den neuen Wert zu reagieren. Allerdings geht diese Technik nicht sonderlich gut in ein Weltbild über, in dem da UI immer wieder automatisch als Reaktion auf state- und prop-Änderungen aktualisiert wird.
> **Durchlauf:** Man geht davon aus, dass wir auf ein "Änderungs"ereignis einer Kontrollbox warten, welches ausgelöst wird, wenn die Kontrollbox aus- oder abgewählt wird. Der Änderungsereignis-Handler wird den neuen Wert, der von der Kontrollbox empfangen wird, einem Wert in `state` zuordnen. Dies löst das Neurendern der Komponente aus, was den Wert der Kontrollbox dem Wert von state neu zuordnen wird. Das ist allerdings unnötig, das wir gerade beim DOM einen Wert angefragt haben, ihm dann aber das Neurendern mit dem gewünschten Wert befohlen haben.
Man sollte also anstatt auf ein `change`-Ereignis auf ein `click`-Ereignis warten, welches bei jedem Click des Nutzers auf die Kontrollbox _oder ein assoziiertes `<label>`_ ausgelöst wird. Kontrollboxen schalten lediglich zwischen Boolean `true` und `false` hin und her, daher bewirkt ein Klick auf die Kontrollbox oder das Label nichts anderes als eine Invertierung des aktuellen Status, das Auslösen einer Neurenderung und das Setzen des gewünschten Wertes innerhalb der Kontrollbox.
### Kontrollboxbeispiel
```js
class MeineEingabemaske extends Component {
toggle = e => {
let checked = !this.state.checked;
this.setState({ checked });
};
render({ }, { checked }) {
return (
<label>
<input
type="checkbox"
checked={checked}
onClick={this.toggle} />
</label>
);
}
}
```
================================================
FILE: content/de/guide/v8/getting-started.md
================================================
---
title: "Los geht's"
---
# Los geht's
Diese Anleitung zeigt, wie man eine einfache tickende Uhr als Komponente erstellt. Detailliertere Informationen zu jedem Thema können auf den dedizierten Seiten unter dem Anleitungsmenü gefunden werden.
> :information_desk_person: Man [_muss_ nicht ES2015 für Preact benutzen](<https://github.com/developit/preact-without-babel>)... man sollte es aber. Diese Anleitung geht davon aus, dass man eine ES2015-Umgebung mit Babel und/oder Webpack/Browserify/Gulp/Grunt/etc. benutzt. Wenn das nicht der Fall ist, verwende [preact-boilerplate] oder eine [CodePen-Vorlage](http://codepen.io/developit/pen/pgaROe?editors=0010).
---
<toc></toc>
---
## Importiere, was man braucht
Das `preact`-Modul bietet die Option für bestimmte und allgemeine Exporte, man kann also alles unter einem persönlichen Namensraum importieren, oder aber das komplette Paket ansprechen.
**Bestimmt:**
```js
import { h, render, Component } from 'preact';
// Weise Babel an, JSX in h()-Aufrufe zu transformieren:
/** @jsx h */
```
**Allgemein:**
```js
import preact from 'preact';
// Weise Babel an, JSX in preact.h()-Aufrufe zu transformieren:
/** @jsx preact.h */
```
> Bestimmte Importierungen funktionieren wundervoll mit hochstrukturierten Applikationen, der allgemeine Import ist hingegen schnell und muss niemals aktualisiert werden, sollte man verschiedene Teile der Bibliothek verwenden.
### Globales Pragma
Anstatt das `@jsx`-Pragma im eigenen Code zu deklarieren sollte man es lieber global in einer `.babelrc`-Datei konfigurieren.
**Bestimmt:**
> **Mit Babel 5 oder niedriger:**
> ```json
> { "jsxPragma": "h" }
> ```
> **Ab Babel 6:**
> ```json
> {
> "plugins": [
> ["transform-react-jsx", { "pragma":"h" }]
> ]
> }
> ```
**Allgemein:**
> **Für Babel 5 und niedriger:**
> ```json
> { "jsxPragma": "preact.h" }
> ```
> **Ab Babel 6:**
> ```json
> {
> "plugins": [
> ["transform-react-jsx", { "pragma":"preact.h" }]
> ]
> }
> ```
## JSX Rendern
Preact bietet von Grund auf eine `h()`-Funktion, die JSX-Code in VDOM-Elemente _([so funktioniert's](https://jasonformat.com/wtf-is-jsx))_ umwandeln. Es bietet außerdem die `render()`-Funktion an, mit der man einen DOM-Baum des Virtuellen DOMs erstellt.
Um JSX zu rendern, importiert man diese zwei Funktionen und setzt sie wie folgt ein:
```js
import { h, render } from 'preact';
render((
<div id="foo">
<span>Hallo Welt!</span>
<button onClick={ e => alert("hi!") }>Klick mich!</button>
</div>
), document.body);
```
Dies sollte eigentlich bekannt sein, wenn man bereits mit [hyperscript] oder einem seiner [vielen Freunde](https://github.com/developit/vhtml) gearbeitet hat.
Hyperscript in einem Virtuellen DOM zu Rendern macht allerdings gar keinen Sinn. Da man Komponenten rendern möchte und diese sich aktualisieren sollen, wenn sich Daten ändern, glänzt in diesem Falle die Differenzierung des Virtuellen DOM ganz besonders. :star2:
## Komponente
Preact exportiert eine generische `Komponente`-Klasse, welche zum Erstellen von verkapselten, sich selbst aktualisierenden Teilen einer Benutzeroberfläche erweitert werden kann. Komponenten unterstützt die standardmäßigen React-[Lebenszyklusmethoden] wie z.B. `shouldComponentUpdate()`und `componentWillReceiveProps()`. Das Bereitstellen von spezifischen Implementationen dieser Methoden ist die bevorzugte Vorgehensweise, wenn man kontrollieren will, _wann_ und _wie_ Komponenten sich aktualisieren.
Komponenten haben außerdem eine `render()`-Methode, allerdings erhält diese, anders als in React, `(props, state)` als Argumente. Dies ermöglicht eine ergonomische Vorgehensweise, mit der man `props` und `state` in lokale Variablen destrukturieren kann, die dann von JSX referenziert werden können.
Nachfolgend ist eine simple `Uhr`-Komponente, die die aktuelle Zeit anzeigt.
```js
import { h, render, Component } from 'preact';
class Uhr extends Component {
render() {
let time = new Date().toLocaleTimeString();
return <span>{ time }</span>;
}
}
// Eine Uhr-Instanz in <body> rendern:
render(<Uhr />, document.body);
```
So weit, so gut. Das Ausführen dieser Anweisung generiert die folgende HTML-DOM-Struktur;:
```html
<span>10:28:57 PM</span>
```
--------------------------------------------------------------------------------
## Der Komponentenlebenszyklus
Damit sich die Uhr jede Sekunde aktualisieren kann, muss man wissen, wann `<Uhr>` an das DOM gemounted wird. _Falls man bereits HTML5 Custom Elements benutzt hat, wird einem dies vertraut vorkommen. Es ähnelt sich mit den `attachedCallback`- und `detachedCallback`-Lebenszyklusmethoden._ Falls sie für eine Komponente definiert sind, ruft Preact die folgenden Lebenszyklusmethoden auf:
| Lebenszyklusmethoden | Wann sie aufgerufen wird |
|-----------------------------|--------------------------------------------------------------|
| `componentWillMount` | bevor die Komponente an das DOM eingehanden wird |
| `componentDidMount` | nachdem die Komponente an das DOM eingehanden wird |
| `componentWillUnmount` | vor dem Entfernen vom DOM |
| `componentWillReceiveProps` | bevor neue props angenommen werden |
| `shouldComponentUpdate` | vor `render()`. `false` ausgeben, um Rendern zu überspringen |
| `componentWillUpdate` | vor `render()` |
| `componentDidUpdate` | nach `render()` |
Gewünscht ist also ein 1-Sekunden-Timer, der startet, sobald die Komponente zum DOM hinzugefügt wird und stoppt, sobald diese vom DOM entfernt wird. Dieser erstellte Timer wird in `componentDidMount` referenziert und mithilfe von `componentWillUnmount` gestoppt. Bei jedem Durchlauf des Timers wird das `state`-Objekt der Komponente mit einem neuen Zeitwert aktualisiert. Dies führt automatisch dazu, dass die Komponente neu gerendert wird.
```js
import { h, render, Component } from 'preact';
class Uhr extends Component {
constructor() {
super();
// Initiale Zeit einstellen:
this.state.time = Date.now();
}
componentDidMount() {
// Zeit jede Sekunde aktualisieren
this.timer = setInterval(() => {
this.setState({ time: Date.now() });
}, 1000);
}
componentWillUnmount() {
// Stoppen, falls nicht renderbar
clearInterval(this.timer);
}
render(props, state) {
let time = new Date(state.time).toLocaleTimeString();
return <span>{ time }</span>;
}
}
// Eine Instanz von Uhr in <body> rendern:
render(<Uhr />, document.body);
```
--------------------------------------------------------------------------------
Das war's! Man hat jetzt eine [tickende Uhr](http://jsfiddle.net/developit/u9m5x0L7/embedded/result,js/).
[hyperscript]: https://github.com/dominictarr/hyperscript
[preact-boilerplate]: https://github.com/developit/preact-boilerplate
================================================
FILE: content/de/guide/v8/linked-state.md
================================================
---
title: Verlinkter State
---
# Verlinkter State
Ein Bereich, den Preact ausführlicher als React behandelt ist das Optimieren der Änderungen von States. Ein gängiges Schema in ES2015-React-Code ist das Benutzen von Arrow-Funktionen innerhalb einer `render()`-Methode, um States im Falle eines Ereignisses zu aktualisieren. Funktionen, die nur innerhalb einer einzelnen Render-Instanz leben ist ineffizient und zwingt den Garbage Collector dazu, deutlich mehr Arbeit als nötig wäre zu verrichten.
---
<toc></toc>
---
## Der schönere, manuelle Weg
Eine Lösung beinhaltet das Definieren von gebundenen Komponentenmethoden mithilfe von ES7-Klassen-Properties ([class instance fields](https://github.com(jeffmo/es-class-fields-and-static-properties)):
```js
class Foo extends Component {
updateText = e => {
this.setState({ text: e.target.value });
};
render({ }, { text }) {
return <input value={text} onInput={this.updateText} />;
}
}
```
Während dies zu deutlich besseren Laufzeitleistungen führt, beinhaltet dieser Ansatz immer noch eine Menge unnötigen Code, der gebraucht wird, um State und UI zu verbinden.
> Ein anderer Ansatuz wäre es, Komponentenmethoden mithilfe von ES7-Decorators _deklarativ_ anzubinden. Ein Beispiel hierfür wäre [decko's](https://github.com/developit/decko) `@bind`:
## Verlinkter State eilt zur Rettung
Glücklicherweise gibt es eine Lösung in Form von Preacts [`linkState`](https://github.com/developit/linkstate)-Modul.
> Frühere Versionen von Preact hatten die `linkState()`-Funktion bereits von Grund auf eingebaut, sie wurde mittlerweile aber in ein seperates Modul verschoben. Wenn man zum alten Verhalten zurückwechseln möchte, findet man auf [dieser Seite](https://github.com/developit/linkstate#usage) Informationen zur Anwendung dieses Polyfills.
Das Aufrufen von `linkState(this, 'text')` gibt eine Handler-Funktion aus, die, falls an diese ein Ereignis weitergegeben wird, seinen zugewiesen Wert zum Aktualisieren der bestimmten Property des States der Komponente benutzt. Mehrere Aufrufe an `linkState(component, name)` mit der selben `component` und `name` werde gecached, sodass man nicht mit Leistungseinbuße rechnen muss.
Nachfolgend ist das genannte Beispiel mithilfe von **Verlinkten State**:
```js
import linkState from 'linkstate';
class Foo extends Component {
render({ }, { text }) {
return <input value={text} onInput={linkState(this, 'text')} />;
}
}
```
Dieses Vorgehen ist präzise, einfach zu verstehen und effektiv. Es verarbeitet verlinkte States jedes Eingabetypus. Ein optionales, drittes Argument `'path'` kann verwendet werden, um einen Punkt-notierten Keypath dem neuen State-Wert für zusätzliche, eigene Bindings (z.B. Anbinden an den Wert einer Dritttanbieterkomponente) explizit bereitzustellen.
## Eigene Ereignispfade
Standardmäßig wird `linkState()`versuchen, den passenden Wert eines Ereignisses automatisch er ermitteln. Ein `<input>`-Element wird beispielsweise, je nach Eingabetyp, die gegebene State-Property zu `event.target.value` bzw. `event.target.checked` setzen. Die meisten eigenen Ereignis-Handler funktionieren so, dass das Weitergeben von Skalarwerte zum von `linkState()` generierten Handler einfach diesen gegebenen Skalarwert verwendet. Dieses Verhalten ist in den meisten Fällen erwünscht.
Es gibt auch Fälle, in den dieses Verhalten nicht wünschenswert ist. Eigene Ereignisse und gruppierte Radio Buttons sind zwei Beispiele. In diesen Fällen kann ein drittes Argument an `linkState()` weitergegeben werden, um Punkt-notierte Keypaths innerhalb des Ereignisses, in dem der Wert gefunden werden kann, zu spezifizieren.
Um diese Funktion verstehen zu können, ist es nützlich, einen Blick unter die Haube von `linkState()` zu werfen. Der nachfolgende Teil illustriert einen manuell erstellten Ereignis-Handler, der einen Wert vom Inneren eines Ereignisobjektes in State schreibt. Dieses Verhalten ist funktional äquivalent zur `linkState()`-Version, beinhaltet allerdings nicht die Memoisationsoptimierung, die `linkState()` so wertvoll macht.
```js
// Dieser von linkState zurückgegebene Handler:
handler = linkState(this, 'thing', 'foo.bar');
// ...ist funktional equivalent zu:
handler = event => {
this.setState({
thing: event.foo.bar
});
}
```
### Illustration: Gruppierte Radio Buttons
Der nachfolgende Code funktioniert nicht wie zuerst erwartet. Wenn der Nutzer "no" anklickt, wird `noChecked` zwar zu `true`, `yesChecked` bleibt aber auch `true`, da `onChange` nicht bei den anderen Radio Buttons ausgelöst wird:
```js
import linkState from 'linkstate';
class Foo extends Component {
render({ }, { yes, no }) {
return (
<div>
<input type="radio" name="demo"
value="yes" checked={yes}
onChange={linkState(this, 'yes')}
/>
<input type="radio" name="demo"
value="no" checked={no}
onChange={linkState(this, 'no')}
/>
</div>
);
}
}
```
Hier hilft die Nutzung des dritten `linkState`-Argumentes weiter,
indem man hier den Wert an Hand eines expliziten Pfades des Ereignisobjekts auswählt.
Angewendet auf das vorherige Beispiel bedeutet das folgendes:
`linkState` soll den Wert der `value`-Property aus `event.target` unter dem Bezeichner `answer` im State setzen.
Der Wert des State-Objekts namens `answer` wird daraufhin genutzt, um die `checked`-Property an den Radio Buttons entsprechend zu reflektieren.
```js
import linkState from 'linkstate';
class Foo extends Component {
render({ }, { answer }) {
return (
<div>
<input type="radio" name="demo"
value="yes" checked={answer == 'yes'}
onChange={linkState(this, 'answer', 'target.value')}
/>
<input type="radio" name="demo"
value="no" checked={answer == 'no'}
onChange={linkState(this, 'answer', 'target.value')}
/>
</div>
);
}
}
```
Nun funktioniert das Beispiel wie erwartet!
================================================
FILE: content/de/guide/v8/progressive-web-apps.md
================================================
---
title: Progressive Web Apps
---
# Progressive Web Apps
Preact ist eine ausgezeichnete Wahl für [progressive Web Apps](https://web.dev/learn/pwa/), für die schnelles Laden und rasche Interaktivitätsmöglichkeiten erwünscht sind. [Preact CLI](https://github.com/preactjs/preact-cli) kodifiziert dies in einem schnellen Baukastenwerkzeug, dass von Grund auf eine PWA (Progressive Web App) mit einem [Lighthouse][LH]-Score von 100 schafft.
[LH]: https://developers.google.com/web/tools/lighthouse/
<ol class="list-view">
<li class="list-item">
<div class="list-header">
<div class="_bubble" style="background-image: url(/pwa-guide/load-less-script.svg);"></div>
</div>
<div class="list-detail">
<div class="_title-block">
<h3>Weniger Skripte laden</h3>
</div>
<p class="_summary">Preact's <a href="/about/project-goals">kleine Größe</a> ist sehr wertvoll, wenn nur ein begrenztes Ladezeitenkontingent verfügbar ist. Man kann davon ausgehen, dass das Laden von großen JavaScript-Bibliotheken mit mobilen Endgeräten immense Wartezeiten bis zur Benutzbarkeit der Applikation führen kann. Das Laden, Evaluieren und Berechnen der Skripte ist zu ressourcenhungrig. Das Reduzieren der Größe von Bibliotheken führt automatisch zu verbesserten Ladezeiten, da folglich auch weniger Code geladen und berechnet werden muss.</p>
</div>
</li>
<li class="list-item">
<div class="list-header">
<div class="_bubble" style="background-image: url(/pwa-guide/faster-tti.svg);"></div>
</div>
<div class="list-detail">
<div class="_title-block">
<h3>Schneller zur Interaktivität</h3>
</div>
<p class="_summary"><p>Wenn man darauf abzielt, <a href="https://infrequently.org/2016/09/what-exactly-makes-something-a-progressive-web-app/">Interaktivität in unter 5 Sekunden</a> zu erreichen, zählt jeder einzelne KB. <a href="/guide/v8/switching-to-preact">Von React zu Preact zu wechseln</a> reduziert die Größe einer Applikation um einige KBs, was wiederum zu führt, dass Interaktivität innerhalb einer RTT (Paketlaufzeit) erreicht werden kann. Daher geben Preact und Progressive Web Apps ein wundervolles Paar ab, wenn man den Code für jede Route größtmöglich reduzieren möchte.</p></p>
</div>
</li>
<li class="list-item">
<div class="list-header">
<div class="_bubble" style="background-image: url(/pwa-guide/building-block.svg);"></div>
</div>
<div class="list-detail">
<div class="_title-block">
<h3> Ein Baustein, der perfekt mit Reacts Ökosystem harmoniert</h3>
</div>
<p class="_summary"><p>Wo auch immer man Reacts <a href="https://facebook.github.io/react/docs/react-dom-server.html">serverseitiges Rendern</a> einsetzen muss, um Pixel flink auf dem Bildschirm erscheinen zu lassen, oder <a href="https://github.com/ReactTraining/react-router">React Router</a> zur Navigation verwendet, lässt sich Preact wundervoll integrieren, da es gut mit einer Vielzahl von Bibliotheken des React-Ökosystem zusammenarbeitet.</p></p>
</div>
</li>
</ol>
## Diese Seite ist eine PWA
In der Tat ist genau diese Website eine Progressive Web App! Hier ist zu sehen, wie die App am Beispiel einer Trace ausgehend von einem Nexus 5X über 3G in unter 5 Sekunden interaktiv wird:
Statische Seiteninhalte werden in der (Service Worker) Cache Storage API gespeichert, die blitzschnelles Laden bei wiederholten Besuchen ermöglicht.
## Leistungstipps
Während Preact einfach in einer PWA zu integrieren ist und reibungslos funktionieren sollte, kann es auch mit einer Reihe von anderen Werkzeugen und Techniken verwendet werden. Diese beinhalten:
<ol class="list-view">
<li class="list-item">
<div class="list-header">
<div class="_bubble" style="background-image: url(/pwa-guide/code-splitting.svg);"></div>
</div>
<div class="list-detail">
<p class="_summary"><strong><a href="https://webpack.js.org/guides/code-splitting/">Code-Splitting</a></strong> teilt den Code auf, sodass man genau den Teil des Codes an den Nutzer ausliefern kann, den er für die angeforderte Seite benötigt. Den Rest der Seite bei Bedarf mithilfe von Lazy-loading aufzurufen, verbessert Ladezeiten immens. Dies wird auch über Webpack unterstützt.</p>
</div>
</li>
<li class="list-item">
<div class="list-header">
<div class="_bubble" style="background-image: url(/pwa-guide/service-worker-caching.svg);"></div>
</div>
<div class="list-detail">
<p class="_summary"><strong><a href="https://developers.google.com/web/fundamentals/getting-started/primers/service-workers">Service Worker caching</a></strong> erlaubt das vom Internet getrennte Cachen von statischen und dynamischen Ressourcen. Dies erlaubt augenblickliches Laden und schnellere Interaktivität bei wiederholtem Besuchen einer Seite. Dieses Verhalten kann mit <a href="https://github.com/GoogleChrome/sw-precache#wrappers-and-starter-kits">sw-precache</a> oder <a href="https://github.com/NekR/offline-plugin">offline-plugin</a> erreicht werden.</p>
</div>
</li>
<li class="list-item">
<div class="list-header">
<div class="_bubble" style="background-image: url(/pwa-guide/prpl.svg);"></div>
</div>
<div class="list-detail">
<p class="_summary"><strong><a href="https://developers.google.com/web/fundamentals/performance/prpl-pattern/">PRPL</a></strong> fördert das vorzeitige Pushen bzw. vorladende Elemente im Browser. Auch so wird die Ladezeit von nachfolgenden Seiten verkürzt, indem es auf Code-Splitting und SW-Caching aufbaut.</p>
</div>
</li>
<li class="list-item">
<div class="list-header">
<div class="_bubble" style="background-image: url(/pwa-guide/lighthouse.svg);"></div>
</div>
<div class="list-detail">
<p class="_summary"><strong><a href="https://github.com/GoogleChrome/lighthouse/">Lighthouse</a></strong> erlaubt es, die Leistung und Funktionalitäten einer Progressiven Web App zu testen, damit man stets darüber aufgeklärt ist, wie performant eine App wirklich ist.</p>
</div>
</li>
</ol>
## Preact CLI
[Preact CLI](https://github.com/preactjs/preact-cli/) ist das offizielle Baukastenwerkzeug für Preact-Projekte. Es besteht aus einem minimalstabhängigen Kommandozeilenwerkzeug, das eigenen Preact-Code in eine hochoptimierte Progressive Web App verpackt. Preact CLI zielt darauf ab, alle obengenannten Empfehlungen zu automatisieren, damit man sich einzig und allein auf das Erstellen von großartigen Komponenten konzentrieren kann.
Anbei einige Funktionen, die Preact CLI mitliefert:
- Automatisches, lückenloses Code-Splitting für URL-Routen
- Automatisches Generieren und Installieren eines ServiceWorkers
- Generierung von HTTP2/Push-Headern (oder Preload Meta Tags), die auf der URL basieren
- Vorzeitiges Rendern, dass zu schnellen "Time To First Paint"-Resultaten führt
- Bedingungsweises Laden von Polyfills, falls diese benötigt werden
Da [Preact CLI](https://github.com/preactjs/preact-cli/) im Inneren von [Webpack](https://webpack.js.org) angetrieben wird, kann man eine `preact.config.js`-Datei definieren und somit den Build-Prozess auf seine eigenen Anforderungen genau abstimmen. Sollte man also Anpassungen vornehmen, kann man immer noch die Vorteile einzelner wundervollen Standardeinstellungen nutzen. Außerdem kann man so einfach Aktualisierungen vornehmen, sollte eine neue Version von `preact-cli` veröffentlich werden.
================================================
FILE: content/de/guide/v8/switching-to-preact.md
================================================
---
title: Von React zu Preact wechseln
---
# (Von React) Zu Preact wechseln
Es gibt zwei verschiedene Herangehensweisen, wie man von React zu Preact wechseln kann:
1. Den `preact-compat`-Alias installieren
2. Die Importierungen nach `preact` abändern und inkompatiblen Code entfernen
---
<toc></toc>
---
## Einfach: `preact-compat`-Alias
Zu Preact wechseln ist eigentlich sehr einfach - man installiert `preact-compat` und setzt einen Alias für `preact-compat` anstatt `react` und `react-dom`.
Das ermöglicht es einem, mit dem Schreiben von React/ReactDOM-Code fortzufahren, ohne jegliche Änderungen am Workflow oder an der Codebasis vornehmen zu müssen.
`preact-compat` fügt zwar ungefähr 2kb zur Gesamtgröße des Projektes hinzu, hat allerdings den Vorteil, den Großteil von bereits existierenden React-Modulen, die man bei [npm](https://npmjs.com) finden sollte, zu unterstützen. Zusätzlich zu Preacts Kern liefert das `preact-compat`-Paket alle Änderungen, die benötigt werden, um genau wie `react` und `react-dom` zu funktionieren, in einem einzelnen Modul.
Der Installationsprozess ist in zwei Schritte unterteilt.
Zuerst muss man `preact` und `preact-compat`, zwei separate Pakete, installieren:
```bash
npm i -S preact preact-compat
```
Sind diese Dependencies installiert, muss man den Build-Prozess so abändern, dass React-Imports stattdessen auf Preact referenzieren.
### `preact-compat`-Alias setzen
Nun, da die Dependencies installiert sind, muss man den Build-Prozess so konfigurieren, dass jegliche Importierungen von `react` oder `react-dom` zu `preact-compat` weitergeleitet werden.
#### Setzen des Alias mithilfe von Webpack
Man fügt einfach die folgende [resolve.alias](https://webpack.github.io/docs/configuration.html#resolve-alias)-Konfiguration zur `webpack.config.js`-Datei hinzu:
```json
{
"resolve": {
"alias": {
"react": "preact-compat",
"react-dom": "preact-compat"
}
}
}
```
#### Setzen des Alias mithilfe von Browserify
Falls Browserify verwendet wird, können Aliase definiert werden, indem man die [aliasify](https://npmjs.com/package/aliasify)-Transformation hinzufügt. Dieses Vorgehen funktioniert wie folgt:
Man installiert zuerst die Transformation: `npm i -D aliasify`
Und weist aliasify danach in der `package.json` an, React-Importierungen an `preact-compat` weiterzuleiten:
```json
{
"aliasify": {
"aliases": {
"react": "preact-compat",
"react-dom": "preact-compat"
}
}
}
```
#### Manuelles Setzen des Alias
Falls kein Build-System verwendet wird oder aber ein permanenter Wechsel zu `preact-compat` erwünscht ist, kann man natürlich auch alle Importierungen und Voraussetzungen in der Codebasis suchen und ersetzen, genauso wie es ein Alias tun würde:
> **find:** `(['"])react(-dom)?\1`
>
> **replace:** `$1preact-compat$1`
In diesem Fall könnte es allerdings deutlich ansprechender sein, direkt zum vollen `preact`-Paket zu wechseln, anstatt auf `preact-compat` angewiesen zu sein.
Preacts Kern besitzt eine Vielzahl von Funktionen, sodass viele idiomatische React-Codebasen direkt mit minimalem Aufwand zu `preact` umgezogen werden können.
Dieser Ansatz wird im nächsten Abschnitt erläutert.
#### Setzen des Alias mithilfe von Node und module-alias
Beachtet man Small Screen Rendering-Funktionalitäten, kann man das [module-alias](https://npmjs.com/package/module-alias)-Paket zum Ersetzen von React mit Preact verwenden, sollte man keinen Bundler (wie z.B. Webpack) für den Build-Prozess des serverseitigen Codes verwenden.
```bash
npm i -S module-alias
```
`patchPreact.js`:
```js
var path = require('path')
var moduleAlias = require('module-alias')
moduleAlias.addAliases({
'react': 'preact-compat/dist/preact-compat.min',
'react-dom': 'preact-compat/dist/preact-compat.min',
'create-react-class': path.resolve(__dirname, './create-preact-class')
})
```
`create-preact-class.js`:
```js
import { createClass } from 'preact-compat/dist/preact-compat.min'
export default createClass
```
Falls die neuartige `import`-Syntax auf dem eigenen Server mit Babel verwendet wird, wird das obrige Verhalten nicht funktionieren, da Babel alle Importierungen an das obere Ende eines Moduls platziert. In diesem Fall speichert man den darüberstehenden Code in einer Datei namens `patchPreact.js` ab und importiert diese am Anfang seiner Datei (`import './patchPreact'`). Mehr über das Verwenden von `module-alias` kann man [hier](https://npmjs.com/package/module-alias) erfahren.
Es ist außerdem möglich, einen Alias direkt mithilfe von Node zu stetzen, ohne auf das `module-alias`-Paket angewiesen zu sein. Diese Methode basiert auf internen Properties von Nodes Modulsystem, daher sollte man sie mit Vorsicht genießen. Um manuell einen Alias zu setzen, sind folgende Schritte nötig:
```js
// patchPreact.js
var React = require('react')
var ReactDOM = require('react-dom')
var ReactDOMServer = require('react-dom/server')
var CreateReactClass = require('create-react-class')
var Preact = require('preact-compat/dist/preact-compat.min')
var Module = module.constructor
Module._cache[require.resolve('react')].exports = Preact
Module._cache[require.resolve('react-dom')].exports = Preact
Module._cache[require.resolve('create-react-class')].exports.default = Preact.createClass
```
### Erstellen und Testen
**Fertig!**
Wenn man nun den Build-Prozess ausführt, werden alle React-Importierungen stattdessen `preact-compat` importieren. Das Bundle wird so deutlich verkleinert.
Es ist immer eine gute Idee, die Testumgebung und die fertige App auszuführen, um zu prüfen, ob sie auch wirklich funktioniert.
---
## Optimal: Wechseln zu Preact
Die Nutzung von `preact-compat` in der eigenen Codebasis ist nicht vorausgesetzt, wenn man von React zu Preact migrieren will.
Preacts API ist fast identisch mit Reacts API. Ein Großteil der React-Codebasen kann mit winzigem bis nicht-existentem Aufwand migriert werden.
Generell involviert der Prozess des Wechselns zu Preact einige Schritte:
### 1. Preact installieren
Dieser Schritt ist vermutlich der Einfachste: man muss die Bibliothek lediglich installieren, um sie verwenden zu können!
```bash
npm install --save preact # or: npm i -S preact
```
### 2. JSX Pragma: Zu `h()` transpilieren
> **Hintergrund:** Während die [JSX]-Spracherweiterung unabhängig von React ist,
> verwenden beliebte Transpilierer wie [Babel] and [Bublé] standardmäßig eine
> Konvertierung von JSX zu `React.createElement()`-Aufrufen.
> Dafür gibt es zwar historische Gründe, es ist allerdings wichtig zu verstehen,
> dass die Funktion, die JSX-Transpilierungen aufruft, eine bereits existierende
> Technologie namens [Hyperscript] ist.
> Preact huldigt dies und versucht, für ein besseres Verständnis für die Simplizität
> von JSX mithilfe der Nutzung von `h()` als sein [JSX Pragma] zu werben.
>
> **TL;DR:** `React.createElement()` wird zugunsten von preact's `h()` ausgetauscht.
In JSX ist das "Pragma" der Name einer Funktion, die das Erstellen eines solchen Elements abwickelt:
> `<div />` transpiliert zu `h('div')`
>
> `<Foo />` transpiliert zu `h(Foo)`
>
> `<a href="/">Hallo</a>` zu `h('a', { href:'/' }, 'Hallo')`
In jedem der obengenannten Beispiele ist `h` der Funktionsname, der als JSX-Pragma deklariert wird.
#### Mithilfe von Babel
Falls Babel verwendet wird, kann man das JSX-Pragma in der `.babelrc`- oder `package.json`-Datei definiert werden. In welcher der beiden Dateien man dies tut, ist lediglich von persönlicher Präferenz abhängig:
```json
{
"plugins": [
["transform-react-jsx", { "pragma": "h" }]
]
}
```
#### Mithilfe von Kommentaren
Falls man mit einem Onlineeditor mit Babel-Integration (z.B. JSFiddle oder CodePen) arbeitet, kann man das JSX-Pragma definieren, indem man am Anfang seines Codes einen Kommentar einfügt:
`/** @jsx h */`
#### Mithilfe von Bublé
[Bublé] unterstützt JSX standardmäßig. Man muss lediglich die `jsx`-Option setzen:
`buble({ jsx: 'h' })`
### 3. Legacy Code aktualisieren
Preact strebt zwar eine vollständige API-Kompatibilität mit React an, allerdings werden kleine Teile des Interfaces absichtlich nicht integriert.
Der am ehesten erwähnbare ausgelassene Teil ist `createClass()`. Die Meinung zum Thema Klassen und OOP gehen weit auseinander, man sollte aber verstehen, dass JavaScript-Klassen intern in VDOM-Bibliotheken zum Repräsentieren von Komponententypen stehen. Dies wird wichtig, wenn man mit den Nuancen der Handhabung von Komponentenlebenszyklen arbeitet.
Falls die Codebasis schwerwiegend von `createClass()` abhängig ist, gibt es trotzdem eine großartige Option:
Laurence Dorman pflegt eine [alleinstehende `createClass()`-implementation](https://github.com/ld0rman/preact-classless-component), die nahtlos in Preact funktioniert und nur wenige hundert Bytes groß ist.
Alternativ kann man `createClass()`-Aufrufe auch automatisch mithilfe von Vu Trans [preact-codemod](https://github.com/vutran/preact-codemod) zu ES-Klassen konvertieren lassen.
Ein weiterer erwähnbarer Unterschied ist, dass Preact standardmäßig lediglich Funktionsreferenzierungen unterstützt.
Stringreferenzierungen sind in React veraltet und werden in naher Zukunft entfernt, da sie eine überraschende Menge an Komplexität für solch minimalen Nutzen hinzufügen.
Wenn man auch in Zukunft Stringreferenzierungen nutzen möchte, bietet [diese kleine Funktion](https://gist.github.com/developit/63e7a81a507c368f7fc0898076f64d8d) eine zukunftssichere Version, die `this.refs.$$` weiterhin wie Stringreferenzierungen behandelt. Die Simplizität dieses kleinen Umwegs für Funktionsreferenzierungen zeigt außerdem, warum Funktionsreferenzierungen mittlerweile die präferierte Methode darstellen.
### 4. Root Render vereinfachen
Seit React 0.13 wurde `render()` durch das `react-dom`-Modul bereitgestellt.
Preact nutzt kein separates Modul für das Rendern des DOMs, da Preact sowieso darauf konzentriert, ein guter DOM-Renderer zu sein.
Daher ist der letzte Schritt des Konvertierens der Codebasis zu Preact das Austauschen von `ReactDOM.render()` zu Preacts `render()`:
```diff
- ReactDOM.render(<App />, document.getElementById('app'));
+ render(<App />, document.body);
```
Man sollte ebenfalls anmerken, dass Preacts `render()`-Funktion nicht-destruktiv ist, daher funktioniert das Rendern nach `<body>` einwandfrei und ist sogar wünschenswert.
Dies ist möglich, da Preact nicht davon ausgeht, das komplette Root-Element zu steuern, das man an Preact weitergibt. Das zweite `render()`-Argument ist `parent`, was bedeutet, dass es ein DOM-Element ist, in das _hinein_ gerendert wird.
Falls es erwünscht ist, direkt vom Root aus neu zu rendern (möglicherweise für Hot Module Replacement), akzeptiert `render()` ein Element zum Ersetzen als drittes Argument:
```js
// initial render:
render(<App />, document.body);
// update in-place:
render(<App />, document.body, document.body.lastElementChild);
```
In dem darüberstehenden Beispiel ist man darauf angewiesen, dass das letzte Child der vorher gerenderte Root ist.
Dies funktioniert zwar in vielen Fällen (JSFiddles, CodePens, uvm.), es ist allerdings trotzdem besser, über mehr Kontrolle zu verfügen.
Deshalb gibt `render()` das Root-Element zurück: man gibt es als drittes Argument zum Neurendern weiter.
Das nachfolgende Beispiel zeigt, wie man als Antwort auf Webpacks Hot Module Replacement-Aktualisierungen neu rendert:
```js
// Root ist das Root DOM Element der App:
let root;
function init() {
root = render(<App />, document.body, root);
}
init();
// Beispiel: Neurendern bei Webpack HMR-Aktualisierung:
if (module.hot) module.hot.accept('./app', init);
```
Das komplette Verfahren kann bei [preact-boilerplate](https://github.com/developit/preact-boilerplate/blob/master/src/index.js#L6-L18) eingesehen werden.
[babel]: https://babeljs.io
[bublé]: https://buble.surge.sh
[JSX]: https://facebook.github.io/jsx/
[JSX Pragma]: http://www.jasonformat.com/wtf-is-jsx/
[preact-boilerplate]: https://github.com/developit/preact-boilerplate
[hyperscript]: https://github.com/dominictarr/hyperscript
================================================
FILE: content/de/guide/v8/types-of-components.md
================================================
---
title: Komponententypen
---
# Komponententypen
Es gibt zwei Arten von Komponenten in Preact:
- Klassische Komponenten mit [Lebenszyklusmethoden] und State
- State-lose, funktionale Komponenten, welche Funktionen sind, die `props` akzeptieren und [JSX] ausgeben.
Innerhalb dieser zwei Typen gibt es außerdem viele verschiedene Wege, Komponenten zu implementieren.
---
<toc></toc>
---
## Beispiel
Hier ein Beispiel: Eine einfache `<Link>`-Komponente, die ein ein HTML-`<a>`-Element erstellt:
```js
class Link extends Component {
render(props, state) {
return <a href={props.href}>{ props.children }</a>;
}
}
```
Die Komponente kann wie folgt instanziert/gerendert werden:
```xml
<Link href="http://example.com">Irgendein Text</Link>
```
### Props & State destrukturieren
Da dies in ES6/ES2015 lebt, kann man die `<Link>`-Komponente weiter vereinfachen, indem man Schlüssel von `props` (das erste `render()`-Argument) lokalen Variablen mithilfe von [destructuring](https://github.com/lukehoban/es6features#destructuring) zuweist:
```js
class Link extends Component {
render({ href, children }) {
return <a {...{ href, children }} />;
}
}
```
Falls man _alle_ `props` der `<Link>`-Komponente in ein `<a>`-Element kopieren möchte, kann man den [spread operator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator) verwenden:
```js
class Link extends Component {
render(props) {
return <a {...props} />;
}
}
```
### State-lose funktionale Komponenten
Zu guter Letzt kann man sehen, dass diese Komponente keinen State hat. Man kann die Komponente mit den selben props rendern und bekommt jedes Mal das gleiche Resultat. Wenn dies der Fall ist, ist die Nutzung von State-losen funktionalen Komponenten empfohlen. Diese sind lediglich Funktionen, die `props` als Argumente annehmen und JSX ausgeben.
```js
const Link = ({ children, ...props }) => (
<a {...props}>{ children }</a>
);
```
> *ES2015-Anmerkung:* Das oben genannte ist eine Arrow-Funktion. Da Parens, oder auch ()-Klammern, statt Braces, oder auch {}-Klammern, für den Funktionskörper verwendet wurden, wird der Wert innerhalb der Parens automatisch zurückgegeben. [Hier](https://github.com/likehoban/es6features#arrow) kann man mehr darüber erfahren.
================================================
FILE: content/de/guide/v8/unit-testing-with-enzyme.md
================================================
---
title: Unit-Prüfung mit Enzyme
---
# Unit-Prüfung mit Enzyme
React bietet ein `react-addons-test-utils`-Modul zum Testen von Komponenten an. Airbnbs `enzyme` geht tiefer auf dieses Konzept ein - es vereinigt mehrere Rendermodi und andere nützliche Funktionen. Das Testen von Preact-Komponenten mithilfe von `enzyme` ist dank dem `preact-compat-enzyme`-Modul möglich. Dieses implementiert die benötigten internen React-Properties auf `preact-compat` drauf.
---
<toc></toc>
---
## Installation
Wir benötigen zwei Module:
- `preact-compat-enzyme`: Um weitere interne React-Properties bereitzustellen.
- `preact-test-utils`: Um Teile der `react-addons-test-utils`-API, die von `enzyme` genutzt werden, bereitzustellen.
```bash
npm install --save-dev preact-compat-enzyme preact-test-utils
```
## Konfiguration
Karma wird als Testeinheit benutzt. Man muss einige [`Webpack-Aliase`](https://github.com/webpack-contrib/karma-webpack#usage) für React und einige andere Module hinzufügen:
```json
{
"resolve": {
"alias": {
"react-dom/server": "preact-render-to-string",
"react-addons-test-utils": "preact-test-utils",
"react": "preact-compat-enzyme",
"react-dom": "preact-compat-enzyme"
}
}
}
```
## Aktuelle Limitationen
1. Momentan wird lediglich der [`mount`](http://airbnb.io/enzyme/docs/api/mount.html) Modus unterstützt.
2. Man muss eventuell Aussagen in `setTimeout` verpacken, wenn `React Wrapper`s `setProps()` und `serState()`-Methoden aufgerufen werden.
## Beispiel
```js
let dataSource = [{ id: '1', name: 'test-content' }, { id: '2', name: 'test-content' }],
table,
wrapper;
beforeEach(() => {
table = <Table dataSource={dataSource}>
<Table.Column dataIndex='id' />
<Table.Column dataIndex='name' />
</Table>
wrapper = mount(table);
})
afterEach(() => {
table = null;
})
it('should render checkboxMode', (done) => {
wrapper.setProps({
rowSelection: {
getProps: (record) => {
if (record.id === '1') {
return {
disabled: true
}
}
}
}
});
setTimeout(() => {
expect(wrapper.find('.checkbox').length).to.be.equal(3);
expect(wrapper.find('.checkbox.disabled').length).to.be.equal(1);
done();
}, 10);
});
```
================================================
FILE: content/de/index.md
================================================
---
title: Preact
---
<jumbotron>
<h1>
<logo height="1.5em" title="Preact" text="true" inverted="true">Preact</logo>
</h1>
<p class="tagline">Schnelle 3kB-Alternative zu React mit der gleichen ES6-API</p>
<p class="intro-buttons">
<a href="/guide/v10/getting-started" class="btn primary">Fang an</a>
<a href="/guide/v10/getting-started#aliasing-react-to-preact" class="btn secondary">Wechsle zu Preact</a>
</p>
</jumbotron>
```jsx
function Counter() {
const [value, setValue] = useState(0);
return (
<>
<div>Counter: {value}</div>
<button onClick={() => setValue(value + 1)}>Increment</button>
<button onClick={() => setValue(value - 1)}>Decrement</button>
</>
)
}
```
<div class="sponsors">
<p><a href="https://opencollective.com/preact">Gesponsort von:</a></p>
<sponsors></sponsors>
</div>
<section class="home-top">
<h2>Eine Bibliothek der anderen Art</h2>
</section>
<section class="home-section">
<img src="/home/metal.svg" alt="metal" loading="lazy" decoding="async" width="54" height="54">
<div>
<h3>Näher am Geschehen</h3>
<p>
Preact bietet die kleinstmögliche Virtual DOM Abstraktion auf dem DOM.
Das Web ist eine stabile Plattform und es ist an der Zeit, dass wir es im Namen der Sicherheit neu implementieren.
</p>
<p>
Preact ist außerdem ein Vorzeigemitglied der Web-Plattform. Es differenziert Virtual DOM gegen das DOM selbst, registriert reale Event-Handler und funktioniert Hand in Hand mit anderen Bibliotheken.
</p>
</div>
</section>
<section class="home-section">
<img src="/home/size.svg" alt="größe" loading="lazy" decoding="async" width="54" height="54">
<div>
<h3>Kleine Größe</h3>
<p>
Die meisten UI-Frameworks sind so riesig, dass sie den Großteil einer JavaScript-App ausmachen.
Mit Preact ist das anders: Es ist winzig genug, damit <em>eigener Code</em> den Großteil der Application ausmacht.
</p>
<p>
Dies bedeutet weniger JavaScript zum herunterladen, analysieren und ausführen - das Resultat ist mehr Zeit für den eigenen Code, sodass eine selbstbestimmte Erfahrung ohne den Kampf ein Framework unter Kontrolle zu halten, möglich ist.
</p>
</div>
</section>
<section class="home-section">
<img src="/home/performance.svg" alt="leistung" loading="lazy" decoding="async" width="54" height="54">
<div>
<h3>Große Leistung</h3>
<p>
Preact ist schnell, was nicht nur an seiner Größe liegt. Dank einer simplen und vorhersehbaren Differenzierungsimplementation ist es eine der schnellsten Virtual DOM-Bibliotheken überhaupt.
</p>
<p>
Preact batched automatisch updates und ist stark auf Performance getuned. Wir arbeiten direkt mit Entwicklern von Browsern zusammen und die maximalste Performance aus Preact heraus zu holen.
</p>
</div>
</section>
<section class="home-section">
<img src="/home/portable.svg" alt="portabel" loading="lazy" decoding="async" width="54" height="54">
<div>
<h3>Portabel & Einbettbar</h3>
<p>
Preacts winziger Fußabdruck ermöglicht dem ressourcenreichen Virtual DOM-Komponentenparadigma Dinge, von dem es sonst nur träumen könnte.
</p>
<p>
Verwende Preact, um Teile einer App ohne komplizierte Integration zu erstellen. Bette Preact in einem Widget ein und wende die selben Werkzeuge und Techniken an, die man normalerweise in einer vollständigen App verwenden würde.
</p>
</div>
</section>
<section class="home-section">
<img src="/home/productive.svg" alt="produktiv" loading="lazy" decoding="async" width="54" height="54">
<div>
<h3>Sofort produktiv</h3>
<p>
Leichtigkeit ist deutlich spaßiger, wenn man dafür Produktivität nicht einbüßen muss. Preacts macht dich von Anfang an produktiv! Es hat sogar einige Bonusfunktionen:
</p>
<ul>
<li>`props`, `state` und `context` werden zu `render()` weitergegeben</li>
<li>Standard HTML-Attribute (z.B. `class` und `for`) können verwendet werden</li>
</ul>
</div>
</section>
<section class="home-section">
<img src="/home/compatible.svg" alt="kompatibel" loading="lazy" decoding="async" width="54" height="54">
<div>
<h3>Ökosystem-kompatibel</h3>
<p>
Virtual DOM-Komponenten machen es einfach, Dinge wieder zu verwenden - alles vom Knopf bis hin zu Datenquellen.
Preacts Gestaltung lässt dich tausende Komponenten, die bereits im React-Ökosystem verfügbar sind, verwenden.
</p>
<p>
Das Hinzufügen eines einfachen <a href="/guide/v10/getting-started#aliasing-react-to-preact">preact-compat</a>-Alias zum Bundler fügt eine Kompatibilitätsschicht hinzu, die es erlaubt, selbst die komplexesten React-Komponenten in der eigenen Preact-App zu verwenden.
</p>
</div>
</section>
<section class="home-top">
<h2>Erlebe es in freier Wildbahn!</h2>
</section>
<section class="home-split">
<div>
<h3>To Do-Listen-Komponente</h3>
<pre><code class="language-jsx">
// --repl
import { Component, render } from "preact";
// --repl-before
export default class TodoList extends Component {
state = { todos: [], text: "" };<br>
setText = (e) => {
this.setState({ text: e.currentTarget.value });
};<br>
addTodo = () => {
let { todos, text } = this.state;
todos = todos.concat({ text });
this.setState({ todos, text: "" });
};<br>
render({}, { todos, text }) {
return (
<form onSubmit={this.addTodo} action="javascript:">
<label>
<span>Add Todo</span>
<input value={text} onInput={this.setText} />
</label>
<button type="submit">Add</button>
<ul>
{todos.map((todo) => (
<li>{todo.text}</li>
))}
</ul>
</form>
);
}
}
// --repl-after
render(<TodoList />, document.getElementById("app"));
</code></pre>
</div>
<div>
<h3>Laufendes Beispiel</h3>
<pre repl="false"><code class="language-jsx">
import TodoList from './todo-list';<br>
render(<TodoList />, document.body);
</code></pre>
<div class="home-demo">
<todo-list></todo-list>
</div>
</div>
</section>
<section class="home-split">
<div>
<h3>Zeige GitHub-Stars</h3>
<pre><code class="language-jsx">
// --repl
import { render } from "preact";
import { useState, useEffect } from "preact/hooks";
// --repl-before
const compare = (a, b) =>
(a.stargazers_count < b.stargazers_count ? 1 : -1);<br>
export default function GitHubRepos({ org }) {
const [items, setItems] = useState([]);<br>
useEffect(() => {
fetch(`https://api.github.com/orgs/${org}/repos`)
.then((res) => res.json())
.then((repos) =>
setItems(repos.sort(compare).slice(0, 5))
);
}, []);<br>
return (
<div>
<h1 class="repo-list-header">
Preact Repositories
</h1>
<div>
{items.map((result) => (
<Result {...result} />
))}
</div>
</div>
);
}<br>
function Result(result) {
return (
<div class="repo-list-item">
<div>
<a
href={result.html_url}
target="_blank"
rel="noopener noreferrer"
>
{result.full_name}
</a>
{" - "}
<strong>
⭐️{result.stargazers_count.toLocaleString()}
</strong>
</div>
<p>{result.description}</p>
</div>
);
}
// --repl-after
render(<GitHubRepos org="preactjs" />, document.getElementById("app"));
</code></pre>
</div>
<div>
<h3>Laufendes Beispiel</h3>
<pre repl="false"><code class="language-jsx">
import GitHubRepos from './github-repos';<br>
render(
<GitHubRepos org="preactjs" />,
document.body
);
</code></pre>
<div class="home-demo">
<github-repos org="preactjs"></github-repos>
</div>
</div>
</section>
<section class="home-top">
<h2>Bereit einzutauchen?</h2>
</section>
<section style="text-align:center;">
<p>
Wir haben verschiedene Anleitungen basierend auf deinem React-Kenntnisstand.
<br>
Wähle die Anleitung aus, die für dich am besten geeignet ist!
</p>
<p>
<a href="/guide/v10/getting-started" class="btn primary">Fang an</a>
<a href="/guide/v10/getting-started#aliasing-react-to-preact" class="btn secondary">Wechsle zu Preact</a>
</p>
</section>
================================================
FILE: content/en/404.md
================================================
---
title: Not Found
---
# Error
Yikes, looks like that page vanished.
Time to head [Home](/).
================================================
FILE: content/en/about/browser-support.md
================================================
---
title: Browser Support
description: Preact supports all modern browsers (Chrome, Firefox, Safari, Edge) out of the box
---
# Browser Support
Preact 11.x supports the following browsers out of the box with no additional polyfills needed:
- Chrome >= 40
- Safari >= 9
- Firefox >= 36
- Edge >= 12
If you need to support older browsers, you can use polyfills or stick to Preact 10.x which supports back to IE11.
================================================
FILE: content/en/about/demos-examples.md
================================================
---
title: Demos & Examples
description: Collection of demos and example Preact applications
---
# Demos & Examples
This pages lists a bunch of demos and examples you can use to learn Preact.
> :information_desk_person: _Built one of your own?
> [Add it!](https://github.com/preactjs/preact-www/blob/master/content/en/about/demos-examples.md)_
## Full Apps
**[Preact Website (preactjs.com)](https://preactjs.com)**<br>
Of course this website is built with Preact.<br>
[GitHub Project](https://github.com/preactjs/preact-www)
**[ESBench](http://esbench.com)** :alarm_clock:<br>
Built with Preact & Material Design Lite.
**[GuriVR](https://gurivr.com)** :eyeglasses:<br>
Natural language based Web VR story creator.<br>
[GitHub Project](https://github.com/opennewslabs/guri-vr)
**[BigWebQuiz](https://bigwebquiz.com)** :game_die:<br>
The audience participation Progressive Web App from Chrome Dev Summit 2016!<br>
[GitHub Project](https://github.com/jakearchibald/big-web-quiz)
**[Nectarine.rocks](http://nectarine.rocks)** :peach:<br>
Open-Source peach.cool app.<br>
[GitHub Project](https://github.com/developit/nectarine)
**[Web Maker](https://webmaker.app/)** :zap:<br>
Blazing fast & offline frontend playground.<br>
[GitHub Project](https://github.com/chinchang/web-maker)
**[BitMidi](https://bitmidi.com/)** :musical_keyboard:<br>
Wayback machine for free MIDI files<br>
[GitHub Project](https://github.com/feross/bitmidi.com)
**[BBC Roasting Calculator](https://www.bbc.com/food/techniques/articles/roast-calculator)** :turkey:<br>
Calculates cooking times for different cuts of meat.
**[Dropfox](https://github.com/developit/dropfox)** :wolf:<br>
Desktop app for Dropbox, built with Preact, Electron and Photon.
**[Embed Hacker News](https://github.com/TXTPEN/hn)** :kissing_closed_eyes:<br>
Embed Hacker News comment tree below your blog article.
**[Connectivity Index](https://cindex.co)** :iphone:<br>
A site that allows you to search through [Akamai State of the Internet Connectivity Report](https://content.akamai.com/PG7010-Q2-2016-SOTI-Connectivity-Report.html) data by country.
**[Drag & Drop file upload (webpack 2)](https://contentful-labs.github.io/file-upload-example/)** :rocket:<br>
Desktop App for uploading assets to Contentful (API based CMS)<br>
[GitHub Project](https://github.com/contentful-labs/file-upload-example)
**[Exchange Widget](https://sgtpep.github.io/exchange-widget/dist/)** :currency_exchange:<br>
The currency exchange widget inspired by a popular mobile app implemented using Preact, Meiosis, HTML tagged templates and native ES modules.<br>
[GitHub Project](https://github.com/sgtpep/exchange-widget)
**[Blaze](https://blaze.now.sh)** :zap:<br>
Modern peer-to-peer file sharing Progressive Web App.<br>
[GitHub Project](https://github.com/blenderskool/blaze)
**[1tuner](https://1tuner.com)** :radio:<br>
Listen to radio and podcasts.<br>
[GitHub Project](https://github.com/robinbakker/1tuner)
**[ColoGuessr](https://cologuessr.com)** :rainbow:<br>
Test how well you know your colors<br>
[GitHub Project](https://github.com/jackpordi/cologuessr)
## Full Demos & Examples
**[Documentation Viewer](https://documentation-viewer.firebaseapp.com)**<br>
View documentation.js output online.<br>
[GitHub Project](https://github.com/developit/documentation-viewer)
**[TodoMVC](http://developit.github.io/preact-todomvc/)**<br>
Unofficial fastest TodoMVC implementation.<br>
[GitHub Project](https://github.com/developit/preact-todomvc)
**[TodoMVC+PouchDB](http://katopz.github.io/preact-todomvc-pouchdb/)** :floppy_disk:<br>
Offline Sync TodoMVC with [PouchDB](https://pouchdb.com/).<br>
[GitHub Project](https://github.com/katopz/preact-todomvc-pouchdb)
**[Hacker News Minimal](https://developit.github.io/hn_minimal/)** :newspaper:<br>
Tiny hacker news client.<br>
[GitHub Project](https://github.com/developit/hn_minimal)
**[Preact Boilerplate](https://preact-boilerplate.surge.sh)** :zap:<br>
2 command starter project. Preact + Webpack + LESS + CSS Modules.<br>
[GitHub Project](https://github.com/developit/preact-boilerplate)
**[Preact Offline Starter](https://preact-starter.now.sh)** :100:<br>
Simplified Webpack2 starter for Progressive Web Apps, with offline support.<br>
[GitHub Project](https://github.com/lukeed/preact-starter)
**[Preact Redux Example](https://preact-redux-example.surge.sh)** :repeat:<br>
Preact + Redux example project, implementing a simple To-Do list.<br>
[GitHub Project](https://github.com/developit/preact-redux-example)
**[Preact Without Babel](https://github.com/developit/preact-without-babel)** :horse:<br>
How to use Preact entirely without Babel, ES2015 or JSX.
**[preact-minimal](https://github.com/aganglada/preact-minimal)** :rocket:<br>
Minimal Preact structure with all the necessary tools to start your project right away.
**[preact-typescript-webpack4-less](https://github.com/lexey111/preact-typescript-webpack4-boilerplate)**<br>
Another one minimal set with Preact, Typescript and Webpack 4.
**[Preact Homepage Generator](https://thomaswood.me/)** :globe_with_meridians:<br>
Quickly spin up a new personal webpage by only needing to modify JSON data.<br>
[GitHub Project](https://github.com/tomasswood/preact-homepage-generator)
**[Parcel + Preact + Unistore Starter](https://github.com/hwclass/parcel-preact-unistore-starter)**<br>
Starter pack for lightning-fast prototyping and small/medium size project structure
**[buildless-preact-starter](https://github.com/ttntm/buildless-preact-starter)** :rocket:<br>
A starter/template for using Preact in buildless environments
## Codepens
- [Flickr Browser](http://codepen.io/developit/full/VvMZwK/) _(@ CodePen)_
- [Animating Text](http://codepen.io/developit/full/LpNOdm/) _(@ CodePen)_
- [60FPS Rainbow Spiral](http://codepen.io/developit/full/xGoagz/) _(@ CodePen)_
- [Simple Clock](http://jsfiddle.net/developit/u9m5x0L7/embedded/result,js/) _(@ JSFiddle)_
- [3D + ThreeJS](http://codepen.io/developit/pen/PPMNjd?editors=0010) _(@ CodePen)_
- [Endless Horse](https://codepen.io/youkwhd/pen/zYbjepj) _(@ CodePen)_
## Templates
:zap: **[JSFiddle Template](https://jsfiddle.net/developit/rs6zrh5f/embedded/result/)**
:zap: **[CodePen Template](http://codepen.io/developit/pen/pgaROe?editors=0010)**
================================================
FILE: content/en/about/libraries-addons.md
================================================
---
title: Libraries & Add-ons
description: Collection of libraries and addons that work well with Preact
---
# Libraries & Add-ons
A collection of modules built to work wonderfully with Preact.
> :information_desk_person: _Built one of your own?
> [Add it!](https://github.com/preactjs/preact-www/blob/master/content/en/about/libraries-addons.md)_
## Add-Ons
- :repeat: **[preact-cycle](https://github.com/developit/preact-cycle)**: Functional-reactive paradigm for Preact
- :page_facing_up: **[preact-render-to-string](https://github.com/preactjs/preact-render-to-string)**: Universal rendering.
- :timer_clock: **[relaks](https://github.com/trambarhq/relaks)**: Create components with render methods that return asynchronously.
- :nut_and_bolt: **[express-preact-views](https://github.com/edwjusti/express-preact-views)**: Express View Engine.
- :floppy_disk: **[Prefresh](https://github.com/JoviDeCroock/prefresh)**: Fast-Refresh for Preact.
- :bookmark_tabs: **[adonis-preact](https://github.com/DonsWayo/adonis-preact)**: Use Preact in Adonisjs
## Components
- :earth_americas: **[preact-router](https://github.com/preactjs/preact-router)**: URL routing for your components
- :bookmark_tabs: **[preact-markup](https://github.com/developit/preact-markup)**: Render HTML & Custom Elements as JSX & Components
- :satellite: **[preact-portal](https://github.com/developit/preact-portal)**: Render Preact components into (a) SPACE :milky_way:
- :pencil: **[preact-richtextarea](https://github.com/developit/preact-richtextarea)**: Simple HTML editor component
- :bookmark: **[preact-token-input](https://github.com/developit/preact-token-input)**: Text field that tokenizes input, for things like tags
- :card_index: **[preact-virtual-list](https://github.com/developit/preact-virtual-list)**: Easily render lists with millions of rows ([demo](https://jsfiddle.net/developit/qqan9pdo/))
- :triangular_ruler: **[preact-layout](https://download.github.io/preact-layout/)**: Small and simple layout library
- :construction_worker: **[preact-helmet](https://github.com/download/preact-helmet)**: A document head manager for Preact
- :arrow_up_down: **[preact-custom-scrollbars](https://github.com/lucafalasco/preact-custom-scrollbars)**: Fully customizable scrollbars, for frictionless native browser scrolling
- 🧱 **[@formisch/preact](https://formisch.dev/preact/guides/introduction/)**: A form library with focus on performance, type safety and bundle size
## Integrations
- :thought_balloon: **[preact-socrates](https://github.com/matthewmueller/preact-socrates)**: Preact plugin for [Socrates](http://github.com/matthewmueller/socrates)
- :rowboat: **[preact-flyd](https://github.com/xialvjun/preact-flyd)**: Use [flyd](https://github.com/paldepind/flyd) FRP streams in Preact + JSX
- :speech_balloon: **[preact-i18nline](https://github.com/download/preact-i18nline)**: Integrates the ecosystem around [i18n-js](https://github.com/everydayhero/i18n-js) with Preact via [i18nline](https://github.com/download/i18nline).
- :diamond_shape_with_a_dot_inside: **[Capacitor](https://capacitorjs.com/solution/preact)**: Turn your Preact app into a Native iOS/Android App and PWA.
- :ice_cube: **[Kretes](https://kretes.dev/docs/howtos/preact-setup/)**: Build full-stack TypeScript apps using Preact and Node.js
- 🏝: **[preact-island](https://github.com/mwood23/preact-island)**: Run your Preact widget on any website with reactive props.
- 🧩 **[ziko-wrapper](https://github.com/zakarialaoui10/ziko-wrapper)**: Wrap your [zikojs](https://github.com/zakarialaoui10/zikojs) components inside a Preact app — and vice versa.
- 💤 **[zikofy](https://github.com/zakarialaoui10/zikofy)**: Turns Preact components into Zikojs `UIElement`.
## GUI Toolkits
- 🎴 **[@mui/material](https://github.com/mui/material-ui/tree/master/examples/material-ui-preact)**: the React UI library you always wanted. Follow your own design system, or start with Material Design.
- :thumbsup: **[preact-material-components](https://github.com/prateekbh/preact-material-components)**: Material Components for the Web (supersedes MDL)
- :white_square_button: **[preact-mdl](https://github.com/developit/preact-mdl)**: Use [MDL](https://getmdl.io) as Preact components
- :rocket: **[preact-photon](https://github.com/developit/preact-photon)**: build beautiful desktop UI with [photon](http://photonkit.com)
- :penguin: **[preact-weui](https://github.com/afeiship/preact-weui)**: [Weui](https://github.com/afeiship/preact-weui) for Preact
- 💅 **[preact-fluid](https://github.com/ajainvivek/preact-fluid)**: [Fluid](https://github.com/ajainvivek/preact-fluid) minimal UI kit for Preact
- :book: **[storybook-preact](https://github.com/storybooks/storybook/tree/next/app/preact)**: Storybook for Preact is a UI development environment for your Preact components
### Testing
- :microscope: **[preact-jsx-chai](https://github.com/developit/preact-jsx-chai)**: JSX assertion testing _(no DOM, right in Node)_
- :white_check_mark: **[unexpected-preact](https://github.com/bruderstein/unexpected-preact)**: JSX assertions, events, snapshots in Jest _(DOM, works under Node jsdom or out-of-the-box in Jest)_ - [docs](https://bruderstein.github.io/unexpected-preact/)
## Utilities
- :tophat: **[preact-classless-component](https://github.com/ld0rman/preact-classless-component)**: create preact components without the class keyword
- :hammer: **[preact-hyperscript](https://github.com/queckezz/preact-hyperscript)**: Hyperscript-like syntax for creating elements
- :white_check_mark: **[shallow-compare](https://github.com/tkh44/shallow-compare)**: simplified `shouldComponentUpdate` helper.
- :signal_strength: **[@deepsignal/preact](https://github.com/EthanStandel/deepsignal/tree/main/packages/preact)**: Extension of `@preact/signals` for full state management
================================================
FILE: content/en/about/project-goals.md
================================================
---
title: Project Goals
description: Read more about Preact's project goals
---
# Preact's Goals
## Goals
Preact aims to deliver on a few key goals:
- **Performance:** Render quickly & efficiently
- **Size:** Small size, lightweight _(approximately 3.5 kB)_
- **Efficiency:** Effective memory usage _(avoiding GC thrash)_
- **Understandability:** Understanding the codebase should take no more than a few hours
- **Compatibility:** Preact aims to be _largely compatible_ with the React API. [preact/compat] attempts to achieve as much compatibility with React as possible.
## Non-Goals
Some React features are intentionally omitted from Preact, either because they are not achievable while meeting the primary project goals listed above or because they don't fit within the scope of Preact's core set of functionality.
The intentional items under [Differences to React](/guide/v10/differences-to-react):
- `PropTypes`, which are easily used as a separate library
- `Children`, can be replaced with native arrays
- `Synthetic Events`, since Preact does not attempt to patch issues in older browsers like IE8
[preact/compat]: /guide/v10/getting-started#aliasing-react-to-preact
================================================
FILE: content/en/about/we-are-using.md
================================================
---
title: Who's using Preact?
description: Companies who are proudly using Preact
---
# Who's using Preact?
Preact is used by a wide spectrum of websites, from Open Source projects to large multinational corporations.
Below is a small sampling of organizations that depend on Preact for public-facing projects.
Does your company use Preact? [Add it to the list!](https://github.com/preactjs/preact-www/blob/master/src/components/we-are-using/index.jsx)
<div class="breaker">
<we-are-using></we-are-using>
</div>
================================================
FILE: content/en/blog/introducing-signals.md
================================================
---
title: Introducing Signals
date: 2022-09-06
authors:
- Marvin Hagemeister
- Jason Miller
---
# Introducing Signals
Signals are a way of expressing state that ensure apps stay fast regardless of how complex they get. Signals are based on reactive principles and provide excellent developer ergonomics, with a unique implementation optimized for Virtual DOM.
At its core, a signal is an object with a `.value` property that holds some value. Accessing a signal's value property from within a component automatically updates that component when the value of that signal changes.
In addition to being straightforward and easy to write, this also ensures state updates stay fast regardless of how many components your app has. Signals are fast by default, automatically optimizing updates behind the scenes for you.
```jsx
// --repl
import { render } from 'preact';
// --repl-before
import { signal, computed } from '@preact/signals';
const count = signal(0);
const double = computed(() => count.value * 2);
function Counter() {
return (
<button onClick={() => count.value++}>
{count} x 2 = {double}
</button>
);
}
// --repl-after
render(<Counter />, document.getElementById('app'));
```
Signals can be used inside or outside of components, unlike hooks. Signals also work great alongside both hooks **_and_** class components, so you can introduce them at your own pace and bring your existing knowledge with you. Try them out in a few components and gradually adopt them over time.
Oh and by the way, we are staying true to our roots of bringing you the smallest libraries possible. Using signals in Preact adds just **1.6kB** to your bundle size.
If you want to jump right in, head over to our [documentation](/guide/v10/signals) to learn more in depth about signals.
## Which problems are solved by signals?
Over the past years we’ve worked on a wide spectrum of apps and teams, ranging from small startups to monoliths with hundreds of developers committing at the same time. During this time everyone on the core team has noticed recurring problems with the way application state is managed.
Fantastic solutions have been created that work to address these problems, but even the best solutions still require manual integration into the framework. As a result we’ve seen hesitance from developers in adopting these solutions, instead preferring to build using framework-provided state primitives.
We built Signals to be a compelling solution that combines optimal performance and developer ergonomics with seamless framework integration.
## The global state struggle
Application state usually starts out small and simple, perhaps a few simple `useState` hooks. As an app grows and more components need to access the same piece of state, that state is eventually lifted up to a common ancestor component. This pattern repeats multiple times until the majority of state ends up living close to the root of the component tree.
This scenario poses a challenge for traditional Virtual DOM based frameworks, which must update the entire tree affected by a state invalidation. In essence, rendering performance is a function of the number of components in that tree. We can work around this by memoizing parts of the component tree using `memo` or `useMemo` so that the framework receives the same objects. When nothing has changed, this lets the framework skip rendering some parts of the tree.
Whilst this sounds reasonable in theory, the reality is often a lot messier. In practice, as codebases grow it becomes difficult to determine where these optimizations should be placed. Frequently, even well-intentioned memoization is rendered ineffective by unstable dependency values. Since hooks have no explicit dependency tree that can be analyzed, tooling can't help developers diagnose **_why_** dependencies are unstable.
## Context chaos
Another common workaround teams reach for state sharing is to place state into context. This allows short-circuiting rendering by potentially skipping render for components between the context provider and consumers. There is a catch though: only the value passed to the context provider can be updated, and only as a whole. Updating a property on an object exposed via context does not update consumers of that context - granular updates aren’t possible. The available options for dealing with this are to split state into multiple contexts, or over invalidate the context object by cloning it when any of its properties change.
Moving values into context seems like a worthwhile tradeoff at first, but the downsides of increasing component tree size just to share values eventually become a problem. Business logic inevitably ends up depending on multiple context values, which can force it to be implemented at a specific location in the tree. Adding a component that subscribes to context in the middle of the tree is costly, as it reduces the number of components that can be skipped when updating context. What’s more, any components beneath the subscriber must now be rendered again. The only solution to this problem is heavy use of memoization, which brings us back to the problems inherent to memoization.
## In search of a better way to manage state
We went back to the drawing board in search of a next generation state primitive. We wanted to create something that simultaneously addressed the problems in current solutions. Manual framework integration, over-reliance on memoization, suboptimal use of context, and lack of programmatic observability felt backwards.
Developers need to "opt in" to performance with these strategies. What if we could reverse that and provide a system that was **fast by default**, making best-case performance something you have to work to opt out of?
Our answer to these questions is Signals. It’s a system that is fast by default without requiring memoization or tricks throughout your app. Signals provide the benefits of fine-grained state updates regardless of whether that state is global, passed via props or context, or local to a component.
## Signals to the future
The main idea behind signals is that instead of passing a value directly through the component tree, we pass a signal object containing the value (similar to a `ref`). When a signal's value changes, the signal itself stays the same. As a result, signals can be updated without re-rendering the components they've been passed through, since components see the signal and not its value. This lets us skip all of the expensive work of rendering components and jump immediately to the specific components in the tree that actually access the signal's value.
We’re exploiting the fact that an application's state graph is generally much shallower than its component tree. This leads to faster rendering, because far less work is required to update the state graph compared to the component tree. This difference is most apparent when measured in the browser - the screenshot below shows a DevTools Profiler trace for the same app measured twice: once using hooks as the state primitive and a second time using signals:
The signals version vastly outperforms the update mechanism of any traditional Virtual DOM based framework. In some apps we've tested, signals are so much faster that it becomes difficult to find them in the flamegraph at all.
Signals flip the performance pitch around: instead of opting-in to performance via memoization or selectors, signals are fast by default. With signals, performance is opt-out (by not using signals).
To achieve this level of performance, signals were built on these key principles:
- **Lazy by default:** Only signals that are currently used somewhere are observed and updated - disconnected signals don't affect performance.
- **Optimal updates:** If a signal's value hasn't changed, components and effects that use that signal's value won't be updated, even if the signal's dependencies have changed.
- **Optimal dependency tracking:** The framework tracks which signals everything depends on for you - no dependency arrays like with hooks.
- **Direct access:** Accessing a signal's value in a component automatically subscribes to updates, without the need for selectors or hooks.
These principles make signals well-suited to a broad range of use cases, even scenarios that have nothing to do with rendering user interfaces.
## Bringing signals to Preact
Having identified the right state primitive, we set about wiring it up to Preact. The thing we've always loved about hooks is that they can be used directly inside components. This is an ergonomic advantage compared to third-party state management solutions, which usually rely on "selector" functions or wrapping components in a special function to subscribe to state updates.
```js
// Selector based subscription :(
function Counter() {
const value = useSelector(state => state.count);
// ...
}
// Wrapper function based subscription :(
const counterState = new Counter();
const Counter = observe(props => {
const value = counterState.count;
// ...
});
```
Neither approach felt satisfactory to us. The selector approach requires wrapping all state access in a selector, which becomes tedious for complex or nested state. The approach of wrapping components in a function requires manual effort to wrap components, which brings with it a host of issues like missing component names and static properties.
We've had the opportunity to work closely with many developers over the past few years. One common struggle, particularly for those new to (p)react, is that concepts like selectors and wrappers are additional paradigms that must be learned before feeling productive with each state management solution.
Ideally, we wouldn't need to know about selectors or wrapper functions and could simply access state directly within components:
```jsx
// Imagine this is some global state and the whole app needs access to:
let count = 0;
function Counter() {
return <button onClick={() => count++}>value: {count}</button>;
}
```
The code is clear and it's easy to understand what is going on, but unfortunately it doesn't work. The component doesn't update when clicking the button because there is no way to know that `count` has changed.
We couldn’t get this scenario out of our heads though. What could we do to make a model this clear into a reality? We began to prototype various ideas and implementations using Preact's [pluggable renderer](/guide/v10/options). It took time, but we eventually landed on a way to make it happen:
```jsx
// --repl
import { render } from 'preact';
import { signal } from '@preact/signals';
// --repl-before
// Imagine this is some global state that the whole app needs access to:
const count = signal(0);
function Counter() {
return <button onClick={() => count.value++}>Value: {count.value}</button>;
}
// --repl-after
render(<Counter />, document.getElementById('app'));
```
There are no selectors, no wrapper functions, nothing. Accessing the signal's value is enough for the component to know that it needs to update when that signal’s value changes. After testing out the prototype in a few apps, it was clear we were onto something. Writing code this way felt intuitive and didn't require any mental gymnastics to keep things working optimally.
## Can we go even faster?
We could have stopped here and released signals as is, but this is the Preact team: we were needed to see how far we could push the Preact integration. In the Counter example above, the value of `count` is only used to display text, which really shouldn't require re-rendering a whole component. Instead of automatically re-rendering the component when the signal's value changes, what if we only re-rendered the text? Better still, what if we bypassed the Virtual DOM entirely and updated the text directly in the DOM?
```jsx
const count = signal(0);
// Instead of this:
<p>Value: {count.value}</p>
// … we can pass the signal directly into JSX:
<p>Value: {count}</p>
// … or even passing them as DOM properties:
<input value={count} onInput={...} />
```
So yeah, we did that too. You can pass a signal directly into the JSX anywhere you'd normally use a string. The signal's value will be rendered as text, and it will automatically update itself when the signal changes. This also works for props.
## Next Steps
If you’re curious and want to jump right in, head over to our [documentation](/guide/v10/signals) for signals. We’d love to hear how you're going to use them.
Remember that there is no rush to switch to signals. Hooks will continue to be supported, and they work great with signals too! We recommend gradually trying out signals, starting with a few components to get used to the concepts.
================================================
FILE: content/en/blog/preact-x.md
================================================
---
title: Preact X, a story of stability
date: 2024-05-24
authors:
- Jovi De Croock
---
# Preact X, a story of stability
A lot of you have been waiting for [Preact 11](https://github.com/preactjs/preact/issues/2621), announced in an issue opened
way back in July 2020, and to be clear I was one of the most excited people for v11.
When we started thinking about Preact 11 we believed that there was no way to introduce the changes we had in mind
in Preact X without breaking changes, some of the things we had in mind:
- Using a backing VNode structure to reduce GC, by doing this we'd only use the result of `h()` to update our backing-node.
- Reconciler performance, to allow optimized paths for mounting/unmounting/etc
- Some changes like removing `px` suffixing, `forwardRef` and breaking IE11 support.
- Keeping ref in props.
- Addressing event/child diffing bugs.
These were our initial goals for v11, but upon going down this path, we realised that many of those changes weren't actually breaking changes and could be released directly in v10 in a non-breaking way. Only the third point, removing the `px` suffix and passing `ref` directly in props as well as dropping IE11, fall into the breaking changes category. We went with releasing the other features in the stable v10 release line, which allows any Preact user to benefit from them immediately without having to change their code.
Preact has a much bigger userbase today compared to when we made the original plans for v11. It enjoys wide usage in many small to big companies for mission critical software. We really want to be sure that any breaking changes we may introduce are absolutely worth the cost of moving the whole ecosystem over to it.
As we were [experimenting](https://github.com/preactjs/preact/tree/v11) we went a new type of diffing, named
[skew based diffing](https://github.com/preactjs/preact/pull/3388), we saw real performance
improvements as well as it fixing a bunch of long-running bugs. As time went on and we invested more time in
these experiments for Preact 11, we started noticing that the improvements we were landing didn't need to be exclusive to Preact 11.
## Releases
Since the aforementioned Preact 11 issue there have been 18 (!!) minor versions of Preact X.
Many of them have been directly inspired by work done on Preact 11. Let's go over a few and look at the impact.
### 10.5.0
The introduction of [resumed hydration](https://github.com/preactjs/preact/pull/2754) -- this functionality basically allows suspending during
the re-hydration of your component tree. This means that for instance in the following component tree we'll re-hydrate and make the `Header`
interactive while the `LazyArticleHeader` suspends, in the meanwhile the server-rendered DOM will stay on screeen. When the lazy-load finishes
we'll continue re-hydrating, our `Header` and `LazyArticleHeader` can be interacted with while our `LazyContents` resolve. This is a pretty
powerful feature to make your most important stuff interactive while not overloading the bundle-size/download-size of your initial bundle.
```jsx
const App = () => {
return (
<>
<Header>
<main>
<Suspense>
<LazyArticleHeader />
<Suspense>
<article>
<LazyContents />
</article>
</Suspense>
</Suspense>
</main>
</>
)
}
```
### 10.8.0
In 10.8.0 we introduced [state settling](https://github.com/preactjs/preact/pull/3553), this would ensure that if a component updates hook-state
during render that we'd pick this up, cancel prior effects and render on. We'd of course have to ensure that this didn't loop but this feature
reduces the amount of renders that are queued up because of in-render state invocations, this feature also increased our compatibility with the
React ecosystem as a lot of libraries relied on effects not being called multiple times due to in-render state updates.
### 10.11.0
After a lot of research we found a way to introduce [useId](https://github.com/preactjs/preact/pull/3583) into Preact, this required a ton of research
of how we could go about adding unique values for a given tree-structure. One of our maintainers wrote about
[our research at the time](https://www.jovidecroock.com/blog/preact-use-id) and we've iterated on it ever since trying to make it as collision free as possible...
### 10.15.0
We found that a pass through re-render resulting in multiple new components re-rendering could result in our `rerenderQueue` being out of order, this could
result in our (context) updates propagating to components that would afterwards render _again_ with stale values, you can check out
[the commit message](https://github.com/preactjs/preact/commit/672782adbf9ccefa7a4d7c175f0adf8580f73c92) for a really detailed explanation! Doing so both
batches these updates up as well as increased our alignment for React libraries.
### 10.16.0
In our research for v11 we went deep on child diffing as we were aware that there were a few cases where our current algorithm would fall short, just listing a few
of these issues:
- [removing an element before another would cause re-insertion](https://github.com/preactjs/preact/issues/3973)
- [re-insertiosn when removing more than 1 child](https://github.com/preactjs/preact/issues/2622)
- [unnecessary unmounting of keyed nodes](https://github.com/preactjs/preact/issues/2783)
Not all of these resulted in a bad state, some just meant decreased performance... When we found out that we could port skew-based diffing to Preact X we
were thrilled, not only would we fix a lot of cases we could see how this algorithm behaves in the wild! Which in retrospect, it did great, at times I would
have wished we had good testbeds to run these on first rather than our community having to report issues. I do want to use this opportunity to thank you all
for helping us out by always filing considerate issues with reproductions, you all are the absolute best!
### 10.19.0
In 10.19.0 Marvin applied his research from [fresh](https://fresh.deno.dev/) to add [pre-compiled JSX functions](https://github.com/preactjs/preact/pull/4177),
this basically allows you to pre-compile your components during transpilation, when render-to-string is running we just have to concatenate the strings rather
than allocating memory for the whole VNode tree. The transform for this is exclusive to Deno at the moment but the general concept is present in Preact!
### 10.20.2
We have faced a number of issues where an event could bubble up to a newly inserted VNode which would result in undesired behaviour, this was fixed
[by adding an event-clock](https://github.com/preactjs/preact/pull/4322). In the following scenario, you would click the button which sets state, the browser
interleaves event bubbling with micro-ticks, which is also what Preact uses to schedule updates. This combination means that Preact will update the UI, meaning
that the `<div>` will get that `onClick` handler which we'll bubble up to and invoke the `click` again toggling this state immediately off again.
```jsx
const App = () => {
const [toggled, setToggled] = useState(false);
return toggled ? (
<div onClick={() => setToggled(false)}>
<span>clear</span>
</div>
) : (
<div>
<button onClick={() => setToggled(true)}>toggle on</button>
</div>
);
};
```
## Stability
The above are some cherry-picked releases of things that our community received _without_ breaking changes, but there is so much more... Adding a new major
version always leaves a part of the community behind and we don't want to do that. If we look at the Preact 8 release line we can see that there's still 100.000
downloads in the past week, the last 8.x release was 5 years ago, just to show that a part of the community gets left behind.
Stability is great, we as the Preact team love stability. We actually released multiple major features on other ecosystem projects:
- [Signals](https://github.com/preactjs/signals)
- [Async rendering](https://github.com/preactjs/preact-render-to-string/pull/333)
- [Streaming rendering](https://github.com/preactjs/preact-render-to-string/pull/354)
- [Prefresh](https://github.com/preactjs/prefresh)
- [The vite preset with pre-rendering](https://github.com/preactjs/preset-vite#prerendering-configuration)
- [A new async router](https://github.com/preactjs/preact-iso)
- [Create Preact](https://github.com/preactjs/create-preact)
We value our ecosystem and we value the extensions being built through our [`options API`](https://marvinh.dev/blog/preact-options/),
this is one of the main drivers behind not wanting to introduce these breaking changes but instead, allow you all to benefit
from our research without a painful migration path.
This doesn't mean that Preact 11 won't happen but it might not be the thing that we initially thought it would be. Instead, we might just drop IE11 support and give you
those performance improvements, all while giving you the stability of Preact X. There are many more ideas floating around and we're very interested in the wider Preact experience in the context of meta-frameworks that provide things like routing out of the box. We're exploring this angle in our vite preset as well as [Fresh](https://fresh.deno.dev/) to get a good feel what a Preact first meta framework should look like.
================================================
FILE: content/en/blog/prerendering-preset-vite.md
================================================
---
title: Prerendering with `@preact/preset-vite`
date: 2024-08-06
authors:
- Ryan Christian
---
# Prerendering with Preset Vite
It's been a half-year since our prerendering plugin has somewhat quietly become available in `@preact/preset-vite`, so let's talk about it, a little of our history, and the ecosystem at large.
Those who have been in our community for a while know how much we like prerendering; it was a first-class feature in Preact-CLI, then WMR, and now our Vite preset. When it's done right, it's a pain-free addition to the typical SPA that improves the user experience greatly and our prerender-plugin aims to facilitate just that.
## What is Prerendering?
"Prerendering", for the context of this post, is the act of generating HTML from your app at build time using server-side rendering (SSR); sometimes this may also be referred to as static site generation (SSG).
While we won't dive deep into the virtues of SSR here, or even argue that you should use it, it's generally advantageous to send a fully populated HTML document to the user on initial navigation (and perhaps upon subsequent navigations too, depending on routing strategy) rather than an empty shell that the client-side JS will eventually render into. Users will get access to the document quicker and can begin to use the page (albeit, often with reduced functionality) while the JS is still downloading in the background.
## Our History in the Space
Since Preact-CLI first hit public release back in May of 2017, built-in prerendering has been a mainstay in our build tooling; we happily carried it forward into WMR in 2020 and it was something that was sorely missed by us and members of the community when we switched to suggesting Vite.
While each iteration has been a little different, all have been built around the same core idea: users will more readily adopt prerendering the simpler it is to set up, including limited changes to their existing codebase. In Preact-CLI, this meant providing a default export of the root component with some JSON data to populate it; in WMR and now Vite, it means exporting a simple `prerender()` function that returns the HTML for the route, with the prerenderer walking through the app itself, replacing the need for JSON up-front.
Anyone who has worked extensively with SSR at scale knows that there is a mountain of complexity that cannot ever be fully abstracted away and we wouldn't argue otherwise. However, nearly every SPA provides a better experience if prerendered and so we want to get as many users as possible on board -- reducing the barrier to entry has shown itself to be wildly successful in our community so it's been a key part of our design philosophy to aim for as "drop-in" as possible.
## Existing Vite Ecosystem
Before we created our own prerendering implementation for our Vite preset, we had a look at the existing Vite ecosystem to see what was being offered but didn't quite find what we were after with the options. Prerendering is at its best when it is as near to "drop-in" as possible, taking your existing app, with minimal modification, and generating HTML from it, but existing solutions were a further step away from "drop-in" than we would've liked and fell into two main categories:
1. Multiple Builds
- Separate client/server builds, often separate entry points too
- Less isomorphic, different branches in your app for different environments
2. Frameworks / Vite Wrappers
- No longer using Vite directly but an abstraction
- Some amount of buy-in/lock-in
- Support matrix for different Vite config options, plugins, etc. can be complicated and less than clear
While these solutions absolutely have their merits and places in the ecosystem, neither felt as great as they could be for our ecosystem, given our historic offerings in this area. The "best case scenario" DX was often sacrificed for more complex or specific needs -- which is a completely valid trade off.
For drop-in prerendering, however, we thought we could provide something a bit different to the existing options, or at least something a bit more familiar to our users.
## Implementation in `@preact/preset-vite`
Years later, we were still quite in love with the simplicity and extensibility of WMR's prerendering and felt it was sorely missing from our Vite preset, so we looked to port it over with a few minor adjustment to fix the qualms we had. A little bit of work later and voila, prerendering via a plugin!
To get started with, here's an example of prerendering a "Hello World" app.
> Hint: Our Vite initializer, (`$ npm create preact`) can set this up for you along with a few other complimentary options, like routing, TypeScript, etc. If you're interested in trying out our prerendering, it's the fastest way to get up-to-speed.
Firstly, enable prerendering by setting `prerender: { enabled: true }` in `@preact/preset-vite`'s plugin options:
```diff
// vite.config.js
import { defineConfig } from 'vite';
import preact from '@preact/preset-vite';
// https://vitejs.dev/config/
export default defineConfig({
plugins: [
preact({
+ prerender: { enabled: true }
}),
],
});
```
...then add a `prerender` attribute to the script containing our `prerender()` function -- this lets the plugin know where to find it. While you can set this to any script you'd like, for our examples here, it'll always be in our app root.
```diff
// index.html
-<script type="module" src="/src/index.jsx"></script>
+<script prerender type="module" src="/src/index.jsx"></script>
```
...finally, make a couple adjustments to our app root:
1. Switch `render` to `hydrate`
- `hydrate` from `preact-iso` is a very small utility which decides whether to render the app or hydrate depending on if it can find existing markup on the document. In dev it'll use `render`, but in production, with prerendered HTML, it'll use `hydrate`.
- We do need to add a window check (`typeof window !== undefined`) to ensure we're not trying to access `document`, a browser global, in Node during SSR.
2. Add our `prerender()` export
- This is the facilitator of prerendering, and it's entirely user controlled. You decide how your app should be rendered, which props to pass in to your root component, make any adjustments to the HTML, run any post-processing you'd like, etc. All that the plugin needs is for an object to be returned containing an `html` property with your HTML string.
- For our examples here we'll use `prerender` from `preact-iso` which is a thin wrapper around `renderToStringAsync` from `preact-render-to-string` with one main advantage: it automatically collects and returns the relative links it finds in the pages you prerender. The prerender plugin can then use these links to "walk" your app, discovering pages itself. We'll show this off further later.
```diff
// src/index.jsx
-import { render } from 'preact';
+import { hydrate, prerender as ssr } from 'preact-iso';
function App() {
return <h1>Hello World!</h1>
}
-render(<App />, document.getElementById('app'));
+if (typeof window !== 'undefined') {
+ hydrate(<App />, document.getElementById('app'));
+}
+export async function prerender(data) {
+ return await ssr(<App {...data} />)
+}
```
With this set up, you will have an app that prerenders. However, no app is really this simple, so let's look at a couple more complex examples.
### Full API Example
```jsx
// src/index.jsx
// ...
export async function prerender(data) {
const { html, links: discoveredLinks } = ssr(<App />);
return {
html,
// Optionally add additional links that should be
// prerendered (if they haven't already been -- these will be deduped)
links: new Set([...discoveredLinks, '/foo', '/bar']),
// Optionally configure and add elements to the `<head>` of
// the prerendered HTML document
head: {
// Sets the "lang" attribute: `<html lang="en">`
lang: 'en',
// Sets the title for the current page: `<title>My cool page</title>`
title: 'My cool page',
// Sets any additional elements you want injected into the `<head>`:
// <link rel="stylesheet" href="foo.css">
// <meta property="og:title" content="Social media title">
elements: new Set([
{ type: 'link', props: { rel: 'stylesheet', href: 'foo.css' } },
{
type: 'meta',
props: { property: 'og:title', content: 'Social media title' }
}
])
}
};
}
```
### Fetch Content Isomorphically with Suspense-based Fetching
```jsx
// src/use-fetch.js
import { useState } from 'preact/hooks';
const cache = new Map();
async function load(url) {
const res = await fetch(url);
if (res.ok) return await res.text();
throw new Error(`Failed to fetch ${url}!`);
}
// Simple suspense-based fetch mechanism with caching
export function useFetch(url) {
const [_, update] = useState({});
let data = cache.get(url);
if (!data) {
data = load(url);
cache.set(url, data);
data.then(
res => update((data.res = res)),
err => update((data.err = err))
);
}
if (data.res) return data.res;
if (data.err) throw data.err;
throw data;
}
```
```jsx
// src/index.jsx
import { hydrate, prerender as ssr } from 'preact-iso';
import { useFetch } from './use-fetch.js';
function App() {
return (
<div>
<Suspense fallback={<p>Loading...</p>}>
<Article />
</Suspense>
</div>
);
}
function Article() {
const data = useFetch('/my-local-article.txt');
return <p>{data}</p>;
}
if (typeof window !== 'undefined') {
hydrate(<App />, document.getElementById('app'));
}
export async function prerender(data) {
return await ssr(<App {...data} />);
}
```
### Using `globalThis` to pass data around
```js
// src/title-util.js
import { useEffect } from 'preact/hooks';
/**
* Set `document.title` or `globalThis.title`
* @param {string} title
*/
export function useTitle(title) {
if (typeof window === 'undefined') {
globalThis.title = createTitle(title);
}
useEffect(() => {
if (title) {
document.title = createTitle(title);
}
}, [title]);
}
```
```jsx
// src/index.jsx
import {
LocationProvider,
Router,
hydrate,
prerender as ssr
} from 'preact-iso';
import { useTitle } from './title-util.js';
function App() {
return (
<LocationProvider>
<main>
<Home path="/" />
<NotFound default />
</main>
</LocationProvider>
);
}
function Home() {
useTitle('Preact - Home');
return <h1>Hello World!</h1>;
}
function NotFound() {
useTitle('Preact - 404');
return <h1>Page Not Found</h1>;
}
if (typeof window !== 'undefined') {
hydrate(<App />, document.getElementById('app'));
}
export async function prerender(data) {
const { html, links } = await ssr(<App {...data} />);
return {
html,
links,
head: {
title: globalThis.title,
elements: new Set([
{
type: 'meta',
props: { property: 'og:title', content: globalThis.title }
}
])
}
};
}
```
While less common of a need, you can also use a variation of this pattern to initialize and pass prerender data deep into your app, skipping the need for a global store/context.
```jsx
// src/some/deep/Component.jsx
function MyComponent({ myFetchData }) {
const [myData, setMyData] = useState(myFetchData || 'some-fallback');
...
}
```
```js
let initialized = false;
export async function prerender(data) {
const init = async () => {
const res = await fetch(...);
if (res.ok) globalThis.myFetchData = await res.json();
initialized = true;
}
if (!initialized) await init();
const { html, links } = await ssr(<App {...data} />);
...
}
```
---
For the curious asking "How does this all work?", it can be broken into three simple steps:
1. Setup
We set the script with your exported `prerender()` function as an additional input and tell Rollup to preserve entry signatures, allowing us to access and call that function post-build.
2. Build
We let Vite build your app as usual: compiling JSX, running plugins, optimizing assets, etc.
3. Prerender
During the `generateBundle` plugin stage, we begin to generate the HTML. Starting with `/`, we begin executing the built JS bundles in Node, calling your `prerender()` function and inserting the HTML it returns into your `index.html` document, finally writing the result to the specified output directory. Any new links your `prerender()` function returns are then queued up to be processed next.
Prerendering completes when we run out of URLs to feed back into your app.
Following this, Vite will continue to finish up the build process, running any other plugins you may have. Your prerendered app will then be available immediately, with no subsequent builds or scripts required.
### Some Neat Features
- File system-based `fetch()` implementation (as shown in the "Isomorphic Fetching" example)
- Before you run to get your pitchfork, hear us out! During prerendering (and only during prerendering) we patch `fetch()` to allow reading files directly from the file system. This allows you to consume static files (text, JSON, Markdown, etc.) during prerendering without having to start up a server to consume it. You can use the same file paths during prerendering as you will in the browser.
- In fact, that's how we build the very page you're reading! `fetch('/content/blog/preact-prerender.json')`, which is what triggers when you navigate to this page, roughly translates to `new Response(await fs.readFile('/content/blog/preact-prerender.json'))` during prerendering. We read the file, wrap it in a `Response` to mimic a network request, and supply it back to your app -- your app can use the same `fetch()` request during prerendering and on the client. - Pairing this with suspense and an async SSR implementation provides a really great DX.
- Crawling Links
- Partly supported by the user-provided `prerender()` function export, partly by the plugin, you can return a set of links upon prerendering the page (`preact-iso` makes this wonderfully simple) which will be added to the plugin's list of URLs to prerender. This will allow the plugin to crawl your site at build time, finding more and more pages to prerender naturally.
- You can also provide links manually via the plugin options or by appending some to those that `preact-iso` returns, as we show above in the Full API Example. This is especially useful for error pages, like a `/404`, that might not be linked to but you still want to have it prerendered.
...and perhaps the biggest advantage:
- Toggle it by flipping a Boolean in your config file
- Because we're not a wrapper, and because you don't need to alter your source code in order to support it (beyond some window checks), there's no lock-in whatsoever. If you decide to move away, or you want to do some testing on your output, all you need to do is flip a Boolean and you're back to a plain SPA with Vite.
- As we've mentioned a few times, prerendering is at its best when it is as near to "drop-in" as possible and that includes being able to drop back out on a whim. It's important to us that you can go from an SPA to prerendering and back again with minimal effort.
## Final Notes
The Vite team would probably like us to mention that this plugin does introduce a tiny patch to the generated client code, and that they (the Vite team) don't necessarily endorse running the browser bundles in Node.
The patch in question is as follows:
```diff
// src/node/plugins/importAnalysisBuild.ts
-if (__VITE_IS_MODERN__ && deps && deps.length > 0) {,
+if (__VITE_IS_MODERN__ && deps && deps.length > 0 && typeof window !== 'undefined') {,
const links = document.getElementsByTagName('link')
...
```
As attempting to execute `document.getElementsByTagName` will error in Node where there is no `document`, we simply add an additional condition to the preloader so that it makes no attempt to run in Node, and that's it. Just the partial change of this one line that would little purpose during prerendering anyways.
We are very, very happy with this level of risk and have been using it heavily for some time now without any issue, but, this is somewhat using the tool beyond what it was intended for and it's something we want to disclose.
For any non-Preact users, good news: our plugin is entirely framework agnostic! To make it slightly easier to use in any other framework, this is alternatively offered as [`vite-prerender-plugin`](https://npm.im/vite-prerender-plugin). Same functionality, and kept in-sync with `@preact/preset-vite`, but drops the other Preact-specific utilities that ship in the Preact preset plugin.
================================================
FILE: content/en/blog/signal-boosting.md
================================================
---
title: Signal Boosting
date: 2022-09-24
authors:
- Joachim Viide
---
# Signal Boosting
The new release of Preact Signals brings significant performance updates to the foundations of the reactive system. Read on to learn what kinds of tricks we employed to make this happen.
We recently [announced](https://twitter.com/jviide/status/1572570215350964224) new versions of the Preact Signals packages:
- [@preact/signals-core](https://www.npmjs.com/package/@preact/signals-core) 1.2.0 for the shared core functionality
- [@preact/signals](https://www.npmjs.com/package/@preact/signals) 1.1.0 for the Preact bindings
- [@preact/signals-react](https://www.npmjs.com/package/@preact/signals-react) 1.1.0 for the React bindings
This post will outline the steps that we took to optimize **@preact/signals-core**. It's the package that acts as a base for the framework specific bindings, but can also be used independently.
Signals are the Preact team's take on reactive programming. If you want a gentle introduction on what Signals are all about and how they tie in with Preact, [the Signals announcement blog post](/blog/introducing-signals) has got you covered. For a deeper dive check out the [official documentation](/guide/v10/signals).
It should be noted that none of these concepts are invented by us. Reactive programming has quite a history, and has already been popularized widely in the JavaScript world by [Vue.js](https://vuejs.org/), [Svelte](https://svelte.dev/), [SolidJS](https://www.solidjs.com/), [RxJS](https://rxjs.dev/) and too many others to name. Kudos to all of them!
## A Whirlwind Tour of the Signals Core
Let's start with an overview of the fundamental features in the **@preact/signals-core** package.
The code snippets below use functions imported from the package. The import statements are shown only when a new function is brought into the mix.
### Signals
Plain _signals_ are the fundamental root values which our reactive system is based on. Other libraries might call them, for example, "observables" ([MobX](https://mobx.js.org/observable-state.html), [RxJS](https://rxjs.dev/guide/observable)) or "refs" ([Vue](https://vuejs.org/guide/extras/reactivity-in-depth.html#how-reactivity-works-in-vue)). The Preact team adopted the term "signal" used by [SolidJS](https://www.solidjs.com/tutorial/introduction_signals).
Signals represent arbitrary JavaScript values wrapped into a reactive shell. You provide a signal with an initial value, and can later read and update it as you go.
```js
// --repl
import { signal } from '@preact/signals-core';
const s = signal(0);
console.log(s.value); // Console: 0
s.value = 1;
console.log(s.value); // Console: 1
```
By themselves signals are not terribly interesting until combined with the two other primitives, _computed signals_ and _effects_.
### Computed Signals
_Computed signals_ derive new values from other signals using _compute functions_.
```js
// --repl
import { signal, computed } from '@preact/signals-core';
const s1 = signal('Hello');
const s2 = signal('World');
const c = computed(() => {
return s1.value + ' ' + s2.value;
});
```
The compute function given to `computed(...)` won't run immediately. That's because computed signals are evaluated _lazily_, i.e. when their values are read.
```js
// --repl
import { signal, computed } from '@preact/signals-core';
const s1 = signal('Hello');
const s2 = signal('World');
const c = computed(() => {
return s1.value + ' ' + s2.value;
});
// --repl-before
console.log(c.value); // Console: Hello World
```
Computed values are also _cached_. Their compute functions can potentially be very expensive, so we want to rerun them only when it matters. A running compute function tracks which signal values are actually read during its run. If none of the values have changed, then we can skip recomputation. In the above example, we can just reuse the previously calculated `c.value` indefinitely as long as both `a.value` and `b.value` stay the same. Facilitating this _dependency tracking_ is the reason why we need to wrap the primitive values into signals in the first place.
```js
// --repl
import { signal, computed } from '@preact/signals-core';
const s1 = signal('Hello');
const s2 = signal('World');
const c = computed(() => {
return s1.value + ' ' + s2.value;
});
console.log(c.value); // Console: Hello World
// --repl-before
// s1 and s2 haven't changed, no recomputation here
console.log(c.value); // Console: Hello World
s2.value = 'darkness my old friend';
// s2 has changed, so the computation function runs again
console.log(c.value); // Console: Hello darkness my old friend
```
As it happens, computed signals are themselves signals. A computed signal can depend on other computed signals.
```js
// --repl
import { signal, computed } from '@preact/signals-core';
// --repl-before
const count = signal(1);
const double = computed(() => count.value * 2);
const quadruple = computed(() => double.value * 2);
console.log(quadruple.value); // Console: 4
count.value = 20;
console.log(quadruple.value); // Console: 80
```
The set of dependencies doesn't have to stay static. The computed signal will only react to changes in the latest set of dependencies.
```js
// --repl
import { signal, computed } from '@preact/signals-core';
// --repl-before
const choice = signal(true);
const funk = signal('Uptown');
const purple = signal('Haze');
const c = computed(() => {
if (choice.value) {
console.log(funk.value, 'Funk');
} else {
console.log('Purple', purple.value);
}
});
c.value; // Console: Uptown Funk
purple.value = 'Rain'; // purple is not a dependency, so
c.value; // effect doesn't run
choice.value = false;
c.value; // Console: Purple Rain
funk.value = 'Da'; // funk not a dependency anymore, so
c.value; // effect doesn't run
```
These three things - dependency tracking, laziness and caching - are common features in reactivity libraries. Vue's _computed properties_ are [one prominent example](https://dev.to/linusborg/vue-when-a-computed-property-can-be-the-wrong-tool-195j).
### Effects
Computed signals lend themselves well to [pure functions](https://en.wikipedia.org/wiki/Pure_function) without side-effects. They're also lazy. So what to do if we want to react to changes in signal values without constantly polling them? Effects to the rescue!
Like computed signals, effects are also created with a function (_effect function_) and also track their dependencies. However, instead of being lazy, effects are _eager_. The effect function gets run immediately when the effect gets created, and then again and again whenever the dependency values change.
```js
// --repl
import { signal, computed, effect } from '@preact/signals-core';
const count = signal(1);
const double = computed(() => count.value * 2);
const quadruple = computed(() => double.value * 2);
effect(() => {
console.log('quadruple is now', quadruple.value);
// Console: quadruple value is now 4
});
count.value = 20; // Console: quadruple value is now 80
```
These reactions are triggered by _notifications_. When a plain signal changes, it notifies its immediate dependents. They in turn notify their own immediate dependents, and so on. As is [common](https://mobx.js.org/computeds.html) in reactive systems, computed signals along the notification's path mark themselves to be outdated and ready be recomputed. If the notification trickles all the way down to an effect, then that effect schedules itself to be run as soon as all previously scheduled effects have finished.
When you're done with an effect, call the _disposer_ that got returned when the effect was first created:
```js
// --repl
import { signal, computed, effect } from '@preact/signals-core';
// --repl-before
const count = signal(1);
const double = computed(() => count.value * 2);
const quadruple = computed(() => double.value * 2);
const dispose = effect(() => {
console.log('quadruple is now', quadruple.value);
// Console: quadruple value is now 4
});
dispose();
count.value = 20; // nothing gets printed to the console
```
There are other functions, like [`batch`](/guide/v10/signals/#batchfn), but these three are the most relevant to the implementation notes that follow.
# Implementation Notes
When we set out to implement more performant versions of the above primitives, we had to find snappy ways to do all the following subtasks:
- Dependency tracking: Keep track of used signals (plain or computed). The dependencies may change dynamically.
- Laziness: Compute functions should only run on demand.
- Caching: A computed signal should recompute only when its dependencies may have changed.
- Eagerness: An effect should run ASAP when something in its dependency chain changes.
A reactive system can be implemented in a bajillion different ways. The first released version of **@preact/signals-core** was based on Sets, so we'll keep using that approach to contrast and compare.
### Dependency Tracking
Whenever a compute/effect function starts evaluating, it needs a way to capture signals that have been read during its run. For that the computed signal or effect sets itself as the current _evaluation context_. When a signal's `.value` property is read, it calls a [getter](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get). The getter adds the signal as a dependency, _source_, of the evaluation context. The context also gets added as a dependent, _target_, of the signal.
In the end signals and effects always have an up-to-date view of their dependencies and dependents. Each signal can then notify its dependents whenever its value has changed. Effects and computed signals can refer to their dependency sets to unsubscribe from those notifications when, say, an effect is disposed.
The same signal may get read multiple times inside the same evaluation context. In such cases it would be handy to do some sort of deduplication for dependency and dependent entries. We also need a way to handle changing sets of dependencies: to either rebuild the set of dependencies on every run or incrementally add/remove dependencies/dependents.
JavaScript's [Set](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set) objects are a good fit for all that. Like many other implementations, the original version of Preact Signals used them. Sets allow adding _and_ removing items in [constant O(1) time](https://en.wikipedia.org/wiki/Time_complexity#Constant_time) (amortized), as well as iterating through the current items in [linear O(n) time](https://en.wikipedia.org/wiki/Time_complexity#Linear_time). Duplicates are also handled automatically! It's no wonder many reactivity systems take advantage of Sets (or [Maps](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map)). The right tool for the job and all that.
However, we were wondering whether there are some alternative approaches. Sets can be relatively expensive to create, and at least computed signals may need two separate Sets: one for dependencies and one for dependents. Jason was being a _total Jason_ again and [benchmarked](https://esbench.com/bench/6317fc2a6c89f600a5701bc9) how Set iteration fares against Arrays. There will be lots of iterating so it all adds up.
Sets also have the property they're iterated in insertion order. Which is cool - that's just what we need later when we deal with caching. But there's the possibility that the order doesn't always stay the same. Observe the following scenario:
```js
// --repl
import { signal, computed } from '@preact/signals-core';
// --repl-before
const s1 = signal(0);
const s2 = signal(0);
const s3 = signal(0);
const c = computed(() => {
if (s1.value) {
s2.value;
s3.value;
} else {
s3.value;
s2.value;
}
});
```
Depending on `s1` the order of dependencies is either `s1, s2, s3` or `s1, s3, s2`. Special steps have to be taken to keep Sets in order: either remove and then add back items, empty the set before a function run, or create a new set for each run. Each approach has the potential to cause memory churn. And all this just to account for the theoretical, but probably rare, case that the order of dependencies changes.
There are multiple other ways to deal with this. For example numbering and then sorting the dependencies. We ended up exploring [linked lists](https://en.wikipedia.org/wiki/Linked_list).
### Linked Lists
Linked lists are often considered quite primitive, but for our purposes they have some very nice properties. If you have a doubly-linked list nodes then the following operations can be extremely cheap:
- Insert an item to one end of the list in O(1) time.
- Remove a node (for which you already have a pointer) from anywhere in the list in O(1) time.
- Iterate through the list in O(n) time (O(1) per node)
Turns out that these operations are all we need for managing dependency/dependent lists.
Let's start by creating a "source Node" for each dependency relation. The Node's `source` attribute points to the signal that's being depended on. Each Node has `nextSource` and `prevSource` properties pointing to the next and previous source Nodes in the dependency list, respectively. Effects or a computed signals get a `sources` attribute pointing to the first Node of the list. Now we can iterate through the dependencies, insert a new dependency, and remove dependencies from the list for reordering.
Now let's do the same the other way around: For each dependent create a "target Node". The Node's `target` attribute points to the dependent effect or computed signal. `nextTarget` and `prevTarget` build a doubly linked list. Plain and computed signal get a `targets` attribute pointing to the first target Node in their dependent list.
But hey, dependencies and dependents come in pairs. For every source Node there **must** be a corresponding target Node. We can exploit this fact and smush "source Nodes" and "target Nodes" into just "Nodes". Each Node becomes a sort of quad-linked monstrosity that the dependent can use as a part of its dependency list, and vice versa.
Each Node can have additional stuff attached to it for bookkeeping purposes. Before each compute/effect function we iterate through the previous dependencies and set the "unused" flag of each Node. We also temporarily store the Node to its `.source.node` property for later. The function can then start its run.
During the run, each time a dependency is read, the bookkeeping values can be used to discover whether that dependency has already been seen during this or the previous run. If the dependency is from the previous run, we can recycle its Node. For previously unseen dependencies we create new Nodes. The Nodes are then shuffled around to keep them in reverse order of use. At the end of the run we walk through the dependency list again, purging Nodes that are still hanging around with the "unused" flag set. Then we reverse the list of remaining nodes to keep it all neat for later consumption.
This delicate dance of death allows us to allocate only one Node per each dependency-dependent pair and then use that Node indefinitely as long as the dependency relationship exists. If the dependency tree stays stable, memory consumption also stays effectively stable after the initial build phase. All the while dependency lists stay up to date and in order of use. With a constant O(1) amount of work per Node. Nice!
### Eager Effects
With the dependency tracking taken care of, eager effects are relatively straightforward to implement via change-notifications. Signals notify their dependents about value changes. If the dependent itself is a computed signal that has dependents, then it passes the notification forward, and so on. Effects that get a notification schedule themselves to be run.
We added a couple of optimizations here. If the receiving end of a notification has already been notified before, and it hasn't yet had a chance to run, then it won't pass the notification forward. This mitigates cascading notification stampedes when the dependency tree fans out or in. Plain signals also don't notify their dependents if the signal's value doesn't actually change (e.g. `s.value = s.value`). But that's just being polite.
For effects to be able to schedule themselves there needs to be some sort of a list of scheduled effects. We added an dedicated attribute `.nextBatchedEffect` to each Effect instance, letting Effect instances do double duty as nodes in a singly-linked scheduling list. This reduces memory churn, because scheduling the same effect again and again requires no additional memory allocations or deallocations.
### Interlude: Notification Subscriptions vs. GC
We haven't been completely truthful. Computed signals don't actually _always_ get notifications from their dependencies. A computed signal subscribes to dependency notifications only when there's something, like an effect, listening to the signal itself. This avoids problems in situations like this:
```js
const s = signal(0);
{
const c = computed(() => s.value);
}
// c has gone out of scope
```
Were `c` to always subscribe to notifications from `s`, then `c` couldn't get garbage collected until `s` too falls out of scope. That's because `s` would keep hanging on to a reference to `c`.
There are multiple solutions to this problem, like using [WeakRefs](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WeakRef) or requiring computed signals to be manually disposed. In our case linked lists provide a very convenient way to dynamically subscribe and unsubscribe to dependency notifications on the fly, thanks to all that O(1) stuff. The end result is that you don't have to pay any special attention to dangling computed signal references. We felt this was the most ergonomic and performant approach.
In those cases where a computed signal **has** subscribed to notifications we can use that knowledge for extra optimizations. This brings us to laziness & caching.
### Lazy & Cached Computed Signals
The easiest way to implement a lazy computed signal would be to just recompute each time its value is read. It wouldn't be very efficient, though. That's where caching and dependency tracking help a bunch.
Each plain and computed signal has their own _version number_. They increment their version numbers every time they've noticed their own value change. When a compute function is run, it stores in the Nodes the last seen version numbers of its dependencies. We could have chosen to store the previous dependency values in the nodes instead of version numbers. However, since computed signals are lazy, they could therefore hang on to outdated and potentially expensive values indefinitely. So we felt version numbering was a safe compromise.
We ended up with the following algorithm for figuring out when a computed signal can take the day off and reuse its cached value:
1. If the no signal anywhere has changed values since the last run, then bail out & return the cached value.
> Each time a plain signal changes it also increments a _global version number_, shared between all plain signals. Each computed signal keeps track of the last global version number they've seen. If the global version hasn't changed since last computation, then recomputation can be skipped early. There couldn't be any changes to any computed value anyway in that case.
1. If the computed signal is listening to notifications, and hasn't been notified since the last run, then bail out & return the cached value.
> When a computed signal gets a notification from its dependencies, it flags the cached value as outdated. As described earlier, computed signals don't always get notifications. But when they do we can take advantage of it.
1. Re-evaluate the dependencies in order. Check their version numbers. If no dependency has changed its version number, even after re-evaluation, then bail out & return the cached value.
> This step is the reason why we gave special love and care to keeping dependencies in their order of use. If a dependency changes, then we don't want to re-evaluate dependencies coming later in the list because it might just be unnecessary work. Who knows, maybe the change in that first dependency causes the next compute function run to drop the latter dependencies.
1. Run the compute function. If the returned value is different from the cached one, then increment the computed signal's version number. Cache and return the new value.
> This is the last resort! But at least if the new value is equal to the cached one, then the version number won't change, and the dependents down the line can use that to optimize their own caching.
The last two steps often recurse into the dependencies. That's why the earlier steps are designed to try to short-circuit the recursion.
# Endgame
In typical Preact fashion there were multiple smaller optimizations thrown in along the way. [The source code](https://github.com/preactjs/signals/tree/main/packages/core/src) contains some comments that may or may not be useful. Check out the [tests](https://github.com/preactjs/signals/tree/main/packages/core/test) if you're curious about what kinds of corner cases we came up with to ensure our implementation is robust.
This post was a brain dump of sorts. It outlined the main steps we took to make **@preact/signals-core** version 1.2.0 better - to some definition of "better". Hopefully some of the ideas listed here will resonate, and get reused and remixed by others. At least that's the dream!
Huge thanks to everyone who contributed. And thanks to you for reading this far! It's been a trip.
================================================
FILE: content/en/blog/simplifying-islands-arch.md
================================================
---
title: Simplifying Islands Architecture
date: 2024-10-27
authors:
- reaper
---
> This is a slightly modified version of the original write up at https://barelyhuman.github.io/preact-islands-diy
# Islands
## Intro
This guide is a simple walkthrough to understand how island architecture works
and being able to setup your own using tools you already have around you.
First off, what are islands ? You can read more about it's origin from
[Islands Architecture - Jason Miller →](https://jasonformat.com/islands-architecture/)
## Why ?
For a lot of devs who've worked with server rendering for a while, we kinda
expected frontend tech to take a turn towards server rendering at some point in
time since data fetching and processing is almost always faster on the server
where you are closer to the data.
Which is one of many reasons but then there's others that the entire web is
debating over, so we'll leave it to the smart people.
Let's move on to implementing the concept
# Getting Started
## Basic Implementation
The basic implementation can be generalized for most SSR + Client Hydration
apps.
Here's an overview
1. Initially render the view on the server as a static page.
2. Hydrate the app on client
To go into the details of each.
### Initial Server Render
In this step, you still build the component tree with whatever UI library you're
using, Vue, React, Preact, Solid, etc. And then flatten the component tree to
only have the static and immediately computable data. In this case, no
side-effects and state management based code is run.
The output is a static html document that you can send to the client.
Since this guide is tied to [preact](https://preactjs.com/), we're going to use
a library from the preact team that helps us achieve this.
Here's what a very rudimentary implementation of rendering a component on the
server would look like.
We're using `express.js` here as an example due to it being the first choice of
most beginners, the process is mostly same for any other web server engine you
pick up. Hapi, Koa, Fastify, etc.
```js
// server.js
import { h } from 'preact';
import preactRenderToString from 'preact-render-to-string';
// ...remaining express.js setup
const HomePage = () => {
return h('h1', {}, 'hello');
};
app.get('/', async (req, res) => {
res.send(preactRenderToString(h(HomePage, {})));
});
```
Here most work is done by `preactRenderToString` , and all we are doing is
writing components. With a little bit of bundling magic, we should be able to
write in JSX to make it a little more friendly to work with.
### Hydrate
Okay, so a term you'll see smart people use around a lot online.
- Partial Hydration
- Progressive Hydration
- add more as they find more such ways etc
To be put simply, it's to bind the interactivity to a DOM element with
_existing_ state/effects/events
This _existing_ state/effects/events might be sent from the server, but if
working with a component that can handle it's own and the logic is well
contained in it, you just mount the component on the DOM with the necessary
bindings.
As an example, this might looks a little something like this
```js
// client.js
import { hydrate } from 'preact';
import Counter from './Counter';
const main = () => {
// assuming the server rendered the component with the following ID as well.
const container = document.getElementById('counter');
hydrate(h(Counter, {}), container);
};
main();
```
Similar to the server render phase, we use a helper from `preact` to help
hydrate a component. You could use `render` but then the actual element is
already something that was rendered by the server, rendering it again would make
no sense and so we just ask preact to try to add in the needed event and state
data instead
What I've explained above is called Partial Hydration, since you don't hydrate
the entire app and just hydrate certain parts of it.
## Into the Deep
There's nothing more that you need to know to understand how to make an island
arch based app but, let's now get into implementing this.
# The Code
The code level architecture for this is very similar to most SSR models and Vite
has a good explanation for how to write your own ssr with vite
[→ Vite Guides - Server-Side Rendering](https://vitejs.dev/guide/ssr.html)
We used webpack instead, to make it a little more verbose which is easier to explain.
> Note: You can get the referenced code from [barelyhuman/preact-islands-diy](http://github.com/barelyhuman/preact-islands-diy/)
## `server/app.js`
Starting with `server/app.js` file. If you have the codebase open locally it
would be helpful while reading this.
The below code snippet only highlights the needed areas
```js
import preactRenderToString from 'preact-render-to-string';
import HomePage from '../pages/HomePage.js';
import { h } from 'preact';
import { withManifestBundles } from '../lib/html.js';
const app = express();
app.get('/', async (req, res) => {
res.send(
withManifestBundles({
body: preactRenderToString(h(HomePage, {}))
})
);
});
```
Looking at the imports, we have the same imports as mentioned in the
[Getting Started](#getting-started) section and not much has changed.
The only addition here is the `withManifestBundles` helper which is what we'll
talk about next.
## `lib/html.js`
The HTML helper is different in different variants of the template but we'll be
only going through `webpack` version which is on the `main` branch.
The base usecase of the helper is to be able to go through a manifest json that
lists what files are being bundled by webpack and their hashed paths when being
used in production.
This is required since we will not know the hash and we need a programmatic way
to find it out.
This manifest is generated by webpack's client configuration which we'll take a
look at in a minute.
```js
// fetch the manifest from the client output
import manifest from '../../dist/js/manifest.json';
export const withManifestBundles = ({ styles, body }) => {
// go through each key in the manifest and construct
// a script tag for each.
const bundledScripts = Object.keys(manifest).map(key => {
const scriptPath = `/public/js/${manifest[key]}`;
return `<script src=${scriptPath}></script>`;
});
return `<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<style id="_goober">
${styles}
</style>
</head>
<body>
${body}
</body>
${bundledScripts.join('')}
</html>`;
};
```
As explained in the comments, we just grab all the files we need from the
manifest and inject them as script tags into the final HTML that is sent from
the server.
Moving onto the configuration that makes it possible to build this.
## `webpack.config.*.js`
I tried to keep the webpack configuration as minimal as possible to avoid
scaring people away from the whole idea so let's go through the configuration.
```js
// webpack.config.server.js
const path = require('path');
const nodeExternals = require('webpack-node-externals');
module.exports = {
mode: process.env.NODE_ENV != 'production' ? 'development' : 'production',
target: 'node',
entry: path.resolve(__dirname, './src/server/app.js'),
output: {
filename: 'server.js',
path: path.resolve(__dirname, './dist')
},
stats: 'errors-warnings',
resolve: {
extensions: ['.js', '.jsx']
},
module: {
rules: [{ test: /\.jsx?$/, loader: 'babel-loader' }]
},
externals: [nodeExternals()]
};
```
Most of them need no explanation, and the only loader we have in place is the
`babel-loader` since we are using a CSS-IN-JS solution for styling.
There's nothing magical going on here, we just give it the entry point of
`server/app.js` and let it build itself to the same folder as the client's
output.
moving on to the client side config, which does add a few more things than
simply providing an entry and getting an output.
This is shortened out to explain the relevant bits
```js
// webpack.config.client.js
const entryPoints = glob
.sync(path.resolve(__dirname, './src/client') + '/**/*.js', {
absolute: true
})
.reduce((acc, path) => {
const entry = path.match(/[^\/]+\.jsx?$/gm)[0].replace(/.jsx?$/, '');
acc[entry] = path;
return acc;
}, {});
```
So the first section is basically finding all files in `src/client` and creating
an object of entries for webpack.
Example: if `src/client/app.client.js` is a file then the output of the above
would be
```json
{
"app.client": "./src/client/app.client.js"
}
```
this is nothing special, it's just how webpack expects entries to be defined.
Everything else is generic configuration that's also present on the server side
```js
{
plugins: [
new WebpackManifestPlugin({
publicPath: '',
basePath: '',
filter: file => {
return /\.mount\.js$/.test(file.name);
}
})
];
}
```
Then we have the manifest plugin, which checks for files that have the string
`mount` in their name, this is done to make sure that only the entry files are
loaded and not random files and we do this by specifying a specific extension
type for the file.
Some frameworks use a `islands` folder to separate islands from entry files. We
instead separate the entry files from islands and have the user decide what
mounts as an island and what doesn't.
The above `WebpackManifestPlugin` generates a `manifest.json` file in
`dist/public/js` which has the bundled file names which we were using in the
`lib/html.js` file.
## `.babelrc`
This is the last part of the configuration, where you ask babel to make sure
that the JSX runtime it uses is from preact and not react.
Pretty self explanatory, but if you need details about the option, please go
through the docs of [babel](https://babeljs.io/) and
[@babel/plugin-transform-react-jsx](https://babeljs.io/docs/en/babel-plugin-transform-react-jsx)
```json
// .babelrc
{
"plugins": [
[
"@babel/plugin-transform-react-jsx",
{ "runtime": "automatic", "importSource": "preact" }
]
]
}
```
## Folders
We can now move on to each folders' significance here.
> **Note**: Please know that you can mix and match the folders if needed, just
> make sure the configurations are edited to handle the changes you do. If not,
> the current structure is good enough for most applications
## `client`
The `src/client` in this `main` branch is used to write the `mount` point code
that gets sent with the rendered html.
You add selective mounting based on pages and selectors that you wish to use,
even though it would fetch multiple JS files, these files are never to have
anything more than the mounting code , your islands should be self serving and
self reliant. You can however send an initial dataset from the server as a
`data-*` attribute but this has to be serializable data or will be lost.
You can also add a wrapper around to create a island manually, but
web-components are not widely supported so if using for a legacy level support
system, you are better off manually mounting like mentioned above.
example:
```js
// src/client/index.mount.js
import { h, hydrate } from 'preact';
// setup goober
import { setup } from 'goober';
setup(h);
// can be moved to a util file and used from there,
// in this file as an example for now.
const mount = async (Component, elm) => {
if (elm?.dataset?.props) {
const props = JSON.parse(elm.dataset.props);
delete elm.dataset.props;
hydrate(<Component {...props} />, elm);
}
};
const main = async () => {
// lazy load and re-mount counter as a client side component if needed
// A better way would be to check if the `counter` element exists on
// the DOM before even importing the component to avoid un-needed
// JS downloads.
const Counter = (await import('../components/Counter.js')).default;
mount(Counter, document.getElementById('counter'));
};
main();
```
## components
The name is pretty self explanatory, since we aren't doing any segregation here
as to what is and what isn't an island, you can shove all your components here
like you normally would.
## layouts
These are separated since I like to keep the layouts far away from components
since sometimes they have more than just rendering conditions. It's not needed
in this specific case because in most cases you'd be running your layouts on the
server and not on the client.
## lib
Contains common helper funcs for both client and server, since both are bundled
separately and dependencies will be inlined as needed.
## pages
This folder acts as the storage for templates. So anything that the server will
be rendering as a page would be put in here. The ability to use layouts and
other components like a normal preact app helps with building composable
templates but still it's easier to just have them separate from the actual
component code.
## public
Stuff that needs to be delivered statically by express is put here, webpack
takes care of copying the whole thing to the final folder.
## server
Self explanatory, server sided files, in most cases you'd like to move routes to
a separate file and maybe add in middlewares to add a helper function to render
preact components for you.
Something like this is definitely a part of the server and not going to be
client sided so just keep it in this folder.
Example
```js
app.use((req, res, next) => {
res.render = (comp, data) => {
return res.write(preactRenderToString(h(comp, { ...data })));
};
});
// and somewhere else in the app
const handler = (req, res) => {
return res.status(200).render(Homepage, { username: 'reaper' });
};
```
That's actually all the code that contributes to setting up your own partial
hydration / island styled hydration with nodejs.
Most of this can be achieved with almost all bundlers and a little more
modification to how the configurations are generated, can help you achieve a
similar DX to astro though you are better off using astro if you aren't a fan of
maintaining configs.
================================================
FILE: content/en/blog.md
================================================
---
title: Blog
---
Find out more about what the Preact team is working on.
<div><blog-overview></blog-overview></div>
<div>
<hr />
<h2>Like what you see?</h2>
<p>
Preact is free to use so that everyone can take part in building on
the web. Thanks to all the awesome sponsors who make working on Preact
possible! If you want to become one of them, consider
<a href="https://opencollective.com/preact">a donation</a>.
</p>
</div>
================================================
FILE: content/en/branding.md
================================================
---
title: Branding
---
Different variations of Preact's logo and symbol that you can use.
<branding></branding>
================================================
FILE: content/en/guide/v10/api-reference.md
================================================
---
title: API Reference
description: Learn more about all exported functions of the Preact module
---
# API Reference
This page serves as a quick overview over all exported functions.
---
<toc></toc>
---
## preact
The `preact` module provides only essential functionality like creating VDOM elements and rendering components. Additional utilities are provided by the various subpath exports, such as `preact/hooks`, `preact/compat`, `preact/debug`, etc.
### Component
`Component` is a base class that can be extended to create stateful Preact components.
Rather than being instantiated directly, Components are managed by the renderer and created as-needed.
```js
import { Component } from 'preact';
class MyComponent extends Component {
// (see below)
}
```
#### Component.render(props, state)
All components must provide a `render()` function. The render function is passed the component's current props and state, and should return a Virtual DOM Element (typically a JSX "element"), an Array, or `null`.
```jsx
import { Component } from 'preact';
class MyComponent extends Component {
render(props, state) {
// props is the same as this.props
// state is the same as this.state
return <h1>Hello, {props.name}!</h1>;
}
}
```
To learn more about components and how they can be used, check out the [Components Documentation](/guide/v10/components).
### render()
`render(virtualDom, containerNode, [replaceNode])`
Render a Virtual DOM Element into a parent DOM element `containerNode`. Does not return anything.
```jsx
// --repl
// DOM tree before render:
// <div id="container"></div>
import { render } from 'preact';
const Foo = () => <div>foo</div>;
render(<Foo />, document.getElementById('container'));
// After render:
// <div id="container">
// <div>foo</div>
// </div>
```
The first argument must be a valid Virtual DOM Element, which represents either a component or an element. When passing a Component, it's important to let Preact do the instantiation rather than invoking your component directly, which will break in unexpected ways:
```jsx
const App = () => <div>foo</div>;
// DON'T: Invoking components directly means they won't be counted as a
// VNode and hence not be able to use functionality relating to vnodes.
render(App(), rootElement); // ERROR
render(App, rootElement); // ERROR
// DO: Passing components using h() or JSX allows Preact to render correctly:
render(h(App), rootElement); // success
render(<App />, rootElement); // success
```
If the optional `replaceNode` parameter is provided, it must be a child of `containerNode`. Instead of inferring where to start rendering, Preact will update or replace the passed element using its diffing algorithm.
```jsx
// DOM tree before render:
// <div id="container">
// <div>bar</div>
// <div id="target">foo</div>
// </div>
import { render } from 'preact';
const Foo = () => <div id="target">BAR</div>;
render(
<Foo />,
document.getElementById('container'),
document.getElementById('target')
);
// After render:
// <div id="container">
// <div>bar</div>
// <div id="target">BAR</div>
// </div>
```
> ⚠️ The `replaceNode`-argument will be removed with Preact `v11`. It introduces too many edge cases and bugs which need to be accounted for in the rest of Preact's source code. If you still need this functionality, we recommend using [`preact-root-fragment`](/guide/v10/preact-root-fragment), a small helper library that provides similar functionality. It is compatible with both Preact `v10` and `v11`.
### hydrate()
`hydrate(virtualDom, containerNode)`
If you've already pre-rendered or server-side-rendered your application to HTML, Preact can bypass most rendering work when loading in the browser. This can be enabled by switching from `render()` to `hydrate()`, which skips most diffing while still attaching event listeners and setting up your component tree. This works only when used in conjunction with pre-rendering or [Server-Side Rendering](/guide/v10/server-side-rendering).
```jsx
// --repl
import { hydrate } from 'preact';
const Foo = () => <div>foo</div>;
hydrate(<Foo />, document.getElementById('container'));
```
### h() / createElement()
`h(type, props, ...children)`
Returns a Virtual DOM Element with the given `props`. Virtual DOM Elements are lightweight descriptions of a node in your application's UI hierarchy, essentially an object of the form `{ type, props }`.
After `type` and `props`, any remaining parameters are collected into a `children` property.
Children may be any of the following:
- Scalar values (string, number, boolean, null, undefined, etc)
- Nested Virtual DOM Elements
- Infinitely nested Arrays of the above
```js
import { h } from 'preact';
h('div', { id: 'foo' }, 'Hello!');
// <div id="foo">Hello!</div>
h('div', { id: 'foo' }, 'Hello', null, ['Preact!']);
// <div id="foo">Hello Preact!</div>
h('div', { id: 'foo' }, h('span', null, 'Hello!'));
// <div id="foo"><span>Hello!</span></div>
```
### toChildArray
`toChildArray(componentChildren)`
This helper function converts a `props.children` value to a flattened Array regardless of its structure or nesting. If `props.children` is already an array, a copy is returned. This function is useful in cases where `props.children` may not be an array, which can happen with certain combinations of static and dynamic expressions in JSX.
For Virtual DOM Elements with a single child, `props.children` is a reference to the child. When there are multiple children, `props.children` is always an Array. The `toChildArray` helper provides a way to consistently handle all cases.
```jsx
import { toChildArray } from 'preact';
function Foo(props) {
const count = toChildArray(props.children).length;
return <div>I have {count} children</div>;
}
// props.children is "bar"
render(<Foo>bar</Foo>, container);
// props.children is [<p>A</p>, <p>B</p>]
render(
<Foo>
<p>A</p>
<p>B</p>
</Foo>,
container
);
```
### cloneElement
`cloneElement(virtualElement, props, ...children)`
This function allows you to create a shallow copy of a Virtual DOM Element.
It's generally used to add or overwrite `props` of an element:
```jsx
function Linkout(props) {
// add target="_blank" to the link:
return cloneElement(props.children, { target: '_blank' });
}
render(
<Linkout>
<a href="/">home</a>
</Linkout>
);
// <a href="/" target="_blank">home</a>
```
### createContext
`createContext(initialState)`
Creates a new Context object which can be used to pass data through the component tree without passing down props through each level.
See the section in the [Context documentation](/guide/v10/context#createcontext).
```jsx
import { createContext } from 'preact';
const MyContext = createContext(defaultValue);
```
### createRef
`createRef(initialValue)`
Creates a new Ref object that acts as a stable, local value that will persist across renders. This can be used to store DOM references, component instances, or any arbitrary value.
See the [References documentation](/guide/v10/refs#createref) for more details.
```jsx
import { createRef, Component } from 'preact';
class MyComponent extends Component {
inputRef = createRef(null);
// ...
}
```
### Fragment
A special kind of component that can have children, but is not rendered as a DOM element.
Fragments make it possible to return multiple sibling children without needing to wrap them in a DOM container:
```jsx
// --repl
import { Fragment, render } from 'preact';
render(
<Fragment>
<div>A</div>
<div>B</div>
<div>C</div>
</Fragment>,
document.getElementById('container')
);
// Renders:
// <div id="container>
// <div>A</div>
// <div>B</div>
// <div>C</div>
// </div>
```
### isValidElement
`isValidElement(virtualElement)`
Checks if the provided value is a valid Preact VNode.
```jsx
import { isValidElement, h } from 'preact';
isValidElement(<div />); // true
isValidElement(h('div')); // true
isValidElement('div'); // false
isValidElement(null); // false
```
### options
See the [Option Hooks](/guide/v10/options) documentation for more details.
## preact/hooks
See the [Hooks](/guide/v10/hooks) documentation for more details. Please note that the page includes a number of "Compat-specific hooks" that are not available from `preact/hooks`, only `preact/compat`.
## preact/compat
`preact/compat` is our compatibility layer that allows you to use Preact as a drop-in replacement for React. It provides all of the APIs of `preact` and `preact/hooks`, whilst also providing a few more to match the React API.
### Children
Offered for compatibility, `Children` is a passthrough wrapper around the [`toChildArray`](#tochildarray) function from core. It's quite unnecessary in Preact apps.
#### Children.map
`Children.map(children, fn, [context])`
Iterates over children and returns a new array, same as [`Array.prototype.map`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map).
```jsx
function List(props) {
const children = Children.map(props.children, child => (
<li>{child}</li>
));
return (
<ul>
{children}
</ul>
);
}
```
> Note: Can be replaced with `toChildArray(props.children).map(...)`.
#### Children.forEach
`Children.forEach(children, fn, [context])`
Iterates over children but does not return a new array, same as [`Array.prototype.forEach`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach).
```jsx
function List(props) {
const children = [];
Children.forEach(props.children, child =>
children.push(<li>{child}</li>)
);
return (
<ul>
{children}
</ul>
);
}
```
> Note: Can be replaced with `toChildArray(props.children).forEach(...)`.
#### Children.count
`Children.count(children)`
Returns the total number children.
```jsx
function MyComponent(props) {
const children = Children.count(props.children);
return <div>I have {children.length} children</div>;
}
```
> Note: Can be replaced with `toChildArray(props.children).length`.
#### Children.only
`Children.only(children)`
Throws if the number of children is not exactly one. Otherwise, returns the only child.
```jsx
function List(props) {
const singleChild = Children.only(props.children);
return (
<ul>
{singleChild}
</ul>
);
}
```
#### Children.toArray
`Children.count(children)`
Converts children to a flat array. An alias of [`toChildArray`](#tochildarray).
```jsx
function MyComponent(props) {
const children = Children.toArray(props.children);
return <div>I have {children.length} children</div>;
}
```
> Note: Can be replaced with `toChildArray(props.children)`.
### createPortal
`createPortal(virtualDom, containerNode)`
Allows you to render somewhere else in the DOM tree than your component's natural parent.
```html
<html>
<body>
<!-- Modals should be rendered here -->
<div id="modal-root"></div>
<!-- App is rendered here -->
<div id="app"></div>
</body>
</html>
```
```jsx
import { createPortal } from 'preact/compat';
import { MyModal } from './MyModal.jsx';
function App() {
const container = document.getElementById('modal-root');
return (
<div>
<h1>My App</h1>
{createPortal(<MyModal />, container)}
</div>
);
}
```
### PureComponent
The `PureComponent` class works similar to `Component`. The difference is that `PureComponent` will skip rendering when the new props are equal to the old ones. To do this we compare the old and new props via a shallow comparison where we check each props property for referential equality. This can speed up applications a lot by avoiding unnecessary re-renders. It works by adding a default `shouldComponentUpdate` lifecycle hook.
```jsx
import { render } from 'preact';
import { PureComponent } from 'preact/compat';
class Foo extends PureComponent {
render(props) {
console.log('render');
return <div />;
}
}
const dom = document.getElementById('root');
render(<Foo value="3" />, dom);
// Logs: "render"
// Render a second time, doesn't log anything
render(<Foo value="3" />, dom);
```
> Note that the advantage of `PureComponent` only pays off when then render is expensive. For simple children trees it can be quicker to just do the `render` compared to the overhead of comparing props.
### memo
`memo` is equivalent to functional components as `PureComponent` is to classes. It uses the same comparison function under the hood, but allows you to specify your own specialized function optimized for your use case.
```jsx
import { memo } from 'preact/compat';
function MyComponent(props) {
return <div>Hello {props.name}</div>;
}
// Usage with default comparison function
const Memoed = memo(MyComponent);
// Usage with custom comparison function
const Memoed2 = memo(MyComponent, (prevProps, nextProps) => {
// Only re-render when `name' changes
return prevProps.name === nextProps.name;
});
```
> The comparison function is different from `shouldComponentUpdate` in that it checks if the two props objects are **equal**, whereas `shouldComponentUpdate` checks if they are different.
### forwardRef
In some cases when writing a component you want to allow the user to get hold of a specific reference further down the tree. With `forwardRef` you can sort-of "forward" the `ref` property:
```jsx
import { createRef, render } from 'preact';
import { forwardRef } from 'preact/compat';
const MyComponent = forwardRef((props, ref) => {
return <div ref={ref}>Hello world</div>;
});
// Usage: `ref` will hold the reference to the inner `div` instead of
// `MyComponent`
const ref = createRef();
render(<MyComponent ref={ref} />, dom);
```
This component is most useful for library authors.
### StrictMode
`<StrictMode><App /></StrictMode>`
Offered strictly for compatibility, `<StrictMode>` is simply an alias of [`Fragment`](#Fragment). It does not provide any additional checks or warnings, all of which are provided by [`preact/debug`](#preactdebug).
```jsx
import { StrictMode } from 'preact/compat';
render(
<StrictMode>
<App />
</StrictMode>,
document.getElementById('root')
);
```
### Suspense
`<Suspense fallback={...}>...</Suspense>`
A component that can be used to "wait" for some asynchronous operation to complete before rendering its children. While waiting, it will render the provided `fallback` content instead.
```jsx
import { Suspense } from 'preact/compat';
function MyComponent() {
return (
<Suspense fallback={<div>Loading...</div>}>
<MyLazyComponent />
</Suspense>
);
}
```
### lazy
`lazy(loadingFunction)`
Allows you to defer loading of a component until it is actually needed. This is useful for code-splitting and lazy-loading parts of your application.
```jsx
import { lazy } from 'preact/compat';
const MyLazyComponent = lazy(() => import('./MyLazyComponent.jsx'));
```
## preact/debug
`preact/debug` provides some low-level debugging utilities that can be used to help identify issues for those building very specific tooling on top of Preact. It is very, very unlikely that any normal consumer should directly use any of the functions below; instead, you should import `preact/debug` at the root of your application to enable helpful warnings and error messages.
### resetPropWarnings
`resetPropWarnings()`
Resets the internal history of which prop type warnings have already been logged. This is useful when running tests to ensure each test starts with a clean slate.
```jsx
import { resetPropWarnings } from 'preact/debug';
import PropTypes from 'prop-types';
function Foo(props) {
return <h1>{props.title}</h1>;
}
Foo.propTypes = {
title: PropTypes.string.isRequired
};
render(<Foo />, document.getElementById('app'));
// Logs: Warning: Failed prop type: The prop `title` is marked as required in `Foo`, but its value is `undefined`.
expect(console.error).toHaveBeenCalledOnce();
resetPropWarnings();
//...
```
### getCurrentVNode
`getCurrentVNode()`
Gets the current VNode being rendered.
```jsx
import { render } from 'preact';
import { getCurrentVNode } from 'preact/debug';
function MyComponent() {
const currentVNode = getCurrentVNode();
console.log(currentVNode); // Logs: Object { type: MyComponent(), props: {}, key: undefined, ref: undefined, ... }
return <h1>Hello World!</h1>
}
render(<MyComponent />, document.getElementById('app'));
```
### getDisplayName
`getDisplayName(vnode)`
Returns a string representation of a Virtual DOM Element's type, useful for debugging and error messages.
```js
import { h } from 'preact';
import { getDisplayName } from 'preact/debug';
getDisplayName(h('div')); // "div"
getDisplayName(h(MyComponent)); // "MyComponent"
getDisplayName(h(() => <div />)); // "<empty string>"
```
### getOwnerStack
`getOwnerStack(vnode)`
Return the component stack that was captured up to this point.
```jsx
import { render, options } from 'preact';
import { getOwnerStack } from 'preact/debug';
const oldVNode = options.diffed;
options.diffed = (vnode) => {
if (vnode.type === 'h1') {
console.log(getOwnerStack(vnode));
// Logs:
//
// in h1 (at /path/to/file.jsx:17)
// in MyComponent (at /path/to/file.jsx:20)
}
if (oldVNode) oldVNode(vnode);
};
function MyComponent() {
return <h1>Hello World!</h1>;
}
render(<MyComponent />, document.getElementById('app'));
```
## preact/devtools
### addHookName
`addHookName(value, name)`
Display a custom label for a hook in the devtools. This may be useful when you have multiple hooks of the same type in a single component and want to be able to distinguish them.
```jsx
import { addHookName } from 'preact/devtools';
import { useState } from 'preact/hooks';
function useCount(init) {
return addHookName(useState(init), 'count');
}
function App() {
const [count, setCount] = useCount(0);
return (
<button onClick={() => setCount(c => c + 1)}>
{count}
</button>;
);
gitextract_65jqq7az/ ├── .editorconfig ├── .github/ │ └── workflows/ │ └── ci.yml ├── .gitignore ├── .npmrc ├── .prettierignore ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── LICENSE ├── README.md ├── content/ │ ├── de/ │ │ ├── 404.md │ │ ├── about/ │ │ │ ├── browser-support.md │ │ │ ├── demos-examples.md │ │ │ ├── libraries-addons.md │ │ │ ├── project-goals.md │ │ │ └── we-are-using.md │ │ ├── guide/ │ │ │ └── v8/ │ │ │ ├── api-reference.md │ │ │ ├── differences-to-react.md │ │ │ ├── extending-component.md │ │ │ ├── external-dom-mutations.md │ │ │ ├── forms.md │ │ │ ├── getting-started.md │ │ │ ├── linked-state.md │ │ │ ├── progressive-web-apps.md │ │ │ ├── switching-to-preact.md │ │ │ ├── types-of-components.md │ │ │ └── unit-testing-with-enzyme.md │ │ └── index.md │ ├── en/ │ │ ├── 404.md │ │ ├── about/ │ │ │ ├── browser-support.md │ │ │ ├── demos-examples.md │ │ │ ├── libraries-addons.md │ │ │ ├── project-goals.md │ │ │ └── we-are-using.md │ │ ├── blog/ │ │ │ ├── introducing-signals.md │ │ │ ├── preact-x.md │ │ │ ├── prerendering-preset-vite.md │ │ │ ├── signal-boosting.md │ │ │ └── simplifying-islands-arch.md │ │ ├── blog.md │ │ ├── branding.md │ │ ├── guide/ │ │ │ ├── v10/ │ │ │ │ ├── api-reference.md │ │ │ │ ├── components.md │ │ │ │ ├── context.md │ │ │ │ ├── debugging.md │ │ │ │ ├── differences-to-react.md │ │ │ │ ├── forms.md │ │ │ │ ├── getting-started.md │ │ │ │ ├── hooks.md │ │ │ │ ├── no-build-workflows.md │ │ │ │ ├── options.md │ │ │ │ ├── preact-custom-element.md │ │ │ │ ├── preact-iso.md │ │ │ │ ├── preact-root-fragment.md │ │ │ │ ├── preact-testing-library.md │ │ │ │ ├── refs.md │ │ │ │ ├── server-side-rendering.md │ │ │ │ ├── signals.md │ │ │ │ ├── typescript.md │ │ │ │ ├── unit-testing-with-enzyme.md │ │ │ │ ├── upgrade-guide.md │ │ │ │ ├── web-components.md │ │ │ │ └── whats-new.md │ │ │ ├── v11/ │ │ │ │ ├── api-reference.md │ │ │ │ ├── components.md │ │ │ │ ├── context.md │ │ │ │ ├── debugging.md │ │ │ │ ├── differences-to-react.md │ │ │ │ ├── forms.md │ │ │ │ ├── getting-started.md │ │ │ │ ├── hooks.md │ │ │ │ ├── no-build-workflows.md │ │ │ │ ├── options.md │ │ │ │ ├── preact-custom-element.md │ │ │ │ ├── preact-iso.md │ │ │ │ ├── preact-root-fragment.md │ │ │ │ ├── preact-testing-library.md │ │ │ │ ├── refs.md │ │ │ │ ├── server-side-rendering.md │ │ │ │ ├── signals.md │ │ │ │ ├── typescript.md │ │ │ │ ├── unit-testing-with-enzyme.md │ │ │ │ ├── upgrade-guide.md │ │ │ │ └── web-components.md │ │ │ └── v8/ │ │ │ ├── api-reference.md │ │ │ ├── differences-to-react.md │ │ │ ├── extending-component.md │ │ │ ├── external-dom-mutations.md │ │ │ ├── forms.md │ │ │ ├── getting-started.md │ │ │ ├── linked-state.md │ │ │ ├── progressive-web-apps.md │ │ │ ├── switching-to-preact.md │ │ │ ├── types-of-components.md │ │ │ └── unit-testing-with-enzyme.md │ │ ├── index.md │ │ ├── repl.md │ │ └── tutorial/ │ │ ├── 01-vdom.md │ │ ├── 02-events.md │ │ ├── 03-components.md │ │ ├── 04-state.md │ │ ├── 05-refs.md │ │ ├── 06-context.md │ │ ├── 07-side-effects.md │ │ ├── 08-keys.md │ │ ├── 09-error-handling.md │ │ ├── 10-links.md │ │ └── index.md │ ├── es/ │ │ ├── 404.md │ │ ├── about/ │ │ │ ├── browser-support.md │ │ │ ├── demos-examples.md │ │ │ ├── libraries-addons.md │ │ │ ├── project-goals.md │ │ │ └── we-are-using.md │ │ ├── blog/ │ │ │ ├── introducing-signals.md │ │ │ ├── preact-x.md │ │ │ ├── prerendering-preset-vite.md │ │ │ ├── signal-boosting.md │ │ │ └── simplifying-islands-arch.md │ │ ├── blog.md │ │ ├── branding.md │ │ ├── guide/ │ │ │ ├── v10/ │ │ │ │ ├── components.md │ │ │ │ ├── forms.md │ │ │ │ ├── getting-started.md │ │ │ │ ├── hooks.md │ │ │ │ ├── upgrade-guide.md │ │ │ │ └── whats-new.md │ │ │ ├── v11/ │ │ │ │ ├── api-reference.md │ │ │ │ ├── components.md │ │ │ │ ├── context.md │ │ │ │ ├── debugging.md │ │ │ │ ├── differences-to-react.md │ │ │ │ ├── forms.md │ │ │ │ ├── getting-started.md │ │ │ │ ├── hooks.md │ │ │ │ ├── no-build-workflows.md │ │ │ │ ├── options.md │ │ │ │ ├── preact-custom-element.md │ │ │ │ ├── preact-iso.md │ │ │ │ ├── preact-root-fragment.md │ │ │ │ ├── preact-testing-library.md │ │ │ │ ├── refs.md │ │ │ │ ├── server-side-rendering.md │ │ │ │ ├── signals.md │ │ │ │ ├── typescript.md │ │ │ │ ├── unit-testing-with-enzyme.md │ │ │ │ ├── upgrade-guide.md │ │ │ │ └── web-components.md │ │ │ └── v8/ │ │ │ ├── api-reference.md │ │ │ ├── differences-to-react.md │ │ │ ├── extending-component.md │ │ │ ├── external-dom-mutations.md │ │ │ ├── forms.md │ │ │ ├── getting-started.md │ │ │ ├── linked-state.md │ │ │ ├── progressive-web-apps.md │ │ │ ├── switching-to-preact.md │ │ │ ├── types-of-components.md │ │ │ └── unit-testing-with-enzyme.md │ │ └── index.md │ ├── fr/ │ │ ├── 404.md │ │ ├── about/ │ │ │ ├── browser-support.md │ │ │ ├── demos-examples.md │ │ │ ├── libraries-addons.md │ │ │ ├── project-goals.md │ │ │ └── we-are-using.md │ │ ├── guide/ │ │ │ └── v8/ │ │ │ ├── api-reference.md │ │ │ ├── differences-to-react.md │ │ │ ├── extending-component.md │ │ │ ├── external-dom-mutations.md │ │ │ ├── forms.md │ │ │ ├── getting-started.md │ │ │ ├── linked-state.md │ │ │ ├── progressive-web-apps.md │ │ │ ├── switching-to-preact.md │ │ │ ├── types-of-components.md │ │ │ └── unit-testing-with-enzyme.md │ │ └── index.md │ ├── it/ │ │ ├── blog/ │ │ │ └── introducing-signals.md │ │ ├── guide/ │ │ │ └── v8/ │ │ │ └── getting-started.md │ │ └── index.md │ ├── ja/ │ │ ├── 404.md │ │ ├── about/ │ │ │ ├── browser-support.md │ │ │ ├── project-goals.md │ │ │ └── we-are-using.md │ │ ├── guide/ │ │ │ └── v10/ │ │ │ ├── api-reference.md │ │ │ ├── components.md │ │ │ ├── context.md │ │ │ ├── debugging.md │ │ │ ├── differences-to-react.md │ │ │ ├── forms.md │ │ │ ├── getting-started.md │ │ │ ├── hooks.md │ │ │ ├── options.md │ │ │ ├── preact-testing-library.md │ │ │ ├── refs.md │ │ │ ├── server-side-rendering.md │ │ │ ├── unit-testing-with-enzyme.md │ │ │ ├── upgrade-guide.md │ │ │ ├── web-components.md │ │ │ └── whats-new.md │ │ └── index.md │ ├── kr/ │ │ ├── 404.md │ │ ├── about/ │ │ │ ├── browser-support.md │ │ │ ├── demos-examples.md │ │ │ ├── libraries-addons.md │ │ │ ├── project-goals.md │ │ │ └── we-are-using.md │ │ ├── guide/ │ │ │ └── v10/ │ │ │ └── differences-to-react.md │ │ ├── index.md │ │ └── tutorial/ │ │ ├── 01-vdom.md │ │ ├── 02-events.md │ │ └── index.md │ ├── pt-br/ │ │ ├── 404.md │ │ ├── about/ │ │ │ ├── browser-support.md │ │ │ ├── demos-examples.md │ │ │ ├── libraries-addons.md │ │ │ ├── project-goals.md │ │ │ └── we-are-using.md │ │ ├── guide/ │ │ │ ├── v10/ │ │ │ │ ├── api-reference.md │ │ │ │ ├── components.md │ │ │ │ ├── context.md │ │ │ │ ├── debugging.md │ │ │ │ ├── differences-to-react.md │ │ │ │ ├── forms.md │ │ │ │ ├── getting-started.md │ │ │ │ ├── hooks.md │ │ │ │ ├── refs.md │ │ │ │ ├── server-side-rendering.md │ │ │ │ ├── signals.md │ │ │ │ ├── unit-testing-with-enzyme.md │ │ │ │ ├── upgrade-guide.md │ │ │ │ ├── web-components.md │ │ │ │ └── whats-new.md │ │ │ └── v8/ │ │ │ ├── api-reference.md │ │ │ ├── differences-to-react.md │ │ │ ├── extending-component.md │ │ │ ├── external-dom-mutations.md │ │ │ ├── forms.md │ │ │ ├── getting-started.md │ │ │ ├── linked-state.md │ │ │ ├── progressive-web-apps.md │ │ │ ├── switching-to-preact.md │ │ │ ├── types-of-components.md │ │ │ └── unit-testing-with-enzyme.md │ │ └── index.md │ ├── ru/ │ │ ├── 404.md │ │ ├── about/ │ │ │ ├── browser-support.md │ │ │ ├── demos-examples.md │ │ │ ├── libraries-addons.md │ │ │ ├── project-goals.md │ │ │ └── we-are-using.md │ │ ├── blog/ │ │ │ ├── introducing-signals.md │ │ │ ├── preact-x.md │ │ │ ├── prerendering-preset-vite.md │ │ │ ├── signal-boosting.md │ │ │ └── simplifying-islands-arch.md │ │ ├── blog.md │ │ ├── branding.md │ │ ├── guide/ │ │ │ ├── v10/ │ │ │ │ ├── api-reference.md │ │ │ │ ├── components.md │ │ │ │ ├── context.md │ │ │ │ ├── debugging.md │ │ │ │ ├── differences-to-react.md │ │ │ │ ├── forms.md │ │ │ │ ├── getting-started.md │ │ │ │ ├── hooks.md │ │ │ │ ├── no-build-workflows.md │ │ │ │ ├── options.md │ │ │ │ ├── preact-custom-element.md │ │ │ │ ├── preact-iso.md │ │ │ │ ├── preact-root-fragment.md │ │ │ │ ├── preact-testing-library.md │ │ │ │ ├── refs.md │ │ │ │ ├── server-side-rendering.md │ │ │ │ ├── signals.md │ │ │ │ ├── typescript.md │ │ │ │ ├── unit-testing-with-enzyme.md │ │ │ │ ├── upgrade-guide.md │ │ │ │ ├── web-components.md │ │ │ │ └── whats-new.md │ │ │ ├── v11/ │ │ │ │ ├── api-reference.md │ │ │ │ ├── components.md │ │ │ │ ├── context.md │ │ │ │ ├── debugging.md │ │ │ │ ├── differences-to-react.md │ │ │ │ ├── forms.md │ │ │ │ ├── getting-started.md │ │ │ │ ├── hooks.md │ │ │ │ ├── no-build-workflows.md │ │ │ │ ├── options.md │ │ │ │ ├── preact-custom-element.md │ │ │ │ ├── preact-iso.md │ │ │ │ ├── preact-root-fragment.md │ │ │ │ ├── preact-testing-library.md │ │ │ │ ├── refs.md │ │ │ │ ├── server-side-rendering.md │ │ │ │ ├── signals.md │ │ │ │ ├── typescript.md │ │ │ │ ├── unit-testing-with-enzyme.md │ │ │ │ ├── upgrade-guide.md │ │ │ │ └── web-components.md │ │ │ └── v8/ │ │ │ ├── api-reference.md │ │ │ ├── differences-to-react.md │ │ │ ├── extending-component.md │ │ │ ├── external-dom-mutations.md │ │ │ ├── forms.md │ │ │ ├── getting-started.md │ │ │ ├── linked-state.md │ │ │ ├── progressive-web-apps.md │ │ │ ├── switching-to-preact.md │ │ │ ├── types-of-components.md │ │ │ └── unit-testing-with-enzyme.md │ │ ├── index.md │ │ ├── repl.md │ │ └── tutorial/ │ │ ├── 01-vdom.md │ │ ├── 02-events.md │ │ ├── 03-components.md │ │ ├── 04-state.md │ │ ├── 05-refs.md │ │ ├── 06-context.md │ │ ├── 07-side-effects.md │ │ ├── 08-keys.md │ │ ├── 09-error-handling.md │ │ ├── 10-links.md │ │ └── index.md │ ├── tr/ │ │ ├── 404.md │ │ ├── about/ │ │ │ ├── browser-support.md │ │ │ ├── demos-examples.md │ │ │ ├── libraries-addons.md │ │ │ ├── project-goals.md │ │ │ └── we-are-using.md │ │ ├── guide/ │ │ │ └── v8/ │ │ │ ├── api-reference.md │ │ │ ├── differences-to-react.md │ │ │ ├── extending-component.md │ │ │ ├── external-dom-mutations.md │ │ │ ├── forms.md │ │ │ ├── getting-started.md │ │ │ ├── linked-state.md │ │ │ ├── progressive-web-apps.md │ │ │ ├── switching-to-preact.md │ │ │ ├── types-of-components.md │ │ │ └── unit-testing-with-enzyme.md │ │ └── index.md │ └── zh/ │ ├── 404.md │ ├── about/ │ │ ├── browser-support.md │ │ ├── demos-examples.md │ │ ├── libraries-addons.md │ │ ├── project-goals.md │ │ └── we-are-using.md │ ├── blog/ │ │ ├── introducing-signals.md │ │ ├── preact-x.md │ │ ├── prerendering-preset-vite.md │ │ ├── signal-boosting.md │ │ └── simplifying-islands-arch.md │ ├── blog.md │ ├── branding.md │ ├── guide/ │ │ ├── v10/ │ │ │ ├── api-reference.md │ │ │ ├── components.md │ │ │ ├── context.md │ │ │ ├── debugging.md │ │ │ ├── differences-to-react.md │ │ │ ├── forms.md │ │ │ ├── getting-started.md │ │ │ ├── hooks.md │ │ │ ├── no-build-workflows.md │ │ │ ├── options.md │ │ │ ├── preact-iso.md │ │ │ ├── preact-testing-library.md │ │ │ ├── refs.md │ │ │ ├── server-side-rendering.md │ │ │ ├── signals.md │ │ │ ├── typescript.md │ │ │ ├── unit-testing-with-enzyme.md │ │ │ ├── upgrade-guide.md │ │ │ ├── web-components.md │ │ │ └── whats-new.md │ │ ├── v11/ │ │ │ ├── api-reference.md │ │ │ ├── components.md │ │ │ ├── context.md │ │ │ ├── debugging.md │ │ │ ├── differences-to-react.md │ │ │ ├── forms.md │ │ │ ├── getting-started.md │ │ │ ├── hooks.md │ │ │ ├── no-build-workflows.md │ │ │ ├── options.md │ │ │ ├── preact-iso.md │ │ │ ├── preact-testing-library.md │ │ │ ├── refs.md │ │ │ ├── server-side-rendering.md │ │ │ ├── signals.md │ │ │ ├── typescript.md │ │ │ ├── unit-testing-with-enzyme.md │ │ │ ├── upgrade-guide.md │ │ │ └── web-components.md │ │ └── v8/ │ │ ├── api-reference.md │ │ ├── differences-to-react.md │ │ ├── extending-component.md │ │ ├── external-dom-mutations.md │ │ ├── forms.md │ │ ├── getting-started.md │ │ ├── linked-state.md │ │ ├── progressive-web-apps.md │ │ ├── switching-to-preact.md │ │ ├── types-of-components.md │ │ └── unit-testing-with-enzyme.md │ ├── index.md │ ├── repl.md │ └── tutorial/ │ ├── 01-vdom.md │ ├── 02-events.md │ ├── 03-components.md │ ├── 04-state.md │ ├── 05-refs.md │ ├── 06-context.md │ ├── 07-side-effects.md │ ├── 08-keys.md │ ├── 09-error-handling.md │ ├── 10-links.md │ └── index.md ├── index.html ├── jsconfig.json ├── package.json ├── plugins/ │ ├── generate-llms-txt.js │ ├── html-routing-middleware.js │ ├── netlify.js │ ├── precompile-markdown/ │ │ ├── gh-emoji/ │ │ │ ├── emoji.json │ │ │ └── index.js │ │ └── index.js │ ├── rss-feed.js │ └── spa-fallback-middleware.js ├── src/ │ ├── analytics.js │ ├── assets/ │ │ ├── .well-known/ │ │ │ └── traffic-advice │ │ ├── _headers │ │ ├── _redirects │ │ ├── contributors.json │ │ └── robots.txt │ ├── components/ │ │ ├── app.jsx │ │ ├── blog-meta/ │ │ │ ├── index.jsx │ │ │ └── style.module.css │ │ ├── blog-overview/ │ │ │ ├── index.jsx │ │ │ └── style.module.css │ │ ├── branding/ │ │ │ ├── index.jsx │ │ │ └── style.module.css │ │ ├── code-editor/ │ │ │ ├── code-mirror.css │ │ │ ├── index.jsx │ │ │ └── style.module.css │ │ ├── content-region/ │ │ │ └── index.jsx │ │ ├── controllers/ │ │ │ ├── blog-page.jsx │ │ │ ├── guide-page.jsx │ │ │ ├── markdown-region.jsx │ │ │ ├── not-found.jsx │ │ │ ├── page.jsx │ │ │ ├── repl/ │ │ │ │ ├── error-overlay.jsx │ │ │ │ ├── error-overlay.module.css │ │ │ │ ├── errors.js │ │ │ │ ├── examples/ │ │ │ │ │ ├── context.txt │ │ │ │ │ ├── counters/ │ │ │ │ │ │ ├── counter-hooks.txt │ │ │ │ │ │ ├── counter-htm.txt │ │ │ │ │ │ ├── counter-signals.txt │ │ │ │ │ │ └── counter.txt │ │ │ │ │ ├── github-repo-list.txt │ │ │ │ │ ├── index.js │ │ │ │ │ ├── spiral.txt │ │ │ │ │ ├── style.css │ │ │ │ │ └── todo-lists/ │ │ │ │ │ ├── todo-list-signals.txt │ │ │ │ │ └── todo-list.txt │ │ │ │ ├── index.jsx │ │ │ │ ├── query-encode.js │ │ │ │ ├── repl.setup.js │ │ │ │ ├── repl.worker.js │ │ │ │ ├── runner.jsx │ │ │ │ ├── style.module.css │ │ │ │ └── window.js │ │ │ ├── repl-page.jsx │ │ │ ├── style.module.css │ │ │ ├── tutorial/ │ │ │ │ ├── contexts.jsx │ │ │ │ ├── index.jsx │ │ │ │ └── style.module.css │ │ │ └── tutorial-page.jsx │ │ ├── doc-version/ │ │ │ ├── index.jsx │ │ │ └── style.module.css │ │ ├── edit-button/ │ │ │ ├── index.jsx │ │ │ └── style.module.css │ │ ├── footer/ │ │ │ ├── index.jsx │ │ │ └── style.module.css │ │ ├── gh-emoji/ │ │ │ └── index.js │ │ ├── github-repos.jsx │ │ ├── header/ │ │ │ ├── corner.jsx │ │ │ ├── corner.module.css │ │ │ ├── gh-version.jsx │ │ │ ├── index.jsx │ │ │ ├── search.jsx │ │ │ └── style.module.css │ │ ├── jumbotron/ │ │ │ ├── index.jsx │ │ │ └── style.module.css │ │ ├── logo.jsx │ │ ├── routes.jsx │ │ ├── sidebar/ │ │ │ ├── index.jsx │ │ │ ├── sidebar-nav.jsx │ │ │ ├── sidebar-nav.module.css │ │ │ └── style.module.css │ │ ├── splitter/ │ │ │ ├── index.jsx │ │ │ └── splitter.module.css │ │ ├── sponsors/ │ │ │ ├── index.jsx │ │ │ └── style.module.css │ │ ├── tab-group/ │ │ │ ├── index.jsx │ │ │ └── style.module.css │ │ ├── table-of-contents/ │ │ │ └── index.jsx │ │ ├── time/ │ │ │ ├── index.jsx │ │ │ └── time.module.css │ │ ├── todo-list.jsx │ │ ├── we-are-using/ │ │ │ ├── index.jsx │ │ │ └── style.module.css │ │ └── widgets.js │ ├── config.json │ ├── index.jsx │ ├── lambda/ │ │ ├── release.js │ │ └── repos.js │ ├── lib/ │ │ ├── content.js │ │ ├── cx.js │ │ ├── frontmatter.js │ │ ├── github.js │ │ ├── i18n.jsx │ │ ├── localstorage.js │ │ ├── page-title.js │ │ ├── prerender-data.jsx │ │ ├── repl.js │ │ ├── toggle-overlay.js │ │ ├── use-content.js │ │ ├── use-delegated-prefetch.js │ │ └── use-resource.js │ ├── locales/ │ │ ├── de.json │ │ ├── en.json │ │ ├── es.json │ │ ├── fr.json │ │ ├── it.json │ │ ├── ja.json │ │ ├── kr.json │ │ ├── pt-br.json │ │ ├── ru.json │ │ ├── tr.json │ │ └── zh.json │ ├── route-config.js │ ├── style/ │ │ ├── buttons.css │ │ ├── docsearch.css │ │ ├── home.css │ │ ├── index.css │ │ ├── list-view.css │ │ ├── markdown.css │ │ ├── prism.css │ │ └── variables.css │ └── types.d.ts └── vite.config.js
SYMBOL INDEX (175 symbols across 66 files)
FILE: plugins/generate-llms-txt.js
function readMarkdownFiles (line 17) | async function readMarkdownFiles(guideDir) {
function generateLlmsTxt (line 35) | function generateLlmsTxt(files) {
function generateLlmsTxtPlugin (line 94) | function generateLlmsTxtPlugin(options = {}) {
FILE: plugins/html-routing-middleware.js
function htmlRoutingMiddlewarePlugin (line 10) | function htmlRoutingMiddlewarePlugin() {
FILE: plugins/netlify.js
function netlifyPlugin (line 8) | function netlifyPlugin() {
FILE: plugins/precompile-markdown/gh-emoji/index.js
constant REG (line 3) | const REG = /([^\\]):([a-z0-9_]+):/gi;
function replace (line 11) | function replace(str) {
FILE: plugins/precompile-markdown/index.js
function precompileMarkdown (line 19) | async function precompileMarkdown(content, path) {
function parseContent (line 41) | function parseContent(content, path) {
method heading (line 65) | heading({ text, depth }) {
method paragraph (line 80) | paragraph({ text }) {
method link (line 91) | link({ href, text }) {
method image (line 98) | image({ href, text }) {
method code (line 101) | code({ text, lang }) {
function markdownToHTML (line 132) | async function markdownToHTML(data) {
function applyEmojiToContent (line 137) | function applyEmojiToContent(data) {
function applyEmoji (line 145) | function applyEmoji(content) {
function generateToc (line 154) | function generateToc(markdown) {
function generateHeadingId (line 173) | function generateHeadingId(text) {
function extractTutorialCodeBlocks (line 186) | function extractTutorialCodeBlocks(markdown) {
function highlightCodeBlocks (line 214) | function highlightCodeBlocks(data) {
function unescapeHTML (line 284) | function unescapeHTML(str) {
function processRepl (line 297) | function processRepl(code) {
FILE: plugins/rss-feed.js
function rssFeedPlugin (line 8) | function rssFeedPlugin() {
FILE: plugins/spa-fallback-middleware.js
function spaFallbackMiddlewarePlugin (line 10) | function spaFallbackMiddlewarePlugin() {
FILE: src/components/app.jsx
function App (line 11) | function App({ prerenderData }) {
FILE: src/components/blog-meta/index.jsx
function BlogMeta (line 9) | function BlogMeta({ meta }) {
function AuthorLinks (line 53) | function AuthorLinks({ authorData, author, i, arr }) {
FILE: src/components/blog-overview/index.jsx
function BlogOverview (line 6) | function BlogOverview() {
FILE: src/components/branding/index.jsx
constant LOGOS (line 3) | const LOGOS = [
function Branding (line 22) | function Branding() {
function LogoVariation (line 32) | function LogoVariation({ name, alt }) {
FILE: src/components/code-editor/index.jsx
function CodeEditor (line 37) | function CodeEditor(props) {
function isViewUpdateFromUserInput (line 100) | function isViewUpdateFromUserInput(viewUpdate) {
FILE: src/components/content-region/index.jsx
constant COMPONENTS (line 6) | const COMPONENTS = {
function ContentRegion (line 10) | function ContentRegion({ content, components, ...props }) {
FILE: src/components/controllers/blog-page.jsx
function BlogPage (line 9) | function BlogPage() {
function BlogLayout (line 20) | function BlogLayout() {
FILE: src/components/controllers/guide-page.jsx
function GuidePage (line 14) | function GuidePage() {
function GuideLayout (line 25) | function GuideLayout() {
function OldDocsWarning (line 51) | function OldDocsWarning() {
constant MAINTAINED_LANGUAGES (line 84) | const MAINTAINED_LANGUAGES = ['en', 'ru', 'zh'];
function UnmaintainedTranslationWarning (line 90) | function UnmaintainedTranslationWarning({ meta }) {
FILE: src/components/controllers/markdown-region.jsx
function MarkdownRegion (line 13) | function MarkdownRegion({ html, meta, components }) {
FILE: src/components/controllers/not-found.jsx
function NotFound (line 6) | function NotFound() {
FILE: src/components/controllers/page.jsx
function Page (line 10) | function Page() {
function PageLayout (line 21) | function PageLayout() {
FILE: src/components/controllers/repl-page.jsx
function ReplPage (line 10) | function ReplPage() {
function getInitialCode (line 37) | async function getInitialCode(query) {
FILE: src/components/controllers/repl/error-overlay.jsx
function ErrorOverlay (line 11) | function ErrorOverlay({ name, message, stack, class: c }) {
FILE: src/components/controllers/repl/errors.js
function parseStackTrace (line 6) | function parseStackTrace(err) {
function patchErrorLocation (line 29) | function patchErrorLocation(err) {
FILE: src/components/controllers/repl/examples/index.js
constant EXAMPLES (line 15) | const EXAMPLES = [
function getExample (line 78) | function getExample(slug, list = EXAMPLES) {
function fetchExample (line 93) | async function fetchExample(slug) {
FILE: src/components/controllers/repl/index.jsx
function Repl (line 16) | function Repl({ code }) {
FILE: src/components/controllers/repl/query-encode.js
function textToBase64 (line 6) | function textToBase64(text) {
function base64ToText (line 16) | function base64ToText(base64) {
FILE: src/components/controllers/repl/repl.worker.js
constant PREPEND (line 7) | const PREPEND = `(function(module,exports){`;
constant IMPORTS (line 10) | const IMPORTS = `import * as $preact from 'preact';
function ping (line 16) | function ping() {
function transpile (line 20) | function transpile(code) {
function bundle (line 79) | async function bundle(sources) {
function get (line 141) | function get(url) {
function process (line 149) | async function process(code, setup) {
FILE: src/components/controllers/repl/runner.jsx
function createRoot (line 16) | function createRoot(doc) {
class Runner (line 22) | class Runner extends Component {
method constructor (line 29) | constructor(props) {
method shouldComponentUpdate (line 34) | shouldComponentUpdate() {
method output (line 39) | get output() {
method componentDidMount (line 60) | componentDidMount() {
method componentWillReceiveProps (line 68) | componentWillReceiveProps({ code, setup }) {
method run (line 75) | run() {
method rebuild (line 92) | async rebuild() {
method setup (line 102) | setup(fresh) {
method setupRealm (line 109) | setupRealm() {
method execute (line 142) | async execute(transpiled, isFallback) {
method render (line 211) | render(props) {
function Realm (line 223) | function Realm({ frame, onError }) {
FILE: src/components/controllers/tutorial-page.jsx
function TutorialPage (line 11) | function TutorialPage() {
function TutorialLayout (line 22) | function TutorialLayout() {
FILE: src/components/controllers/tutorial/contexts.jsx
function SolutionProvider (line 17) | function SolutionProvider({ children }) {
FILE: src/components/controllers/tutorial/index.jsx
function Tutorial (line 43) | function Tutorial({ html, meta }) {
function ButtonContainer (line 217) | function ButtonContainer({ meta, showCode, help }) {
function TutorialSetupBlock (line 249) | function TutorialSetupBlock({ code, runner, useResult, useRealm, useErro...
constant TUTORIAL_COMPONENTS (line 298) | const TUTORIAL_COMPONENTS = {
function Solution (line 303) | function Solution({ children }) {
FILE: src/components/doc-version/index.jsx
constant LATEST_MAJOR (line 6) | const LATEST_MAJOR = 'v10';
constant PREVIEW_MAJOR (line 7) | const PREVIEW_MAJOR = 'v11';
constant AVAILABLE_DOCS (line 8) | const AVAILABLE_DOCS = ['11', '10', '8'];
function DocVersion (line 13) | function DocVersion() {
FILE: src/components/edit-button/index.jsx
function EditThisPage (line 5) | function EditThisPage({ isFallback }) {
FILE: src/components/footer/index.jsx
function useContributors (line 26) | function useContributors() {
function Footer (line 40) | function Footer() {
FILE: src/components/gh-emoji/index.js
constant REG (line 3) | const REG = /\b:([a-z0-9_]+):\b/gi;
function replace (line 7) | function replace(str) {
FILE: src/components/github-repos.jsx
function GitHubRepos (line 5) | function GitHubRepos({ org }) {
function Result (line 26) | function Result(result) {
FILE: src/components/header/corner.jsx
function Corner (line 3) | function Corner() {
FILE: src/components/header/gh-version.jsx
function ReleaseLink (line 6) | function ReleaseLink({ ...props }) {
FILE: src/components/header/index.jsx
function Header (line 14) | function Header() {
function MainNav (line 44) | function MainNav() {
function SocialLinks (line 87) | function SocialLinks() {
function LanguagePicker (line 119) | function LanguagePicker() {
function NavMenu (line 190) | function NavMenu(props) {
function ExpandableNavLink (line 228) | function ExpandableNavLink({ isOpen, label, children, ...rest }) {
function NavLink (line 252) | function NavLink({ href, flair, clsx, isOpen, ...rest }) {
function pathMatchesHref (line 273) | function pathMatchesHref(path, href) {
function pathToI18nLabel (line 290) | function pathToI18nLabel(path) {
FILE: src/components/header/search.jsx
function injectDocsearchCSS (line 17) | function injectDocsearchCSS() {
function waitForDocsearch (line 34) | function waitForDocsearch(root) {
function Search (line 69) | function Search() {
FILE: src/components/logo.jsx
class Logo (line 4) | class Logo extends Component {
method componentDidMount (line 33) | componentDidMount() {
method componentWillUnmount (line 38) | componentWillUnmount() {
method componentDidUpdate (line 44) | componentDidUpdate() {
method renderEllipse (line 48) | renderEllipse(fg, deg, offset) {
method render (line 69) | render(
FILE: src/components/routes.jsx
function Routes (line 34) | function Routes() {
FILE: src/components/sidebar/index.jsx
function Sidebar (line 9) | function Sidebar() {
FILE: src/components/sidebar/sidebar-nav.jsx
function SidebarNav (line 15) | function SidebarNav({ items, onClick }) {
function SidebarGroup (line 61) | function SidebarGroup({ level, children }) {
function SidebarNavLink (line 67) | function SidebarNavLink(props) {
FILE: src/components/splitter/index.jsx
function Splitter (line 19) | function Splitter({
FILE: src/components/sponsors/index.jsx
function Sponsors (line 48) | function Sponsors() {
function SponsorItem (line 58) | function SponsorItem({ link, title, width, height, id }) {
FILE: src/components/tab-group/index.jsx
function TabGroup (line 17) | function TabGroup({ tabstring, children }) {
FILE: src/components/table-of-contents/index.jsx
function Toc (line 7) | function Toc() {
function listToTree (line 32) | function listToTree(arr) {
function TocItem (line 56) | function TocItem(props) {
FILE: src/components/time/index.jsx
function Time (line 3) | function Time({ value }) {
FILE: src/components/todo-list.jsx
class TodoList (line 3) | class TodoList extends Component {
method render (line 19) | render(props, { todos, text }) {
FILE: src/components/we-are-using/index.jsx
function WeAreUsing (line 294) | function WeAreUsing() {
FILE: src/index.jsx
function prerender (line 33) | async function prerender() {
FILE: src/lambda/release.js
function releaseLambda (line 5) | async function releaseLambda(req, _context) {
function checkStatus (line 19) | function checkStatus(r) {
function parseVersion (line 33) | function parseVersion(version) {
FILE: src/lambda/repos.js
function repoLambda (line 25) | async function repoLambda(req, _context) {
FILE: src/lib/content.js
function getContent (line 5) | async function getContent([lang, name]) {
FILE: src/lib/cx.js
function cx (line 1) | function cx() {
FILE: src/lib/frontmatter.js
function parseFrontmatter (line 9) | function parseFrontmatter(content, path = '') {
function cleanReplComments (line 45) | function cleanReplComments(content) {
FILE: src/lib/github.js
function checkStatus (line 7) | function checkStatus(r) {
FILE: src/lib/i18n.jsx
function getNavigatorLanguage (line 34) | function getNavigatorLanguage(available) {
function LanguageProvider (line 48) | function LanguageProvider({ children }) {
function useLanguageContext (line 102) | function useLanguageContext() {
function useTranslate (line 109) | function useTranslate() {
FILE: src/lib/localstorage.js
function useStoredValue (line 24) | function useStoredValue(key, initial, force) {
FILE: src/lib/page-title.js
function createTitle (line 4) | function createTitle(title) {
FILE: src/lib/prerender-data.jsx
function getFallbackData (line 11) | function getFallbackData() {
function PrerenderDataProvider (line 27) | function PrerenderDataProvider({ value, children }) {
function usePrerenderData (line 47) | function usePrerenderData() {
FILE: src/lib/toggle-overlay.js
function useOverlayToggle (line 9) | function useOverlayToggle() {
function setHeight (line 32) | function setHeight() {
function convertRemToPixels (line 37) | function convertRemToPixels(rem) {
FILE: src/lib/use-content.js
function getContentPath (line 20) | function getContentPath(path) {
function useContent (line 30) | function useContent(path) {
function prefetchContent (line 47) | function prefetchContent(path) {
function useTitle (line 62) | function useTitle(title) {
function useDescription (line 80) | function useDescription(text) {
FILE: src/lib/use-delegated-prefetch.js
function useDelegatedPrefetch (line 11) | function useDelegatedPrefetch() {
FILE: src/lib/use-resource.js
constant CACHE (line 12) | const CACHE = new Map();
function useResource (line 15) | function useResource(fn, deps) {
function setupCacheEntry (line 46) | function setupCacheEntry(fn, cacheKey, update) {
FILE: src/route-config.js
constant LIBRARIES (line 52) | const LIBRARIES = {
function flattenRoutes (line 310) | function flattenRoutes(routes) {
FILE: src/types.d.ts
type IntrinsicElements (line 5) | interface IntrinsicElements {
type GitHubOrgRepoData (line 12) | interface GitHubOrgRepoData {
type FilteredRepoData (line 20) | interface FilteredRepoData {
type PrerenderData (line 27) | interface PrerenderData {
type FrontMatterMeta (line 34) | interface FrontMatterMeta {
type TableOfContents (line 50) | interface TableOfContents {
type ContentMetaData (line 57) | interface ContentMetaData extends FrontMatterMeta {
type ContentData (line 71) | interface ContentData {
Condensed preview — 553 files, each showing path, character count, and a content snippet. Download the .json file or copy for the full structured content (3,742K chars).
[
{
"path": ".editorconfig",
"chars": 230,
"preview": "root = true\n\n[*]\nindent_style = tab\nend_of_line = lf\ncharset = utf-8\ntrim_trailing_whitespace = true\ninsert_final_newlin"
},
{
"path": ".github/workflows/ci.yml",
"chars": 647,
"preview": "name: CI\n\non:\n push:\n branches:\n - master\n pull_request:\n branches:\n - master\n\njobs:\n build:\n name"
},
{
"path": ".gitignore",
"chars": 60,
"preview": "/node_modules\n/npm-debug.log\n/build\n.DS_Store\ndist\n*.sw[op]\n"
},
{
"path": ".npmrc",
"chars": 97,
"preview": "; Allow installs to proceed even when peer dependency versions don't align\nlegacy-peer-deps=true\n"
},
{
"path": ".prettierignore",
"chars": 31,
"preview": "package.json\npackage-lock.json\n"
},
{
"path": "CODE_OF_CONDUCT.md",
"chars": 3215,
"preview": "# Contributor Covenant Code of Conduct\n\n## Our Pledge\n\nIn the interest of fostering an open and welcoming environment, w"
},
{
"path": "CONTRIBUTING.md",
"chars": 2784,
"preview": "# Contributing\n\nThanks for contributing to Preact's documentation!\n\n## Repo Setup\n\nTo work on the site locally, you'll w"
},
{
"path": "LICENSE",
"chars": 1087,
"preview": "The MIT License (MIT)\n\nCopyright (c) 2016-present Jason Miller\n\nPermission is hereby granted, free of charge, to any per"
},
{
"path": "README.md",
"chars": 781,
"preview": "# Preact Documentation Website\n\n[![Preact Slack Community](https://img.shields.io/badge/slack-Preact%20Slack%20Community"
},
{
"path": "content/de/404.md",
"chars": 114,
"preview": "---\ntitle: Not Found\n---\n\n# Error\n\nOh, diese Seite gibt es wohl nicht mehr.\n\nZeit [nach Hause](/) zurückzukehren!\n"
},
{
"path": "content/de/about/browser-support.md",
"chars": 515,
"preview": "---\ntitle: Browserunterstützung\n---\n\n# Browserunterstützung\n\nPrect unterstützt moderne Browser (Chrome, Firefox, Safari,"
},
{
"path": "content/de/about/demos-examples.md",
"chars": 4489,
"preview": "---\ntitle: Demos & Beispiele\n---\n\n# Demos & Beispiele\n\nDiese Seite zeigt einige Demos und Beispiele, die zum Erlernen vo"
},
{
"path": "content/de/about/libraries-addons.md",
"chars": 4061,
"preview": "---\ntitle: Bibliotheken & Add-ons\n---\n\n# Bibliotheken & Add-ons\n\n\nEine Auswahl an Modulen, die nahtlos mit Preact funkti"
},
{
"path": "content/de/about/project-goals.md",
"chars": 1292,
"preview": "---\ntitle: Projektziele\n---\n\n# Preacts Ziele\n\n## Ziele\n\nPreact zielt darauf ab, Leistung aufgrund folgender Ziele zu lie"
},
{
"path": "content/de/about/we-are-using.md",
"chars": 504,
"preview": "---\ntitle: Wer benutzt Preact?\n---\n\n# We Are Using\n\nPreact wird von einem breiten Spektrum von Webseiten verwendet: von "
},
{
"path": "content/de/guide/v8/api-reference.md",
"chars": 4560,
"preview": "---\ntitle: API-Referenzierung\n---\n\n# API-Referenzierung\n\n---\n\n<toc></toc>\n\n---\n\n## `Preact.Component`\n\n`Component` ist e"
},
{
"path": "content/de/guide/v8/differences-to-react.md",
"chars": 5813,
"preview": "---\ntitle: Unterschiede zu React\n---\n\n# Unterschiede zu React\n\nPreact selbst soll keine Neuimplementation von React sein"
},
{
"path": "content/de/guide/v8/extending-component.md",
"chars": 2212,
"preview": "---\ntitle: Kompontente erweitern\n---\n\n# Komponente erweitern\n\nEs besteht die Möglichkeit, dass manche Projekte eine Komp"
},
{
"path": "content/de/guide/v8/external-dom-mutations.md",
"chars": 2973,
"preview": "---\ntitle: Externe DOM-Mutationen\n---\n\n# Externe DOM-Mutationen\n\n---\n\n<toc></toc>\n\n---\n\n## Übersicht\n\nManchmal ist es nö"
},
{
"path": "content/de/guide/v8/forms.md",
"chars": 3340,
"preview": "---\ntitle: Eingabemasken\n---\n\n# Eingabemasken\n\nEingabemasken funktionieren in Preact fast genauso wie in React, allerdin"
},
{
"path": "content/de/guide/v8/getting-started.md",
"chars": 7083,
"preview": "---\ntitle: \"Los geht's\"\n---\n\n# Los geht's\n\nDiese Anleitung zeigt, wie man eine einfache tickende Uhr als Komponente erst"
},
{
"path": "content/de/guide/v8/linked-state.md",
"chars": 5973,
"preview": "---\ntitle: Verlinkter State\n---\n\n# Verlinkter State\n\nEin Bereich, den Preact ausführlicher als React behandelt ist das O"
},
{
"path": "content/de/guide/v8/progressive-web-apps.md",
"chars": 7796,
"preview": "---\ntitle: Progressive Web Apps\n---\n\n# Progressive Web Apps\n\nPreact ist eine ausgezeichnete Wahl für [progressive Web Ap"
},
{
"path": "content/de/guide/v8/switching-to-preact.md",
"chars": 12093,
"preview": "---\ntitle: Von React zu Preact wechseln\n---\n\n# (Von React) Zu Preact wechseln\n\nEs gibt zwei verschiedene Herangehensweis"
},
{
"path": "content/de/guide/v8/types-of-components.md",
"chars": 2287,
"preview": "---\ntitle: Komponententypen\n---\n\n# Komponententypen\n\nEs gibt zwei Arten von Komponenten in Preact:\n\n- Klassische Kompone"
},
{
"path": "content/de/guide/v8/unit-testing-with-enzyme.md",
"chars": 2504,
"preview": "---\ntitle: Unit-Prüfung mit Enzyme\n---\n\n# Unit-Prüfung mit Enzyme\n\nReact bietet ein `react-addons-test-utils`-Modul zum "
},
{
"path": "content/de/index.md",
"chars": 9378,
"preview": "---\ntitle: Preact\n---\n\n\n<jumbotron>\n <h1>\n <logo height=\"1.5em\" title=\"Preact\" text=\"true\" inverted=\"true\">Pre"
},
{
"path": "content/en/404.md",
"chars": 98,
"preview": "---\ntitle: Not Found\n---\n\n# Error\n\nYikes, looks like that page vanished.\n\nTime to head [Home](/).\n"
},
{
"path": "content/en/about/browser-support.md",
"chars": 417,
"preview": "---\ntitle: Browser Support\ndescription: Preact supports all modern browsers (Chrome, Firefox, Safari, Edge) out of the b"
},
{
"path": "content/en/about/demos-examples.md",
"chars": 6277,
"preview": "---\ntitle: Demos & Examples\ndescription: Collection of demos and example Preact applications\n---\n\n# Demos & Examples\n\nTh"
},
{
"path": "content/en/about/libraries-addons.md",
"chars": 5830,
"preview": "---\ntitle: Libraries & Add-ons\ndescription: Collection of libraries and addons that work well with Preact\n---\n\n# Librari"
},
{
"path": "content/en/about/project-goals.md",
"chars": 1186,
"preview": "---\ntitle: Project Goals\ndescription: Read more about Preact's project goals\n---\n\n# Preact's Goals\n\n## Goals\n\nPreact aim"
},
{
"path": "content/en/about/we-are-using.md",
"chars": 519,
"preview": "---\ntitle: Who's using Preact?\ndescription: Companies who are proudly using Preact\n---\n\n# Who's using Preact?\n\nPreact is"
},
{
"path": "content/en/blog/introducing-signals.md",
"chars": 13360,
"preview": "---\ntitle: Introducing Signals\ndate: 2022-09-06\nauthors:\n - Marvin Hagemeister\n - Jason Miller\n---\n\n# Introducing Sign"
},
{
"path": "content/en/blog/preact-x.md",
"chars": 9386,
"preview": "---\ntitle: Preact X, a story of stability\ndate: 2024-05-24\nauthors:\n - Jovi De Croock\n---\n\n# Preact X, a story of stabi"
},
{
"path": "content/en/blog/prerendering-preset-vite.md",
"chars": 16590,
"preview": "---\ntitle: Prerendering with `@preact/preset-vite`\ndate: 2024-08-06\nauthors:\n - Ryan Christian\n---\n\n# Prerendering with"
},
{
"path": "content/en/blog/signal-boosting.md",
"chars": 22389,
"preview": "---\ntitle: Signal Boosting\ndate: 2022-09-24\nauthors:\n - Joachim Viide\n---\n\n# Signal Boosting\n\nThe new release of Preact"
},
{
"path": "content/en/blog/simplifying-islands-arch.md",
"chars": 13955,
"preview": "---\ntitle: Simplifying Islands Architecture\ndate: 2024-10-27\nauthors:\n - reaper\n---\n\n> This is a slightly modified vers"
},
{
"path": "content/en/blog.md",
"chars": 456,
"preview": "---\ntitle: Blog\n---\n\nFind out more about what the Preact team is working on.\n\n<div><blog-overview></blog-overview></div>"
},
{
"path": "content/en/branding.md",
"chars": 115,
"preview": "---\ntitle: Branding\n---\n\nDifferent variations of Preact's logo and symbol that you can use.\n\n<branding></branding>\n"
},
{
"path": "content/en/guide/v10/api-reference.md",
"chars": 19753,
"preview": "---\ntitle: API Reference\ndescription: Learn more about all exported functions of the Preact module\n---\n\n# API Reference\n"
},
{
"path": "content/en/guide/v10/components.md",
"chars": 7484,
"preview": "---\ntitle: Components\ndescription: Components are the heart of any Preact application. Learn how to create them and use "
},
{
"path": "content/en/guide/v10/context.md",
"chars": 7231,
"preview": "---\ntitle: Context\ndescription: Context allows you to pass props through intermediate components. This documents describ"
},
{
"path": "content/en/guide/v10/debugging.md",
"chars": 8300,
"preview": "---\ntitle: Debugging Preact Apps\ndescription: How to debug Preact applications when something goes wrong\n---\n\n# Debuggin"
},
{
"path": "content/en/guide/v10/differences-to-react.md",
"chars": 9071,
"preview": "---\ntitle: Differences to React\ndescription: What are the differences between Preact and React. This document describes "
},
{
"path": "content/en/guide/v10/forms.md",
"chars": 12418,
"preview": "---\ntitle: Forms\ndescription: Forms and form controls allow you to collect user input in your application and is a funda"
},
{
"path": "content/en/guide/v10/getting-started.md",
"chars": 9606,
"preview": "---\ntitle: Getting Started\ndescription: How to get started with Preact. We'll learn how to setup the tooling (if any) an"
},
{
"path": "content/en/guide/v10/hooks.md",
"chars": 19102,
"preview": "---\ntitle: Hooks\ndescription: Hooks in Preact allow you to compose behaviours together and re-use that logic in differen"
},
{
"path": "content/en/guide/v10/no-build-workflows.md",
"chars": 6283,
"preview": "---\ntitle: No-Build Workflows\ndescription: Whilst build tools like Webpack, Rollup, and Vite are incredibly powerful and"
},
{
"path": "content/en/guide/v10/options.md",
"chars": 3567,
"preview": "---\ntitle: Option Hooks\ndescription: Preact has several option hooks that allow you to attach callbacks to various stage"
},
{
"path": "content/en/guide/v10/preact-custom-element.md",
"chars": 3637,
"preview": "---\ntitle: preact-custom-element\ndescription: Wrap your Preact component up as a custom element\n---\n\n# preact-custom-ele"
},
{
"path": "content/en/guide/v10/preact-iso.md",
"chars": 16122,
"preview": "---\ntitle: preact-iso\ndescription: preact-iso is a collection of isomorphic async tools for Preact\n---\n\n# preact-iso\n\npr"
},
{
"path": "content/en/guide/v10/preact-root-fragment.md",
"chars": 3921,
"preview": "---\ntitle: preact-root-fragment\ndescription: A standalone Preact 10+ implementation of the deprecated `replaceNode` para"
},
{
"path": "content/en/guide/v10/preact-testing-library.md",
"chars": 10209,
"preview": "---\ntitle: Testing with Preact Testing Library\ndescription: Testing Preact applications made easy with testing-library\n-"
},
{
"path": "content/en/guide/v10/refs.md",
"chars": 6224,
"preview": "---\ntitle: References\ndescription: Refs are a way of creating stable values that are local to a component instance and p"
},
{
"path": "content/en/guide/v10/server-side-rendering.md",
"chars": 6598,
"preview": "---\ntitle: Server-Side Rendering\ndescription: Render your Preact application on the server to show content to users quic"
},
{
"path": "content/en/guide/v10/signals.md",
"chars": 33016,
"preview": "---\ntitle: Signals\ndescription: Composable reactive state with automatic rendering\n---\n\n# Signals\n\nSignals are reactive "
},
{
"path": "content/en/guide/v10/typescript.md",
"chars": 16199,
"preview": "---\ntitle: TypeScript\ndescription: Preact has built-in TypeScript support. Learn how to make use of it!\n---\n\n# TypeScrip"
},
{
"path": "content/en/guide/v10/unit-testing-with-enzyme.md",
"chars": 7924,
"preview": "---\ntitle: Unit Testing with Enzyme\ndescription: Testing Preact applications made easy with enzyme\n---\n\n# Unit Testing w"
},
{
"path": "content/en/guide/v10/upgrade-guide.md",
"chars": 8295,
"preview": "---\ntitle: Upgrading from Preact 8.x\ndescription: Upgrade your Preact 8.x application to Preact X\n---\n\n# Upgrading from "
},
{
"path": "content/en/guide/v10/web-components.md",
"chars": 3755,
"preview": "---\ntitle: Web Components\ndescription: How to use web components with Preact\n---\n\n# Web Components\n\nWeb Components are a"
},
{
"path": "content/en/guide/v10/whats-new.md",
"chars": 4787,
"preview": "---\ntitle: What's new in Preact X\ndescription: New features and changes in Preact X\n---\n\n# What's new in Preact X\n\nPreac"
},
{
"path": "content/en/guide/v11/api-reference.md",
"chars": 19456,
"preview": "---\ntitle: API Reference\ndescription: Learn more about all exported functions of the Preact module\n---\n\n# API Reference\n"
},
{
"path": "content/en/guide/v11/components.md",
"chars": 7484,
"preview": "---\ntitle: Components\ndescription: Components are the heart of any Preact application. Learn how to create them and use "
},
{
"path": "content/en/guide/v11/context.md",
"chars": 7231,
"preview": "---\ntitle: Context\ndescription: Context allows you to pass props through intermediate components. This documents describ"
},
{
"path": "content/en/guide/v11/debugging.md",
"chars": 8300,
"preview": "---\ntitle: Debugging Preact Apps\ndescription: How to debug Preact applications when something goes wrong\n---\n\n# Debuggin"
},
{
"path": "content/en/guide/v11/differences-to-react.md",
"chars": 9071,
"preview": "---\ntitle: Differences to React\ndescription: What are the differences between Preact and React. This document describes "
},
{
"path": "content/en/guide/v11/forms.md",
"chars": 12418,
"preview": "---\ntitle: Forms\ndescription: Forms and form controls allow you to collect user input in your application and is a funda"
},
{
"path": "content/en/guide/v11/getting-started.md",
"chars": 9726,
"preview": "---\ntitle: Getting Started\ndescription: How to get started with Preact. We'll learn how to setup the tooling (if any) an"
},
{
"path": "content/en/guide/v11/hooks.md",
"chars": 15896,
"preview": "---\ntitle: Hooks\ndescription: Hooks in Preact allow you to compose behaviours together and re-use that logic in differen"
},
{
"path": "content/en/guide/v11/no-build-workflows.md",
"chars": 6283,
"preview": "---\ntitle: No-Build Workflows\ndescription: Whilst build tools like Webpack, Rollup, and Vite are incredibly powerful and"
},
{
"path": "content/en/guide/v11/options.md",
"chars": 3567,
"preview": "---\ntitle: Option Hooks\ndescription: Preact has several option hooks that allow you to attach callbacks to various stage"
},
{
"path": "content/en/guide/v11/preact-custom-element.md",
"chars": 3637,
"preview": "---\ntitle: preact-custom-element\ndescription: Wrap your Preact component up as a custom element\n---\n\n# preact-custom-ele"
},
{
"path": "content/en/guide/v11/preact-iso.md",
"chars": 16122,
"preview": "---\ntitle: preact-iso\ndescription: preact-iso is a collection of isomorphic async tools for Preact\n---\n\n# preact-iso\n\npr"
},
{
"path": "content/en/guide/v11/preact-root-fragment.md",
"chars": 3921,
"preview": "---\ntitle: preact-root-fragment\ndescription: A standalone Preact 10+ implementation of the deprecated `replaceNode` para"
},
{
"path": "content/en/guide/v11/preact-testing-library.md",
"chars": 10209,
"preview": "---\ntitle: Testing with Preact Testing Library\ndescription: Testing Preact applications made easy with testing-library\n-"
},
{
"path": "content/en/guide/v11/refs.md",
"chars": 6224,
"preview": "---\ntitle: References\ndescription: Refs are a way of creating stable values that are local to a component instance and p"
},
{
"path": "content/en/guide/v11/server-side-rendering.md",
"chars": 5533,
"preview": "---\ntitle: Server-Side Rendering\ndescription: Render your Preact application on the server to show content to users quic"
},
{
"path": "content/en/guide/v11/signals.md",
"chars": 33016,
"preview": "---\ntitle: Signals\ndescription: Composable reactive state with automatic rendering\n---\n\n# Signals\n\nSignals are reactive "
},
{
"path": "content/en/guide/v11/typescript.md",
"chars": 16453,
"preview": "---\ntitle: TypeScript\ndescription: Preact has built-in TypeScript support. Learn how to make use of it!\n---\n\n# TypeScrip"
},
{
"path": "content/en/guide/v11/unit-testing-with-enzyme.md",
"chars": 7924,
"preview": "---\ntitle: Unit Testing with Enzyme\ndescription: Testing Preact applications made easy with enzyme\n---\n\n# Unit Testing w"
},
{
"path": "content/en/guide/v11/upgrade-guide.md",
"chars": 7454,
"preview": "---\ntitle: Upgrading from Preact 10.x\ndescription: Upgrade your Preact 10.x application to Preact 11\n---\n\n# Upgrading fr"
},
{
"path": "content/en/guide/v11/web-components.md",
"chars": 3755,
"preview": "---\ntitle: Web Components\ndescription: How to use web components with Preact\n---\n\n# Web Components\n\nWeb Components are a"
},
{
"path": "content/en/guide/v8/api-reference.md",
"chars": 3900,
"preview": "---\ntitle: API Reference\n---\n\n# API Reference\n\n---\n\n<toc></toc>\n\n---\n\n## Preact.Component\n\n`Component` is a base class t"
},
{
"path": "content/en/guide/v8/differences-to-react.md",
"chars": 5227,
"preview": "---\ntitle: Differences to React\n---\n\n# Differences to React\n\nPreact itself is not intended to be a reimplementation of R"
},
{
"path": "content/en/guide/v8/extending-component.md",
"chars": 1869,
"preview": "---\ntitle: Extending Component\n---\n\n# Extending Component\n\nIt is possible that some projects would wish to extend Compon"
},
{
"path": "content/en/guide/v8/external-dom-mutations.md",
"chars": 2611,
"preview": "---\ntitle: External DOM Mutations\n---\n\n# External DOM Mutations\n\n## Overview\n\nSometimes there is a need to work with thi"
},
{
"path": "content/en/guide/v8/forms.md",
"chars": 2740,
"preview": "---\ntitle: Forms\n---\n\n# Forms\n\nForms in Preact work much the same as they do in React, except there is no support for th"
},
{
"path": "content/en/guide/v8/getting-started.md",
"chars": 6592,
"preview": "---\ntitle: Getting Started\n---\n\n# Getting Started\n\nThis guide walks through building a simple \"ticking clock\" component."
},
{
"path": "content/en/guide/v8/linked-state.md",
"chars": 4989,
"preview": "---\ntitle: Linked State\n---\n\n# Linked State\n\nOne area Preact takes a little further than React is in optimizing state ch"
},
{
"path": "content/en/guide/v8/progressive-web-apps.md",
"chars": 6599,
"preview": "---\ntitle: Progressive Web Apps\n---\n\n# Progressive Web Apps\n\nPreact is an excellent choice for [Progressive Web Apps](ht"
},
{
"path": "content/en/guide/v8/switching-to-preact.md",
"chars": 10758,
"preview": "---\ntitle: Switching to Preact from React\n---\n\n# Switching to Preact (from React)\n\nThere are two different approaches to"
},
{
"path": "content/en/guide/v8/types-of-components.md",
"chars": 2086,
"preview": "---\ntitle: Types of Components\n---\n\n# Types of Components\n\nThere two types of components in Preact:\n\n- Classical Compone"
},
{
"path": "content/en/guide/v8/unit-testing-with-enzyme.md",
"chars": 7643,
"preview": "---\ntitle: Unit Testing with Enzyme\ndescription: Testing Preact applications made easy with enzyme\n---\n\n# Unit Testing w"
},
{
"path": "content/en/index.md",
"chars": 9049,
"preview": "---\ntitle: Preact\ndescription: Fast 3kB alternative to React with the same modern API\n---\n\n<jumbotron>\n <h1>\n "
},
{
"path": "content/en/repl.md",
"chars": 124,
"preview": "---\ntitle: 'REPL: Try Preact in the browser'\ndescription: Try Preact instantly using our simple in-browser editor / IDE\n"
},
{
"path": "content/en/tutorial/01-vdom.md",
"chars": 7812,
"preview": "---\ntitle: Virtual DOM\nprev: /tutorial\nnext: /tutorial/02-events\nsolvable: true\n---\n\n# Virtual DOM\n\nYou might have heard"
},
{
"path": "content/en/tutorial/02-events.md",
"chars": 2834,
"preview": "---\ntitle: Events\nprev: /tutorial/01-vdom\nnext: /tutorial/03-components\nsolvable: true\n---\n\n# Events\n\nEvents are how we "
},
{
"path": "content/en/tutorial/03-components.md",
"chars": 9433,
"preview": "---\ntitle: Components\nprev: /tutorial/02-events\nnext: /tutorial/04-state\nsolvable: true\n---\n\n# Components\n\nAs we alluded"
},
{
"path": "content/en/tutorial/04-state.md",
"chars": 6873,
"preview": "---\ntitle: State\nprev: /tutorial/03-components\nnext: /tutorial/05-refs\nsolvable: true\n---\n\n# State\n\nNow that we know how"
},
{
"path": "content/en/tutorial/05-refs.md",
"chars": 5399,
"preview": "---\ntitle: Refs\nprev: /tutorial/04-state\nnext: /tutorial/06-context\nsolvable: true\n---\n\n# Refs\n\nAs we learned in the fir"
},
{
"path": "content/en/tutorial/06-context.md",
"chars": 9962,
"preview": "---\ntitle: Context\nprev: /tutorial/05-refs\nnext: /tutorial/07-side-effects\nsolvable: true\n---\n\n# Context\n\nAs an applicat"
},
{
"path": "content/en/tutorial/07-side-effects.md",
"chars": 5447,
"preview": "---\ntitle: Side Effects\nprev: /tutorial/06-context\nnext: /tutorial/08-keys\nsolvable: true\n---\n\n# Side Effects\n\nSide effe"
},
{
"path": "content/en/tutorial/08-keys.md",
"chars": 9287,
"preview": "---\ntitle: Keys\nprev: /tutorial/07-side-effects\nnext: /tutorial/09-error-handling\nsolvable: true\n---\n\n# Keys\n\nIn chapter"
},
{
"path": "content/en/tutorial/09-error-handling.md",
"chars": 4888,
"preview": "---\ntitle: Error Handling\nprev: /tutorial/08-keys\nnext: /tutorial/10-links\nsolvable: true\n---\n\n# Error Handling\n\nJavaScr"
},
{
"path": "content/en/tutorial/10-links.md",
"chars": 2350,
"preview": "---\ntitle: Congratulations!\nprev: /tutorial/09-error-handling\nsolvable: false\n---\n\n# Congratulations!\n\nYou've completed "
},
{
"path": "content/en/tutorial/index.md",
"chars": 1342,
"preview": "---\ntitle: Learn Preact\nnext: /tutorial/01-vdom\ncode: false\nsolvable: false\n---\n\n# Learn Preact\n\nHave you ever wondered "
},
{
"path": "content/es/404.md",
"chars": 98,
"preview": "---\ntitle: Not Found\n---\n\n# Error\n\nOps, parece que esta página no existe.\n\nVolver al [Inicio](/).\n"
},
{
"path": "content/es/about/browser-support.md",
"chars": 466,
"preview": "---\ntitle: Browser Support\n---\n\n# Soporte de navegadores\n\nPreact ofrece soporte para navegadores modernos (Chrome, Firef"
},
{
"path": "content/es/about/demos-examples.md",
"chars": 3408,
"preview": "---\ntitle: Demos & Examples\n---\n\n# Demostraciones y Ejemplos\n\nEsta página contiene una serie de demos y ejemplos que pue"
},
{
"path": "content/es/about/libraries-addons.md",
"chars": 3381,
"preview": "---\ntitle: Libraries & Add-ons\n---\n\n# Librerías y complementos\n\nUna colección de módulos construidos para trabajar perfe"
},
{
"path": "content/es/about/project-goals.md",
"chars": 1240,
"preview": "---\ntitle: Project Goals\n---\n\n# Objetivos del proyecto\n\n## Objetivos\n\nPreact tiene como objetivo cumplir con los siguien"
},
{
"path": "content/es/about/we-are-using.md",
"chars": 487,
"preview": "---\ntitle: ¿Quién está usando Preact?\n---\n\n# We Are Using\n\nPreact es utilizado por muchos sitios web, desde proyectos de"
},
{
"path": "content/es/blog/introducing-signals.md",
"chars": 15025,
"preview": "---\ntitle: Introduciendo los Signals\ndate: 2022-09-06\nauthors:\n - Marvin Hagemeister\n - Jason Miller\ntranslation_by:\n "
},
{
"path": "content/es/blog/preact-x.md",
"chars": 10882,
"preview": "---\ntitle: Preact X, una historia de estabilidad\ndate: 2024-05-24\nauthors:\n - Jovi De Croock\ntranslation_by:\n - Ezequi"
},
{
"path": "content/es/blog/prerendering-preset-vite.md",
"chars": 18427,
"preview": "---\ntitle: Prerendering with `@preact/preset-vite`\ndate: 2024-08-06\nauthors:\n - Ryan Christian\ntranslation_by:\n - Ezeq"
},
{
"path": "content/es/blog/signal-boosting.md",
"chars": 24968,
"preview": "---\ntitle: El impulso de signal\ndate: 2022-09-24\nauthors:\n - Joachim Viide\ntranslation_by:\n - Ivan Ulloque\n---\n\n# El i"
},
{
"path": "content/es/blog/simplifying-islands-arch.md",
"chars": 14448,
"preview": "---\ntitle: Simplificando la arquitectura de Islas\ndate: 2024-10-27\nauthors:\n - reaper\ntranslation_by:\n - Ezequiel Mast"
},
{
"path": "content/es/blog.md",
"chars": 507,
"preview": "---\ntitle: Blog\n---\n\nDescubra más acerca de en qué está trabajando el equipo de Preact.\n\n<div><blog-overview></blog-over"
},
{
"path": "content/es/branding.md",
"chars": 128,
"preview": "---\ntitle: Branding\n---\n\nDiferentes variaciones del logotipo y el símbolo de Preact que puedes utilizar.\n\n<branding></br"
},
{
"path": "content/es/guide/v10/components.md",
"chars": 6697,
"preview": "---\ntitle: Componentes\ndescription: Los componentes son el corazón de cualquier aplicación de Preact. Aprenda como crear"
},
{
"path": "content/es/guide/v10/forms.md",
"chars": 6112,
"preview": "---\ntitle: Forms\ndescription: La forma de construir formularios en Preact que siempre funcionen\n---\n\n# Formularios\n\nLos "
},
{
"path": "content/es/guide/v10/getting-started.md",
"chars": 4995,
"preview": "---\ntitle: Primeros pasos\n---\n\n# Primeros pasos\n\nEsta guía lo ayuda a comenzar a desarrollar aplicaciones Preact. Hay 3 "
},
{
"path": "content/es/guide/v10/hooks.md",
"chars": 15838,
"preview": "---\ntitle: Hooks\ndescription: Los hooks en Preact te ayudan a componer distintos comportamientos y reutilizar esa lógica"
},
{
"path": "content/es/guide/v10/upgrade-guide.md",
"chars": 8855,
"preview": "---\ntitle: Actualización desde Preact 8.x\ndescription: Actualice su aplicación Preact 8.x a Preact X\n---\n\n# Actualizació"
},
{
"path": "content/es/guide/v10/whats-new.md",
"chars": 5240,
"preview": "---\ntitle: Novedades de Preact X\ndescription: Nuevas funciones y cambios en Preact X\n---\n\n# Novedades de Preact X\n\nPreac"
},
{
"path": "content/es/guide/v11/api-reference.md",
"chars": 20366,
"preview": "---\ntitle: Referencia de la API\ndescription: Aprende más sobre todas las funciones exportadas del módulo Preact\ntranslat"
},
{
"path": "content/es/guide/v11/components.md",
"chars": 7817,
"preview": "---\ntitle: Componentes\ndescription: Los componentes son el corazón de cualquier aplicación Preact. Aprende a crearlos y "
},
{
"path": "content/es/guide/v11/context.md",
"chars": 7602,
"preview": "---\ntitle: Context\ndescription: Context te permite pasar props a través de componentes intermedios. Este documento descr"
},
{
"path": "content/es/guide/v11/debugging.md",
"chars": 9033,
"preview": "---\ntitle: Depuración de Aplicaciones Preact\ndescription: Cómo depurar aplicaciones Preact cuando algo sale mal\ntranslat"
},
{
"path": "content/es/guide/v11/differences-to-react.md",
"chars": 10057,
"preview": "---\ntitle: Diferencias con React\ndescription: Cuáles son las diferencias entre Preact y React. Este documento las descri"
},
{
"path": "content/es/guide/v11/forms.md",
"chars": 13013,
"preview": "---\ntitle: Formularios\ndescription: Los formularios y controles de formulario te permiten recopilar entrada del usuario "
},
{
"path": "content/es/guide/v11/getting-started.md",
"chars": 10502,
"preview": "---\ntitle: Comenzando\ndescription: Cómo empezar con Preact. Aprenderemos cómo configurar las herramientas (si las hay) y"
},
{
"path": "content/es/guide/v11/hooks.md",
"chars": 16877,
"preview": "---\ntitle: Hooks\ndescription: Los Hooks en Preact te permiten componer comportamientos juntos y reutilizar esa lógica en"
},
{
"path": "content/es/guide/v11/no-build-workflows.md",
"chars": 7014,
"preview": "---\ntitle: Flujos de Trabajo sin Compilación\ndescription: Aunque herramientas de compilación como Webpack, Rollup y Vite"
},
{
"path": "content/es/guide/v11/options.md",
"chars": 3916,
"preview": "---\ntitle: Hooks de Opción\ndescription: Preact tiene varios hooks de opción que te permiten adjuntar callbacks a varias "
},
{
"path": "content/es/guide/v11/preact-custom-element.md",
"chars": 3980,
"preview": "---\ntitle: preact-custom-element\ndescription: Envuelve tu componente Preact como un elemento personalizado\ntranslation_b"
},
{
"path": "content/es/guide/v11/preact-iso.md",
"chars": 17419,
"preview": "---\ntitle: preact-iso\ndescription: preact-iso es una colección de herramientas isómorfás asíncronas para Preact\ntranslat"
},
{
"path": "content/es/guide/v11/preact-root-fragment.md",
"chars": 4074,
"preview": "---\ntitle: preact-root-fragment\ndescription: Una implementación independiente y heredada de Preact 10+ del parámetro dep"
},
{
"path": "content/es/guide/v11/preact-testing-library.md",
"chars": 10896,
"preview": "---\ntitle: Pruebas con Preact Testing Library\ndescription: Pruebas de aplicaciones Preact hechas fáciles con testing-lib"
},
{
"path": "content/es/guide/v11/refs.md",
"chars": 6614,
"preview": "---\ntitle: Referencias\ndescription: Las Refs son una forma de crear valores estables que son locales a una instancia de "
},
{
"path": "content/es/guide/v11/server-side-rendering.md",
"chars": 5839,
"preview": "---\ntitle: Renderizado en el Servidor\ndescription: Renderiza tu aplicación Preact en el servidor para mostrar contenido "
},
{
"path": "content/es/guide/v11/signals.md",
"chars": 36039,
"preview": "---\ntitle: Señales\ndescription: Estado reactivo composable con renderizado automático\ntranslation_by:\n - Ezequiel Mastr"
},
{
"path": "content/es/guide/v11/typescript.md",
"chars": 17544,
"preview": "---\ntitle: TypeScript\ndescription: Preact tiene soporte integrado de TypeScript. ¡Aprende cómo usarlo!\ntranslation_by:\n "
},
{
"path": "content/es/guide/v11/unit-testing-with-enzyme.md",
"chars": 8888,
"preview": "---\ntitle: Prueba Unitaria con Enzyme\ndescription: Pruebas de aplicaciones Preact hechas fáciles con enzyme\ntranslation_"
},
{
"path": "content/es/guide/v11/upgrade-guide.md",
"chars": 8223,
"preview": "---\ntitle: Actualizar desde Preact 10.x\ndescription: Actualiza tu aplicación Preact 10.x a Preact 11\ntranslation_by:\n -"
},
{
"path": "content/es/guide/v11/web-components.md",
"chars": 4291,
"preview": "---\ntitle: Web Components\ndescription: Cómo usar web components con Preact\ntranslation_by:\n - Ezequiel Mastropietro\n---"
},
{
"path": "content/es/guide/v8/api-reference.md",
"chars": 1207,
"preview": "---\ntitle: Referencia de la API\n---\n\n# Referencia de la API\n\n---\n\n<toc></toc>\n\n---\n\n## `Preact.Component`\n\n### Métodos d"
},
{
"path": "content/es/guide/v8/differences-to-react.md",
"chars": 5711,
"preview": "---\ntitle: Diferencias con React\n---\n\n# Diferencias con React\n\nPreact no pretende ser una reimplementación de React. Exi"
},
{
"path": "content/es/guide/v8/extending-component.md",
"chars": 2099,
"preview": "---\ntitle: Extendiendo Component\n---\n\n# Extendiendo `Component`\n\nEs posible que en algunos proyectos quieras extender `C"
},
{
"path": "content/es/guide/v8/external-dom-mutations.md",
"chars": 2771,
"preview": "---\ntitle: Mutaciones externas del DOM\n---\n\n# Mutaciones externas del DOM\n\nA veces existe la necesidad de trabajar con l"
},
{
"path": "content/es/guide/v8/forms.md",
"chars": 3213,
"preview": "---\ntitle: Forms\n---\n\n# Formularios\n\nLos Formularios en Preact funcionan de la misma manera que en React, excepto que no"
},
{
"path": "content/es/guide/v8/getting-started.md",
"chars": 6735,
"preview": "---\ntitle: Getting Started\n---\n\n# Primeros pasos\n\nEn esta guía vamos a ver cómo crear un simple componente de \"Reloj\". P"
},
{
"path": "content/es/guide/v8/linked-state.md",
"chars": 5171,
"preview": "---\ntitle: Estado asociado\n---\n\n# Estado asociado\n\nHay un área de Preact que va un poco más allá que React a la hora de "
},
{
"path": "content/es/guide/v8/progressive-web-apps.md",
"chars": 5569,
"preview": "---\ntitle: Progressive Web Apps\n---\n\n# Progressive Web Apps\n\nPreact es una excelente elección para [Progressive Web Apps"
},
{
"path": "content/es/guide/v8/switching-to-preact.md",
"chars": 8791,
"preview": "---\ntitle: Cambiando a Preact\n---\n\n# Cambiar a Preact (desde React)\n\nHay dos formas distintas de moverse de React a Prea"
},
{
"path": "content/es/guide/v8/types-of-components.md",
"chars": 2305,
"preview": "---\ntitle: Types of Components\n---\n\n# Tipos de Componentes\n\nHay dos tipos de componentes en Preact:\n\n- Componentes clási"
},
{
"path": "content/es/guide/v8/unit-testing-with-enzyme.md",
"chars": 2533,
"preview": "---\ntitle: Prueba unitaria con Enzyme\n---\n\n# Prueba unitaria con Enzyme\n\n`React` proporciona un módulo `reac-addons-test"
},
{
"path": "content/es/index.md",
"chars": 9218,
"preview": "---\ntitle: Preact\n---\n\n\n<jumbotron>\n <h1>\n <logo height=\"1.5em\" title=\"Preact\" text=\"true\" inverted=\"true\">Pre"
},
{
"path": "content/fr/404.md",
"chars": 121,
"preview": "---\ntitle: Not Found\n---\n\n# Erreur\n\nOops, on dirait que cette page a disparu.\n\nIl est temps de revenir à l'[accueil](/)."
},
{
"path": "content/fr/about/browser-support.md",
"chars": 501,
"preview": "---\ntitle: Support des navigateurs\n---\n\n# Support des navigateurs\n\nPreact supporte les navigateurs modernes (Chrome, Fir"
},
{
"path": "content/fr/about/demos-examples.md",
"chars": 4546,
"preview": "---\ntitle: Démos et Exemples\n---\n\n# Démos et Exemples\n\nCette page liste un certain nombre de démos et d'exemples utiles "
},
{
"path": "content/fr/about/libraries-addons.md",
"chars": 6574,
"preview": "---\ntitle: Bibliothèques et modules complémentaires\n---\n\n# Bibliothèques et modules complémentaires\n\nUne liste de module"
},
{
"path": "content/fr/about/project-goals.md",
"chars": 1338,
"preview": "---\ntitle: Les objectifs de Preact\n---\n\n# Les objectifs de Preact\n\n## Objectifs\n\nPreact vise à remplir certains objectif"
},
{
"path": "content/fr/about/we-are-using.md",
"chars": 481,
"preview": "---\ntitle: Qui utilise Preact ?\n---\n\n# We Are Using\n\nPreact est utilisé par un large spectre de sites web, de projets Op"
},
{
"path": "content/fr/guide/v8/api-reference.md",
"chars": 4218,
"preview": "---\ntitle: Référence API\n---\n\n# Référence API\n\n---\n\n<toc></toc>\n\n---\n\n## `Preact.Component`\n\n`Component` est une classe "
},
{
"path": "content/fr/guide/v8/differences-to-react.md",
"chars": 6122,
"preview": "---\ntitle: Différences avec React\n---\n\n# Différences avec React\n\nEn soit, Preact n'a pas pour but d'être une réimplément"
},
{
"path": "content/fr/guide/v8/extending-component.md",
"chars": 2161,
"preview": "---\ntitle: Étendre le composant de base\n---\n\n# Étendre le composant de base\n\nIl est possible que certains projets souhai"
},
{
"path": "content/fr/guide/v8/external-dom-mutations.md",
"chars": 2931,
"preview": "---\ntitle: Modification Externe du DOM\n---\n\n# Modification Externe du DOM\n\nParfois vous avez besoin de travailler avec d"
},
{
"path": "content/fr/guide/v8/forms.md",
"chars": 3385,
"preview": "---\ntitle: Formulaires\n---\n\n# Formulaires\n\nDans Preact, les formulaires fonctionnent globalement de la même façon que da"
},
{
"path": "content/fr/guide/v8/getting-started.md",
"chars": 6703,
"preview": "---\ntitle: Commencer\n---\n\n# Commencer\n\nDans ce guide, nous allons créer un simple composant d'horloge. Vous pouvez trouv"
},
{
"path": "content/fr/guide/v8/linked-state.md",
"chars": 5638,
"preview": "---\ntitle: Etat lié\n---\n\n# Etat lié\n\nUn point sur lequel Preact va un peu plus loin que React est l'optimisation des cha"
},
{
"path": "content/fr/guide/v8/progressive-web-apps.md",
"chars": 7314,
"preview": "---\ntitle: Progressive Web Apps\n---\n\n# Progressive Web Apps\n\n## Vue d'ensemble\n\nPreact est un excellent choix pour les ["
},
{
"path": "content/fr/guide/v8/switching-to-preact.md",
"chars": 11615,
"preview": "---\ntitle: Passer à Preact (à partir de React)\n---\n\n# Passer à Preact (à partir de React)\n\nIl y a deux approches différe"
},
{
"path": "content/fr/guide/v8/types-of-components.md",
"chars": 2327,
"preview": "---\ntitle: Types de composants\n---\n\n# Types de composants\n\nIl y a deux types de composants dans Preact :\n\n- Les composan"
},
{
"path": "content/fr/guide/v8/unit-testing-with-enzyme.md",
"chars": 2773,
"preview": "---\ntitle: Tests unitaires avec Enzyme\n---\n\n# Tests unitaires avec Enzyme\n\nReact fournit un module `react-addons-test-ut"
},
{
"path": "content/fr/index.md",
"chars": 9254,
"preview": "---\ntitle: Preact\n---\n\n<jumbotron>\n <h1>\n <logo height=\"1.5em\" title=\"Preact\" text=\"true\" inverted=\"true\">Prea"
},
{
"path": "content/it/blog/introducing-signals.md",
"chars": 15367,
"preview": "---\ntitle: Introduzione ai Signals\ndate: 2023-11-01\nauthors:\n - Marvin Hagemeister\n - Jason Miller\ntranslation_by:\n -"
},
{
"path": "content/it/guide/v8/getting-started.md",
"chars": 7080,
"preview": "---\ntitle: Getting Started\n---\n\n# Primi passi\n\nIn questa guida vedremo come creare un semplice componente \"Orologio\". In"
},
{
"path": "content/it/index.md",
"chars": 9325,
"preview": "---\ntitle: Preact\n---\n\n\n<jumbotron>\n <h1>\n <logo height=\"1.5em\" title=\"Preact\" text=\"true\" inverted=\"true\">Pre"
},
{
"path": "content/ja/404.md",
"chars": 72,
"preview": "---\ntitle: Not Found\n---\n\n# エラー\n\nおっと、このページは消えたみたいです。\n\n[ホーム](/)に向かいましょう。\n"
},
{
"path": "content/ja/about/browser-support.md",
"chars": 209,
"preview": "---\ntitle: ブラウザのサポート\ndescription: Preactはそのままですべてのモダンブラウザ(Chrome, Firefox, Safari, Edge)とIE11をサポートします。\n---\n\n# ブラウザのサポート\n"
},
{
"path": "content/ja/about/project-goals.md",
"chars": 709,
"preview": "---\ntitle: プロジェクトの目的\ndescription: Preactプロジェクトの目的について詳しく知る\n---\n\n# Preactの目的\n\n## 目的\n\nPreactは以下の目的を達成することを目指しています。\n\n- **パフ"
},
{
"path": "content/ja/about/we-are-using.md",
"chars": 356,
"preview": "---\ntitle: Preactを使っている企業\ndescription: Preactを使っている企業\n---\n\n# Preactを使っている企業\n\nPreactはオープンソースから大きな多国籍企業まで幅広いウェブサイトに使われています"
},
{
"path": "content/ja/guide/v10/api-reference.md",
"chars": 4958,
"preview": "---\ntitle: APIリファレンス\ndescription: Preactモジュールでエクスポートされているすべての関数について詳しく学びましょう。\n---\n\n# APIリファレンス\n\nこのページはPreactで提供されているすべての"
},
{
"path": "content/ja/guide/v10/components.md",
"chars": 4442,
"preview": "---\ntitle: コンポーネント\ndescription: コンポーネントはPreactアプリケーションの心臓部です。コンポーネントを作成して、それらを連携してUIを構成する方法を学びましょう。\n---\n\n# コンポーネント\n\nコンポー"
},
{
"path": "content/ja/guide/v10/context.md",
"chars": 2041,
"preview": "---\ntitle: コンテキスト(Context)\ndescription: コンテキストは間にあるコンポーネントを飛ばしてpropsを渡すことができます。このドキュメントは新しいAPIと古いAPIの両方を説明します。\n---\n\n# コン"
},
{
"path": "content/ja/guide/v10/debugging.md",
"chars": 5167,
"preview": "---\ntitle: Preactアプリケーションのデバッグ\ndescription: 問題が起きたときにPreactアプリケーションをデバッグする方法\n---\n\n# Preactアプリケーションのデバッグ\n\nPreactにはデバックを容易"
},
{
"path": "content/ja/guide/v10/differences-to-react.md",
"chars": 4456,
"preview": "---\ntitle: Reactとの違い\ndescription: ReactとPreactの違いは何でしょう。このドキュメントはそれらを詳細に解説します。\n---\n\n# Reactとの違い\n\nPreactはReactの再実装ではありません"
},
{
"path": "content/ja/guide/v10/forms.md",
"chars": 2576,
"preview": "---\ntitle: フォーム\ndescription: Preactでどこでも動作する素晴らしいフォームを作成する方法\n---\n\n# フォーム\n\nPreactのフォームとHTMLのフォームは、ほとんど同じように動作します。両方ともコントロ"
},
{
"path": "content/ja/guide/v10/getting-started.md",
"chars": 4165,
"preview": "---\ntitle: はじめに\ndescription: 初歩的なPreactの使い方の説明をします。ここではツールの設定やアプリケーションを書く方法を説明します。\n---\n\n# はじめに\n\nこのガイドはPreact初心者向けの内容です。\n"
},
{
"path": "content/ja/guide/v10/hooks.md",
"chars": 9065,
"preview": "---\ntitle: フック(Hooks)\ndescription: フックは処理を組み合わせて処理を作ることや異なるコンポーネントでその処理を使い回すことを可能にします。\n---\n\n# フック(Hooks)\n\nフック(Hooks)はステー"
},
{
"path": "content/ja/guide/v10/options.md",
"chars": 2408,
"preview": "---\ntitle: オプションフック\ndescription: Preactにはいつくかのオプションフックがあります。それらを使うと差分処理の各段階で実行されるコールバック関数をセットすることができます。\n---\n\n# オプションフック\n"
},
{
"path": "content/ja/guide/v10/preact-testing-library.md",
"chars": 8135,
"preview": "---\ntitle: Preact Testing Libraryを使ったテスト\ndescription: Testing Libraryを使用してPreactアプリケーションのテストを容易にする\n---\n\n# Preact Testing"
},
{
"path": "content/ja/guide/v10/refs.md",
"chars": 2275,
"preview": "---\ntitle: リファレンス(Ref) \ndescription: Preactがレンダリングした生のDOM Nodeにアクセスするにはリファレンス(Ref)を使います。\n---\n\n# リファレンス(Ref)\n\nPreactがレンダリ"
},
{
"path": "content/ja/guide/v10/server-side-rendering.md",
"chars": 1719,
"preview": "---\ntitle: サーバサイドレンダリング\ndescription: サーバでPreactアプリケーションをレンダリングして高速に表示します。\n---\n\n# サーバサイドレンダリング\n\nサーバサイドレンダリング(よくSSRと略される)を"
},
{
"path": "content/ja/guide/v10/unit-testing-with-enzyme.md",
"chars": 5479,
"preview": "---\ntitle: Enzymeを使った単体テスト\ndescription: Enzymeを使ってPreactアプリケーションの単体テストを行う。\n---\n\n# Enzymeを使った単体テスト\n\nAirbnbの[Enzyme](https"
},
{
"path": "content/ja/guide/v10/upgrade-guide.md",
"chars": 5936,
"preview": "---\ntitle: Preact 8.xからのアップグレード\ndescription: Preact 8.xからPreact Xにアップグレードする\n---\n\n# Preact 8.xからのアップグレード\n\nこのドキュメントはPreact"
},
{
"path": "content/ja/guide/v10/web-components.md",
"chars": 4858,
"preview": "---\ntitle: Webコンポーネント\ndescription: WebコンポーネントとPreactを連携させる方法\n---\n\n# Webコンポーネント\n\nPreactはサイズが小さくて標準を尊重しているので、Webコンポーネントの構築"
},
{
"path": "content/ja/guide/v10/whats-new.md",
"chars": 3414,
"preview": "---\ntitle: Preact Xの新機能\ndescription: Preact Xの新機能と変更点\n---\n\n# Preact Xの新機能\n\nPreact XはPreact 8.xから大きく前進しました。私達はコードの隅々まで見直し"
}
]
// ... and 353 more files (download for full content)
About this extraction
This page contains the full source code of the preactjs/preact-www GitHub repository, extracted and formatted as plain text for AI agents and large language models (LLMs). The extraction includes 553 files (2.8 MB), approximately 769.1k tokens, and a symbol index with 175 extracted functions, classes, methods, constants, and types. Use this with OpenClaw, Claude, ChatGPT, Cursor, Windsurf, or any other AI tool that accepts text input. You can copy the full output to your clipboard or download it as a .txt file.
Extracted by GitExtract — free GitHub repo to text converter for AI. Built by Nikandr Surkov.