We read our code far more than we write it, so plan accordingly.
Even if you don't plan on anyone reading your code, chances are someone will... even if it's you 12 months from now.
Primitive names typically call the thing what it is. Some examples are:
For this post, I took a look at the card examples provided on the Tailwind website at https://v1.tailwindcss.com/components/cards.
In order to keeps things simple, I chose to focus on one example, the "Horizontal" card.
First of all, the name is poor because on mobile devices, it's stacked... That's why we believe a component's name should "describe it's purpose, rather than its appearance".
But on top of that, looking at the code, I'm even sure where the card styles actually start. As you can see in the screenshot, there's padding around the card... Looking at the code, there's no obvious way to know if that's coming from the card styles, or the component that's wrapping the card.
The single responsibility principle states that everything you create should be created for a single, focused reason. The styles you apply to a given selector should be created for a single purpose, and should do that single purpose extremely well.
Defining a frontend architecture that implements modern best practices including component-based development, atomic organization, and the BEM css naming convention may take more forethought when initially starting up, but has consistently (across our projects) proven to actually speed up development as a project matures, and save both time and money when updates or bug fixes are required. It will also make any future frontend developer's experience with the codebase far more pleasant!
Because we follow component-based development principles, our projects get faster to work on over time. If you don't do things that way, projects inevitably get SLOWER to work on over time. And you're never sure if the change you're about to make is going to affect all of the places you want it to, nor if it's going to change the way some other element in an unrelated part of the site
| #!/bin/sh | |
| # Installation: | |
| # - Copy this file to /usr/local/bin/k4 | |
| # - Make it executable `chmod +x /usr/local/bin/4k` | |
| # | |
| # Use: | |
| # - Run `4k <command>` | |
| # - If you haven't configured that command for the current project | |
| # you'll be asked to configure it now |
| {# | |
| # This is the PL template for the "parent" pattern | |
| #} | |
| {% set flexible_grid_base_class = flexible_grid_base_class|default('flexible-grid') %} | |
| {% set item_count = flexible_grid_item_count|default(rows|length) %} | |
| {# Dynamically define grid columns #} | |
| {% if item_count is divisible by(3) %} | |
| {% set flexible_grid_modifiers = ["columns-3"] %} |
In this post, I'm going to run through how I setup visual regression testing on sites. Visual regression testing is essentially the act of taking a screenshot of a web page (whether the whole thing, or just a specific element) and comparing that against an existing screenshot of the same thing to see if there are any differences.
There's nothing worse than adding a new component, tweaking styles, or pushing a config update, only to have the client tell you two months later that some random other part of the site is now broken, and you discover it's because of the change that you pushed... now it's been two months, and reverting that change has significant implications.
That's the worst. Literally the worst.
All kinds of testing can help improve the stability and integrity of a site. There's Functional, Unit, Integration, Stress, Performance, Usability, and Regression, just to name a few. What's most important to you will change depending on the project requirements, but in my experience, Functiona
Someone recently asked the following in Slack. I didn't want it to get lost in Slack's history, so I thought I'd post it here:
Question: I’m setting a css background image inside my Pattern Lab footer template which displays correctly in Pattern Lab; however, Drupal isn’t locating the image. How is sharing images between PL and Drupal supposed to work?
My Answer: I’ve been using Pattern Lab’s built-in data.json files to handle this lately. e.g. you could do something like:
footer-component.twig:
Install the latest Java JDK (not JRE)
npm install --save-dev webdriverio chai node-notifier wdio-mocha-framework wdio-browserstack-service wdio-visual-regression-service
{
"scripts": {