Popular Design News of the Week: February 10, 2020 – February 16, 2020

Every week users submit a lot of interesting stuff on our sister site Webdesigner News, highlighting great content from around the web that can be of interest to web designers. 

The best way to keep track of all the great stories and news being posted is simply to check out the Webdesigner News site, however, in case you missed some here’s a quick and useful compilation of the most popular designer news that we curated from the past week.

Note that this is only a very small selection of the links that were posted, so don’t miss out and subscribe to our newsletter and follow the site daily for all the news.

Avoid these 10 UX Design Fails

 

15+ Best Sites to Download Mockups

 

UX 101: Norman Doors

 

Neumorphism: A Trend that is Already Over?

 

A New Approach to Color (inspired by Dark Mode) in Our Design System

 

Drop.lol – Easy WebRTC File Transfer

 

Preloader Design Tips and Inspirations

 

Google Earth Just Released 1,000 Beautiful Wallpapers You Can Download for Free

 

How Deceptive UX Patterns Trick You into Doing What Companies Want

 

Design System Subtasks, by Step

 

UX Debt 101

 

How to Automate your Workspace and Write Less Code

 

Google Maps is Turning 15! Celebrate with a New Look and Features

 

Sketch 63 — What’s New?

 

Redesign: Gridniking

 

Youtube Tag Generator

 

Glitch Art Generator

 

New Marvel Eternals Logo Leaked

 

Brandless, the Pioneering Amazon Alternative, Shuts Down

 

A Dark Web Tycoon Pleads Guilty, but How was He Caught?

 

Facebook Buys AR Startup Building a 1:1 Digital Map of the Physical World

 

How to Save on Business Expenses as a SaaS Company

 

The Case of the Stolen Domain Names

 

Our Obsession with ‘Color Trends’ is Killing the Planet

 

Forecasting the Future of Design

 

Want more? No problem! Keep track of top design news from around the web with Webdesigner News.

Source
p img {display:inline-block; margin-right:10px;}
.alignleft {float:left;}
p.showcase {clear:both;}
body#browserfriendly p, body#podcast p, div#emailbody p{margin:0;}

“CSS4” Update

Since I first chimed in on the CSS4¹ thing, there’s been tons of more discussion on it. I’m going to round up my favorite thoughts from others here. There is an overwhelming amount of talk about this, so I’m going to distill it here down as far as I can, hopefully making it easier to follow.

  • Jen Simmons kicked off a discussion on GitHub under the CSS Working Group draft repo. The best we have for developers trying to stay current on CSS right now is “just keep up” and that’s not working. Better to “draw a line” around certain things and say “Here, this. This part is ready. This part is done.”
  • Michelle Barker says it’s hard to prioritize what to learn without guidance.
  • Nicole Sullivan thinks if developers can “tick the checkbox” of CSS4, it would “drive developers to upgrade their skills, businesses to upgrade their tech stacks, and browsers to focus on cross-browser compat.”
  • Dave Rupert sees value in the Perceived Velocity through Version Numbers.
  • Natalya Shelburne says that, in “a time-scarce world”, engineers she works with don’t feel like new CSS is production-ready and don’t prioritize learning it.
  • Rachel Andrew thinks that the browser support of features, particularly the complex and nuanced nature of subfeatures, is a barrier. Since we don’t know anyone else’s browser support requirements, it’s irresponsible to suggest blanket features to learn/use.
  • Brian Kardell brought up that JavaScript is “versioned” yearly and it seems to work over there (Although Shawn Wang rightly mentioned that we should probably be asking them what has worked and what hasn’t). Personally, I prefer the idea of CSS2020 over CSS4 (I just like the synchronicity with JavaScript), and Brain Kardell thinks just because we use a year in the name doesn’t mean we have to do it every year. Chen Hui Jing mentioned that Babel throws a wrench in things a bit. Polyfilling new JavaScript is a different beast than polyfilling new CSS and that affects expectations.
  • Miriam thinks we need to settle on a list of features, but that it should be criteria-based. I suppose criteria would be status of spec, browser support (“2 major browsers” is the most common theme), and some kind of importance modifier. My first article took a stab at a feature list and here’s another thought. PPK agrees that flexbox is too old, and favors grid and custom properties. Timothy Miller has a few ideas.
  • fantasai doesn’t think this message should come from the CSSWG.
  1. The more we keep calling it CSS4, the harder it will be to call it anything else. If that’s how it shakes out, fine, but my preference is to mimic JavaScript “versioning”. I’m going to stop calling it CSS4 after this until a name settles in better.

The post “CSS4” Update appeared first on CSS-Tricks.

Fonts in Focus: two

For the first in this new series of Fonts in Focus, we visited the New York offices of Hoefler & Co. For this second installment, we remain in New York, just fifteen minutes’ walk from Broadway to Lafayette street and the stateside offices of Commercial Type, established in 2007 and headed by Christian Schwartz in […]

The post Fonts in Focus: two appeared first on I Love Typography.

While You Weren’t Looking, CSS Gradients Got Better

One thing that caught my eye on the list of features for Lea Verou’s conic-gradient() polyfill was the last item:

Supports double position syntax (two positions for the same color stop, as a shortcut for two consecutive color stops with the same color)

Surprisingly, I recently discovered most people aren’t even aware that double position for gradient stops is something that actually exists in the spec, so I decided to write about it.

According to the spec:

Specifying two locations makes it easier to create solid-color “stripes” in a gradient, without having to repeat the color twice.

I completely agree, this was the first thing I thought of when I became aware of this feature.

Let’s say we want to get the following result: a gradient with a bunch of equal width vertical stripes (which I picked up from an earlier post by Chris):

Screenshot. Shows 8 vertical rainbow stripes, from left to right: violet, magenta, red, orange, yellow, yellowish green, teal, blue.
Desired gradient result.

The hex values are: #5461c8, #c724b1, #e4002b, #ff6900, #f6be00, #97d700, #00ab84 and #00a3e0.

Let’s first see how we’d CSS this without using double stop positions!

We have eight stripes, which makes each of them one-eighth of the gradient width. One eighth of 100% is 12.5%, so we go from one to the next at multiples of this value.

This means our linear-gradient() looks as follows:

linear-gradient(90deg, #5461c8 12.5% /* 1*12.5% */, #c724b1 0, #c724b1 25% /* 2*12.5% */, #e4002b 0, #e4002b 37.5% /* 3*12.5% */, #ff6900 0, #ff6900 50% /* 4*12.5% */, #f6be00 0, #f6be00 62.5% /* 5*12.5% */, #97d700 0, #97d700 75% /* 6*12.5% */, #00ab84 0, #00ab84 87.5% /* 7*12.5% */, #00a3e0 0)

Note that we don’t need to repeat stop position % values because, whenever a stop position is smaller than a previous one, we automatically have a sharp transition. That’s why it’s always safe to use 0 (which is always going to be smaller than any positive value) and have #c724b1 25%, #e4002b 0 instead of #c724b1 25%, #e4002b 25%, for example. This is something that can make our life easier in the future if, for example, we decide we want to add two more stripes and make the stop positions multiples of 10%.

Not too bad, especially compared to what gradient generators normally spit out. But if we decide one of those stripes in the middle doesn’t quite fit in with the others, then changing it to something else means updating in two places.

Again, not too bad and nothing we can’t get around with a little bit of help from a preprocessor:

$c: #5461c8 #c724b1 #e4002b #ff6900 #f6be00 #97d700 #00ab84 #00a3e0; @function get-stops($c-list) { $s-list: (); $n: length($c-list); $u: 100%/$n; @for $i from 1 to $n { $s-list: $s-list, nth($c-list, $i) $i*$u, nth($c-list, $i + 1) 0 } @return $s-list
} .strip { background: linear-gradient(90deg, get-stops($c)))
}

This generates the exact CSS gradient we saw a bit earlier and now we don’t have to modify anything in two places anymore.

See the Pen by thebabydino (@thebabydino) on CodePen.

However, even if a preprocessor can save us from typing the same thing twice, it doesn’t eliminate repetition from the generated code.

And we may not always want to use a preprocessor. Leaving aside the fact that some people are stubborn or have an irrational fear or hate towards preprocessors, it sometimes feels a bit silly to use a loop.

For example, when we barely have anything to loop over! Let’s say we want to get a much simpler background pattern, such as a diagonal hashes one, which I’d imagine is a much more common use case than an over-the-top rainbow one that’s probably not a good fit on most websites anyway.

Screenshot. Shows a pattern of diagonal light grey hashes on a white background.
Desired hashes result

This requires using repeating-linear-gradient() and this means a bit of repetition, even if we don’t have the same long list of hex values as we did before:

