SVG Marching Ants

CSS border-radius can do that?

The fast and visual way to understand your users

(This is a sponsored post.)

Hotjar is everything your team needs to:

• Get instant visual user feedback
• See how people are really using your site
• Uncover insights to make the right changes
• All in one central place

If you are a web or UX designer or into web marketing, Hotjar will allow you to improve how your site performs. Try it for free.

Direct Link to Article — Permalink

The post The fast and visual way to understand your users appeared first on CSS-Tricks.

from CSS-Tricks https://synd.co/2CzmGTt
via IFTTT

Did we get anywhere on that :nth-letter() thing?

No, not really.

I tried to articulate a need for it in 2011 in A Call for ::nth-everything.

Jeremy takes a fresh look at this here in 2018, noting that the first published desire for this was 15 years ago. All the same use cases still exist now, but perhaps slightly more, since web typography has come along way since then. Our desire to do more (and hacks to make it happen) are all the greater.

I seem to recall the main reason we don't have these things isn't necessarily the expected stuff like layout paradoxes, but rather the different typed languages of the world. As in, there are languages in which single characters are words and text starts in different places and runs in different directions. The meaning of "first" and "line" might get nebulous in a way specs don't like.

Direct Link to Article — Permalink

The post Did we get anywhere on that :nth-letter() thing? appeared first on CSS-Tricks.

from CSS-Tricks https://ift.tt/2OaTFns
via IFTTT

Introducing GitHub Actions

How to Import a Sass File into Every Vue Component in an App

If you're working on a large-scale Vue application, chances are at some point you're going to want to organize the structure of your application so that you have some globally defined variables for CSS that you can make use of in any part of your application.

This can be accomplished by writing this piece of code into every component in your application:

<style lang="scss">
  @import "./styles/_variables.scss";
</style>

But who has time for that?! We're programmers, let's do this programmatically.

Why?

You might be wondering why we would want to do something like this, especially if you're just starting out in web development. Globals are bad, right? Why would we need this? What even are Sass variables? If you already know all of this, then you can skip down to the next section for the implementation.

Companies big and small tend to have redesigns at least every one-to-two years. If your code base is large, managed by many people, and you need to change the line-height everywhere from 1.1rem to 1.2rem, do you really want to have to go back into every module and change that value? A global variable becomes extraordinarily useful here. You decide what can be at the top-level and what needs to be inherited by other, smaller, pieces. This avoids spaghetti code in CSS and keeps your code DRY.

I once worked for a company that had a gigantic, sprawling codebase. A day before a major release, orders came down from above that we were changing our primary brand color. Because the codebase was set up well with these types of variables defined correctly, I had to change the color in one location, and it propagated through 4,000 files. That's pretty powerful. I also didn't have to pull an all-nighter to get the change through in time.

Styles are about design. Good design is, by nature, successful when it's cohesive. A codebase that reuses common pieces of structure can look more united, and also tends to look more professional. If you have to redefine some base pieces of your application in every component, it will begin to break down, just like a phrase does in a classic game of telephone.

Global definitions can be self-checking for designers as well: "Wait, we have another tertiary button? Why?" Leaks in cohesive UI/UX announce themselves well in this model.

How?

The first thing we need is to have vue-cli 3 installed. Then we create our project:

npm install -g @vue/cli
# OR
yarn global add @vue/cli

# then run this to scaffold the project
vue create scss-loader-example

When we run this command, we're going to make sure we use the template that has the Sass option:

? Please pick a preset: Manually select features
? Check the features needed for your project:
  ◉ Babel
  ◯ TypeScript
  ◯ Progressive Web App (PWA) Support
  ◯ Router
  ◉ Vuex
❯ ◉ CSS Pre-processors
  ◉ Linter / Formatter
  ◯ Unit Testing
  ◯ E2E Testing

The other options are up to you, but you need the CSS Pre-processors option checked. If you have an existing vue cli 3 project, have no fear! You can also run:

npm i node-sass sass-loader
# OR
yarn add node-sass sass-loader

First, let's make a new folder within the src directory. I called mine styles. Inside of that, I created a _variables.scss file, like you would see in popular projects like bootstrap. For now, I just put a single variable inside of it to test:

$primary: purple;

Now, let's create a file called vue.config.js at the root of the project at the same level as your package.json. In it, we're going to define some configuration settings. You can read more about this file here.

Inside of it, we'll add in that import statement that we saw earlier:

module.exports = {
  css: {
    loaderOptions: {
      sass: {
        data: `@import "@/styles/_variables.scss";`
      }
    }
  }
};

OK, a couple of key things to note here:

• You will need to shut down and restart your local development server to make any of these changes take hold.
• That @/ in the directory structure before styles will tell this configuration file to look within the src directory.
• You don't need the underscore in the name of the file to get this to work. This is a Sass naming convention.
• The components you import into will need the lang="scss" (or sass, or less, or whatever preprocessor you're using) attribute on the style tag in the .vue single file component. (See example below.)

Now, we can go into our default App.vue component and start using our global variable!

<style lang="scss">
#app {
  font-family: "Avenir", Helvetica, Arial, sans-serif;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  text-align: center;
  //this is where we use the variable
  color: $primary;
  margin-top: 60px;
}
</style>

Here's a working example! You can see the text in our app turn purple:

Shout out to Ives, who created CodeSandbox, for setting up a special configuration for us so we could see these changes in action in the browser. If you'd like to make changes to this sandbox, there's a special Server Control Panel option in the left sidebar, where you can restart the server. Thanks, Ives!

And there you have it! You no longer have to do the repetitive task of @import-ing the same variables file throughout your entire Vue application. Now, if you need to refactor the design of your application, you can do it all in one place and it will propagate throughoutyour app. This is especially important for applications at scale.

The post How to Import a Sass File into Every Vue Component in an App appeared first on CSS-Tricks.

from CSS-Tricks https://ift.tt/2NIxIac
via IFTTT

Why Using reduce() to Sequentially Resolve Promises Works

Writing asynchronous JavaScript without using the Promise object is a lot like baking a cake with your eyes closed. It can be done, but it's gonna be messy and you'll probably end up burning yourself.

I won't say it's necessary, but you get the idea. It's real nice. Sometimes, though, it needs a little help to solve some unique challenges, like when you're trying to sequentially resolve a bunch of promises in order, one after the other. A trick like this is handy, for example, when you're doing some sort of batch processing via AJAX. You want the server to process a bunch of things, but not all at once, so you space the processing out over time.

Ruling out packages that help make this task easier (like Caolan McMahon's async library), the most commonly suggested solution for sequentially resolving promises is to use Array.prototype.reduce(). You might've heard of this one. Take a collection of things, and reduce them to a single value, like this:

let result = [1,2,5].reduce((accumulator, item) => {
  return accumulator + item;
}, 0); // <-- Our initial value.

console.log(result); // 8

But, when using reduce() for our purposes, the setup looks more like this:

let userIDs = [1,2,3];

userIDs.reduce( (previousPromise, nextID) => {
  return previousPromise.then(() => {
    return methodThatReturnsAPromise(nextID);
  });
}, Promise.resolve());

Or, in a more modern format:

let userIDs = [1,2,3];

userIDs.reduce( async (previousPromise, nextID) => {
  await previousPromise;
  return methodThatReturnsAPromise(nextID);
}, Promise.resolve());

This is neat! But for the longest time, I just swallowed this solution and copied that chunk of code into my application because it "worked." This post is me taking a stab at understanding two things:

1. Why does this approach even work?
2. Why can't we use other Array methods to do the same thing?

Why does this even work?

Remember, the main purpose of reduce() is to "reduce" a bunch of things into one thing, and it does that by storing up the result in the accumulator as the loop runs. But that accumulator doesn't have to be numeric. The loop can return whatever it wants (like a promise), and recycle that value through the callback every iteration. Notably, no matter what the accumulator value is, the loop itself never changes its behavior — including its pace of execution. It just keeps rolling through the collection as fast as the thread allows.

This is huge to understand because it probably goes against what you think is happening during this loop (at least, it did for me). When we use it to sequentially resolve promises, the reduce() loop isn't actually slowing down at all. It’s completely synchronous, doing its normal thing as fast as it can, just like always.

Look at the following snippet and notice how the progress of the loop isn't hindered at all by the promises returned in the callback.

function methodThatReturnsAPromise(nextID) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {

      console.log(`Resolve! ${dayjs().format('hh:mm:ss')}`);

      resolve();
    }, 1000);
  });
}

