diff options
author | 2021-03-31 16:10:27 -0400 | |
---|---|---|
committer | 2021-03-31 16:10:27 -0400 | |
commit | d9084ff4ad9e25577846d3eb53046c2f0066097f (patch) | |
tree | f6ae46756c68c6036d2f861a0373a4686f9efa74 /src/compiler/index.ts | |
parent | 3fa6396a7b092258c994d0bee6719b89b45c7bf8 (diff) | |
download | astro-d9084ff4ad9e25577846d3eb53046c2f0066097f.tar.gz astro-d9084ff4ad9e25577846d3eb53046c2f0066097f.tar.zst astro-d9084ff4ad9e25577846d3eb53046c2f0066097f.zip |
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
Diffstat (limited to 'src/compiler/index.ts')
0 files changed, 0 insertions, 0 deletions