kalamuna / kalastatic_dot_module

Drupal integration module for the Kalastatic prototyping and styleguide tool
https://www.drupal.org/project/kalastatic
2 stars 3 forks source link

Drupal assets #22

Open soniktrooth opened 7 years ago

soniktrooth commented 7 years ago

drupal_get_js() and drupal_get_css() are the key to being able to generate the assets page, however these functions have disappeared in D8. I've had a dig but cannot work out what black spell to cast in order to evoke a similar reaction out of the beast. Any ideas @RobLoach or @derekderaps?

soniktrooth commented 7 years ago

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Asset%21AssetResolverInterface.php/interface/AssetResolverInterface/8.2.x

soniktrooth commented 7 years ago

So I went down a big rabbit hole with this. I seem to be in the right general area but I can't work it out.

I found some interesting code in processAttachments() in HtmlResponseAttachentsProcessor.php and boiled it down to:

    $attached = $response->getAttachments();
    $assets = AttachedAssets::createFromRenderArray(['#attached' => $attached]);
    $css = AssetResolver::getCssAssets($assets);

But I don't know how to get a $response or even if I'm able to get one inside a Controller. I could be barking up the wrong tree, but these functions sound like they should do what we want.

hawkeyetwolf commented 7 years ago

In D7, I use the #attached property for FormAPI and render elements whenever possible. As a last resort you can attach to the page render element via hook_page_alter().

drupal_add_css() and _js() are a last resort. I can dig up documentation on that if you'd like.

Not sure about D8 though, I look forward to learning!

soniktrooth commented 7 years ago

@derekderaps you're misunderstanding.

I'm calling drupal_GET_js() and drupal_GET_css() in D7 which returns rendered <script> and <style> tags. This is consumed by Kalastatic and stuck inside the styleguide/prototype <head></head> so that when we are styling things, we are taking into account the styling that Drupal will be adding to the page.

We need to get the same functionality for D8 but it seems a lot more complex. At the end of the day though there is SOMETHING that is rendering those tags in head so we just have to work out what and where so we can call it. Worst case is we have to load all the library.yml files and recreate it ourselves but I can't even work that out—all the OOP is turning my brain to goo. So undiscoverable.

hawkeyetwolf commented 7 years ago

Ah, you're totally right, I was on a call and just responding real quick-like. Hmmm....

soniktrooth commented 7 years ago

@RobLoach now that we found a solution for #23 can you check this one out? We're not going to be able to style things properly in the prototype without this working.

soniktrooth commented 7 years ago

@thiagodemellobueno you had thoughts today on an approach and/or whether this was still a thing that module needed to do. Care to elaborate?

thiagodemellobueno commented 7 years ago

@josh

Yeah, my thoughts are that this seems to be a relatively difficult and even then testy thing to solve with automation. As you mentioned D8 gets way more granular re: whats loaded in a given page at a given time.

If we shift our thinking re: this problem from a “feature” to a “workflow” or “best practices” approach, We can imagine that setting up a baseline set of includes to give us a “good baseline set of drupaly css and js includes”… is just another one of those tasks that we recognize and set aside time for like: “set up living style guide” … we could have “establish sites baseline asset includes in port and style guide”… then in the time it takes to see which things we want to include and populate an array/config in both style guide and prototype and were done.

Not exactly the most elegant solution, but if we’ve found anything it’s that solving this one has been consistently inelegant. This way it’s at least “part of the plan and not hard”

Thoughts?

On Dec 13, 2016, at 6:57 PM, Josh notifications@github.com wrote:

@thiagodemellobueno https://github.com/thiagodemellobueno you had thoughts today on an approach and/or whether this was still a thing that module needed to do. Care to elaborate?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kalamuna/kalastatic_dot_module/issues/22#issuecomment-266900451, or mute the thread https://github.com/notifications/unsubscribe-auth/AAE1dVhQNy1WGLxOHu7VQH76nGcymXU7ks5rHzDPgaJpZM4LA6LA.

soniktrooth commented 7 years ago

@thiagodemellobueno fair enough—what do you envisage the workflow would look like? I'm assuming something like:

Is that what you were thinking?

thiagodemellobueno commented 7 years ago

yeah,

or in kalastatic 2, populate kalastatic.yaml @robloach hopped on the yaml hoverjetwagon

and populate 1d arrays, styles and scripts with paths that get printed in a loop in homepage.yaml and kstatic-kss-builder/index.twig

RobLoach commented 7 years ago

TODO

  1. Expose the JavaScript and CSS as HTML output kalastatic/css, kalastatic/js
  2. Have KSTAT include the CSS/JS in the Prototype
  3. Have KSTAT include the CSS/JS in the Styleguide