Comments (26)
RFC is up: #721 would love feedback there.
from roadmap.
Don't worry everyone, I still intend to add support for partials and am working on the RFC right now! My main concern going into this project was that head merging was something we would need to account for and figure out a solution for. But the fact that htmx has support for it already, and you could build similar things for jQuery and anywhere else, actually means that we don't (in my currently opinion) need to try and find a solution for that in Astro. So this can be as simple as a config flag in the page to opt in to partial fragment behavior.
from roadmap.
a bear can only dream....
from roadmap.
πββοΈ Also want to mention I'm thinking of using this for plain JS or vanilla custom elements. I think Partials will save developers time and complexity cleaning up HTML or selecting just a portion.
from roadmap.
I am very interested in this in the context of micro-frontends using classic Server-Side Includes.
That is, I would like to include header and footer on a page via SSI as fragments.
Ideally, header, footer, and the body of the page would come from three different Astro applications and be server-side rendered. The three applications would be owned by three different teams and upgrade to newer Astro versions at their own pace.
I started a related discussion for that use case: #713
from roadmap.
Here's my research on head merging support:
Library | Head targeting | Head merging |
---|---|---|
htmx | β | β (head-support plugin) |
Unpoly | β | β |
jQuery | β | β |
Given this, I think htmx users are already in a really good place. For the other two, it would not be difficult to create head merging plugins. Someone should do that!
That leaves me to think that simply adding the ability to treat pages like fragments, should be enough to make everyone happy here. It would mean losing styles, but if you're ok with that and don't want to write the code to merge the head then that can work.
from roadmap.
I would like to use Astro partials and am not using htmx.
from roadmap.
@georgwittberger are you inferring partial support isnβt required? If so, I disagree π
Note the non-goals above:
This isn't an integration specifically for HTMX or any one library. It should work with any library or manual DOM manipulation that does innerHTML.
from roadmap.
@georgwittberger are you inferring partial support isnβt required? If so, I disagree π
No, I don't. I just thought it could be helpful to point out what is possible with the current state of Astro.
I agree that a general HTML partial support would be a really useful feature of Astro. However, no matter if you are using HTMX or some other library to patch the DOM client-side the question remains how Astro should support style and script injection for HTML partials. So, if the final decision should be that styles and scripts are simply not supported in HTML partials then I think it could be nice for developers to know how they can achieve some solution with "normal" Astro pages, even if that requires a specific library like HTMX to make head-merging work.
from roadmap.
@ayoayco No, scoped styles requires head merging. So if you need that you can do that today without any new features just by extracting them from the returned HTML. This proposal will be to explicitly opt-out of styles/scripts.
from roadmap.
I would assume global CSS, either with <style is:global>
or imported CSS or an atomic CSS library like Tailwind. I would love for @michrome and others who want this feature to chime in on that.
from roadmap.
This was implemented and is in the stable version of Astro.
from roadmap.
I would like to bring into the conversation Github.com's web-components-based framework, catalyst.
The relevant aspect is that associated javascript and css would still need to be fetched and deduplicated.
from roadmap.
@lilnasy Thanks for mentioning it, will make certain the solution here works with that.
My current thinking is that if a partial contains a <head>
then we will do head injection. If there is no head then we will not. So libraries that can do head diffing should work.
from roadmap.
Makes me think of RSS feed. Could this maybe also be used/hooked into when rendering RSS content? So there would be no need for a custom Markdown parser/renderer (e.g. markdown-it
).
from roadmap.
This is amazing. Would unlock so many use cases for .astro files as API endpoints.
from roadmap.
Awesome. I'd be very interested in trying this out, with and without htmx!
from roadmap.
For htmx users, the head support extension already does almost exactly what I would want. If you create a page like this:
<head>
<style>
.clicked {
color: blue;
}
</style>
</head>
<div class="clicked">I was clicked</div>
The styles/scripts are merged into the real head of the document. The fragment target does not have any head content.
Is the desire to not use the head support? What is the problem with using Astro with htmx exactly?
from roadmap.
I'd like to have a page that might contain multiple components rendered on it and only update one via htmx, without having to rerender the other ones. Partials/fragments seem like they'd suit this, but there might be a simpler approach I'm not thinking of?
from roadmap.
What is the problem with using Astro with htmx exactly?
From the previous discussions, there isn't a problem. There's a desire to not have to use hx-select
. Today, we have to use hx-select
because the response is a complete HTML document. It won't be required when the response can be a partial. So the desire is met with the goal:
- The ability to request a URL from Astro that excludes the usual page elements (doctype, head injection).
And what you're suggesting here is perfect for more advanced cases π
from roadmap.
@michrome Ok thanks. If you use the head-support plugin then the head contents are moved into the head and you don't need to use hx-select. Is that not true? Or do you just not want to use head-support.
I don't consider that to be an advanced case. Astro components contain styles, which is very normal. I would say that not having the styles and dealing with it through global styles is the more advanced case.
from roadmap.
First up: what's being proposed above is exactly what I want! π
Ok thanks. If you use the head-support plugin then the head contents are moved into the head and you don't need to use hx-select. Is that not true? Or do you just not want to use head-support.
I don't consider that to be an advanced case. Astro components contain styles, which is very normal. I would say that not having the styles and dealing with it through global styles is the more advanced case.
The simplest use cases in my mind are:
- appending/replacing
<li>
s in a list; - or replacing the text content of a element that's already on screen.
Neither require additional styles. What's being proposed is good because there's no need to use use hx-select
(for htmx users) or do any extraction from the response (for any framework). π
Assuming I am being too reductive then perhaps the use case of a new component with styles is more typical. It feels more 'advanced' to me because client side I have to detect content from the rest of the partial β¦Β but that's exactly what head-support
is for so I personally wouldn't have any problem using itβin fact I'd want to use it for in this case. π
TLDRβthis is all good.
from roadmap.
I have tried the HTMX head-support extension today and it plays nicely with Astro's current way of injecting styles and scripts into the <head>
element.
Assuming you have the following initial page markup:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>My Page</title>
<script src="https://unpkg.com/[email protected]"></script>
<script src="https://unpkg.com/[email protected]/dist/ext/head-support.js"></script>
<link rel="stylesheet" href="/style.css" />
</head>
<body hx-ext="head-support">
<h1>My Page</h1>
<button hx-post="/result" hx-swap="outerHTML">Click me!</button>
</body>
</html>
Then the following Astro page src/pages/result.astro
can be used to swap the <button>
for new content with potentially new styles:
<html>
<head></head>
<body>
<div class="result">This is pink!</div>
</body>
</html>
<style>
.result {
background-color: hotpink;
}
</style>
Astro injects the <style>
tag into the <head>
when sending the response. HTMX then picks it up from there and inserts it into the existing <head>
element of the page. This happens only once, so even if you would render the <button>
again inside the result the new <style>
tag is not inserted over and over again on each request. The head-support
extension is smart enough to detect which elements have already been inserted.
If you are concerned about having the "real" content inside html > body
in the Astro page: HTMX also handles that. In this case only the inner HTML of the <body>
is swapped in. So the resulting HTML document looks like this:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>My Page</title>
<script src="https://unpkg.com/[email protected]"></script>
<script src="https://unpkg.com/[email protected]/dist/ext/head-support.js"></script>
<link rel="stylesheet" href="/style.css" />
<style>.result[data-astro-cid-hhnqfkh6] { background-color: hotpink; }</style>
</head>
<body hx-ext="head-support">
<h1>My Page</h1>
<div class="result" data-astro-cid-hhnqfkh6>This is pink!</div>
</body>
</html>
from roadmap.
@matthewp , this sounds very reasonable. π
I totally agree that partial support in Astro can very well come with limitations, e.g. not being able to inject styles or scripts. The docs can explain such caveats and also workarounds like the one above for those who want to respond with HTML fragments including style / script injection.
from roadmap.
Oh yeah, I donβt expect Astro to handle head merging itself. Will scoped styles be supported still?
from roadmap.
Okay clear π partials for plain unstyled HTML. Another question, sorry if out of scope for this story, but in the receiving page of a partial whatβs going to be the best approach to style the coming in HTML?
from roadmap.
Related Issues (20)
- Add a stylesheet feature to the sitemap integration
- Assets: Request for Stricter `getImage()` Attributes HOT 1
- `@astrojs/alpinejs` Lacks TypeScript Support For Alpine Shorthand Directives HOT 7
- Improve `astro:build:done` hooks, remove `RouteData`
- Wrong RouteData during build HOT 5
- Unable to pass variable from the configuration (integration) to (static file) endpoint HOT 7
- Production Dependencies HOT 6
- Allow framework components to stream responses or run in parallel HOT 6
- Incremental Builds HOT 7
- Built-in SVG components HOT 6
- First-party support for a Picture component HOT 9
- i18n routing HOT 19
- Integration hooks for middleware HOT 4
- Support prefetch in core HOT 1
- Supporting CSS-in-JS HOT 25
- CSRF Protection #471 HOT 1
- Improved env handling HOT 61
- env variables aren't populated even though process.env exists HOT 12
- CSS `define:vars` should only add definitions to top-level components 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 roadmap.