Archiwum kategorii: CSS

A Reasonable Approach for Getting Comfortable With Command Line

Post pobrano z: A Reasonable Approach for Getting Comfortable With Command Line

Considering how much the command line is an integral part of the developer’s workflow, it should not be thought overly difficult or tedious to learn.

At one time I avoided it myself, but one day began teaching myself ways to make the difficult as easy as it should be. I got over the hurdle, and you can too. It was worth investing my time to increase my command line comfort-level, and I am going to share a few tips and resources that I found helpful in this post.

The intended reader is the type who typically avoids the command line, or perhaps uses it occasionally but not as a regular or essential tool.

Tip #1: Maintain a Pragmatic Mindset

The way to get more comfortable with the command line is this: practice. You practice, and you get better. There is no secret trick to this; study and repetition of skills will turn into understanding and mastery. There is no use in the mindset that you cannot do this; it will only keep you from your goal. You may as well discard such thoughts and get down to it.

Tip #2: Keep a Cheat sheet

Don’t be afraid to keep a cheat sheet. I find that a thin, spiral-bound notebook kept next to my keyboard is perfect; writing the command down helps commit it to memory; having it in a place where I can refer to it while I am typing is convenient to the process. Do not permit yourself merely to copy and paste; you will not learn this way. Until you know the command, make yourself type it out.

Tip #3: Peruse languages outside of the one(s) you normally use

  1. Spend time looking at commands in various languages, looking at the commands even if you don’t immediately absorb, use, or remember them. It is worth it to invest a bit of time regularly, looking at these commands; patterns will eventually emerge. Some of them may even come back to you at an unexpected time and give you an extra eureka moment!
  2. Skimming through books with lots of CLI commands can prove interestingly useful for recognizing patterns in commands. I even take this one step further by getting my favorites spiral-bound. I am a big fan of spiral binding; a place like FedEx offers coil binding services at a surprisingly low cost.

Tip #4: Practice… safely

When I am advising someone who is new to contributing to open source, they are inevitably a bit nervous about it. I think this is perfectly natural if only to comfort myself that my own nervousness about it was perfectly natural. A good way to practice, though, is to set up your own repository for a project and regularly commit to it. Simply using common Git commands in a terminal window to commit inconsequential changes to a project of your own, will establish the „muscle memory” so that when it does come time to actually commit code of consequence, you won’t be held back by still being nervous about the commands themselves.

These are the commands I have noticed most common to use in the practical day-to-day of development. It’s perfectly acceptable to expect yourself to learn these and to be able to do any of them without a second thought. Do not use a GUI tool (they make weird merge choices). Learn how to write these commands yourself.

  • Check status
  • Create a new branch and switch to it
  • Add files
    • Add all the changes
    • Just add one of the changes
  • Commit
  • Push to a remote branch
  • Get a list of your branches
  • Checkout a branch
  • Delete a branch
  • Delete a branch even if there are changes
  • Fetch and merge the changes to a branch

Syncing a fork took longer to learn- I don’t often spend my work hours writing code for a repository that I don’t have access to. While contributing to open source software, however, I had to learn how to do this. The GitHub article about the topic is sufficient; even now I still have it bookmarked.

Tip #5: Level Up!

I really enjoy using Digital Ocean to level up my skills. Their step-by-step guides are really useful, and for $5 USD per month, „Droplets” are a cost-effective way to do so.

Here’s a suggested self-learning path (which, feel free to choose your own adventure! There are over 1700 tutorials in the Digital Ocean community):

  1. Create a Droplet with Ghost pre-installed. There is a little command line work to finalize the installation, which makes it a good candidate. It’s not completely done for you but there’s not so much to do that it’s overwhelming. There’s even an excellent tutorial already written by Melissa Anderson.
  2. Set up a GitHub repo to work on a little theming for Ghost, making small changes and practice your command line work.

It would be remiss of me to write any guide without mentioning Ember, as the ember-cli is undoubtedly one of the strongest there is. Feel free to head over to the docs and read that list!

Conclusion

There may be some that find this brief guide too simplistic. However, as famously said by S. Thompson in Calculus Made Easy- „What one fool can do, other fools can do also.” Don’t let anyone else make you think that using the command line is horribly difficult, or that they are a genius because they can. With practice, you will be able to do it, and it will soon be a simple thing.


A Reasonable Approach for Getting Comfortable With Command Line is a post from CSS-Tricks

Reboot, Resets, and Reasoning

Post pobrano z: Reboot, Resets, and Reasoning

I saw in an article by Nicholas Cerminara the other day (careful visiting that link, looks like they have some tracking scripts run wild) that Bootstrap 4 has a new CSS reset baked in they are calling Reboot:

Reboot, a collection of element-specific CSS changes in a single file, kickstart Bootstrap to provide an elegant, consistent, and simple baseline to build upon.

If you’re new to CSS development, the whole idea of a CSS reset is to deal with styling inconsistencies across browsers. For example, just now I popped a <button> onto a page with no other styling whatsoever. Chrome applies padding: 2px 6px 3px; – Firefox applies padding: 0 8px;. A CSS reset would apply new padding to that element, so that all browsers are consistent about what they apply. There are loads of examples like that.

By way of a bit of history…

In 2007 Jeff Starr rounded up a bunch of different CSS resets. The oldest one dated is Tantek Çelik’s undohtml.css (that’s a direct link to the source). We can see that the purpose behind it was to strip away default styling.

/* undohtml.css */
/* (CC) 2004 Tantek Celik. Some Rights Reserved.             */
/*   http://creativecommons.org/licenses/by/2.0                   */
/* This style sheet is licensed under a Creative Commons License. */

/* Purpose: undo some of the default styling of common (X)HTML browsers */

By far, the most popular reset came shortly after: the Meyer reset. It has different stuff in it than Tantek’s did (it has even been updated with some HTML5 elements) but the spirit is the same: remove default styling. You’ll probably recognize this famous block of code, finding its way into your DevTools style panel everywhere:

html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed, 
figure, figcaption, footer, header, hgroup, 
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
	margin: 0;
	padding: 0;
	border: 0;
	font-size: 100%;
	font: inherit;
	vertical-align: baseline;
}

Start with a reset like this (at the top of your production stylesheet) and the styles you write afterword will be on a steady foundation.

Years later, as HTML5 became more real, resets like Richard Clark’s HTML5 Reset gained popularity. It was still a modified version of the Meyer reset, and the retained that spirit.

article,aside,details,figcaption,figure,
footer,header,hgroup,menu,nav,section { 
    display:block;
}

Sprinkled all throughout this, there were plenty of developers who went minimal by just zapping margin and padding from everything and leaving it at that:

* {
  padding: 0;
  margin: 0;
}

Dumb trivia: the CSS-Tricks logo was inspired by the universal selector and that idea.

Along comes Normalize.css…

