| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* chore: use monorepo
* chore: scaffold astro-scripts
* chore: move tests inside packages/astro
* chore: refactor tests, add scripts
* chore: move parser to own module
* chore: move runtime to packages/astro
* fix: move parser to own package
* test: fix prettier-plugin-astro tests
* fix: tests
* chore: update package-lock
* chore: add changesets
* fix: cleanup examples
* fix: starter example
* chore: update changeset config
* chore: update changeset config
* chore: setup changeset release workflow
* chore: bump lockfiles
* chore: prism => astro-prism
* fix: tsc --emitDeclarationOnly
* chore: final cleanup, switch to yarn
* chore: add lerna
* chore: update workflows to yarn
* chore: update workflows
* chore: remove lint workflow
* chore: add astro-dev script
* chore: add symlinked README
|
|
|
|
* Fix visible components
The wrapper component is grabbed with querySelector, so no need for `.item()` call which was throwing.
* Add back in display contents
|
|
|
|
* chore(examples): add kitchen-sink
* feat: support children in rendered components
* feat: add support for rendering children in Svelte
* fix: cleanup p/react fragment children
* chore: add @ts-nocheck to svelte files
* chore: update lockfiles
* fix: types
* feat: memoize frontend/renderer/utils
* fix: disable eslint for compiled SvelteWrapper
* fix: add missing dep
Co-authored-by: Nate Moore <nate@skypack.dev>
|
|
* Improve renderer types
Looking at the render code I noticed that the Component rendering is not typed. This adds that, might help prevent a bug in the future.
* Create the supported renderer type
|
|
|
|
* Fix React import
* Change default export
* Fix :visible dynamic component
* Use colon to alias vue createElement
Co-authored-by: Matthew Phillips <matthew@skypack.dev>
|
|
|
|
|
|
* Implement fallback capability
This makes it possible for a dynamic component to render fallback content on the server.
The mechanism is a special `static` prop passed to the component. If `static` is true then the component knows it can render static content.
Putting aside the word `static`, is this the right approach? I think giving components the flexibility to make the decision themselves *is* the right approach.
However in this case we have a special property that is passed in non-explicitly. I think we have to do it this way because if the caller passes in a prop it will get serialized and appear on the client. By making this something we *add* during rendering, it only happens on the server (and only when using `:load`).
Assuming this is the right approach, is `static` the right name for this prop? Other candidates:
* `server`
That's all I have!
* Use `import.meta.env.astro` to tell if running in SSR mode.
* Run formatter
|
|
Previously dynamic component URLs were being resolved client-side in a weird way that only worked during dev. This change makes them handle during compilation, so it works in both (and improves readability of the dynamic import output).
|
|
* WIP: new hydration methods
* refactor: genericize load/idle/visible renderers
* fix: do not pass "data-astro-id" to component
* docs: add hydration section to README
* docs: update README
Co-authored-by: Nate Moore <nate@skypack.dev>
|
Nate Moore
Nate Moore
Matthew Phillips
Drew Powers
