summaryrefslogtreecommitdiff
path: root/src/compiler/index.ts
diff options
context:
space:
mode:
authorGravatar Matthew Phillips <matthew@matthewphillips.info> 2021-03-31 16:10:27 -0400
committerGravatar GitHub <noreply@github.com> 2021-03-31 16:10:27 -0400
commitd9084ff4ad9e25577846d3eb53046c2f0066097f (patch)
treef6ae46756c68c6036d2f861a0373a4686f9efa74 /src/compiler/index.ts
parent3fa6396a7b092258c994d0bee6719b89b45c7bf8 (diff)
downloadastro-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