Normalize.css represents the first meaningful shift in spirit for what a CSS reset should do. This is what seemed so different about it to me:

  • It was a fresh evaluation of everything that could be styled different across browsers and it address all of it. Where older CSS resets were a handful of lines of code, the uncompressed and documented normalize is 447.
  • It didn’t remove any styling from elements that were already consistent across browsers (for the most part). For example, there isn’t anything in Normalize for h2-h6 elements, just a fix for a weird h1 thing. That means you aren’t zapping away header hierarchy, that default styling remains.
  • It was more accommodating to the idea of altering it, rather than just including it. For example, there is a section just for the <pre> tag and one line of that sets its font-family. You could change that to the font-family you want, and it would be just as effective of a reset.

The code is satisfying to read, as it explains what it’s doing without drowning in specifics:

/**
 * 1. Remove the bottom border in Chrome 57- and Firefox 39-.
 * 2. Add the correct text decoration in Chrome, Edge, IE, Opera, and Safari.
 */

abbr[title] {
  border-bottom: none; /* 1 */
  text-decoration: underline; /* 2 */
  text-decoration: underline dotted; /* 2 */
}

Today Normalize is at 7.0.0 and has going on 30,000 GitHub stars. It’s wicked popular.

So… resets can be opinionated?

We’ve seen lots of different takes on CSS resets and we’ve seen fundamental shifts in the approach, so I think it’s fair to say CSS resets can take an opinionated stance.

Let’s consider some ways…

  • Does the reset touch every single possible element? Or a subset of elements? How does it decide which elements to touch and which not to?
  • What properties are changed? Only ones with cross-browser differences? Or some other criteria, like the similarity to other elements that needed changes? Is it OK to apply properties to elements that don’t have cross-browser issues in the name of consistency and efficiency?
  • Do you try to preserve the spirit of the user agent stylesheet? Sensible defaults?
  • Do you apply any properties that don’t have cross-browser issues could be considered beneficial to „reset”, like typographic defaults or box-sizing?
  • Do you include „toolbox” classes for common needs? Or leave that for other projects to handle?
  • Are you concerned about the size of it?
  • Do you use a preprocessor or any other tooling?

Take a look at Vanilla CSS Un-Reset. Loads of opinions here, starting with the idea that it’s meant to re-style elements after you un-style then with a reset. It set’s the body font size in pt, set a very specific monospace font stack, includes a ol ol ol ol selector, a clearfix, and alignment helper classes. No judgment there. People make things to help with their own problems and I’m sure this was helpful to the creator. But we can see the opinions shine through there.

Now look at MiniReset.css. Very different! It does wipe out type styles „so that using semantic markup doesn’t affect the styling”, but leaves some defaults in place on purpose „so that buttons and inputs keep their default layout”, puts in some things that don’t have cross-browser problems but are useful globally (box-sizing), and adds some minor responsive design helpers.

Totally different set of opinions there.

Jonathan Neal created a reset called santize.css that is very clear about it’s opinions. Search for the word „opinionated” in the source code and you’ll see it 19 times. All these are choices that Jonathan made based on research and what seem to be modern best practices, and no doubt sprinkled with his own needs and desires for what should be in a reset.

/*
 * Remove the text shadow on text selections (opinionated).
 * 1. Restore the coloring undone by defining the text shadow (opinionated).
 */

::-moz-selection {
	background-color: #b3d4fc; /* 1 */
	color: #000000; /* 1 */
	text-shadow: none;
}

::selection {
	background-color: #b3d4fc; /* 1 */
	color: #000000; /* 1 */
	text-shadow: none;
}

The word „reset”

Personally, I think it’s useful to think of all of them under the same umbrella term and just be aware of the philosophical differences. But, Normalize intentionally separates itself:

A modern, HTML5-ready alternative to CSS resets

Sanitize calls itself a CSS library and doesn’t use the word „reset” anywhere except to cite the Meyer reset.

Reboot

Reboot is interesting as it’s perhaps the newest player in this world. It’s file history dates back to 2015, which is probably related to Bootstrap 4 taking a while to drop after Bootstrap 3. Reboot doesn’t have its own repo, it’s a part of Bootstrap. Here’s the direct file and the docs.

The way they think about it is interesting:

Reboot builds upon Normalize, providing many HTML elements with somewhat opinionated styles using only element selectors. Additional styling is done only with classes. For example, we reboot some <table> styles for a simpler baseline and later provide .table, .table-bordered, and more.

You can have a class that does styling, but if you use a reset, you don’t have to overload that class with reset styles that handle cross-browser consistency issues.

//
// Tables
//

table {
  border-collapse: collapse; // Prevent double borders
}

caption {
  padding-top: $table-cell-padding;
  padding-bottom: $table-cell-padding;
  color: $text-muted;
  text-align: left;
  caption-side: bottom;
}

th {
  // Matches default `<td>` alignment by inheriting from the `<body>`, or the
  // closest parent with a set `text-align`.
  text-align: inherit;
}

It’s definitely opinionated, but in a way that rolls with Bootstrap nicely. The fact that it’s buried within Bootstrap is pretty good signaling this is designed for that world, not as a drop-in for any project. That said, I did my best to compile a straight CSS version of it here.

Tailoring a reset based on browser support

So long as we’re talking about the past and future of resets, it’s worth mentioning Browserslist again, which is a standardized format for declaring what browsers/versions a project supports.

A reset could be built in a such a way that the things it includes know why they are there. Exactly what browser and version it is there to support. Then if browserslist configuration says that particular browser isn’t supported by this project anyway, that CSS could be removed.

That’s what PostCSS Normalize does.


Reboot, Resets, and Reasoning is a post from CSS-Tricks

Breaking down CSS Box Shadow vs. Drop Shadow

Post pobrano z: Breaking down CSS Box Shadow vs. Drop Shadow

Drop shadows. Web designers have loved them for a long time to the extent that we used to fake them with PNG images before CSS Level 3 formally introduced them to the spec as the box-shadow property. I still reach for drop shadows often in my work because they add a nice texture in some contexts, like working with largely flat designs.

Not too long after box-shadow was introduced, a working draft for CSS Filters surfaced and, with it, a method for drop-shadow() that looks a lot like box-shadow at first glance. However, the two are different and it’s worth comparing those differences.

For me, the primary difference came to light early on when I started working with box-shadow. Here’s a simple triangle not unlike the one I made back then.

See the Pen CSS Caret by CSS-Tricks (@css-tricks) on CodePen.

Let’s use this to break down the difference between the two.

Box Shadow

Add a box-shadow on that bad boy and this happens.

See the Pen CSS Caret Box Shadow by CSS-Tricks (@css-tricks) on CodePen.

It’s annoying, but makes sense. CSS uses a box model, where the element’s edges are bound in the shape of a rectangle. Even in cases where the shape of the element does not appear to be a box, the box is still there and that is was box-shadow is applied to. This was my „ah-ha moment” when understanding the box in box-shadow.

CSS Filter Drop Shadow

CSS Filters are pretty awesome. Take a gander at all the possibilities for adding visual filters on elements and marvel at how CSS suddenly starts doing a lot of things we used to have to mockup in Photoshop.

Filters are not bound to the box model. That means the outline of our triangle is recognized and the transparency around it is ignored so that the intended shape receives the shadow.

