[AssetMapper] load of specific CSS files #51329
Comments
|
Yes, I see what you mean here, and I am thinking about something similar. I think the right place to do it is in TwigComponent though. What I imagine is as follows: let's say you have UserCardComponent, this component displays user information and can be added to many different pages. This component came with its own Js and CSS. Here is the component template: <div class="user-info">
<p>Name: {{ user.name }}</p>
...
</div>
{% twig_component_styles %}
.user-info {
border: solid 2px black;
& p {
color: red;
}
}
{% end_twig_component_styles %}
{% twig_component_javascript %}
// your component js
{% end_twig_component_javascript %}Then when Twig is parsing the files, it adds the content of twig_component_styles and twig_component_javascript into a dedicated CSS and javascript and references these files into the import map. |
|
Cool that I'm not the only one thinking about this topic. |
|
To make the CSS compatible with Turbo, it needs to be loaded in the |
|
Parts of this sound similar to https://laravel.com/docs/10.x/blade#stacks from Laravel - the idea of being able to push things onto a "stack", which is then resolved only at the end of the request. That would allow components to define their own
For live components, I'm not sure: it seems like metadata about "styles" would need to be returned in some way that the frontend could parse it out and add it to |
|
I think there is two distinct topics here:
1 --> App <-- 2 I focus more on the 1, as it's smaller, less ambitious but has a lot of usecases with partial templates, twig components and atomic design pattern. For (I guess!) not so much efforts. For the 2, you're not forced to end the process with AssetMapper: you can totally use your function to end up to a webpacked specific target, wants to gather the javascripts the same way, and so on. For the 1, the goal is to leverage the new paradigm that assetMapper and HTTP2 bring: As we don't pack files up now (hello @weaverryan! Idea came from your answer on symfonycasts ❤️ ), we end up with a lot of link tags? No worries, let's use this as an advantage instead of an annoying inconvenient! I feel like AssetMapper can have a function that delivers the stacked CSSs in the head tag, like importmap() does lower here. Something like |
|
There is a third point here actually: the architecture suggested by @WebMamba above colocating styles with the component template looks quite similar to the architecture of projects using CSS-in-JS to keep styles with their JS components. But there is a major thing in those CSS-in-JS artchitectures: the styles shipped to the browser are not actually just an extraction of the styles being in the code. The shipped styles are scoped only to the component itself, by changing both the CSS selectors and the HTML of the component. If you still require all selectors you write to be namespaced properly by the developer to avoid conflicts between 2 components reusing the same selector (because they use simple class name like |
|
I think we should stick on the point 1. given how simple (I don't speak for coding it, I don't know) is it as a concept. I was wondering if there is some capability also to check if stimulus controllers are called for a given page, and to load them accordingly? Same for translations also, but I think this is uncorrelated and can't be managed by the front part. Anyway, I still don't see any args against such a feat, beside "who code it?", but if you want to roast it, feel free :) |
|
Hi! ICYMI, #51543 adds CSS support to AssetMapper. The current iteration allows you to And yes, it also has the ability to render a bunch of
Yup! https://symfony.com/bundles/StimulusBundle/current/index.html#lazy-stimulus-controllers And with #51543, if you import CSS from within a lazy CSS controller, that CSS will be downloaded & added to the page only when that Stimulus controller is first needed on the page. About this issue specifically, I won't weigh in if it's a good idea, but @WebMamba's proposal with TwigComponents is likely possible, as (not shown in his example) we control an Cheers! |
Description
Please receive consider this idea: because we expose all our CSS files through the head tag now, we should be able to adapt them to the current page content..
Typical usecase:
The goal is to charge the CSS for the cards' and view buttons' homepage only for the homepage, and not to charge the "buy" button CSS here. And on the product page, having only the "buy" button CSS link tag.
We can achieve such a thing with
{% extends stylesheets %}blocks, but it's hard to keep track of what will be charged 15 times and if I have to keepparent()or not in specific situations. Let's do this automatically!It may be quite simple to do on the twig side, as I can think of a twig custom function to achieve that; But I don't know how to combine this with the assetMapper
asset('hashed.version.of.css')and keep this working afterbin/console asset-map:compile. Maybe hard, maybe simple?Please take few seconds to mind it, as I may not be the only one to atomize my css into multiple, component based files. Once again, assetMapper opens a paradigm where multiple CSS files is possible without impacting performances, but rather improves them.
Have a nice day!
Example
Imagine a new
{% stylized %}statement or function, that you will put at beginning of all your templates. Let's sayarticle_card.html.twig:{% stylized asset('foo/article_card.css') %}(or{% stylized %}only with we keep the same folder structure)you only declare your CSS here; not anymore in layout or anywhere else. It's convenient for the developer as he never forgets to add the 'use' in a js or css bootstraper somewhere; he just adds 'stylized' on top of his template and here we go.
The goal for twig & assetMapper? when a page loads:
Because assetMapper opens a way where we keep our CSS atomized in multiple files, it's really easier to aim for required and non required CSS parts than before with a huge webpacked file.
The text was updated successfully, but these errors were encountered: