astro/test
Matthew Phillips d9084ff4ad
Implement fallback capability (#44)
* 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
2021-03-31 16:10:27 -04:00
..
fixtures Implement fallback capability (#44) 2021-03-31 16:10:27 -04:00
astro-basic.test.js [ci] npm run format 2021-03-30 14:52:09 +00:00
astro-doctype.test.js [ci] npm run format 2021-03-30 14:52:09 +00:00
astro-fallback.test.js Implement fallback capability (#44) 2021-03-31 16:10:27 -04:00
astro-markdown.test.js [ci] npm run format 2021-03-30 14:52:09 +00:00
astro-scoped-styles.test.js Fix nested parens bug (#39) 2021-03-30 10:37:04 -06:00
astro-styles-ssr.test.js Extract Astro styles to external stylesheets (#43) 2021-03-31 13:04:18 -06:00
helpers.js Implement fallback capability (#44) 2021-03-31 16:10:27 -04:00
react-component.test.js [ci] npm run format 2021-03-30 14:52:09 +00:00
snowpack-integration.test.js [ci] npm run format 2021-03-30 14:52:09 +00:00
test-utils.js Absorb Snowpack config inside Astro (#32) 2021-03-26 13:14:32 -06:00