See the Pen CSS Caret Drop Shadow by CSS-Tricks (@css-tricks) on CodePen.

Deciding Which Method to Use

The answer is totally up to you. The simple example of a triangle above might make it seem that filter: drop-shadow() is better, but it’s not a fair comparison of the benefits or even the possibilities of both methods. It’s merely an illustration of their different behaviors in a specific context.

Like most things in development, the answer of which method to use depends. Here’s a side-by-side comparison to help distinguish the two and when it might be best to choose one over the other.

Box Shadow Drop Shadow
Specification CSS Backgrounds and Borders Module Level 3 Filter Effects Module Level 1
Browser Support Great Good
Supports Spread Radius Yes, as an optional fourth value No
Blur Radius Calculation is based on a pixel length Calculation is based on the stdDeviation attribute of the SVG filter
Supports inset shadows Yes No
Performance Not hardware accelerated Hardware accelerated in browsers that support it. It’s a heavy lift without it.

Wrapping Up

The difference between box-shadow and filter: drop-shadow() really boils down to the CSS box model. One sees it and the other disregards it. There are other differences that distinguish the two in terms of browser support, performance and such, but the way the two treat the box model is the key difference.

Update: Amelia identified another key difference in the comments where the spread of the radius for drop-shadow() is calculated differently than box-shadow and even that of text-shadow. That means that the spread radius you might specify in box-shadow is not one-to-one with the default spread value for drop-shadow, so the two are not equal replacements of one another in some cases.

Let’s cap this off with a few other great examples illustrating that. Lennart Schoors also has a nice write-up with practical examples using tooltips and icons that we previously called out.

See the Pen Drop-shadow vs box-shadow (2) by Kseso (@Kseso) on CodePen.

See the Pen box-shadow & drop-shadow by qnlz (@qnlz) on CodePen.

See the Pen Drop-shadow vs box-shadow (3) en png´s by Kseso (@Kseso) on CodePen.


Breaking down CSS Box Shadow vs. Drop Shadow is a post from CSS-Tricks

Creating Vue.js Transitions & Animations

Post pobrano z: Creating Vue.js Transitions & Animations

My last two projects hurled me into the JAMstack. SPAs, headless content management, static generation… you name it. More importantly, they gave me the opportunity to learn Vue.js. More than „Build a To-Do App” Vue.js, I got to ship real-life, production-ready Vue apps.

The agency behind Snipcart (Spektrum) wanted to start using decoupled JavaScript frameworks for small to medium sites. Before using them on client projects, however, they chose to experiment on themselves. After a few of my peers had unfruitful experiences with React, I was given the green light to prototype a few apps in Vue. This prototyping morphed into full-blown Vue apps for Spektrum connected to a headless CMS. First, I spent time figuring out how to model and render our data appropriately. Then I dove head first into Vue transformations to apply a much-needed layer of polish on our two projects.

I’ve prepared live demos on CodePen and GitHub repos to go along with this article.

This post digs into Vue.js and the tools it offers with its transition system. It is assumed that you are already comfortable with the basics of Vue.js and CSS transitions. For the sake of brevity and clarity, we won’t get into the „logic” used in the demo.

Handling Vue.js Transitions & Animations

Animations & transitions can bring your site to life and entice users to explore. Animations and transitions are an integral part of UX and UI design. They are, however, easy to get wrong. In complex situations like dealing with lists, they can be nearly impossible to reason about when relying on native JavaScript and CSS. Whenever I ask backend developers why they dislike front end so vehemently, their response is usually somewhere along the lines of „… animations„.

Even for those of us who are drawn to the field by an urge to create intricate micro-interactions and smooth page transitions, it’s not easy work. We often need to rely on CSS for performance reasons, even while working in a mostly JavaScript environment, and that break in the environment can be difficult to manage.

This is where frameworks like Vue.js step in, taking the guess-work and clumsy chains of setTimeout functions out of transitions.

The Difference Between Transitions and Animations

The terms transition and animation are often used interchangeably but are actually different things.

  • A transition is a change in the style properties on an element to be transitioned in a single step. They are often handled purely through CSS.
  • An animation is more complex. They are usually multi-step and sometimes run continuously. Animations will often call on JavaScript to pick up where CSS’ lack of logic drops off.

It can be confusing, as adding a class could be the trigger for a transition or an animation. Still, it is an important distinction when stepping into the world of Vue because both have very different approaches and toolboxes.

Here’s an example of transitions in use on Spektrum’s site:

Using Transitions

The simplest way to achieve transition effects on your page is through Vue’s <transition> component. It makes things so simple, it almost feels like cheating. Vue will detect if any CSS animations or transitions are being used and will automatically toggle classes on the transitioned content, allowing for a perfectly timed transition system and complete control.

First step is to identify our scope. We tell Vue to prepend the transition classes with modal, for example, by setting the component’s name attribute. Then to trigger a transition all you need to do is toggle the content’s visibility using the v-if or v-show attributes. Vue will add/remove the classes accordingly.

There are two „directions” for transitions: enter (for an element going from hidden to visible) and leave (for an element going from visble to hidden). Vue then provides 3 „hooks” that represent different timeframes in the transition:

  • .modal-enter-active / .modal-leave-active: These will be present throughout the entire transition and should be used to apply your CSS transition declaration. You can also declare styles that need to be applied from beginning to end.
  • .modal-enter / .modal-leave: Use these classes to define how your element looks before it starts the transition.
  • .modal-enter-to / .modal-leave-to: You’ve probably already guessed, these determine the styles you wish to transition towards, the „complete” state.

To visualize the whole process, take a look at this chart from Vue’s documentation:

How does this translate into code? Say we simply want to fade in and out, putting the pieces together would look like this:

<button class="modal__open" @click="modal = true">Help</button>

<transition name="modal">
  <section v-if="modal" class="modal">
    <button class="modal__close" @click="modal = false">&times;</button>
  </section>
</transition>
.modal-enter-active,
.modal-leave-active { transition: opacity 350ms }

.modal-enter,
.modal-leave-to { opacity: 0 }

.modal-leave,
.modal-enter-to { opacity: 1 }

This is likely the most basic implementation you will come across. Keep in mind that this transition system can also handle content changes. For example, you could react to a change in Vue’s dynamic <component>.

<transition name="slide">
  <component :is="selectedView" :key="selectedView"/>
</transition>
.slide-enter { transform: translateX(100%) }
.slide-enter-to { transform: translateX(0) }
.slide-enter-active { position: absolute }

.slide-leave { transform: translateX(0) }
.slide-leave-to { transform: translateX(-100%) }

.slide-enter-active,
.slide-leave-active { transition: all 750ms ease-in-out }

Whenever the selectedView changes, the old component will slide out to the left and the new one will enter from the right!

Here’s a demo that uses these concepts:

See the Pen VueJS transition & transition-group demo by Nicolas Udy (@udyux) on CodePen.

Transitions on Lists

Things get interesting when we start dealing with lists. Be it some bullet points or a grid of blog posts, Vue gives you the <transition-group> component.

It is worth noting that while the <transition> component doesn’t actually render an element, <transition-group> does. The default behaviour is to use a <span> but you can override this by setting the tag attribute on the <transition-group>.

The other gotcha is that all list items need to have a unique key attribute. Vue can then keep track of each item individually and optimize its performance. In our demo, we’re looping over the list of companies, each of which has a unique ID. So we can set up our list like so:

<transition-group name="company" tag="ul" class="content__list">
  <li class="company" v-for="company in list" :key="company.id">
    <!-- ... -->
  </li>
</transition-group>

The most impressive feature of transition-group is how Vue handles changes in the list’s order so seamlessly. For this, an additional transition class is available, .company-move (much like the active classes for entering and leaving), which will be applied to list items that are moving about but will remain visible.

In the demo, I broke it down a bit more to show how to leverage different states to get a cleaner end result. Here’s a simplified and uncluttered version of the styles:

/* base */
.company {
  backface-visibility: hidden;
  z-index: 1;
}

/* moving */
.company-move {
  transition: all 600ms ease-in-out 50ms;
}

/* appearing */
.company-enter-active {
  transition: all 300ms ease-out;
}

/* disappearing */
.company-leave-active {
  transition: all 200ms ease-in;
  position: absolute;
  z-index: 0;
}

/* appear at / disappear to */
.company-enter,
.company-leave-to {
  opacity: 0;
}

Using backface-visibility: hidden on an element, even in the absence of 3D transforms, will ensure silky 60fps transitions and avoid fuzzy text rendering during transformations by tricking the browser into leveraging hardware acceleration.

In the above snippet, I’ve set the base style to z-index: 1. This assures that elements staying on page will always appear above elements that are leaving. I also apply a absolute positioning to items that are leaving to remove them from the natural flow, triggering the move transition on the rest of the items.

That’s all we need! The result is, frankly, almost magic.

Using Animations

The possibilities and approaches for animation in Vue are virtually endless, so I’ve chosen one of my favourite techniques to showcase how you could animate your data.

We’re going to use GSAP’s TweenLite library to apply easing functions to our state’s changes and let Vue’s lightning fast reactivity reflect this on the DOM. Vue is just as comfortable working with inline SVG as it is with HTML.

We’ll be creating a line graph with 5 points, evenly spaced along the X-axis, whose Y-axis will represent a percentage. You can take a look here at the result.

See the Pen SVG path animation with VueJS & TweenLite by Nicolas Udy (@udyux) on CodePen.

Let’s get started with our component’s logic.

new Vue({
  el: '#app',
  // this is the data-set that will be animated
  data() {
    return {
      points: { a: -1, b: -1, c: -1, d: -1, e: -1 }
    }
  },

  // this computed property builds an array of coordinates that
  // can be used as is in our path
  computed: {
    path() {
      return Object.keys(this.points)
        // we need to filter the array to remove any
        // properties TweenLite has added
        .filter(key => ~'abcde'.indexOf(key))
        // calculate X coordinate for 5 points evenly spread
        // then reverse the data-point, a higher % should
        // move up but Y coordinates increase downwards
        .map((key, i) => [i * 100, 100 - this.points[key]])
    }
  },

  methods: {
    // our randomly generated destination values
    // could be replaced by an array.unshift process
    setPoint(key) {
      let duration = this.random(3, 5)
      let destination = this.random(0, 100)
      this.animatePoint({ key, duration, destination })
    },
    // start the tween on this given object key and call setPoint
    // once complete to start over again, passing back the key
    animatePoint({ key, duration, destination }) {
      TweenLite.to(this.points, duration, {
        [key]: destination,
        ease: Sine.easeInOut,
        onComplete: this.setPoint,
        onCompleteParams: [key]
      })
    },
    random(min, max) {
      return ((Math.random() * (max - min)) + min).toFixed(2)
    }
  },

  // finally, trigger the whole process when ready
  mounted() {
    Object.keys(this.points).forEach(key => {
      this.setPoint(key)
    })
  }
});

Now for the template.

<main id="app" class="chart">
  <figure class="chart__content">
    <svg xmlns="http://www.w3.org/2000/svg" viewBox="-20 -25 440 125">
      <path class="chart__path" :d="`M${path}`"
        fill="none" stroke="rgba(255, 255, 255, 0.3)"
        stroke-width="1.2" stroke-linecap="round" stroke-linejoin="round"/>

      <text v-for="([ x, y ]) in path" :x="x - 10" :y="y - 7.5"
        font-size="10" font-weight="200" fill="currentColor">
        {{ 100 - (y | 0) + '%' }}
      </text>
    </svg>
  </figure>
</main>

Notice how we bind our path computed property to the path element’s d attribute. We do something similar with the text nodes that output the current value for that point. When TweenLite updates the data, Vue reacts instantly and keeps the DOM in sync.

That’s really all there is to it! Of course, additional styles were applied to make things pretty, which at this point you might realize is more work then the animation itself!

Live demos (CodePen) & GitHub repo

Go ahead, browse the live demos or analyze/re-use the code in our open source repo!

Conclusion

I’ve always been a fan of animations and transitions on the web, but I’m also a stickler for performance. As a result, I’m always very cautious when it comes to relying on JavaScript. However, combining Vue’s blazing fast and low-cost reactivity with its ability to manage pure CSS transitions, you would really have to go overboard to have performance issues.

It’s impressive that such a powerful framework can offer such a simple yet manageable API. The animation demo, including the styling, was built in only 45 minutes. And if you discount the time it took to set up the mock data used in the list-transition, it’s achievable in under 2 hours. I don’t even want to imagine the migraine-inducing process of building similar setups without Vue, much less how much time it would take!

Now get out there and get creative! The use cases go far beyond what we have seen in this post: the only true limitation is your imagination. Don’t forget to check out the transitions and animations section in Vue.js’ documentation for more information and inspiration.


This post originally appeared on Snipcart’s blog. Got comments, questions? Add them below!


Creating Vue.js Transitions & Animations is a post from CSS-Tricks

The Art of Comments

Post pobrano z: The Art of Comments

I believe commenting code is important. Most of all, I believe commenting is misunderstood. I tweeted out the other day that „I hear conflicting opinions on whether or not you should write comments. But I get thank you’s from junior devs for writing them so I’ll continue.” The responses I received were varied, but what caught my eye was that for every person agreeing that commenting was necessary, they all had different reasons for believing this.

Commenting is a more nuanced thing than we give it credit for. There is no nomenclature for commenting (not that there should be) but lumping all comments together is an oversimplification. The example in this comic that was tweeted in response is true:

comic exploring code in real life with bad this is a bridge comment
From Abstrusegoose

This is where I think a lot of the misconceptions of comments lie. The book Clean Code by Robert C. Martin talks about this: that comments shouldn’t be necessary because code should be self-documenting. That if you feel a comment is necessary, you should rewrite it to be more legible. I both agree and disagree with this. In the process of writing a comment, you can often find things that could be written better, but it’s not an either/or. I might still be able to rewrite that code to be more self-documenting and also write a comment as well, for the following reason:

