Comments (9)
When initially experimenting with Astro I was looking into how to use Lit with it and came across this issue. My hope was for (2) - a renderer in the monorepo but not enabled by default (at least not until Lit SSR is released as stable.)
from astro.
Ah I see your point. IMO this would be easier to address with something like #73, as Astro could support multiple props (e.g. :static :load
) to signal intent for both server and client. I guess in theory even without that you could just stack them, like <foo-component:static:load ...>
. Not sure how much that's a footgun.
from astro.
Note that if we did this we would need a way to differentiate between custom elements that should be server rendered and those that should not. I think we should not server render lower case tag names by default, they should be treated as simple HTML. However some sort of :static property might be a way to opt-in.
I don’t think it needs to be this complicated. Custom element names require a hyphen. If you’re already relying on component naming conventions to determine whether something is a component, I’d assume you could just add hyphenation to the heuristic.
This does raise an interesting question though about plain .html imports, especially with declarative web components on the standards track and making their way into Chrome (behind a flag).
from astro.
now that @natemoo-re added a “framework selector” to create-Astro, we do have a better story to consider moving all built in renderers out of Astro
Yep, this was the goal of that change!
IMO I'd go with (2). The Lit renderer is worth moving into the monorepo and adding to the create-astro
selector but we shouldn't enable it by default.
I'm actually +1 on removing any renderers from being included by default, but that's probably a conversation to continue elsewhere. Perhaps we could spin that and "the version problem" into new issues.
from astro.
My point is that how do we know the user wants to server render the component. Custom elements are often used for enhancement purposes where server rendering isn't necessary, for example a date picker doesn't need server rendering. We need a way to signal intent, like we have with pascal case framework components. Maybe this is an argument for needing to use custom elements with pascal case like all the others when server rendering.
from astro.
I'm curious how people are feeling about this now that we've had some time to launch Astro. Should we bring a Lit renderer into the monorepo? Into core? I think these options are all possible:
- The lit renderer is a 3rd party renderer (by me, under my personal npm namespace).
- The lit renderer is in the monorepo but not included by default.
- The lit renderer is in the monorepo and included by default.
Imo, (3) should not be done, at least not yet. SSR support in Lit is in the rc phase. We should at least wait until its released as stable before bringing it in.
That leaves either (1) or (2), and I don't have a strong preference. I think including it in the monorepo eventually is a good idea, but I can see an argument for waiting until it's stable.
cc @natemoo-re @drwpow @FredKSchott
from astro.
Right now we’re in this weird place where every renderer slows down startup time regardless of whether you need it. Until we have esbuild-powered dependendency handling, I’m hesitant to add more built-in renderers.
@backlineint points out the other issue with all of our built in renderers: no control over framework version. Since we tied renderer version to framework version, I think this may be a larger issue that we need to address before v1.0
now that @natemoo-re added a “framework selector” to create-Astro, we do have a better story to consider moving all built in renderers out of Astro
from astro.
@FredKSchott Thanks, I think you're saying you're against (3) which I am as well. Which leaves either (1), (2), or another option that hasn't been brought up yet. What do you think?
from astro.
Ah yea sorry, should have been more clear: strong +1 for option 2
from astro.
Related Issues (20)
- Dependency Dashboard
- Vitest fails because of the ImageFunction helper (with content collections)
- [Bug]: WordPress Rest Api does not optimize images - set:html HOT 2
- "Browser APIs are not available on the server" error in `client:visible` component HOT 1
- Popup works as expected in dev mode but not in the build
- "Transition was aborted because of invalid state" coming form hoisted.*.js HOT 4
- files[normalizedPath] is not a function
- `@astrojs/lit` - `Module '"astro"' has no exported member 'AstroIntegration'.` HOT 1
- @astrojs/rss uses trailing slash in urls when it shouldn't HOT 1
- Add a new `Astro.metadata` global object HOT 6
- SVG rendering error - "unsupported file type" HOT 2
- VIewTransitions break on presence of <input name="action"> HOT 2
- cannot dev or preview a page, if the page filename contain 'index', eg. e-index.astro HOT 2
- onTouchStart not being attached to DOM elements when using jsx HOT 8
- Rendering React component does not work HOT 4
- `@astrojs/mdx`: “smart quotes” are broken in HTML headers HOT 2
- React hydration error with react table but works fine the same example in next.js HOT 2
- ViewTransitions breaking Radix/Shadcn ui Dropdown Functionality in Astro App HOT 7
- Relative paths in css url() references get double encoded HOT 4
- @astro/node gcloud [ERROR] TypeError: Error: Unexpected end of multipart data HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from astro.