The front end on Drupal 8

02/26/2016 - 09:45

I remember back at Drupalcon Portland 2013 asking Angie Byron (webchick), Why not ship the new Drupal 8 with a blank canvas theme, so front end developers could do their job without the needing to shop for a third party theme? She said that was a good argument and should be taken into consideration, and it looks like my requested was fulfilled. Thank you.

Creating a new theme

Classy and Stable are just pure CSS and HTML code, exactly the blank canvas that you need to create your new theme -- and they are part of core. The main difference between them is "classes". Classy adds class attributes so you can use them to build up your CSS code. Stable, on the other hand, is more purist and won't give you any of this, so you will have to override basically every single template to add HTML attributes.

Do not expect to find clutter like SASS, LESS, Grunt, Bower, npm, gems, Compass, Foundation, Bundler... All of these tools are awesome, but after years of using them, considering the evolution that they have gone through, I'm starting to doubt if they are making our lives easier or more complicated (this goes for you Ruby and your gem versions -- thankfully libSass came to the rescue). It's up to you "the developer" to decide what tools you are going to use and set up your environment.

Enable the debug mode

You will not get really far on your first D8 sites unless you enable the debug mode. Floyd explained how to do this very well on a previous post: Ten Pointers for new Drupal 8 developers.

Where do things belong?

This site being my first D8 attempt I approached the new theme as I did on any other Drupal site: Display Suite, Context, preprocess hooks, and you don't need to touch a single PHP template. I'm well known for writing my themes without touching a single template, but on D8 that's no longer the desired path to take. In D8 your HTML code should be allocated in Twig templates, but that leaves you with the dilemma of the Node Display user interface and modules like Display Suite. I'm ok using these modules to layout my fields but if I need to add a class I have to edit the template? Confusing, right?

We had the opportunity to have Angie recently at our office, and I cornered her (sorry Angie) to ask about these issues. She in fact confirmed the trend was to put your HTML code into Twig template as the community made huge efforts to remove all this code from the D7 functions.

It is clear to me that you should send an object from the controller to the template with all the needed values, and then build your HTML code there by using the variables you just passed. However, it's really quick using Display Suite to layout your node fields -- moreover if you take into account multiple displays. It's also intuitive to the user because s/he can sees the fields layout on the admin interface, and you can export it into code, which makes you less dependent on the database.

This line has became more blurred than ever, and perhaps I'll have to wait some time until a trend is established. If you already have any input please let us know about it.

Checking for emptiness

Be careful when you try to find out if the output of {{ foo.bar }} is empty. You are dealing with renderable arrays on your Twig templates and as it's explained over here on Drupal.org, it's not easy to know when it's truly empty.

Responsive images

Another core feature is the responsive images, under "/admin/config/media/responsive-image-style" -- you will be able to create different styles of responsive images, and if you combine them with the <hook_name>.breakpoints.yml file you will have better control of them.

Here is what our ab2016.breakpoints.yml file looks like:

ab2016.mobile: label: mobile mediaQuery: '' weight: 0 multipliers: - 1x - 1.5x - 2xab2016.tablet: label: tablet mediaQuery: 'all and (min-width: 768px) and (max-width: 992px)' weight: 1 multipliers: - 1x - 1.5x - 2xab2016.desktop: label: desktop mediaQuery: 'all and (min-width: 992px) and (max-width: 1200px)' weight: 2 multipliers: - 1x - 1.5x - 2xab2016.desktop-lg: label: desktop-lg mediaQuery: 'all and (min-width: 1200px)' weight: 3 multipliers: - 1x - 1.5x - 2xab2016.1vw: label: Viewport Sizing mediaQuery: '' weight: 4 multipliers: - 1x - 1.5x - 2x

When creating a new style for a specific breakpoint you have three options:

Select multiple image styles and use the sizes attribute: This option will output an img tag with a srcset, something similar to this:

<img property="schema:thumbnailUrl" srcset="/sites/default/files/styles/max_768x768/public/my-image.png?itok=ibfcP6IN 768w, /sites/default/files/styles/max_992x992/public/my-image.png?itok=4QuVPlhU 992w, /sites/default/files/styles/max_768x768_1_5x/public/my-image.png?itok=Mg4Cdx65 1152w, /sites/default/files/styles/max_1200x1200/public/my-image.png?itok=6m11wbwz 1200w, ... sizes="100vw" src="/sites/default/files/styles/max_2000x2000/public/my-image.png?itok=Hhut0ibw" alt="My image" typeof="foaf:Image">
Select a single image style: This will give you a picture tag with your style in it, something similar to this:

<picture>... <source srcset="/sites/default/files/styles/max_992x992/public/my-image.png?itok=nJ6RWBL6 1x, /sites/default/files/styles/max_992x992_1_5x/public/my-image.png?itok=wQl9JTHH 1.5x, /sites/default/files/styles/max_768x768_2x/public/my-image.png?itok=MGLwtJwj 2x" media="all and (min-width: 768px) and (max-width: 992px)" type="image/png"> <source srcset="/sites/default/files/styles/max_768x768/public/my-image.png?itok=R04MFCuT 1x, /sites/default/files/styles/max_768x768_1_5x/public/my-image.png?itok=01HL1dPa 1.5x, /sites/default/files/styles/max_768x768_2x/public/my-image.png?itok=MGLwtJwj 2x" type="image/png">... <img property="schema:image" srcset="/sites/default/files/styles/max_992x992/public/my-image.png?itok=nJ6RWBL6" alt="My image" typeof="foaf:Image"></picture>
Do not use this breakpoint: Can't get more clear than that title.

Kick old browsers

For real, draw the line on old browsers and develop only for those that support the current standards. What's the point of jumping into Drupal 8 when you can't use responsive images, flex layouts, etc.

Be patient

Everything is still in early stages, and we collaborated to fix the bugs we encountered:

Conclusion

I'm still puzzled about D8, I've been working for many years with Drupal and this is not at all my first project with Twig (we have worked with Laravel and Symfony, both with Twig templates before), but somehow I feel like D8 is not any one of them but instead a hybrid of all of them.

Although it's easy to see when the template is rendered thanks to the developement feature, it's not easy to find out where this template is called from, and once you find the caller you may still have to understand about controllers, entity, services, and so on. We all have read about this but coming from the "procedural programming" that Drupal has been is quite a jump, and making the connection is not as simple as it sounds.

So far Drupal 8 looks stronger and more robust to me, and I kind of like its complexity, but this is no longer a tool for beginners. Perhaps that was the intention the community with the development of this version but I'm wondering how easy will be for new programmers to join this wagon.

Original Article:

The front end on Drupal 8