Code can describe how, but it cannot explain why.

This isn’t a new concept, but it’s a common theme I notice in helpful comments that I have come across. The ability to communicate something that the code cannot, or cannot concisely.

All of that said, there is just not one right way or one reason to write a comment. In order to better learn, let’s dig into some of the many beneficial types of comments that might all serve a different purpose, followed by patterns we might want to avoid.

Good comments

What is the Why

Many examples of good comments can be housed under this category. Code explains what you’d like the computer to take action on. You’ll hear people talk about declarative code because it describes the logic precisely but without describing all of the steps like a recipe. It lets the computer do the heavy lifting. We could also write our comments to be a bit more declarative

/*
  We had to write this function because the browser 
  interprets that everything is a box
*/

This doesn’t describe what the code below it will do. It doesn’t describe the actions it will take. But if you found a more elegant way of rewriting this function, you could feel confident in doing so because your code is likely the solution to the same problem in a different way.

Because of this, less maintenance is required (we’ll dig more into this further on). If you found a better way to write this, you probably wouldn’t need to rewrite the comment. You could also quickly understand whether you could rewrite another section of code to make this function unnecessary without spending a long time parsing all the steps to make the whole.

Clarifying something that is not legible by regular human beings

When you look at a long line of regex, can you immediately grok what’s going on? If you can, you’re in the minority, and even if you can at this moment, you might not be able to next year. What about a browser hack? Have you ever seen this in your code?

.selector { [;property: value;]; }

what about

var isFF = /a/[-1]=='a';

The first one targets Chrome ≤ 28, Safari ≤ 7, Opera ≥ 14, the second one is Firefox versions 2-3. I have written code that needs something like this. In order to avoid another maintainer or a future me assuming I took some Salvia before heading to work that day, it’s great to tell people what the heck that’s for. Especially in preparation for a time when we don’t have to support that browser anymore, or the browser bug is fixed and we can remove it.

Something that is clear and legible to you is not necessarily clear to others

Who’s smart? We are! Who writes clean code? We do! We don’t have to comment, look how clear it is. The problem with this way of thinking is that we all have deeper knowledge in different areas. On small teams where people’s skillsets and expertise are more of a circle than a venn diagram, this is less of an issue than big groups that change teams or get junior devs or interns frequently. But I’d probably still make room for those newcomers or for future you. On bigger teams where there are junior engineers or even just engineers from all types of background, people might not outrightly tell you they need you to comment, but many of these people will also express gratitude when you do.

Comments like chapters of a book

If this very article was written as one big hunk rather than broken up into sections with whitespace and smaller headings, it would be harder to skim through. Maybe not all of what I’m saying applies to you. Commenting sections or pieces allows people to skip to a part most relevant to them. But alas! You say. We have functional programming, imports, and modules for this now.

It’s true! We break things down into smaller bits so that they are more manageable, and thank goodness for that. But even in smaller sections of code, you’ll necessarily come to a piece that has to be a bit longer. Being able quickly grasp what is relevant or a label for an area that’s a bit different can speed up productivity.

A guide to keep the logic straight while writing the code

This one is an interesting one! These are not the kind of comments you keep, and thus could also be found in the „bad patterns” section. Many times when I’m working on a bigger project with a lot of moving parts, breaking things up into the actions I’m going to take is extremely helpful. This could look like

// get the request from the server and give an error if it failed
// do x thing with that request
// format the data like so

Then I can easily focus on one thing at a time. But when left in your code as is, these comments can be screwy to read later. They’re so useful while you’re writing it but once you’re finished can merely be a duplication of what the code does, forcing the reader to read the same thing twice in two different ways. It doesn’t make them any less valuable to write, though.

My perfect-world suggestion would be to use these comments at the time of writing and then revisit them after. As you delete them, you could ask „does this do this in the most elegant and legible way possible?” „Is there another comment I might replace this with that will explain why this is necessary?” „What would I think is the most useful thing to express to future me or other from another mother?”

This is OK to refactor

Have you ever had a really aggressive product deadline? Perhaps you implemented a feature that you yourself disagreed with, or they told you it was „temporary” and „just an AB test so it doesn’t matter”. *Cue horror music* … and then it lived on… forever…

As embarrassing as it might be, writing comments like

// this isn't my best work, we had to get it in by the deadline

is rather helpful. As a maintainer, when I run across comments like this, I’ll save buckets of time trying to figure out what the heck is wrong with this person and envisioning ways I could sabotage their morning commute. I’ll immediately stop trying to figure out what parts of this code I should preserve and instead focus on what can be refactored. The only warning I’ll give is to try not to make this type of coding your fallback (we’ll discuss this in detail further on).

Commenting as a teaching tool

Are you a PHP shop that just was given a client that’s all Ruby? Maybe it’s totally standard Ruby but your team is in slightly over their heads. Are you writing a tutorial for someone? These are the limited examples for when writing out the how can be helpful. The person is literally learning on the spot and might not be able to just infer what it’s doing because they’ve never seen it before in their lives. Comment that sh*t. Learning is humbling enough without them having to ask you aloud what they could more easily learn on their own.

I StackOverflow’d the bejeezus outta this

Did you just copy paste a whole block of code from Stack Overflow and modify it to fit your needs? This isn’t a great practice but we’ve all been there. Something I’ve done that’s saved me in the past is to put the link to the post where I found it. But! Then we won’t get credit for that code! You might say. You’re optimizing for the wrong thing would be my answer.

Inevitably people have different coding styles and the author of the solution solved a problem in a different way than you would if you knew the area deeper. Why does this matter? Because later, you might be smarter. You might level up in this area and then you’ll spend less time scratching your head at why you wrote it that way, or learn from the other person’s approach. Plus, you can always look back at the post, and see if any new replies came in that shed more light on the subject. There might even be another, better answer later.

Bad Comments

Writing comments gets a bad wrap sometimes, and that’s because bad comments do indeed exist. Let’s talk about some things to avoid while writing them.

They just say what it’s already doing

John Papa made the accurate joke that this:

// if foo equals bar ...
If (foo === bar) { 

} // end if

is a big pain. Why? Because you’re actually reading everything twice in two different ways. It gives no more information, in fact, it makes you have to process things in two different formats, which is mental overhead rather than helpful. We’ve all written comments like this. Perhaps because we didn’t understand it well enough ourselves or we were overly worried about reading it later. For whatever the reason, it’s always good to take a step back and try to look at the code and comment from the perspective of someone reading it rather than you as the author, if you can.

It wasn’t maintained

Bad documentation can be worse than no documentation. There’s nothing more frustrating than coming across a block of code where the comment says something completely different than what’s expressed below. Worse than time-wasting, it’s misleading.

One solution to this is making sure that whatever code you are updating, you’re maintaining the comments as well. And certainly having less and only more meaningful comments makes this upkeep less arduous. But commenting and maintaining comments are all part of an engineer’s job. The comment is in your code, it is your job to work on it, even if it means deleting it.