[1,2,3].reduce( (accumulatorPromise, nextID) => {

  console.log(`Loop! ${dayjs().format('hh:mm:ss')}`);

  return accumulatorPromise.then(() => {
    return methodThatReturnsAPromise(nextID);
  });
}, Promise.resolve());

In our console:

"Loop! 11:28:06"
"Loop! 11:28:06"
"Loop! 11:28:06"
"Resolve! 11:28:07"
"Resolve! 11:28:08"
"Resolve! 11:28:09"

The promises resolve in order as we expect, but the loop itself is quick, steady, and synchronous. After looking at the MDN polyfill for reduce(), this makes sense. There's nothing asynchronous about a while() loop triggering the callback() over and over again, which is what's happening under the hood:

while (k < len) {
  if (k in o) {
    value = callback(value, o[k], k, o);
  }
  k++;
}

With all that in mind, the real magic occurs in this piece right here:

return previousPromise.then(() => {
  return methodThatReturnsAPromise(nextID)
});

Each time our callback fires, we return a promise that resolves to another promise. And while reduce() doesn't wait for any resolution to take place, the advantage it does provide is the ability to pass something back into the same callback after each run, a feature unique to reduce(). As a result, we're able build a chain of promises that resolve into more promises, making everything nice and sequential:

new Promise( (resolve, reject) => {
  // Promise #1
  
  resolve();
}).then( (result) => { 
  // Promise #2
  
  return result;
}).then( (result) => { 
  // Promise #3
  
  return result;
}); // ... and so on!

All of this should also reveal why we can't just return a single, new promise each iteration. Because the loop runs synchronously, each promise will be fired immediately, instead of waiting for those created before it.

[1,2,3].reduce( (previousPromise, nextID) => {

  console.log(`Loop! ${dayjs().format('hh:mm:ss')}`);
  
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      console.log(`Resolve! ${dayjs().format('hh:mm:ss')}`);
      resolve(nextID);
    }, 1000);
  });
}, Promise.resolve());

In our console:

"Loop! 11:31:20"
"Loop! 11:31:20"
"Loop! 11:31:20"
"Resolve! 11:31:21"
"Resolve! 11:31:21"
"Resolve! 11:31:21"

Is it possible to wait until all processing is finished before doing something else? Yes. The synchronous nature of reduce() doesn't mean you can't throw a party after every item has been completely processed. Look:

function methodThatReturnsAPromise(id) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      console.log(`Processing ${id}`);
      resolve(id);
    }, 1000);
  });
}

let result = [1,2,3].reduce( (accumulatorPromise, nextID) => {
  return accumulatorPromise.then(() => {
    return methodThatReturnsAPromise(nextID);
  });
}, Promise.resolve());

result.then(e => {
  console.log("Resolution is complete! Let's party.")
});

Since all we're returning in our callback is a chained promise, that's all we get when the loop is finished: a promise. After that, we can handle it however we want, even long after reduce() has run its course.

Why won't any other Array methods work?

Remember, under the hood of reduce(), we're not waiting for our callback to complete before moving onto the next item. It's completely synchronous. The same goes for all of these other methods:

• Array.prototype.map()
• Array.prototype.forEach()
• Array.prototype.filter()
• Array.prototype.some()
• Array.prototype.every()

But reduce() is special.

We found that the reason reduce() works for us is because we're able to return something right back to our same callback (namely, a promise), which we can then build upon by having it resolve into another promise. With all of these other methods, however, we just can't pass an argument to our callback that was returned from our callback. Instead, each of those callback arguments are predetermined, making it impossible for us to leverage them for something like sequential promise resolution.

[1,2,3].map((item, [index, array]) => [value]);
[1,2,3].filter((item, [index, array]) => [boolean]);
[1,2,3].some((item, [index, array]) => [boolean]);
[1,2,3].every((item, [index, array]) => [boolean]);

I hope this helps!

At the very least, I hope this helps shed some light on why reduce() is uniquely qualified to handle promises in this way, and maybe give you a better understanding of how common Array methods operate under the hood. Did I miss something? Get something wrong? Let me know!

The post Why Using reduce() to Sequentially Resolve Promises Works appeared first on CSS-Tricks.

from CSS-Tricks https://ift.tt/2pYy7vB
via IFTTT