repeating-linear-gradient(-45deg, #ccc /* can't skip this, repeating gradient won't work */, #ccc 2px, transparent 0, transparent 9px /* can't skip this either, tells where gradient repetition starts */)

Here, we cannot ditch the first and last stops because those are precisely what indicate how the gradient repeats within the rectangle defined by the background-size.

If you want to understand why it’s better to use repeating-linear-gradient() instead of a plain old linear-gradient() combined with the proper background-size in order to create such hashes, check out this other article I wrote a while ago.

This is precisely where such feature comes to the rescue — it allows us to avoid repetition in the final CSS code.

For the rainbow stripes case, our CSS becomes:

linear-gradient(90deg, #5461c8 12.5%, #c724b1 0 25%, #e4002b 0 37.5%, #ff6900 0 50%, #f6be00 0 62.5%, #97d700 0 75%, #00ab84 0 87.5%, #00a3e0 0)

And to recreate the hashes, we only need:

repeating-linear-gradient(-45deg, #ccc 0 2px, transparent 0 9px)

See the Pen by thebabydino (@thebabydino) on CodePen.

What about support? Well, glad you asked! It actually happens to be pretty good! It works in Safari, Chromium browsers (which now includes Edge as well!) and Firefox. Pre-Chromium Edge and maybe some mobile browsers could still hold you back, but if you don’t have to worry about providing support for every browser under the sun or it’s fine to provide a fallback, go ahead and start using this!

The post While You Weren’t Looking, CSS Gradients Got Better appeared first on CSS-Tricks.

Designing Ethically, Optimizing Videos, And Shining The Spotlight On Our SmashingConf Speakers

Designing Ethically, Optimizing Videos, And Shining The Spotlight On Our SmashingConf Speakers

Designing Ethically, Optimizing Videos, And Shining The Spotlight On Our SmashingConf Speakers

Iris Lješnjanin

2020-02-14T14:00:00+00:00 2020-02-15T00:36:24+00:00

An important part of our job is staying up to date, and we know how difficult it can be. Technologies don’t really change that fast — coding languages take a long time to be specified and implemented. But the ideas surrounding these technologies and the things we can do with them are constantly evolving, and hundreds of blog posts and articles are published every day. There’s no way you can read all of those but you’ll still have to keep up to date.

Fear not, we’ve got your backs! Our bi-weekly Smashing Podcast has you covered with a variety of topics across multiple levels of expertise.

A shout-out and big thank you to both Drew McLellan and Bethany Andrew for making the episodes so brilliantly witty and informative!

Topple the cat wearing headphones and holding a coffee-to-go cup while listening to the Smashing Podcast
Catching up with what’s new in the web industry doesn’t mean you have to be tied up to a chair and desk! Do as Topple the Cat does it: grab your headphones and stretch those legs! You can subscribe and tune in anytime with any of your favorite apps.

A Lovely New Addition To The Smashing Books

We’re so proud to be introducing a new book to the Smashing bookshelf — a cover so eloquently designed and a book that covers topics that are very close to our hearts: ethics and privacy.

The “The Ethical Design Handbook” is our new guide on ethical design for digital products that respect customer choices and are built and designed with ethics in mind. It’s full of practical guidelines on how to make ethical decisions to influence positive change and help businesses grow in a sustainable way.

The cover of the Ethical Design Handbook
Written by Trine Falbe, Martin Michael Frederiksen and Kim Andersen. You can download a free PDF excerpt (5 MB) (also available as ePUB and Kindle) and get a sneakpeek beforehand!

Of course, you can jump right over to the table of contents and see for yourself, but be sure to pre-order the book while you can! There’s still a discount available before the official release — we’ll start shipping printed hardcover copies in the first two weeks of March! Stay tuned!

Learning And Networking, The Smashing Way

Our SmashingConfs are known to be friendly, inclusive events where front-end developers and designers come together to attend live sessions and hands-on workshops. From live designing to live debugging, we want you to ask speakers anything — from naming conventions to debugging strategies. For each talk, we’ll have enough time to go into detail, and show real examples from real work on the big screen.

We like to bring you closer to folks working in the web industry, and so every once in a while we interview the speakers who share the stage! For SmashingConf Austin, the spotlight shined on:

  • Miriam Suzanne, who’ll be talking about the wonderful new world of CSS, new techniques and possibilities.
  • Zach Leatherman, who’ll let us in on everything we need to know about type,font performance tooling and general workflow when it comes to web fonts.
  • Rémi Parmentier, who’ll bring us closer to the good ol’ HTML Email, common techniques, state of things and what you can achieve with HTML Email today (if you are willing enough to explore its unconventional world).
Four different illustrations designed by Ricardo Gimenes dressed up in different costumes representing each city where the SmashingConf will take place this year
This year, we’re organizing SmashingConf in four cities — see you there?

Shining The Spotlight On Optimizing Video Files

Mark your calendars! In less than two weeks (Feb. 25, we’ll be hosting a Smashing TV webinar with Doug Sillars who’ll be sharing several possible scenarios to optimize video files for fast and efficient playback on the web. Join us at 17:00 London time — we’d love to hear your thoughts and experiences you’ve had in your career!

Smashing TV illustration with Topple the Cat holding a video camera
Smashing TV is a series of webinars and live streams packed with practical tips for designers and developers. Think of it as some sort of a Hollywood blockbuster with cats, but only better, because it’s for people like you!

Ricardo Gimenes, the talent behind the illustrations on all things SmashingWe often get asked who the creative talent behind the illustrations is: It’s the one-and-only Ricardo Gimenes, someone we’re ever so proud to have in our team!

We publish a new article every day on various topics that are current in the web industry. Here are some that our readers seemed to enjoy the most and have recommended further:

  • How To Create Maps With React And Leaflet
    by Shajia Abidi
    Leaflet is a very powerful tool, and we can create a lot of different kinds of maps. This tutorial will help you understand how to create an advanced map along with the help of React and Vanilla JS.
  • Understanding CSS Grid: Grid Template Areas
    by Rachel Andrew
    In a new series, Rachel Andrew breaks down the CSS Grid Layout specification. This time, she takes us through grid-template-areas and how it can be used to place items.
  • How To Create A Headless WordPress Site On The JAMstack
    by Sarah Drasner & Geoff Graham
    In this post, Sarah and Geoff set up a demo site and tutorial for headless WordPress — including a starter template! They explain how to set up a Vue application with Nuxt, pulling in the posts from our application via the WordPress API.
  • Magic Flip Cards: Solving A Common Sizing Problem
    by Dan Halliday
    In this article, Dan reviews the standard approach to creating animated flip cards and introduces an improved method which solves its sizing problem.

Best Picks From Our Newsletter

With the start of a brand-new decade, we decided to start off with topics dedicated to web performance. There are so many talented folks out there working on brilliant projects, and we’d love to spread the word and give them the credit they deserve!

Note: A huge thank you to Cosima Mielke for writing and preparing these posts!

Tiny Helpers For Web Developers

Minifying an SVG, extracting CSS from HTML, or checking your color palette for accessibility — we all know those moments when we need a little tool to help us complete a task quickly and efficiently. If you ever find yourself in such a situation again, Tiny Helpers might have just the tool you’re looking for.

Tiny Helpers

Maintained by Stefan Judis, Tiny Helpers is a collection of free, single-purpose online tools for web developers. The tools cover everything from APIs, accessibility, and color, to fonts, performance, regular expressions, SVG, and unicode. And if you know of a useful tool that isn’t featured yet, you can submit a pull request with your suggestion. One for the bookmarks.

Real-World Color Palette Inspiration

There are a lot of fantastic sites out there that help you find inspiring color palettes. However, once you have found a palette you like, the biggest question is still left unanswered: how should you apply the colors to your design? Happy Hues is here to help.

Happy Hues

Designed by Mackenzie Child, Happy Hues gives you color palette inspiration while acting as a real-world example for how the colors could be used in your design. Just change the palette, and the Happy Hues site changes its colors to show you what your favorite palette looks like in an actual design. Clever!

Free Usability Heuristics Posters

Back in 1994, Jakob Nielsen wrote an article for Nielsen Norman Group, outlining general principles for interface design: the 10 usability heuristics. Today, decades later, these heuristics still serve as a checklist for interface designers. A fact that inspired the folks at Agente Studio to create a set of posters dedicated to them.

10 Usability Heuristics for User Interface Design

Each of the ten beautifully-designed posters illustrates and explains one of Nielsen’s heuristics. The posters are CC-licensed and can be downloaded and printed for free after you shared the page on social media. JPEG and EPS formats are available.

A Guide To Fighting Online Tracking

It’s no secret that we’re being tracked online. And while we can’t stop all of it, there are things we can do to fight back.

Illustration of a woman sweeping data away
Image credit: Rose Wong

In his New York Times article, Tim Herrera dives deeper into the data companies collect about us and how they share it with third parties, into “secret scores” and shocking third-party reports that list our delivery service orders and private Airbnb messages from years ago. Besides being a good reminder to be more wary of handing out our data, the article features links to tools and practical tips for preventing advertiser tracking. A must-read.

The Illustrated Children’s Guide To Kubernetes

Have you ever tried to explain software engineering to a child or to a friend, colleague, or relative who isn’t that tech-savvy? Well, finding easy words to explain a complex concept can be a challenge. A challenge that “The Illustrated Children’s Guide to Kubernetes” masters beautifully.

The Illustrated Children’s Guide to Kubernetes

Designed as a storybook and available to be read online or as a PDF, the free guide tells the story of a PHP app named Phippy who wished she had her own environment, just her and a webserver she could call home. On her journey, she meets Captain Kube who gives her a new home on his ship Kubernetes. A beautiful metaphor to explain the core concept of Kubernetes.

Generator Of Geometric Shapes

To stand out from the crowd of a myriad of websites out there, we can define one unique thing, the signature, that brings a bit of personality into our digital products. Perhaps it’s a little glitch effect, or a pencil scribble, a game or unusual shapes. Or, it could be a set of seemingly random geometric flow lines.

Flow Lines Generator

Flow Lines Generator produces random geometric lines, and we can adjust the formulas and distances between the shapes drawn, and then export the outcome as SVG. Perhaps every single page on your site could have a variation of these lines in some way? It might be enough to stand out from the crowd, mostly because nobody else has that exact visual treatment. It might be worth looking at!

Git From Beginner To Advanced

Most of us will be dealing with Git regularly, sometimes running Git commands from terminal, and sometimes using a visual tool to pull, push, commit and merge. If you feel like you’d like to supercharge your skills and gain a few Git superpowers, where do you start?

Git Cheat Sheet

Mike Riethmueller has published a quick guide to Git, from beginner to advanced, explaining how Git works, how to configure it, aliases, important commands, staging/unstaging files, managing merge conflicts, stashing and a few advanced tips. Need more advanced stuff? Harry Roberts has published “Little Things I Like To Do With Git”, Atlassian has Advanced Git Tutorials, Bruno Passos lists useful git commands, and GitHub provides a Git Cheat Sheet PDF.

The Museum Of Obsolete Media

Do you remember the days when you listened to a music cassette on your Walkman, watched your favorite movie on video tape instead of streaming it, or stored your data on a floppy disk? The media we considered state-of-the-art back then, is obsolete today. And, well, a lot of other formats shared the same fate in the past.

The Museum Of Obsolete Media

In his Museum of Obsolete Media, Jason Curtis collects examples of media that went out of use, not just the ones you might remember, but also real curiosities and treasures dating back as far as to the middle of the 19th century. Things like the “carte de visite”, “Gould Moulded Records”, or “Magnabelt” for example. A fascinating trip back in time.

Each and every issue of the Smashing Newsletter is written and edited with love and care. No third-party mailings or hidden advertising — you’ve got our word.

Smashing Editorial (cm, vf, ra, il)
Why JavaScript is Eating HTML

Web development is always changing. One trend in particular has become very popular lately, and it fundamentally goes against the conventional wisdom about how a web page should be made. It is exciting for some but frustrating for others, and the reasons for both are difficult to explain.

A web page is traditionally made up of three separate parts with separate responsibilities: HTML code defines the structure and meaning of the content on a page, CSS code defines its appearance, and JavaScript code defines its behavior. On teams with dedicated designers, HTML/CSS developers and JavaScript developers, this separation of concerns aligns nicely with job roles: Designers determine the visuals and user interactions on a page, HTML and CSS developers reproduce those visuals in a web browser, and JavaScript developers add the user interaction to tie it all together and “make it work.” People can work on one piece without getting involved with all three.

In recent years, JavaScript developers have realized that by defining a page’s structure in JavaScript instead of in HTML (using frameworks such as React), they can simplify the development and maintenance of user interaction code that is otherwise much more complex to build. Of course, when you tell someone that the HTML they wrote needs to be chopped up and mixed in with JavaScript they don’t know anything about, they can (understandably) become frustrated and start asking what the heck we’re getting out of this.

As a JavaScript developer on a cross-functional team, I get this question occasionally and I often have trouble answering it. All of the materials I’ve found on this topic are written for an audience that is already familiar with JavaScript — which is not terribly useful to those who focus on HTML and CSS. But this HTML-in-JS pattern (or something else that provides the same benefits) will likely be around for a while, so I think it’s an important thing that everyone involved in web development should understand.

This article will include code examples for those interested, but my goal is to explain this concept in a way that can be understood without them.

Background: HTML, CSS, and JavaScript

To broaden the audience of this article as much as possible, I want to give a quick background on the types of code involved in creating a web page and their traditional roles. If you have experience with these, you can skip ahead.

HTML is for structure and semantic meaning

HTML (HyperText Markup Language) code defines the structure and meaning of the content on a page. For example, this article’s HTML contains the text you’re reading right now, the fact that it is in a paragraph, and the fact that it comes after a heading and before a CodePen.

Let’s say we want to build a simple shopping list app. We might start with some HTML like this:

CodePen Embed Fallback

We can save this code in a file, open it in a web browser, and the browser will display the rendered result. As you can see, the HTML code in this example represents a section of a page that contains a heading reading “Shopping List (2 items),” a text input box, a button reading “Add Item,” and a list with two items reading “Eggs” and “Butter.” In a traditional website, a user would navigate to an address in their web browser, then the browser would request this HTML from a server, load it and display it. If there are already items in the list, the server could deliver HTML with the items already in place, like they are in this example.

Try to type something in the input box and click the “Add Item” button. You’ll notice nothing happens. The button isn’t connected to any code that can change the HTML, and the HTML can’t change itself. We’ll get to that in a moment.

CSS is for appearance

CSS (Cascading Style Sheets) code defines the appearance of a page. For example, this article’s CSS contains the font, spacing, and color of the text you’re reading.

You may have noticed that our shopping list example looks very plain. There is no way for HTML to specify things like spacing, font sizes, and colors. This is where CSS (Cascading Style Sheets) comes in. On the same page as the HTML above, we could add CSS code to style things up a bit:

CodePen Embed Fallback

As you can see, this CSS changed the font sizes and weights and gave the section a nice background color (designers, please don’t @ me; I know this is still ugly). A developer can write style rules like these and they will be applied consistently to any HTML structure: if we add more <section>, <button> or <ul> elements to this page, they will have the same font changes applied.

The button still doesn’t do anything, though: that’s where JavaScript comes in.

JavaScript is for behavior

JavaScript code defines the behavior of interactive or dynamic elements on a page. For example, the embedded CodePen examples in this article are powered by JavaScript.

Without JavaScript, to make the Add Item button in our example work would require us to use special HTML to make it submit data back to the server (<form action="...">, if you’re curious). Then the browser would discard the entire page and reload an updated version of the entire HTML file. If this shopping list was part of a larger page, anything else the user was doing would be lost. Scrolled down? You’re back at the top. Watching a video? It starts over. This is how all web applications worked for a long time: any time a user interacted with a webpage, it was as if they closed their web browser and opened it again. That’s not a big deal for this simple example, but for a large complex page which could take a while to load, it’s not efficient for either the browser or the server.

If we want anything to change on a webpage without reloading the entire page, we need JavaScript (not to be confused with Java, which is an entirely different language… don’t get me started). Let’s try adding some:

CodePen Embed Fallback

Now when we type some text in the box and click the “Add Item” button, our new item is added to the list and the item count at the top is updated! In a real app, we would also add some code to send the new item to the server in the background so that it will still show up the next time we load the page.

Separating JavaScript from the HTML and CSS makes sense in this simple example. Traditionally, even more complicated interactions would be added this way: HTML is loaded and displayed, and JavaScript runs afterwards to add things to it and change it. As things get more complex, however, we start needing to keep better track of things in our JavaScript.

If we were to keep building this shopping list app, next we’d probably add buttons for editing or removing items from the list. Let’s say we write the JavaScript for a button that removes an item, but we forget to add the code that updates the item total at the top of the page. Suddenly we have a bug: after a user removes an item, the total on the page won’t match the list! Once we notice the bug, we fix it by adding that same totalText.innerHTML line from our “Add Item” code to the “Remove Item” code. Now we have the same code duplicated in more than one place. Later on, let’s say we want to change that code so that instead of “(2 items)” at the top of the page it reads “Items: 2.” We’ll have to make sure we update it in all three places: in the HTML, in the JavaScript for the “Add Item” button, and in the JavaScript for the “Remove Item” button. If we don’t, we’ll have another bug where that text abruptly changes after a user interaction.

In this simple example, we can already see how quickly these things can get messy. There are ways to organize our JavaScript to make this kind of problem easier to deal with, but as things continue to get more complex, we’ll need to keep restructuring and rewriting things to keep up. As long as HTML and JavaScript are kept separate, a lot of effort can be required to make sure everything is kept in sync between them. That’s one of the reasons why new JavaScript frameworks, like React, have gained traction: they are designed to show the relationships between things like HTML and JavaScript. To understand how that works, we first need to understand just a teeny bit of computer science.

Two kinds of programming

The key concept to understand here involves the distinction between two common programming styles. (There are other programming styles, of course, but we’re only dealing with two of them here.) Most programming languages lend themselves to one or the other of these, and some can be used in both ways. It’s important to grasp both in order to understand the main benefit of HTML-in-JS from a JavaScript developer’s perspective.

  • Imperative programming: The word “imperative” here implies commanding a computer to do something. A line of imperative code is a lot like an imperative sentence in English: it gives the computer a specific instruction to follow. In imperative programming, we must tell the computer exactly how to do every little thing we need it to do. In web development, this is starting to be considered “the old way” of doing things and it’s what you do with vanilla JavaScript, or libraries like jQuery. The JavaScript in my shopping list example above is imperative code.
    • Imperative: “Do X, then do Y, then do Z”.
    • Example: When the user selects this element, add the .selected class to it; and when the user de-selects it, remove the .selected class from it.
  • Declarative programming: This is a more abstract layer above imperative programming. Instead of giving the computer instructions, we instead “declare” what we want the results to be after the computer does something. Our tools (e.g. React) figure out the how for us automatically. These tools are built with imperative code on the inside that we don’t have to pay attention to from the outside.
    • Declarative: “The result should be XYZ. Do whatever you need to do to make that happen.”
    • Example: This element has the .selected class if the user has selected it.

HTML is a declarative language

Forget about JavaScript for a moment. Here’s an important fact: HTML on its own is a declarative language. In an HTML file, you can declare something like:

<section> <h1>Hello</h1> <p>My name is Mike.</p>
</section>

When a web browser reads this HTML, it will figure out these imperative steps for you and execute them:

  1. Create a section element
  2. Create a heading element of level 1
  3. Set the inner text of the heading element to “Hello”
  4. Place the heading element into the section element
  5. Create a paragraph element
  6. Set the inner text of the paragraph element to “My name is Mike”
  7. Place the paragraph element into the section element
  8. Place the section element into the document
  9. Display the document on the screen

As a web developer, the details of how a browser does these things is irrelevant; all that matters is that it does them. This is a perfect example of the difference between these two kinds of programming. In short, HTML is a declarative abstraction wrapped around a web browser’s imperative display engine. It takes care of the “how” so you only have to worry about the “what.” You can enjoy life writing declarative HTML because the fine people at Mozilla or Google or Apple wrote the imperative code for you when they built your web browser.

JavaScript is an imperative language

We’ve already looked at a simple example of imperative JavaScript in the shopping list example above, and I mentioned how the complexity of an app’s features has ripple effects on the effort required to implement them and the potential for bugs in that implementation. Now let’s look at a slightly more complex feature and see how it can be simplified by using a declarative approach.

Imagine a webpage that contains the following:

  • A list of labelled checkboxes, each row of which changes to a different color when it is selected
  • Text at the bottom like “1 of 4 selected” that should update when the checkboxes change
  • A “Select All” button which should be disabled if all checkboxes are already selected
  • A “Select None” button which should be disabled if no checkboxes are selected

Here’s an implementation of this in plain HTML, CSS and imperative JavaScript:

CodePen Embed Fallback

There isn’t much CSS code here because I’m using the wonderful PatternFly design system, which provides most of the CSS for my example. I imported their CSS file in the CodePen settings.

All the small things

In order to implement this feature with imperative JavaScript, we need to give the browser several granular instructions. This is the English-language equivalent to the code in my example above:

  • In our HTML, we declare the initial structure of the page:
    • There are four row elements, each containing a checkbox. The third box is checked.
    • There is some summary text which reads “1 of 4 selected.”
    • There is a “Select All” button which is enabled.
    • There is a “Select None” button which is disabled.
  • In our JavaScript, we write instructions for what to change when each of these events occurs:
    • When a checkbox changes from unchecked to checked:
      • Find the row element containing the checkbox and add the .selected CSS class to it.
      • Find all the checkbox elements in the list and count how many are checked and how many are not checked.
      • Find the summary text element and update it with the checked number and the total number.
      • Find the “Select None” button element and enable it if it was disabled.
      • If all checkboxes are now checked, find the “Select All” button element and disable it.
    • When a checkbox changes from checked to unchecked:
      • Find the row element containing the checkbox and remove the .selected class from it.
      • Find all the checkbox elements in the list and count how many are checked and not checked.
      • Find the summary text element and update it with the checked number and the total number.
      • Find the “Select All” button element and enable it if it was disabled.
      • If all checkboxes are now unchecked, find the “Select None” button element and disable it.
    • When the “Select All” button is clicked:
      • Find all the checkbox elements in the list and check them all.
      • Find all the row elements in the list and add the .selected class to them.
      • Find the summary text element and update it.
      • Find the “Select All” button and disable it.
      • Find the “Select None” button and enable it.
    • When the “Select None” button is clicked:
      • Find all the checkbox elements in the list and uncheck them all.
      • Find all the row elements in the list and remove the .selected class from them.
      • Find the summary text element and update it.
      • Find the “Select All” button and enable it.
      • Find the “Select None” button and disable it.

Wow. That’s a lot, right? Well, we better remember to write code for each and every one of those things. If we forget or screw up any of those instructions, we will end up with a bug where the totals don’t match the checkboxes, or a button is enabled that doesn’t do anything when you click it, or a row ends up with the wrong color, or something else we didn’t think of and won’t find out about until a user complains.

The big problem here is that there is no single source of truth for the state of our app, which in this case is “which checkboxes are checked?” The checkboxes know whether or not they are checked, of course, but, the row styles also have to know, the summary text has to know, and each button has to know. Five copies of this information are stored separately all around the HTML, and when it changes in any of those places the JavaScript developer needs to catch that and write imperative code to keep the others in sync.

This is still only a simple example of one small component of a page. If that sounds like a headache, imagine how complex and fragile an application becomes when you need to write the whole thing this way. For many complex modern web applications, it’s not a scalable solution.

Moving towards a single source of truth

Tools, like React, allow us to use JavaScript in a declarative way. Just as HTML is a declarative abstraction wrapped around the web browser’s display instructions, React is a declarative abstraction wrapped around JavaScript.

Remember how HTML let us focus on the structure of a page and not the details of how the browser displays that structure? Well, when we use React, we can focus on the structure again by defining it based on data stored in a single place. When that source of truth changes, React will update the structure of the page for us automatically. It will take care of the imperative steps behind the scenes, just like the web browser does for HTML. (Although React is used as an example here, this concept is not unique to React and is used by other frameworks, such as Vue.)

Let’s go back to our list of checkboxes from the example above. In this case, the truth we care about is simple: which checkboxes are checked? The other details on the page (e.g. what the summary says, the color of the rows, whether or not the buttons are enabled) are effects derived from that same truth. So, why should they need to have their own copy of this information? They should just use the single source of truth for reference, and everything on the page should “just know” which checkboxes are checked and conduct themselves accordingly. You might say that the row elements, summary text, and buttons should all be able to automatically react to a checkbox being checked or unchecked. (See what I did there?)

Tell me what you want (what you really, really want)

In order to implement this page with React, we can replace the list with a few simple declarations of facts:

  • There is a list of true/false values called checkboxValues that represents which boxes are checked.
    • Example:  checkboxValues = [false, false, true, false]
    • This list represents the truth that we have four checkboxes, and that the third one is checked.
  • For each value in checkboxValues, there is a row element which:
    • has a CSS class called .selected if the value is true, and
    • contains a checkbox, which is checked if the value is true.
  • There is a summary text element that contains the text “{x} of {y} selected” where {x} is the number of true values in checkboxValues and {y} is the total number of values in checkboxValues.
  • There is a “Select All” button that is enabled if there are any false values in checkboxValues.
  • There is a “Select None” button that is enabled if there are any true values in checkboxValues.
  • When a checkbox is clicked, its corresponding value changes in checkboxValues.
  • When the “Select All” button is clicked, it sets all values in checkboxValues to true.
  • When the “Select None” button is clicked, it sets all values in checkboxValues to false.

You’ll notice that the last three items are still imperative instructions (“When this happens, do that”), but that’s the only imperative code we need to write. It’s three lines of code, and they all update the single source of truth. The rest of those bullets are declarations (“there is a…”) which are now built right into the definition of the page’s structure. In order to do this, we write our elements in a special JavaScript syntax provided by React called JSX, which resembles HTML but can contain JavaScript logic. That gives us the ability to mix logic like “if” and “for each” with the HTML structure, so the structure can be different depending on the contents of checkboxValues at any given time.

Here’s the same shopping list example as above, this time implemented with React:

CodePen Embed Fallback

JSX is definitely weird. When I first encountered it, it just felt wrong. My initial reaction was, “What the heck is this? HTML doesn’t belong in JavaScript!” I wasn’t alone. That said, it’s not HTML, but rather JavaScript dressed up to look like HTML. It is also quite powerful.

Remember that list of 20 imperative instructions above? Now we have three. For the price of defining our HTML inside our JavaScript, the rest of them come for free. React just does them for us whenever checkboxValues changes.

With this code, it is now impossible for the summary to not match the checkboxes, or for the color of a row to be wrong, or for a button to be enabled when it should be disabled. There is an entire category of bugs which are now impossible for us to have in our app: sources of truth being out of sync. Everything flows down from the single source of truth, and we developers can write less code and sleep better at night. Well, JavaScript developers can, at least…

It’s a trade-off

As web applications become more complex, maintaining the classic separation of concerns between HTML and JavaScript comes at an increasingly painful cost. HTML was originally designed for static documents, and in order to add more complex interactive functionality to those documents, imperative JavaScript has to keep track of more things and become more confusing and fragile.

The upside: predictability, reusability and composition

The ability to use a single source of truth is the most important benefit of this pattern, but the trade-off gives us other benefits, too. Defining elements of our page as JavaScript code means that we can turn chunks of it into reusable components, preventing us from copying and pasting the same HTML in multiple places. If we need to change a component, we can make that change in one place and it will update everywhere in our application (or in many applications, if we’re publishing reusable components to other teams).

We can take these simple components and compose them together like LEGO bricks, creating more complex and useful components, without making them too confusing to work with. And if we’re using components built by others, we can easily update them when they release improvements or fix bugs without having to rewrite our code.

The downside: it’s JavaScript all the way down

All of those benefits do come at a cost. There are good reasons people value keeping HTML and JavaScript separate, and to get these other benefits, we need to combine them into one. As I mentioned before, moving away from simple HTML files complicates the workflow of someone who didn’t need to worry about JavaScript before. It may mean that someone who previously could make changes to an application on their own must now learn additional complex skills to maintain that autonomy.

There can also be technical downsides. For example, some tools like linters and parsers expect regular HTML, and some third-party imperative JavaScript plugins can become harder to work with. Also, JavaScript isn’t the best-designed language; it’s just what we happen to have in our web browsers. Newer tools and features are making it better, but it still has some pitfalls you need to learn about before you can be productive with it.

Another potential problem is that when the semantic structure of a page is broken up into abstract components, it can become easy for developers to stop thinking about what actual HTML elements are being generated at the end. Specific HTML tags like <section> and <aside> have specific semantic meanings that are lost when using generic tags like <div> and <span>, even if they look the same visually on a page. This is especially important for accessibility. For example, these choices will impact how screen reader software behaves for visually impaired users. It might not be the most exciting part, but JavaScript developers should always remember that semantic HTML is the most important part of a web page.

Use it if it helps you, not because it’s “what’s hot right now”

It’s become a trend for developers to reach for frameworks on every single project. Some people are of the mindset that separating HTML and JavaScript is obsolete, but this isn’t true. For a simple static website that doesn’t need much user interaction, it’s not worth the trouble. The more enthusiastic React fans might disagree with me here, but if all your JavaScript is doing is creating a non-interactive webpage, you shouldn’t be using JavaScript. JavaScript doesn’t load as fast as regular HTML, so if you’re not getting a significant developer experience or code reliability improvement, it’s doing more harm than good.

You also don’t have to build your entire website in React! Or Vue! Or Whatever! A lot of people don’t know this because all the tutorials out there show how to use React for the whole thing. If you only have one little complex widget on an otherwise simple website, you can use React for that one component. You don’t always need to worry about webpack or Redux or Gatsby or any of the other crap people will tell you are “best practices” for your React app.

For a sufficiently complex application, declarative programming is absolutely worth the trouble. It is a game changer that has empowered developers the world over to build amazing, robust and reliable software with confidence and without having to sweat the small stuff. Is React in particular the best possible solution to these problems? No. Will it just be replaced by the next thing? Eventually. But declarative programming is not going anywhere, and the next thing will probably just do it better.

What’s this I’ve heard about CSS-in-JS?

I’m not touching that one.

The post Why JavaScript is Eating HTML appeared first on CSS-Tricks.

Setting Up API Mocking With Mirage JS And Vue.js

Setting Up API Mocking With Mirage JS And Vue.js

Setting Up API Mocking With Mirage JS And Vue.js

Kelvin Omereshone

2020-02-13T11:00:00+00:00 2020-02-14T00:35:51+00:00

In the era of SPA and the JAMstack, there has always been a separation of concern between the APIs and front-end development. Almost all JavaScript projects that can be found out in the wild interact with a web service or API and either use it for authentications or getting user-related data.

So, whenever you’re working on a project and the necessary API still hasn’t been implemented by the back-end team or you need to quickly test a feature, you have some of the following options:

  • You could proxy to a locally running version of your actual backend which, in most cases as a front-end developer, you wouldn’t have.
  • You could comment out actual request and replace with mock data. (This is okay but not so great as you would need to undo that to get to production and you might not be able to deal with network states and latency.)

What Is API Mocking?

API mocking is an imitation or a simulation of an actual API. It is mostly done in order to intercept requests that are supposed to be made to an actual backend API but this mocking exist on your frontend.

Why is API Mocking Important

API mocking is significantly important in a lot of ways:

  1. It makes for a very good front-end development experience not to depend on production APIs before building out features.
  2. You could share your entire frontend and it would work without depending on an actual backend API.

What Is Mirage JS?

Mirage JS was created 5 years ago and was pretty much used in the Ember community before Sam Selikoff officially announced its release on the 24th of January, 2020 on Twitter.

Mirage JS solves the pain point for testing backend APIs without depending on those APIs. It allows for seamless front-end development experience by mocking production APIs.

Mirage JS is an API mocking library for Vue.js, React, Angular and Ember frameworks

What Makes Mirage JS A Better Choice?

There have been other options for API mocking (such as Axios interceptors, Typicode’s JSON server, and so on) but what I think is pretty interesting about Mirage is that it doesn’t get in the way of your development process (as you would see when we set it up with Vue in a bit). It is lightweight and yet powerful.

It comes with battery included out of the box that allows you to replicate real production API consumption scenarios like simulating a slow network with its timing option.

Getting Started With Mirage JS And Vue.js

So now that you know what Mirage JS is and why it’s important to your front-end development workflow, let’s look at setting it up with the progressive web framework: Vue.js.

Creating A Green-Field (Clean Installation) Vue Project

Using the Vue CLI, create a fresh Vue.js project by going into the directory you want the project to be created in and running (in your terminal):

vue create miragejs-demo-vue 

The above command would set up a new Vue project which you can now cd into and run either yarn serve or npm run serve.

#Installing Mirage JS

Now let’s install Mirage JS as a development dependency in our Vue.js project by running the following command:

yarn add -D miragejs

Or if you are using NPM, run this:

npm install --save-dev miragejs

And that’s it! Mirage JS is now installed in our Vue.js project.

Let’s Mock Out Something

With Mirage JS installed, let’s see how we configure it to talk to Vue and mock out a basic todos (an API that returns a list of todos) API.

Define Your Server

To get started, we need to create a server.js file in the /src directory of our Vue.js project. After that, add the following:

import { Server, Model } from 'miragejs' export function makeServer({ environment = "development" } = {}) { let server = new Server({ environment, models: { todo: Model, }, seeds(server) { server.create("todo", { content: "Learn Mirage JS" }) server.create("todo", { content: "Integrate With Vue.js" }) }, routes() { this.namespace = "api" this.get("/todos", schema => { return schema.todos.all() }) }, }) return server
}

Code Explained

Firstly, the server.js file is how you set up Mirage JS to create a new instance of it’s mock (fake) server which will intercept all API calls you make in your app matching the routes that you define.

Now, I agree the above may be overwhelming at first, but let’s take a closer look at what’s going on here:

import { Server, Model } from 'miragejs'

From the above code snippet, we are importing Server and Model from miragejs.

  • Server
    This is a class exposed by Mirage to helps us instantiate a new instance of a Mirage JS server to “serve” as our fake server.
  • Model
    Another class exposed by Mirage to help in creating models(a model determines the structure of a Mirage JS database entry) powered by Mirage’s ORM.
export function makeServer({ environment = "development" } = {}) {}

The above basically export a function called makeServer from the src/server.js. You could also note we are passing in an environment parameter and setting Mirage’s environment mode to development (you would see us passing test environment later on in this article).

The Body Of makeServer

Now we are doing a couple of things in the makeServer body. Let’s take a look:

let server = new Server({})

We are instantiating a new instance of the Server class and passing it a configuration option. The content of the configuration options help set up mirage:

{ environment, models: { todo: Model, }, seeds(server) { server.create("todo", { content: "Learn Mirage JS" }) server.create("todo", { content: "Integrate With Vue.js" }) }, routes() { this.namespace = "api" this.get("/todos", schema => { return schema.todos.all() }) }, }

Firstly we are passing the environment parameter we initialized in the function definition.

models: { todo: Model, },

The next option which is the models option takes an object of the different models we want Mirage to mock.

In the above, we simply want a todo model which we are instantiating from the Model class.

seeds(server) {
server.create("todo", { content: "Learn Mirage JS" })
server.create("todo", { content: "Integrate With Vue.js" })
},

The next option is the seeds method which takes in a parameter called server. The seeds method helps create seeds(seeds are initial data or an entry into Mirage’s database) for our models. In our case to create the seeds for the todo model we do:

server.create("todo", { content: "Learn Mirage JS" })
server.create("todo", { content: "Integrate With Vue.js" })

so the server has a create method which expects as the first argument a string which corresponds to the name of the model, then an object which will contain the properties or attributes of a particular seed.

routes() { this.namespace = "api" this.get("/todos", schema => { return schema.todos.all() }) },

finally, we have the routes method which defines the various route(routes are our mock API endpoints) Mirage JS is going to mock. Let’s look at the body of the method:

this.namespace = "api"

this line sets up the namespace for all routes that means our todo route can now be accessed from /api/todos.

this.get("/todos", schema => { return schema.todos.all()
})

The above creates a get route and it’s handler using the this.get() method. The get() method expects the route i.e “/todos” and a handler function that takes in schema as an argument. The schema object is how you interact with Mirage’s ORM which is powered by Mirage JS in-memory database.

Finally:

return schema.todos.all()

We are returning a list of all our todos, using the schema object made possible by Mirage’s ORM.

src/main.js

So we are done setting up src/server.js but Vue doesn’t know about it(at least not yet). So let’s import it in our main.js file like so:

import { makeServer } from "./server"

Then we call the makeServer function like so:

if (process.env.NODE_ENV === "development") { makeServer()
}

The above if conditional is a guard to make sure mirage only runs in development.

Set up Complete!

Now we’ve set up Miragejs with Vue. Let’s see it in action. In our App.vue file, we would clear out the content and replace with the below snippet:

<template> <ul id="todos"> <li v-for="todo in todos" v-bind:key="todo.id">{{ todo.content }}</li> </ul>
</template> <script> export default { name: 'app', data() { return { todos: [] } }, created() { fetch("/api/todos") .then(res => res.json()) .then(json => { this.todos = json.todos }) } }
</script>

If you are familiar with Vue.js, the above would be nothing new but for the sake of being total, what we are doing is making an API request using fetch when our App.vue component is created, then we pass in the returned data to the todos array in our component state. Afterward, we are using a v-for to iterate the todos array and displaying the content property of each todo.

Where Is The Mirage JS Part?

If you notice, in our App.vue component, we didn’t do anything specific to Mirage, we are just making an API call as we would normally do. This feature of Mirage is really great for DX cause under the hood, Mirage would intercept any requests that match any of the routes defined in src/server.js while you are in development.

This is pretty handy cause no work would be needed in your part to switch to an actual production server when you are in a production environment provided the routes match your production API endpoints.

So restart your Vue dev server via yarn serve to test Mirage JS.

You should see a list of two todos. One thing you’d find pretty interesting is that we did not need to run a terminal command to start up Mirage because it removes that overhead by running as a part of your Vue.js application.

Mirage JS And Vue test-utils

If you are already using Vue Test-utils in your Vue application, you’d find it exciting to know that Mirage can easily work with it to mock network requests. Let’s see an example set up using our todos application.

We would be using Jest for our unit-testing. So if you are following along, you could pretty much use the Vue CLI to install the @vue/unit-jest plugin like so:

vue add @vue/unit-jest

The above will install @vue/cli-plugin-unit-jest and @vue/test-utils development dependencies while also creating a tests directory and a jest.config.js file. It will also add the following command in our package.json scripts section (pretty neat):

"test:unit": "vue-cli-service test:unit"

Let’s Test!

We would update our App.vue to look like this:

<!-- src/App.vue -->
<template> <div v-if="serverError" data-testid="server-error"> {{ serverError }} </div> <div v-else-if="todos.length === 0" data-testid="no-todos"> No todos! </div> <div v-else> <ul id="todos"> <li v-for="todo in todos" v-bind:key="todo.id" :data-testid="'todo-' + todo.id" > {{ todo.content }} </li> </ul> </div>
</template> <script> export default { name: "app", data() { return { todos: [], serverError: null, } }, created() { fetch("/api/todos") .then(res => res.json()) .then(json => { if (json.error) { this.serverError = json.error } else { this.todos = json.todos } }) }, }
</script>

Nothing really epic is going on in the above snippet; we are just structuring to allow for the network testing we would be implementing with our unit test.

Although Vue CLI has already added a /tests folder for us, I find it to be a much better experience when my tests are placed close to the components they are testing. So create a /__tests__ folder in src/ and create an App.spec.js file inside it. (This is also the recommended approach by Jest.)

// src/__tests__/App.spec.js
import { mount } from "@vue/test-utils"
import { makeServer } from "../server"
import App from "../App.vue" let server beforeEach(() => { server = makeServer({ environment: "test" })
}) afterEach(() => { server.shutdown()
})

So to set up our unit testing, we are importing the mount method from @vue/test-utils, importing the Miragejs server we created earlier and finally importing the App.vue component.

Next, we are using the beforeEach life cycle function to start the Mirage JS server while passing in the test environment. (Remember, we set by default the environment to be development.)

Lastly, we are shutting down the server using server.shutdown in the afterEach lifecycle method.

Our Tests

Now let’s flesh out our test (we would be adopting the quickstart section of the Mirage js docs. So your App.spec.js would finally look like this:

// src/__tests__/App.spec.js import { mount } from "@vue/test-utils"
import { makeServer } from "./server"
import App from "./App.vue" let server beforeEach(() => { server = makeServer({ environment: "test" })
}) it("shows the todos from our server", async () => { server.create("todo", { id: 1, content: "Learn Mirage JS" }) server.create("todo", { id: 2, content: "Integrate with Vue.js" }) const wrapper = mount(App) // let’s wait for our vue component to finish loading data // we know it’s done when the data-testid enters the dom. await waitFor(wrapper, '[data-testid="todo-1"]') await waitFor(wrapper, '[data-testid="todo-2"]') expect(wrapper.find('[data-testid="todo-1"]').text()).toBe("Learn Mirage JS") expect(wrapper.find('[data-testid="todo-2"]').text()).toBe("Integrate with Vue.js")
}) it("shows a message if there are no todo", async () => { // Don’t create any todos const wrapper = mount(App) await waitFor(wrapper, '[data-testid="no-todos"]') expect(wrapper.find('[data-testid="no-todos"]').text()).toBe("No todos!")
}) // This helper method returns a promise that resolves
// once the selector enters the wrapper’s dom.
const waitFor = function(wrapper, selector) { return new Promise(resolve => { const timer = setInterval(() => { const todoEl = wrapper.findAll(selector) if (todoEl.length > 0) { clearInterval(timer) resolve() } }, 100) })
} afterEach(() => { server.shutdown()
})

Note: We are using a helper here (as defined in the Mirage JS docs). It returns a promise that allows us to know when the elements we are testing are already in the DOM.

Now run yarn test:unit.

All your tests should pass at this point.

Testing Different Server State With Mirage JS

We could alter our Mirage JS server to test for different server states. Let’s see how.

// src/__tests__/App.spec.js
import { Response } from "miragejs"

First, we import the Response class from Mirage, then we create a new test scenario like so:

it("handles error responses from the server", async () => { // Override Mirage’s route handler for /todos, just for this test server.get("/todos", () => { return new Response( 500, {}, { error: "The database is taking a break.", } ) }) const wrapper = mount(App) await waitFor(wrapper, '[data-testid="server-error"]') expect(wrapper.find('[data-testid="server-error"]').text()).toBe( "The database is taking a break." )
})

Run your test and it all should pass.

Conclusion

This article aimed to introduce you to Mirage JS and show you how it makes for a better front-end development experience. We saw the problem Mirage JS created to address (building production-ready front-end without any actual backend API) and how to set it up with Vue.js.

Although this article scratched the surface of what Mirage JS can do, I believe it is enough to get you started.

  • You could go through the docs as well as join the Mirage JS discord server.
  • The supporting repo for this article is available on GitHub.

References

Smashing Editorial (dm, il)
5 Pitfalls of User-Generated Content (And How to Avoid Them)

It brings with it a host of benefits. UGC can greatly increase engagement with websites, as well as shareability and authenticity. Of course, along with benefits are a host of pitfalls, from having to take the time to moderate content, to establishing an engaged community to submit the content in the first place. It’s important to know the pitfalls of user generated content and how they can be avoided. With a clear strategy, and contingency plan in place, it can end up being a very successful and profitable way of driving engagement to a website.

Here are the pitfalls of user-generated content and how to fix them.

1. It Needs To Be Moderated

In an ideal world, all user generated content would stick to the rules and adhere to the site’s standards. Sadly, that’s not the case. Users will upload whatever they like, from inappropriate sites, to offensive words, or totally irrelevant content.

How To Avoid It

Ensure you build in features where content can be moderated. For example, review companies such as TripAdvisor rely on pre-moderation. This means that all reviews which are submitted are sent through a screening process before being put live for everyone to see. This can take a couple of days to sift through depending on the levels of content which has been uploaded, but ensures the site holds its reputation and doesn’t post offensive, random or meaningless content.

You can also implement functions for the UX of a site which means users can report content themselves. This is the system many large companies such as Facebook and Instagram have built in. The pros of this is that content is available instantly for other users to see and engage with but means unwanted content can also get through.

2. People Use It For Their Own Personal Gain

Once user generated content begins to roll in, it can soon increase the site’s popularity, raise the share count, and have numerous benefits. And this will be something others will latch onto. Users can submit their own content for personal gain, rather than that of the site. For example, a competitor could be promoting a service or running a competition and pretend to be a random user to publicise and promote their own products or services.

How To Avoid It

This comes under careful moderation again, but instead of just looking out for offensive or inappropriate content, you look at the context of what has been submitted and whether it’s for personal gain of the contributor. It’s worth adding in code so that any links submitted, automatically default to “no-follow.” Otherwise you’ll have people uploading content purely for a backlink to their own site. Also check the links they are submitting, where they are pointing to and if they are promoting, selling or advertising anything. You can build in a script that picks up certain keywords and blocks them from appearing or flags up certain comments. This can be a useful feature to easily filter through the genuine and the spam content.

3. You Need An Engaged Community To Continuously Generate New Content

It can take a while for a community to become engaged and known enough to submit content. Many companies rely on user generated content as part of their marketing strategy, yet don’t account for the initial time taken to gather loyal readers and contributors. With no users, there will be no user-submitted content. Simple, but true.

How To Avoid It

Get people to know the company and build a loyal following before requesting content. If those wanting to submit something stumble across your site and see it is under-developed, you have hardly any social media followers and no presence, they won’t see the worth in submitting anything. Build a solid base and learn what motivates people to want to submit content and get them excited about joining part of your community. Users want to have their work, ideas and submissions featured on an aesthetically pleasing site that has been well-designed and feels premium. Ensure plenty of thought has gone into the design process of the look of the site, as well as making the user journey to actually submit the content an easy one. People that find the process easy and rewarding will be likely to return and recommend it to others.

4. Copyright Infringement

With an in-house content creation team, submissions usually have to go through a process before they reach publication. They will be checked, assets confirmed as royalty-free and they will have a knowledge of what you can and what you can’t do. By allowing users to submit content you can be opening yourself to a myriad of copyright infringements on everything from duplicate content to image usage.

How To Avoid It

To avoid receiving a hefty copyright infringement lawsuit in your inbox, it’s important you put certain steps into place. With user generated content there are many questions about who is liable for third-party content if it turns out to be false, improper or harmful; unless you make it clear initially, the blame could fall on the website owner. Ensure you have a contract and guidelines in place that stipulates any content users submit is their own responsibility and they are liable should any issues arise. Make guidelines that states images should be royalty-free and available for re-use before they submit them.

5. Unverified Sources Can Damage Website Credibility

When users are free to submit whatever content they like, there is bound to be a fair amount of fake news. You can never really know who every person who submits something is, nor where they are getting their facts and statements from. Negative comments or sources can damage a brand, particularly when other users have no way of knowing if the contributor is trustworthy or not. After all, “If it’s on the internet, it must be true…”

How To Avoid It

Many sites have come across issues with this, with popular social media sites having many users create fake profiles of companies or celebrities. This can be very damaging to a brand and is why it is an idea to have verified users. Twitter and Instagram are known by the well-recognised blue tick which ensures other users know exactly who is posting content. Other sites such as Waze and TripAdvisor award badges to those who are loyal and regular contributors. Not only does this give an incentive to continually contribute, but other users (and moderators) know they are more trustworthy and less likely to post spam or malicious content that could damage the reputation of a site.

 

Featured image via Unsplash.

Source
p img {display:inline-block; margin-right:10px;}
.alignleft {float:left;}
p.showcase {clear:both;}
body#browserfriendly p, body#podcast p, div#emailbody p{margin:0;}

2020 Stack

In an article with the most clickbaity article ever, Joe Honton does a nice job of talking about the evolving landscape of web development. “Full-stack” perhaps had its day as a useful term, but since front-end development touches so many parts of the stack now, it’s not a particularly useful term. Joe himself did a lot to popularize it, so it does feel extra meaningful coming from him.

Plus the spectrum of how much there is to know is so wide we can’t all know it all, so to get things done, we take what we do know and slot ourselves into cross-functional teams.

Since no one person can handle it all, the 2020 stack must be covered by a team. Not a group of individuals, but a true team. That means that when one person is falling behind, another will pick up the slack. When one person has superior skills, there’s a mechanism in place for mentoring the others. When there’s a gap in the team’s knowledge-base, they seek out and hire a team member who’s smarter than all of them.

So the “2020 Stack” is essentially “know things and work on teams” more so than any particular combination of technologies. That said, Joe does have opinions on technologies, including writing HTML in some weird GraphQL looking syntax that I’d never seen before.

Direct Link to ArticlePermalink

The post 2020 Stack appeared first on CSS-Tricks.

Understanding CSS Grid: Grid Template Areas

Understanding CSS Grid: Grid Template Areas

Understanding CSS Grid: Grid Template Areas

Rachel Andrew

2020-02-12T11:30:00+00:00 2020-02-13T00:39:46+00:00

When using CSS Grid Layout, you can always place items from one grid line to another. However, there is an alternate way of describing your layout, one that is visual in nature. In this article, we will learn how to use the grid-template-areas property to define placement on the grid and find out how the property really works.

In case you missed the previous articles in this series, you can find them over here:

Describing Layout With grid-template-areas

The grid-template-areas property accepts one or more strings as a value. Each string (enclosed in quotes) represents a row of your grid. You can use the property on a grid that you have defined using grid-template-rows and grid-template-columns, or you can create your layout in which case all rows will be auto-sized.

The following property and value describe a grid with four areas — each spanning two column tracks and two row tracks. An area is caused to span multiple tracks by repeating the name in all of the cells that you would like it to cover:

grid-template-areas: "one one two two" "one one two two" "three three four four" "three three four four";

Items are placed into the layout by being named with an indent using the grid-area property. Therefore, if I want to place an element with a class of test into the area of the grid named one, I use the following CSS:

.test { grid-area: one;
}

You can see this in action in the CodePen example shown below. I have four items (with classes one to four); these are assigned to the relevant grid area using the grid-area property and therefore display on the grid in the correct boxes.

See the Pen Simple grid-template-areas example by Rachel Andrew (@rachelandrew) on CodePen.

See the Pen Simple grid-template-areas example by Rachel Andrew (@rachelandrew) on CodePen.

If you use the Firefox Grid Inspector, then you can see the area names and the grid lines demonstrating that each item does indeed span two row and two column tracks — all without doing any line-based positioning on the item itself.

A grid of four items with the Firefox Grid Inspector highlighting the lines
Each items spans two rows and two columns

Rules For Using grid-template-areas

There are a few rules when creating a layout in this way. Breaking the rules will make the value invalid and therefore your layout will not happen. The first rule is that you must describe a complete grid, i.e. every cell on your grid must be filled.

If you do want to leave a cell (or cells) as empty space, you do this by inserting a . or series such as ... with no space between them.

Therefore, if I change the value of grid-template-areas as follows:

grid-template-areas: "one one two two" "one one two two" ". . four four" "three three four four";

I now have two cells with no content in them. Item three only displays in the last row of the grid.

One item now only spans one row with the Firefox Grid Inspector highlighting the lines
There is now whitespace in the grid

You can only define each area once, meaning that you can’t use this property to copy content into two places on the grid! So the following value would be invalid and cause the entire property to be ignored as we have duplicated the area three:

grid-template-areas: "one one three three" "one one two two" "three three four four" "three three four four";

You can’t create a non-rectangular area, so the property can’t be used to create an ‘L’ or ‘T’ shaped area — making the following value also invalid:

grid-template-areas: "one one two two" "one one one one" "three three four four" "three three four four";

Formatting The Strings

I like to display the value of grid-template-areas as I have above (with each string representing a row below the row before). This gives me a visual representation of what the layout will be.

To help with this, it is valuable to add additional whitespace characters between each cell, and also to use multiple . characters denoting empty cells.

In the value below, I have used multiple whitespace characters between smaller words, and also multiple . characters so the empty cells line up:

grid-template-areas: "one one two two" "one one two two" "..... ..... four four" "three three four four";

That said, it is also completely valid to have all of the strings on one line, so we could write our example as follows:

grid-template-areas: "one one two two" "one one two two" "three three four four" "three three four four";

Explaining grid-template-areas And grid-area

The reason that each area needs to be a complete rectangle is that it needs to be the same shape that you could create by using line-based placement. If we stick with our example above, we could make this layout with grid lines as in the next CodePen. Here I have created my grid as before. This time, however, I used grid lines to create the positioning using the longhand grid-column-start, grid-column-end, grid-row-start and grid-row-end properties.

See the Pen Grid Line placement by Rachel Andrew (@rachelandrew) on CodePen.

See the Pen Grid Line placement by Rachel Andrew (@rachelandrew) on CodePen.

Note: If you read my previous article “Understanding CSS Grid: Grid Lines” you will know that it is possible to use grid-area as a shorthand for declaring all four lines at once.

This means that we could also create our layout with the following order of lines:

  • grid-row-start
  • grid-column-start
  • grid-row-end
  • grid-column-end
.one { grid-area: 1 / 1 / 3 / 3;
} .two { grid-area: 1 / 3 / 3 / 5;
} .three { grid-area: 3 / 1 / 5 / 3;
} .four { grid-area: 3 / 3 / 5 / 5;
}

The grid-area property is interesting as it can take line numbers and line names. It is also important to understand the different way it behaves when in each mode.

Using grid-area With Line Numbers

If you use the grid-area property with line numbers, then the lines are assigned in the order described above.

If you miss off any values — therefore providing 1, 2 or 3 line numbers — missing values are set to auto which means that the area will span 1 track (that being the default). So the following CSS would place an item grid-row-start: 3 with all other values set to auto, therefore, the item would be auto-placed in the first available column track, and span one row track and one column track.

grid-area: 3;

Using grid-area With Idents

If you use an ident (which is what a named area is called in Grid Layout), then the grid-area property also takes four lines. If you have named lines on your grid as described in “Understanding CSS Grid: Creating A Grid Container”, then you can use these named lines in the same way as numbered lines.

However, what happens when you miss off some lines is different to when you use idents and not numbers.

Below, I have created a grid with named lines and used grid-area to place an item (missing off the final value):

.grid { display: grid; grid-template-columns: [one-start three-start] 1fr 1fr [one-end three-end two-start four-start] 1fr 1fr [two-end four-end]; grid-template-rows: [one-start two-start] 100px 100px [one-end two-end three-start four-start] 100px 100px [three-end four-end];;
} .two { grid-area: two-start / two-start / two-end;
}

This means that we are missing the line name for grid-column-end. The spec says that in this situation, grid-column-end should use a copy of grid-column-start. If grid-column-end and grid-column-start are identical, then the end line is thrown away, and essentially the value is set to auto so we span one track as in the numbered version.

The same thing happens if we miss off the third value grid-row-end; it becomes the same as grid-row-start and therefore becomes auto.

Take a look at the next CodePen example of how each grid-area is used and how this then changes the layout of the item:

See the Pen Missing idents in grid-area by Rachel Andrew (@rachelandrew) on CodePen.

See the Pen Missing idents in grid-area by Rachel Andrew (@rachelandrew) on CodePen.

This then explains why grid-area works with a single value ident representing an area name.

When we create a named area with the grid-template-areas property, the edge of each area can be referenced by a line name which is the same as the area name you used. In our case, we could take our area named one and place our item using named lines as follows:

.one { grid-row-start: one; grid-row-end: one; grid-column-start: one; grid-row-end: one;
}

If the line is a -start line, then one resolves to the start end of the column or row. If it is an -end line, then one resolves to the end line of the column or row.

This means that when we say grid-area: one, we have omitted the last three values for the grid-area shorthand; they all end up being copies of the first value — all in our case become one and the item is placed just as with our longhand usage.

The way that naming works in Grid Layout is clever and enables some interesting things, which I have written about in my previous articles “Naming Things In CSS Grid Layout” and “Editorial Design Patterns With CSS Grid And Named Columns”.

Layering Items When Using grid-template-areas

Only one name can occupy each cell when using grid-template-areas, however, you can still add additional items to the grid after doing your main layout in this way. You can use the line numbers as usual.

In the below CodePen example, I have added an additional item and positioned it using line-based positioning over the items already positioned:

See the Pen Placing an item with line numbers by Rachel Andrew (@rachelandrew) on CodePen.

See the Pen Placing an item with line numbers by Rachel Andrew (@rachelandrew) on CodePen.

You can also use lines names defined when creating your usual columns or rows. Even better, you’ll have some line names created by the formation of the areas. We’ve already seen how you can get four line names with the name of the area. You also get a line on the start edge of each area with -start appended to the name of the area, and a line at the end edge of each area with -end appended.

Therefore, the area named one has start edge lines named one-start and end edge lines named one-end.

You can then use these implicit line names to place an item on the grid. This can be useful if you are redefining the grid at different breakpoints as long as you always want the placed item to come after a certain line name.

See the Pen Placing an item with implicit line names by Rachel Andrew (@rachelandrew) on CodePen.

See the Pen Placing an item with implicit line names by Rachel Andrew (@rachelandrew) on CodePen.

Using Grid Template Areas In Responsive Design

I often work with building up components in a component library and I find that using grid-template-areas can be helpful in terms of being able to see exactly what a component will look like from the CSS. It is also very straightforward to redefine the component at different breakpoints by redefining the value of grid-template-areas sometimes in addition to changing the number of available column tracks.

In the CSS below, I have defined a single column layout for my component. Next, at a minimum width of 600px, I redefine the number of columns and also the value of grid-template-areas in order to create a layout with two columns. The nice thing about this approach is that anyone looking at this CSS can see how the layout works!

.wrapper { background-color: #fff; padding: 1em; display: grid; gap: 20px; grid-template-areas: "hd" "bd" "sd" "ft"; } @media (min-width: 600px) { .wrapper { grid-template-columns: 3fr 1fr; grid-template-areas: "hd hd" "bd sd" "ft ft"; }
} header { grid-area: hd; }
article {grid-area: bd; }
aside { grid-area: sd; }
footer { grid-area: ft; }

Accessibility

You need to be aware when using this method that it is very easy to move things around and cause the problem of disconnecting the visual display from the underlying source order. Anyone tabbing around the site, or who is watching the screen while having the content spoken, will be using the order that things are in the source. By moving the display from that order, you could create a very confusing, disconnected experience. Don’t use this method to move things around without also ensuring that the source is in a sensible order and matching the visual experience.

Summary

That’s the lowdown on using the grid-template-area and grid-area properties to create layouts. If you haven’t used this layout method before, give it a try. I find that it is a lovely way to experiment with layouts and often use it when prototyping a layout — even if for one reason or another we will ultimately use a different method for the production version.

Overflow And Data Loss In CSS

CSS is designed to keep your content readable. Let’s explore situations in which you might encounter overflow in your web designs and how CSS has evolved to create better ways to manage and design around unknown amounts of content. Read article →

Smashing Editorial (il)
Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Youtube
Consent to display content from Youtube
Vimeo
Consent to display content from Vimeo
Google Maps
Consent to display content from Google