If your comments are of good quality to begin with, and express why and not the how, you may find that this problem takes care of itself. For instance, if I write

// we need to FLIP this animation to be more performant in every browser

and refactor this code later to go from using getBoundingClientRect() to getBBox(), the comment still applies. The function exists for the same reason, but the details of how are what has changed.

You could have used a better name

I’ve definitely seen people write code (or done this myself) where the variable or functions names are one letter, and then comment what the thing is. This is a waste. We all hate typing, but if you are using a variable or function name repeatedly, I don’t want to scan up the whole document where you explained what the name itself could do. I get it, naming is hard. But some comments take the place of something that could easily be written more precisely.

The comments are an excuse for not writing the code better to begin with

This is the crux of the issue for a lot of people. If you are writing code that is haphazard, and leaning back on your comments to clarify, this means the comments are holding back your programming. This is a horse-behind-the-cart kind of scenario. Unfortunately, even as the author it’s not so easy to determine which is which.

We lie to ourselves in myriad ways. We might spend the time writing a comment that could be better spent making the code cleaner to begin with. We might also tell ourselves we don’t need to comment our code because our code is well-written, even if other people might not agree.

There are lazy crutches in both directions. Just do your best. Try not to rely on just one correct way and instead write your code, and then read it. Try to envision you are both the author and maintainer, or how that code might look to a younger you. What information would you need to be as productive as possible?


People tend to, lately, get on one side or the other of „whether you should write comments”, but I would argue that that conversation is not nuanced enough. Hopefully opening the floor to a deeper conversation about how to write meaningful comments bridges the gap.

Even so, it can be a lot to parse. Haha get it? Anyways, I’ll leave you with some (better) humor. A while back there was a Stack Overflow post about the best comments people have written or seen. You can definitely waste some time in here. Pretty funny stuff.


The Art of Comments is a post from CSS-Tricks

Getting Nowhere on Job Titles

Post pobrano z: Getting Nowhere on Job Titles

Last week on ShopTalk, Dave and I spoke with Mandy Michael and Lara Schenck. Mandy had just written the intentionally provocative „Is there any value in people who cannot write JavaScript?” which guided our conversation. Lara is deeply interested in this subject as well, as someone who is a job seeking web worker, but places herself on the spectrum as a non-unicorn.

Part of that discussion was about job titles. If there was a ubiquitously accepted and used job title that meant you were specifically skilled at HTML and CSS, and there was a market for that job title, there probably wouldn’t be any problem at all. There isn’t though. „Web developer” is too vague. „Front-end developer” maybe used to mean that, but has been largely co-opted by JavaScript.

In fact, you might say that none of us has an exactly perfect job title and the industry at large has trouble agreeing on a set of job titles.

Lara created a repo with the intent to think all this out and discuss it.

If there is already a spectrum between design and backend development, and front-end development is that place in between, perhaps front-end development, if we zoon in, is a spectrum as well:

I like the idea of spectrums, but I also agree with a comment by Sarah Drasner where she mentioned that this makes it seem like you can’t be good at both. If you’re a dot right in the middle in this specrum, you are, for example, not as good at JavaScript as someone on the right.

This could probably be fixed with some different dataviz (perhaps the size of the dot), or, heaven forbid, skill-level bars.

More importantly, if you’re really interested in the discussion around all this, Lara has used the issues area to open that up.

Last year, Geoff also started thinking about all our web jobs as a spectrum. We can break up our jobs into parts and map them onto those parts in differnet ways:

See the Pen Web Terminology Matrix by Geoff Graham (@geoffgraham) on CodePen.

See the Pen Web Terminology Venn Diagram by Geoff Graham (@geoffgraham) on CodePen.

That can certainly help us understand our world a little bit, but doesn’t quite help with the job titles thing. It’s unlikely we’ll get people to write job descriptions that include a data visualization of what they are looking for.

Jeff Pelletier took a crack at job titles and narrowed it down to three:

Front-end Implementation (responsive web design, modular/scalable CSS, UI frameworks, living style guides, progressive enhancement & accessibility, animation and front-end performance).

Application Development (JavaScript frameworks, JavaScript preprocessors, code quality, process automation, testing).

Front-end Operations (build tools, deployment, speed: (app, tests, builds, deploys), monitoring errors/logs, and stability).

Although those don’t quite feel like titles to me and converting them into something like „Front-end implementation developer” doesn’t seem like something that will catch on.

Cody Lindley’s Front-End Developer Handbook has a section on job titles. I won’t quote it in full, but they are:

  • Front-End Developer
  • Front-End Engineer (aka JavaScript Developer or Full-stack JavaScript Developer)
  • CSS/HTML Developer
  • Front-End Web Designer
  • Web/Front-End User Interface (aka UI) Developer/Engineer
  • Mobile/Tablet Front-End Developer
  • Front-End SEO Expert
  • Front-End Accessibility Expert
  • Front-End Dev. Ops
  • Front-End Testing/QA

Note the contentious „full stack” title, in which Brad Frost says:

In my experience, “full-stack developers” always translates to “programmers who can do frontend code because they have to and it’s ‘easy’.” It’s never the other way around.

Still, these largely feel pretty good to me. And yet weirdly, almost like there is both too many and too few. As in, while there is good coverage here, but if you are going to cover specialties, you might as well add in performance, copywriting, analytics, and more as well. The more you add, the further away we are to locking things down. Not to mention the harder it becomes when people crossover these disciplines, like they almost always do.

Oh well.


Getting Nowhere on Job Titles is a post from CSS-Tricks

I haven’t experienced imposter syndrome, and maybe you haven’t either

Post pobrano z: I haven’t experienced imposter syndrome, and maybe you haven’t either

In recent years it’s become trendy to discuss how we all apparently suffer from this imposter syndrome – an inability to internalize one’s accomplishments and a persistent fear of being exposed as a “fraud”.

I take two issues with this:

  • it minimizes the impact that this experience has on people that really do suffer from it.
  • we’re labelling what should be considered positive personality traits – humility, an acceptance that we can’t be right all the time, a desire to know more, as a “syndrome” that we need to “deal with”, “get over” or “get past”.

It’s not an officially recognized syndrome (yet?), but you can have medical diagnoses that are like imposter syndrome. A general feeling that you’re faking it or don’t know as much as you should isn’t it.

Direct Link to ArticlePermalink


I haven’t experienced imposter syndrome, and maybe you haven’t either is a post from CSS-Tricks

Prettier + Stylelint: Writing Very Clean CSS (Or, Keeping Clean Code is a Two-Tool Game)

Post pobrano z: Prettier + Stylelint: Writing Very Clean CSS (Or, Keeping Clean Code is a Two-Tool Game)

It sure is nice having a whole codebase that is perfectly compliant to a set of code style guidelines. All the files use the same indentation, the same quote style, the same spacing and line-break rules, heck, tiny things like the way zero’s in values are handled and how keyframes are named.

It seems like a tall order, but these days, it’s easier than ever. It seems to me it’s become a two-tool game:

  1. A tool to automatically fix easy-to-fix problems
  2. A tool to warn about harder-to-fix problems

Half the battle: Prettier

Otherwise known as „fix things for me, please”.

Best I can tell, Prettier is a fairly new project, only busting onto the scene in January 2017. Now in the last quarter of 2017, it seems like everybody and their sister is using it. They call it an Opinionated Code Formatter.

The big idea: upon save of a document, all kinds of code formatting happens automatically. It’s a glorious thing to behold. Indentation and spacing is corrected. Quotes are consistent-ified. Semi colons are added.

Run Prettier over your codebase once and gone are the muddy commits full of code formatting cruft. (You might consider making a temporary git user so one user doesn’t look like they’ve commited a bazillion lines of code more than another, if you care about that.) That alone is a damn nice benefit. It makes looking through commits a heck of a lot easier and saves a bunch of grunt work.

As this post suggest, Prettier is only half the battle though. You’ll notice that Prettier only supports a handful of options. In fact, I’m pretty sure when it launched it didn’t have any configuration at all. Opinionated indeed.

What it does support are things that are easy to fix, requiring zero human brainpower. Use double quotes accidentally (uggkch muscle memory) when your style guide is single quotes? Boom – changed on save.

There are other potential problems that aren’t as easy to fix. For example, you’ve used an invalid #HEX code. You probably wouldn’t want a computer guessing what you meant there. That’s better to just be visually marked as an error for you to fix.

That’s where this next part comes in.

The other half of the battle: Stylelint

Otherwise known as „let me know about problem, so I can fix them”.

Stylelint is exactly that. In fact, in that GIF above show Prettier do it’s thing, you saw some red dots and red outlines in my Sublime Text editor. That wasn’t Prettier showing me what it was going to fix (Prettier displays no errors, it just fixes what it can). That was Stylelint running it’s linting and showing me those errors.

Whereas Prettier supports 10ish rules, Stylelint supports 150ish. There is a standard configuration, but you can also get as fine-grained as you want there and configure how you please. David Clark wrote about it here on CSS-Tricks last year.

With these warnings so clearly visible, you can fix them up by hand quickly. It becomes rather second nature.

Getting it all going

These tools work in a wide variety of code editors.

These are the Prettier editor integrations. Between all these, that probably covers 96% webdevnerds.

It’s very easy to think „I’ll just install this into my code editor, and it will work!” That gets me every time. Getting these tools to work is again a two-part game.

  1. Install code editor plugin.
  2. Do the npm / yarn installation stuff. These are node-based tools. It doesn’t mean your project needs to have anything to do with node in production, this is a local development dependency.

These are intentionally separated things. The meat of these tools is the code that parses your code and figures out the problems it’s going to fix. That happens through APIs that other tools can call. That means these tools don’t have to be rewritten and ported to work in a new environment, instead, that new environment calls the same APIs everyone else does and does whatever it needs to do with the results.

Above is a barebones project in Sublime Text with both Prettier and Stylelint installed. Note the `package.json` shows we have our tools installed and I’m listing my „packages” so you can see I have the Sublime Text Plugin jsPrettier installed. You can also see the dotfiles there that configure the rules for both tools.

Don’t let the „js” part mislead you. You could use this setup on the CSS of your WordPress site. It really doesn’t matter what your project is.

Getting more exotic

There is certainly leveling up that can happen here. For example:

  • You might consider configuring Stylelint to ignore problems that Prettier fixes. They are going to be fixed anyway, so why bother looking at the errors.
  • You might consider updating your deployment process to stop if Stylelint problems are found. Sometimes Stylelint is showing you an error that will literally cause a problem, so it really shouldn’t go to production.
  • We mostly talked about CSS here, but JavaScript is arguably even more important to lint (and Prettier supports as well). ES Lint is probably the way to go here. There are also tools like Rubocop for Ruby, and I’m sure linters for about every language imaginable.

Related


Prettier + Stylelint: Writing Very Clean CSS (Or, Keeping Clean Code is a Two-Tool Game) is a post from CSS-Tricks

Building a Progress Ring, Quickly

Post pobrano z: Building a Progress Ring, Quickly

On some particularly heavy sites, the user needs to see a visual cue temporarily to indicate that resources and assets are still loading before they taking in a finished site. There are different kinds of approaches to solving for this kind of UX, from spinners to skeleton screens.

If we are using an out-of-the-box solution that provides us the current progress, like preloader package by Jam3 does, building a loading indicator becomes easier.

For this, we will make a ring/circle, style it, animate given a progress, and then wrap it in a component for development use.

Step 1: Let’s make an SVG ring

From the many ways available to draw a circle using just HTML and CSS, I’m choosing SVG since it’s possible to configure and style through attributes while preserving its resolution in all screens.

<svg
  class="progress-ring"
  height="120"
  width="120"
>
  <circle
    class="progress-ring__circle"
    stroke-width="1"
    fill="transparent"
    r="58"
    cx="60"
    cy="60"
  />
</svg>

Inside an <svg> element we place a <circle> tag, where we declare the radius of the ring with the r attribute, its position from the center in the SVG viewBox with cx and cy and the width of the circle stroke.

You might have noticed the radius is 58 and not 60 which would seem correct. We need to subtract the stroke or the circle will overflow the SVG wrapper.

radius = (width / 2) - (strokeWidth * 2)

These means that if we increase the stroke to 4, then the radius should be 52.

52 = (120 / 2) - (4 * 2)

So it looks like a ring we need to set its fill to transparent and choose a stroke color for the circle.

See the Pen SVG ring by Jeremias Menichelli (@jeremenichelli) on CodePen.

Step 2: Adding the stroke

The next step is to animate the length of the outer line of our ring to simulate visual progress.

We are going to use two CSS properties that you might not have heard of before since they are exclusive to SVG elements, stroke-dasharray and stroke-dashoffset.

stroke-dasharray

This property is like border-style: dashed but it lets you define the width of the dashes and the gap between them.

.progress-ring__circle {
  stroke-dasharray: 10 20;
}

With those values, our ring will have 10px dashes separated by 20px.

See the Pen Dashed SVG ring by Jeremias Menichelli (@jeremenichelli) on CodePen.

stroke-dashoffset

The second one allows you to move the starting point of this dash-gap sequence along the path of the SVG element.

Now, imagine if we passed the circle’s circumference to both stroke-dasharray values. Our shape would have one long dash occupying the whole length and a gap of the same length which wouldn’t be visible.

This will cause no change initially, but if we also set to the stroke-dashoffset the same length, then the long dash will move all the way and reveal the gap.

Decreasing stroke-dasharray would start to reveal our shape.

A few years ago, Jake Archibald explained this technique in this article, which also has a live example that will help you understand it better. You should go read his tutorial.

The circumference

What we need now is that length which can be calculated with the radius and this simple trigonometric formula.

circumference = radius * 2 * PI

Since we know 52 is the radius of our ring:

326.7256 ~= 52 * 2 * PI

We could also get this value by JavaScript if we want:

const circle = document.querySelector('.progress-ring__circle');
const radius = circle.r.baseVal.value;
const circumference = radius * 2 * Math.PI;

This way we can later assign styles to our circle element.

circle.style.strokeDasharray = `${circumference} ${circumference}`;
circle.style.strokeDashoffset = circumference;

Step 3: Progress to offset

With this little trick, we know that assigning the circumference value to stroke-dashoffset will reflect the status of zero progress and the 0 value will indicate progress is complete.

Therefore, as the progress grows we need to reduce the offset like this:

function setProgress(percent) {
  const offset = circumference - percent / 100 * circumference;
  circle.style.strokeDashoffset = offset;
}

By transitioning the property, we will get the animation feel:

.progress-ring__circle {
  transition: stroke-dashoffset 0.35s;
}

One particular thing about stroke-dashoffset: its starting point is vertically centered and horizontally titled to the right. It’s necessary to negatively rotate the circle to get the desired effect.

.progress-ring__circle {
  transition: stroke-dashoffset 0.35s;
  transform: rotate(-90deg);
  transform-origin: 50% 50%,
}

Putting all of this together will give us something like this.

See the Pen vegymB by Jeremias Menichelli (@jeremenichelli) on CodePen.

A numeric input was added in this example to help you test the animation.

For this to be easily coupled inside your application it would be best to encapsulate the solution in a component.

As a web component

Now that we have the logic, the styles, and the HTML for our loading ring we can port it easily to any technology or framework.

First, let’s use web components.

class ProgressRing extends HTMLElement {...}

window.customElements.define('progress-ring', ProgressRing);

This is the standard declaration of a custom element, extending the native HTMLElement class, which can be configured by attributes.

<progress-ring stroke="4" radius="60" progress="0"></progress-ring>

Inside the constructor of the element, we will create a shadow root to encapsulate the styles and its template.

constructor() {
  super();

  // get config from attributes
  const stroke = this.getAttribute('stroke');
  const radius = this.getAttribute('radius');
  const normalizedRadius = radius - stroke * 2;
  this._circumference = normalizedRadius * 2 * Math.PI;

  // create shadow dom root
  this._root = this.attachShadow({mode: 'open'});
  this._root.innerHTML = `
    <svg
      height="${radius * 2}"
      width="${radius * 2}"
     >
       <circle
         stroke="white"
         stroke-dasharray="${this._circumference} ${this._circumference}"
         style="stroke-dashoffset:${this._circumference}"
         stroke-width="${stroke}"
         fill="transparent"
         r="${normalizedRadius}"
         cx="${radius}"
         cy="${radius}"
      />
    </svg>

    <style>
      circle {
        transition: stroke-dashoffset 0.35s;
        transform: rotate(-90deg);
        transform-origin: 50% 50%;
      }
    </style>
  `;
}

You may have noticed that we have not hardcoded the values into our SVG, instead we are getting them from the attributes passed to the element.

Also, we are calculating the circumference of the ring and setting stroke-dasharray and stroke-dashoffset ahead of time.

The next thing is to observe the progress attribute and modify the circle styles.

setProgress(percent) {
  const offset = this._circumference - (percent / 100 * this._circumference);
  const circle = this._root.querySelector('circle');
  circle.style.strokeDashoffset = offset; 
}

static get observedAttributes() {
  return [ 'progress' ];
}

attributeChangedCallback(name, oldValue, newValue) {
  if (name === 'progress') {
    this.setProgress(newValue);
  }
}

Here setProgress becomes a class method that will be called when the progress attribute is changed.

The observedAttributes are defined by a static getter which will trigger attributeChangeCallback when, in this case, progress is modified.

See the Pen ProgressRing web component by Jeremias Menichelli (@jeremenichelli) on CodePen.

This Pen only works in Chrome at the time of this writing. An interval was added to simulate the progress change.

As a Vue component

Web components are great. That said, some of the available libraries and frameworks, like Vue.js, can do quite a bit of the heavy-lifting.

To start, we need to define the view component.

const ProgressRing = Vue.component('progress-ring', {});

Writing a single file component is also possible and probably cleaner but we are adopting the factory syntax to match the final code demo.

We will define the attributes as props and the calculations as data.

const ProgressRing = Vue.component('progress-ring', {
  props: {
    radius: Number,
    progress: Number,
    stroke: Number
  },
  data() {
    const normalizedRadius = this.radius - this.stroke * 2;
    const circumference = normalizedRadius * 2 * Math.PI;

    return {
      normalizedRadius,
      circumference
    };
  }
});

Since computed properties are supported out-of-the-box in Vue we can use it to calculate the value of stroke-dashoffset.

computed: {
  strokeDashoffset() {
    return this._circumference - percent / 100 * this._circumference;
  }
}

Next, we add our SVG as a template. Notice that the easy part here is that Vue provides us with bindings, bringing JavaScript expressions inside attributes and styles.

template: `
  <svg
    :height="radius * 2"
    :width="radius * 2"
  >
    <circle
      stroke="white"
      fill="transparent"
      :stroke-dasharray="circumference + ' ' + circumference"
      :style="{ strokeDashoffset }"
      :stroke-width="stroke"
      :r="normalizedRadius"
      :cx="radius"
      :cy="radius"
    />
  </svg>
`

When we update the progress prop of the element in our app, Vue takes care of computing the changes and update the element styles.

See the Pen Vue ProgressRing component by Jeremias Menichelli (@jeremenichelli) on CodePen.

Note: An interval was added to simulate the progress change. We do that in the next example as well.

As a React component

In a similar way to Vue.js, React helps us handle all the configuration and computed values thanks to props and JSX notation.

First, we obtain some data from props passed down.

class ProgressRing extends React.Component {
  constructor(props) {
    super(props);

    const { radius, stroke } = this.props;

    this.circumference = radius * 2 * Math.PI;
    this.normalizedRadius = radius - stroke * 2;
  }
}

Our template is the return value of the component’s render function where we use the progress prop to calculate the stroke-dashoffset value.

render() {
  const { radius, stroke, progress } = this.props;
  const strokeDashoffset = this.circumference - progress / 100 * this.circumference;

  return (
    <svg
      height={radius * 2}
      width={radius * 2}
      >
      <circle
        stroke="white"
        fill="transparent"
        strokeWidth={ stroke }
        strokeDasharray={ this.circumference + ' ' + this.circumference }
        style={ { strokeDashoffset } }
        stroke-width={ stroke }
        r={ this.normalizedRadius }
        cx={ radius }
        cy={ radius }
        />
    </svg>
  );
}

A change in the progress prop will trigger a new render cycle recalculating the strokeDashoffset variable.

See the Pen React ProgressRing component by Jeremias Menichelli (@jeremenichelli) on CodePen.

Wrap up

The recipe for this solution is based on SVG shapes and styles, CSS transitions and a little of JavaScript to compute special attributes to simulate the drawing circumference.

Once we separate this little piece, we can port it to any modern library or framework and include it in our app, in this article we explored web components, Vue, and React.

Further reading


Building a Progress Ring, Quickly is a post from CSS-Tricks