Online Resource

Online Resource

Online Resource

Online Resource

Online Resource

Engineer-in-Chief requested for revision of costs

IEEE Computer Society

Online Resource

Benard, Bonnie, author

Stuart Robson rolls up his sleeves and begins to piece together the jigsaw puzzle that is design tokens and component based design. Starting with the corners, and working around the edges, Stu helps us to piece together a full picture of a modern design system.

If you stare at your twitter feed long enough, it can look like everyone is talking about Design Systems. In some cases you could be persuaded to think how shallow the term can go.

“Isn’t this what we called Style Guides?”, “Here’s my React Design System”, “I’ve just updated the Design System in Sketch”

To me, they are some and all of these things. Over the last 4 years of consulting with two clients on their Design System, my own view has changed a little.

If you dig a little deeper into Design Systems twitter you will probably see the term “Design Tokens” pop up at least once a day somewhere. Design Tokens came out of work that was being done at Salesforce with Jina and others who pioneered the creation of Design Tokens as we know them today – creating the first command line tool in Theo that had started the adoption of Design Tokens to the wider Design Systems Community.

A cool term but, what are they?

If you look at your client work, your companies site, the project you’re working on you should notice some parts of the page have a degree of consistency: the background colour of your form buttons is the same colour as your link text, or your text has the same margin, or your card elements have the same spacing as your media object.

These are design decisions, and they should be littered across the overall design of your project. These decisions might start off in a Sketch file and make their way into code from detailed investigation of a Sketch file, or you may find that the design evolves from your design application once it gets into code.

These design decisions can change, and to keep them synchronised across design and development in applications, as well as a larger documentation site in your Design System, is going to take some effort.

This is where Design Tokens come in, and I find the best way to succinctly reiterate what they are is via the two following quotes…

“Design Tokens are an abstraction for everything impacting the visual design of an app/platform.”
– Sönke Rohde

…and

“We use them in place of hard-coded values in order to maintain a scale-able and consistent visual system.”
– Jina

There are several global design decisions that we can abstract to create a top level design token – Sizing, Font Families, Font Styles, Font Weights, Font Sizes, Line Heights, Border Styles, Border Colours, Border Radius, Horizontal Rule Colours, Background Colours, Gradients, Background Gradients, Box Shadows, Filters, Text Colours, Text Shadow, Time, Media Queries, Z Index, Icons – these can all be abstracted as required.

So, spicy Sass variables?

We can look at Design Tokens as an abstraction of CSS, sort of like Sass variables, but spicier. Looking at them like this we can see that they are (in either .yaml or .json) a group of related key value pairs with more information that can be added as needed.

The great thing with abstracting design decisions outside of your CSS pre-processor is that you’re not tying those decisions to one platform or codebase.

As a crude example, we can see here that we are defining a name and a value that could then become our color, background-color, or border-color, and more.

# Colours
# -------
- name: color-red
  value: #FF0000
- name: color-green
  value: #00FF00
- name: color-blue
  value: #0000FF
- name: color-white
  value: #FFFFFF
- name: color-black
  value: #000000

These can then generate our Sass variables (as an example) for our projects.

$color-red: #FF0000 !default;
$color-green: #00FF00 !default;
$color-blue: #0000FF !default;
$color-white: #FFFFFF !default;
$color-black: #000000 !default;

Why are they so good

Ok, so we now know what Design Tokens are, but why do we need them? What makes them better than our existing solutions (css pre-processors) for defining these design decisions?

I think there are 5 really good reasons why we all should start abstracting these design decisions away from the CSS that they may live in. Some of these reasons are similar to reasons some developers use a pre-processor like Sass, but with added bonuses.

Consistency

Much like using a CSS pre-processor or using CSS custom properties, being able to define a background colour, breakpoint, or font-size in more than one place using the same key ensures that we are using the Sass values across the entire product suite we are developing for.

Using our Design Tokens in their generated formats, we can be sure to not end up with 261 shades of blue.

Maintainability

By using a pre-processor like Sass, or using native CSS custom properties, we can already have maintainable code in our projects. Design Tokens also do this at the abstracted level as well.

Scalability

“Design Tokens enable us to scale our Design across all the permutations.”
– Jina

At this point, we’re only talking about abstracting the design decisions for use in CSS. Having Design Tokens allows design to scale for multiple brands or multiple projects as needed.

The main benefit of Design Tokens in regards to scalability is the option that it gives us to offer the Design Tokens for other platforms and frameworks as needed. With some of the tools available, we can even have these Tokens shared between applications used by designers and developers.

Your marketing site and your iOS application can soon share the same design decisions codified, and you can move towards creating an Android app or web application as required.

Documentation

If we abstract the design decisions from one platform specific programming language it would be no good if it wasn’t made to be easily accessible.

The tools and applications available that are mentioned later in this article can now create their own documentation, or allow you to create your own. This documentation is either hosted within a web-based application or can be self-hosted with the rest of your Design Systems documentation.

Most of the command line tools go further and allow you do add more details that you wish to convey in the documentation, making it as unique as it is required for your project.

Empowerment

When you abstract your design decisions to Design Tokens, you can help empower other people on the project. With the tools available today, and the tools that are just around the corner, we can have these design decisions determined by anyone on the team.

No-one necessarily needs to understand how to set up the codebase to update the colour slightly. Some of the tools I mention later on allow you to update the Design Tokens in the browser.

Design Systems are already “bridging the gap” between design and development. With Design Tokens and the tooling available, we can create better team relationships by closing that gap instead.

Some of the benefits of creating and using Design Tokens are the same as using a pre-processor when it comes to authoring CSS. I feel the added bonuses of being able to empower other team members and document how you use them, as well as the fundamental reasoning in that they can be platform agnostic, are all great “selling points” to why you need to start using Design Tokens today.

Tools

There are several tools available to help you and your team to create the required files from your abstracted Design Tokens:

Command Line Tools

There are several tools available on the command line that can be used as part of, or separate to, your development process.

These tools allow you to define the Design Tokens in a .json or .yaml file format which can then be compiled into the formats you require.

Some have built in functions to turn the inputted values to something different when compiled – for example, turning hexadecimal code that is a Design Token into a RGB value in your .css file. These command line tools, written in JavaScript, allow you to create your own ways in which you want things transformed.

My current client has certain design decisions for typography in long form content (font size, weight, line height and margins) which need to be together to make sense. Being able to write JavaScript to compile these design decisions into an independent Sass map for each element allows us to develop with assurance that the long form content has the correct styling.

WYSIWYG Tools

WYSIWYG (What You See Is What You Get Tools) have been around for almost as long as we have been able to make websites. I can just about remember using Dreamweaver 2, before I knew what a <table> was.

When browsers started to employ vendor prefixes to new CSS for their browsers, a flurry of online WYSIWYG tools came with it built in. They’re still there, but the industry has moved on.

Design Tokens also have a few WYSIWYG tools available. From simpler online tools that allow you to generate the correct Sass variables needed for your design decisions to tools that store your decisions online and allow you to export them as npm packages.

These types of tools for creating Design Tokens can help empower the team as a whole, with some automatically creating documentation which can easily be shared with a url.

Retrofitting Tools

If you are starting from scratch on a new re-design or on a new project that requires a Design System and Tokens, the many of the tools mentioned above will help you along your way. But what if you’re in the middle of a project, or you have to maintain something and want to start to create the parts required for a Design System?

Luckily there are several tools and techniques to help you make a start.

One new tool that might be useful is Superposition. Currently in private beta with the public release set for Q1 of 2020 Superposition helps you “Extract design tokens from websites and use them in code and in your design tool.”

Entering your domain gives you a nice visual documentation of your sites styles as Design Tokens. These can then be exported as Sass Variables, CSS Custom Properties, JavaScript with the team working on exports to iOS and Android.

If you have an existing site, this could be a good first step before moving to one of the other tools mentioned above.

You could also make use of CSSStats or Project Wallace’s Analysis page that I mentioned earlier. This would give you an indication of what Design Tokens you would need to implement.

Component Based Design

So, we’ve created our Design Tokens by abstracting the design decisions of brand colours, typography, spacing and more. Is that as far as we can go?

Levels of Design Decisions

Once we have created our first set of Design Tokens for our project, we can take it that little bit deeper. With command line tools and some of the applications available, you can link these more global decisions to a more deeper level.

For example, you can take your chosen colours and make further design decisions on the themes of your project, such as what the primary, secondary, or tertiary colours are or what your general component and layout spacing will be.

With this, we can go one step further. We could also define some component specific design decisions that can then be compiled for the developer to use. Invest in time to check over the designs with a fine toothcomb and make sure you are using the correct Sass variable or CSS custom property for that component.

If you are going more than one or two levels of design decision making, you can compile each set of these Design Tokens to your Sass variables which can then be used as required. So you can provide: global, theme, component level Sass variables which can be used in the project. Or you could choose to only compile what you need for the components you are creating.

Variables, Maps, Custom Properties

Some of the tools available for creating and maintaining your Design Tokens allow you to compile to certain programming languages.

With my current client work, I am making use of Sass variables, Sass maps, and CSS custom properties. The Design Tokens are compiled into one or more of these options depending on how they will be used.

Colours are compiled as global Sass variables, inside of a couple of Sass maps and CSS custom properties. Our macro layout breakpoints are defined as a single Sass map.

If we know we are creating a component that has the ability to be themed, we can make use of CSS custom properties to reduce the amount of CSS we need to override, and also allow us to inline things that can be changed via a CMS as required. Which leaves us using Sass variables for parts of a component that won’t change. We are using Sass maps differently still. As mentioned, we generate a Sass map containing the design decisions for each element of text, and we can use long form text. This Sass map is then compiled into separate CSS declarations as needed using Sass mixins.

I find the beauty of being able to make use of the global, themed, and component level design decisions by compiling them into various formats (that essentially become CSS) and that gives us more power in authoring components.

Creating Consistent Utility Classes

As you have created your more global generic design decisions, you can create your own small set of utility classes.

Using a pre-processor like Sass you can define a set of mixins and functions that can take your Design Tokens that have been compiled down into variables and maps and generate separate classes for each design decision.

By making tokens available to all digital teams, we can enable them to create custom experiences that are aligned to current visual standards when a component does not (or will not) exist in the design system. Maya King

In creating utility classes with Design Tokens (using something like Sass) you have consistency with the overall Design System for times when you or a team need to create a one-off component for a project.

These exceptions tend to be something that won’t make it as part of the overall Design System, but it still needs that look and feel.

Having classes available that we can guarantee use the generic, global design decisions from the Design Tokens means these one-off components should be well on their way to have the overall look and feel of the project, and will get any updates with little to no additional overhead.

Wrapping Up

I think we are starting to see the potential of using Design Tokens as Design Systems become even more popular. I think that, from this overview, we can see how they can help us close the gap that still exists in places between the designers and developers on the team. They can help empower people who do not code to make changes that can be automatically updating live work.

I think you can start now. You may not have or need what you could term “a fully-fledged Design System” but this small step will help move towards one in the future and give you instant benefits of consistency and maintainability now. If you want more Design Tokens, as well as the links that are dotted around this article I also maintain a GitHub repo of Awesome Design Tokens which I try to keep updated with links to tools, articles, examples, videos, and anything else that’s related to Design Tokens.

About the author

Stuart Robson is a freelance front-end developer and design systems advocate who curates the design systems newsletter - news.design.systems

More articles by Stuart

On today's episode, Aimee and Chuck welcome Maximillian "Max" Stoiber to the show. Max hails from Austria and is an expert in open source development at Think Mill. Tune in to JSJ 245 Styled Components and React-Boilerplate with Max Stoiber.

JSJ 269 Reusable React and JavaScript Components with Cory House

On today’s episode of JavaScript Jabber, we have panelists Joe Eames, Aimee Knight, Charles Max Wood, and playing the part of both host and guest, Cory House. Encourage your team to investigate reusable components, whether that’d be React, Angular, Vue, or Ember. Tune in!

[00:01:35] – Overview

We can finally write reusable components that it is really lightweight. It doesn’t take much framework-specific code to get things done.

Around 3 years ago, the idea of web component standard was all front-end developers could share our components with each other whether someone is in Angular or React. Web components continue to be an interesting standard but people continue to reach for JavaScript libraries instead – React, Angular, Vue. 

[00:04:50] – Browser support issue

The story in JavaScript libraries is easier. You have more power, more flexibility, more choices, and get superior performance, in certain cases, by choosing a JavaScript library over the standard right now. If you try to use the web components standard, you have to Polyfill-in some features so you can run things across browser. You also won’t get JavaScript features like intelligently splitting bundles and lazy load different components.

Whether you’re in Angular or React, you have this model of putting your data in your curly braces. That setup is non-existent in standardized web components. You have to play the game of putting and pulling data into and out the DOM using DOM selectors. You actually take a step backward in developer ergonomics when you choose to leverage the platform instead.

[00:07:50] – Polymer

The reason that Polymer is useful is it adds some goodness on top of web components. One of those things is that it makes it easier to bind in data and not having to do things like writing a DOM query to be able to get your hands on this div and put this text inside of it. With Polymer, you can do something that feels more like Angular, where you can put in your curly braces and just bind in some data into that place. Polymer ends up adding some nice syntactic sugar on top of the web components standard just to make it easier to create web components. Polymer is also used to bundle in Polyfill for the features across browser.   

[00:14:20] – Standards are dead

No. The standard itself has been embraced at different levels by different libraries. What you can see for the near future is popular libraries leveraging pieces of the web components platform to do things in a standard-spaced way. Effectively, Angular, Vue, Aurelia, are going to be abstractions over the web components standard. Arguably the most popular way to do components today is React. But React completely ignores the web components standard. When you look at React, you can’t see what piece of the web components standard would fundamentally make React a better component library.

Cory can’t seem to run to anybody that is actually using the standard in production to build real applications. People continue to reach for the popular JavaScript libraries that we so often hear about.

[00:17:05] – Libraries making reusable components

There is a risk that it would have been a waste for people writing components on Angular, for React, for Vue. But it’s not necessarily safer writing on the web component standard when you have so few people leveraging that standard. There’s always the risk that that standard may shift as well.

As an example, Cory’s team created approximately 100 reusable components in React. If they end up moving to a hot new library, the components are really just functions that take parameters and contain HTML. There is little there

[00:21:20] – Why opt for reusable components

Reusable components are inherently useful in a situation where you’re going to be doing something more than once. If you think about any work that you do as a software developer, we’d like to think that we’re coming in and creating new things but often it is groundhogs day. There are all sorts of opportunities for reuse.

As a company, we want to encapsulate our forms in reusable components so it’s literally impossible for our software developers to do something that goes against our standard. That’s the power of reusable components.  

[00:31:20] – Rigid component vs. flexible component

As component developers, if we try to create a reusable component in a vacuum, bad things happen. If you’re going to do a reusable component, start by solving a specific problem on a given application. If we think that a component’s going to be useful in multiple places, we put it in a folder called reusable right there in our application source folder.

We try to follow that rule of three as well. If we’ve taken that component and used it in 3 places, that’s a good sign that we should extract it out, put it in our NPM package, that way, everybody has this centralized component to utilize. At that point, it has been tested. It’s been through the fire. People have used it in the real world in a few places so we can be confident that the API is truly flexible enough.

Be as rigid as you can upfront. Once you add features, it’s really hard to take features away. But it’s quite easy to add features later. If you start with something rigid, it’s easier to understand. It’s easier to maintain and you can always add a few more switches later.

[00:36:00] – Reusable components

The reason that we can’t reuse code is every time a new project comes up, people are spending up their own ideas rather than leveraging standards that should have been put in place previously.

We’ve had the technical ability to do this for a long time. We just haven’t been around long enough for consolidation to happen, for standardization to happen. You look at how quickly things are changing in our industry. For instance, a couple of years ago, everybody had pretty much decided that two-way binding was the way to build web applications. And then, React came along and shook that up. So today, you have different ways of thinking about that issue.

[00:42:45] – Component development on teams

Aimee’s team has component development and they’re using Angular 1.6. All of our base components are sitting in a seed application. We just go in when we want to create a new property and we just extend all of those components with specific functionalities that we need.

[00:47:45] – Mobile to web crossover

Cory’s team is creating React components but it’s not leveraged on a mobile application. But people use React Native components on the web. And in fact, if you use create-react-app today, you can do that right now. It’s wired up to work in React Native components. In that way, you can literally have these same components running on your Native mobile apps as you do on your web application.

[00:50:00] – Challenge

Cory’s challenge for everybody listening is sit down with your team and have a quick conversation about whether you think components make sense. Look back at the last few months of development and say, "if we have a reusable component library, what would be in it? How often have we found ourselves copying and pasting code between different projects? How much benefit would we get out of this story?"

Once you’ve realized the benefits of the component model, both in the way that makes you think about your application, in a way that it helps you move faster and faster over time, I really think you won’t go back to the old model. I’d encourage people to investigate reusable components, whether that’d be React, Angular, Vue or Ember.

Picks

Cory House

• Creating Reusable React Components on Pluralsight
• Ted Talk: Why You Should Define your Fears Instead of Your Goals by Tim Ferriss

Joe Eames

• UI-Router
• Persistence

Aimee Knight

• Ask HN: People who completed a boot camp 3+ years ago, what are you doing now?
• NgAtlanta

Charles Max Wood

• Upwork.com

JSJ 269 Reusable React and JavaScript Components with Cory House

On today’s episode of JavaScript Jabber, we have panelists Joe Eames, Aimee Knight, Charles Max Wood, and playing the part of both host and guest, Cory House. Encourage your team to investigate reusable components, whether that’d be React, Angular, Vue, or Ember. Tune in!

[00:01:35] – Overview

We can finally write reusable components that it is really lightweight. It doesn’t take much framework-specific code to get things done.

Around 3 years ago, the idea of web component standard was all front-end developers could share our components with each other whether someone is in Angular or React. Web components continue to be an interesting standard but people continue to reach for JavaScript libraries instead – React, Angular, Vue. 

[00:04:50] – Browser support issue

The story in JavaScript libraries is easier. You have more power, more flexibility, more choices, and get superior performance, in certain cases, by choosing a JavaScript library over the standard right now. If you try to use the web components standard, you have to Polyfill-in some features so you can run things across browser. You also won’t get JavaScript features like intelligently splitting bundles and lazy load different components.

Whether you’re in Angular or React, you have this model of putting your data in your curly braces. That setup is non-existent in standardized web components. You have to play the game of putting and pulling data into and out the DOM using DOM selectors. You actually take a step backward in developer ergonomics when you choose to leverage the platform instead.

[00:07:50] – Polymer

The reason that Polymer is useful is it adds some goodness on top of web components. One of those things is that it makes it easier to bind in data and not having to do things like writing a DOM query to be able to get your hands on this div and put this text inside of it. With Polymer, you can do something that feels more like Angular, where you can put in your curly braces and just bind in some data into that place. Polymer ends up adding some nice syntactic sugar on top of the web components standard just to make it easier to create web components. Polymer is also used to bundle in Polyfill for the features across browser.   

[00:14:20] – Standards are dead

No. The standard itself has been embraced at different levels by different libraries. What you can see for the near future is popular libraries leveraging pieces of the web components platform to do things in a standard-spaced way. Effectively, Angular, Vue, Aurelia, are going to be abstractions over the web components standard. Arguably the most popular way to do components today is React. But React completely ignores the web components standard. When you look at React, you can’t see what piece of the web components standard would fundamentally make React a better component library.

Cory can’t seem to run to anybody that is actually using the standard in production to build real applications. People continue to reach for the popular JavaScript libraries that we so often hear about.

[00:17:05] – Libraries making reusable components

There is a risk that it would have been a waste for people writing components on Angular, for React, for Vue. But it’s not necessarily safer writing on the web component standard when you have so few people leveraging that standard. There’s always the risk that that standard may shift as well.

As an example, Cory’s team created approximately 100 reusable components in React. If they end up moving to a hot new library, the components are really just functions that take parameters and contain HTML. There is little there

[00:21:20] – Why opt for reusable components

Reusable components are inherently useful in a situation where you’re going to be doing something more than once. If you think about any work that you do as a software developer, we’d like to think that we’re coming in and creating new things but often it is groundhogs day. There are all sorts of opportunities for reuse.

As a company, we want to encapsulate our forms in reusable components so it’s literally impossible for our software developers to do something that goes against our standard. That’s the power of reusable components.  

[00:31:20] – Rigid component vs. flexible component

As component developers, if we try to create a reusable component in a vacuum, bad things happen. If you’re going to do a reusable component, start by solving a specific problem on a given application. If we think that a component’s going to be useful in multiple places, we put it in a folder called reusable right there in our application source folder.

We try to follow that rule of three as well. If we’ve taken that component and used it in 3 places, that’s a good sign that we should extract it out, put it in our NPM package, that way, everybody has this centralized component to utilize. At that point, it has been tested. It’s been through the fire. People have used it in the real world in a few places so we can be confident that the API is truly flexible enough.

Be as rigid as you can upfront. Once you add features, it’s really hard to take features away. But it’s quite easy to add features later. If you start with something rigid, it’s easier to understand. It’s easier to maintain and you can always add a few more switches later.

[00:36:00] – Reusable components

The reason that we can’t reuse code is every time a new project comes up, people are spending up their own ideas rather than leveraging standards that should have been put in place previously.

We’ve had the technical ability to do this for a long time. We just haven’t been around long enough for consolidation to happen, for standardization to happen. You look at how quickly things are changing in our industry. For instance, a couple of years ago, everybody had pretty much decided that two-way binding was the way to build web applications. And then, React came along and shook that up. So today, you have different ways of thinking about that issue.

[00:42:45] – Component development on teams

Aimee’s team has component development and they’re using Angular 1.6. All of our base components are sitting in a seed application. We just go in when we want to create a new property and we just extend all of those components with specific functionalities that we need.

[00:47:45] – Mobile to web crossover

Cory’s team is creating React components but it’s not leveraged on a mobile application. But people use React Native components on the web. And in fact, if you use create-react-app today, you can do that right now. It’s wired up to work in React Native components. In that way, you can literally have these same components running on your Native mobile apps as you do on your web application.

[00:50:00] – Challenge

Cory’s challenge for everybody listening is sit down with your team and have a quick conversation about whether you think components make sense. Look back at the last few months of development and say, "if we have a reusable component library, what would be in it? How often have we found ourselves copying and pasting code between different projects? How much benefit would we get out of this story?"

Once you’ve realized the benefits of the component model, both in the way that makes you think about your application, in a way that it helps you move faster and faster over time, I really think you won’t go back to the old model. I’d encourage people to investigate reusable components, whether that’d be React, Angular, Vue or Ember.

Picks

Cory House

• Creating Reusable React Components on Pluralsight
• Ted Talk: Why You Should Define your Fears Instead of Your Goals by Tim Ferriss

Joe Eames

• UI-Router
• Persistence

Aimee Knight

• Ask HN: People who completed a boot camp 3+ years ago, what are you doing now?
• NgAtlanta

Charles Max Wood

• Upwork.com

Panel:

• Charles Max Wood
• Aimee Knight
• Chris Ferdinandi
• Joe Eames

Special Guest: Heydon Pickering

In this episode, the panel talks with Heydon Pickering who is a designer and writer. The panel and the guest talk about his new book, which is centered on the topic of today’s show: inclusive components. Check out Heydon’s Twitter, Website, GitHub, and Mastodon social accounts to learn more about him. To purchase the book – go here!

Show Topics:

0:00 – Advertisement: KENDO UI

0:38 – Chuck: Aimee, Chris, Joe, and myself – we are today’s panel. My show the DevRev is available online to check it out.

1:30 – Guest: Plain ice cream would be frozen milk and that would be terrible. So I am lemon and candy JavaScript!

2:13 – Chuck: We are talking today about...?

2:22 – Chris: He’s talking about “inclusive components” today!

2:41 – Guest: Traveling is very stressful and I wanted something to do on the plane. I’ve done this book, “Inclusive Design Patterns.”

If you don’t want to buy the book you can go to the blog. I have been talking with Smashing Magazine.

5:40 – Panel.

5:47 – Guest: I approached Smashing Magazine initially. They didn’t think there was a market for this content at the time. They were very supportive but we will do it as an eBook so our costs our down. At the time, the editor came back and said that: “it was quite good!” We skimmed it but came back to it now and now the content was more relevant in their eyes. I didn’t want to do the same book but I wanted to do it around “patterns.” Rewriting components is what I do all the time. I use Vanilla JavaScript. Backbone.js is the trendy one.

9:52 – Panel: The hard book did it get published?

10:02 – Guest: We are in the works and it’s all in the final stages right now. It has to go through a different process for the print version.

11:54 – Panel.

11:58 – (Guest continues about the editorial process.)

12:09 – Panel: They probably switched to TFS – it’s Microsoft’s.

12:23 – Guest: There was this argument on Twitter about the different processors.

13:35 – Chris: What are the ways that people are breaking accessibility with their code through JavaScript? 

13:59 – Guest: The whole premise is that there aren’t a ton of different components that we use. Generally, speaking. Most things we do through JavaScript – it’s just different ways of doing this/that, and hiding things. I am discounting things with Node or other stuff. Most of what we are doing, with interactive design, is showing and hiding.

18:37 – Chris: I have some specialty friends where they tell me where I’ve screwed up my code. For example Eric Bailey and Scott O’Hara but, of course, in very kind ways. What are some things that I can make sure that my code is going to work for many different people.

19:18 – Guest: You have accessibility and inclusive design. People think of accessibility as a check-list and that’s okay but there could be problems with this.

26:00 – Panel: That’s a great guideline.

26:05 – Chris: You talked about ARIA roles and it can be confusing. One side is: I don’t know when to use these and the other side is: I don’t know when NOT to use these so I’m going to use them for EVERYTHING! I guess both can be detrimental. What’s your advice on this topic?

27:00 – Guest: Scott is great and I would trust him to the end of the Earth about what he says.

Guest mentions Léonie Watson and her talks about this topic.

29:26 – (Guest continues.)

29:36 – Advertisement – Sentry.io

30:31 – Chris.

30:40 – Guest: There is a lot of pressure, though, right? People wouldn’t blog about this if it wasn’t worthwhile. It doesn’t matter what the style is or what the syntax is.

The guest talks about not throwing ARIA onto everything.

36:34 – Aimee: Is this something that was mentioned in the book: people with disabilities and accessibility.

37:28 – Guest: Yes, of course. I think it’s important to make your interfaces flexible and robust to think and include people with disabilities.

39:00 – Guest mentions larger buttons.

40:52 – Panelists and Guest talk back-and-forth.

42:22 – Chris: It’s an accessibility and inclusivity element. I saw a dropdown menu and worked great on certain devices but not others. I could beat this horse all day long but the whole: what happens of the JavaScript file doesn’t load or just accordion options?

43:50 – Guest: It’s the progressive enhancement element.

44:05 – Guest: I think it’s worth noting. I think these things dovetail really nicely.

46:29 – Chris: Did you do a video interview, Aimee, talking about CSS? Is CSS better than JavaScript in some ways I don’t know if this is related or not?

47:03 – Aimee: When I talk about JavaScript vs. CSS...the browser optimizes those.

47:27 – Aimee: But as someone who loves JavaScript...and then some very talented people taught me that you have to find the right tool for the job.

47:29 – Guest: I am the other way around – interesting.

52:50 – Chuck: Picks!

52:55 – Advertisement – Get A Coder Job!

END – Advertisement: CacheFly!

Links:

• JavaScript
• Backbone.js
• Microsoft’s TFS
• Léonie Watson
• React
• Elixir
• Ember.js
• Vue
• GO
• jQuery
• Node.js
• Puppeteer
• Cypress
• Heydon’s GitHub
• Heydon’s Mastodon
• Heydon’s Book
• Medium Article on Heydon
• Heydon’s Website
• Heydon’s Twitter

Sponsors:

• DevLifts
• Kendo UI
• Sentry
• CacheFly

Picks:

Joe

• Chris Ferdinandi's Blog
• Luxur board game
• Cypress.io

Aimee

• Blog about interviewing
• Birthday Cake Quest Bar

Chris

• Web Dev Career Guide: https://gomakethings.com/career-guide/
• Use FREECAREER at checkout to get it for free
• Neapolitan Ice Cream 
• Netflix Web Performance case study

Charles

• Disney Heroes Battle Mode
• MFCEO Project Podcast
• Gary Lee Audio Experience
• Suggestions for JavaScript Jabber

Heydon

• Bruck
• What is Mastodon and why should I use it?

In this episode of JavaScript Jabber the panelists and guest delve into the advantages of the shadow dom, transitioning from polymer js polyfills to native web components when moving for SAP UI to UI5, which works within React, Vue, Angular, and others.

Panel

• AJ O’Neal
• Aimee Knight
• Steve Edwards
• Dan Shappir

Guest

• Peter Müßig
• Follow Peter on Twitter > @pmuessig, Github

Sponsors

• Taiko, free and open source browser test automation

____________________________________________________________

"The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today!

____________________________________________________________

Links

• OpenUI5
• Home - SAPUI5 SDK

Picks

AJ O’Neal:

• Vinyl Clocks
• Acrylic Stand
• AJ's YouTube Channel (AMA)

Aimee Knight

• Announcing Div Ops as the Slack and Reddit communities

Steve Edwards

• Today on Pearls Before Swine - Comics by Stephan Pastis

Dan Shappir

• The Wixing Street Interview | Facts about Wixing in Germany
• Wix.com werbung | versuch nicht zu lachen
• UI5 Web Components

Peter Müßig

• JavaScript Jabber

Follow JavaScript Jabber on Twitter > @JSJabber

Online Resource

I’m working on a project at Twitter that uses React and webpack. After a few conversations with @sokra last year, this is the setup I put in place for testing React components (authored using JSX and ES6) using Karma.

Dependencies

You’ll need to install various packages. It looks like a lot of dependencies, but all the non-Karma packages will be necessary for general module bundling during development.

Full set of required packages:

• babel-core: to transform JSX and transpile ES6.
• babel-loader: webpack loader for Babel.
• karma: the test runner.
• karma-chai-plugins: assertion library (or your library of choice).
• karma-chrome-launcher: Chrome browser launcher.
• karma-cli: CLI tool for Karma.
• karma-mocha: adapter for the Mocha testing framework.
• karma-sourcemap-loader: sourcemap loader.
• karma-webpack: to use webpack with Karma.
• react
• webpack: module bundler

webpack entry file

If you use webpack-specific features in your modules (e.g., loaders, plugins) you will need to use webpack to build a test bundle. The fastest and simplest approach is to create a single, test-specific entry file.

Create a file named tests.bundle.js. Within this file, you create a webpack context to match all the files that conform to a naming pattern – in this case *.spec.js(x).

var context = require.context('.', true, /.+.spec.jsx?$/);
context.keys().forEach(context);
module.exports = context;

Next, you point Karma to this file.

Karma config

Karma is configured using a karma.conf.js file. The browsers, plugins, and frameworks are specified in the standard way.

Point Karma at the tests.bundle.js file, and run it through the relevant preprocessor plugins (see example below).

The karma-webpack plugin relies on 2 custom properties of the Karma config: webpack and webpackMiddleware. The value of the former must be a webpack config object.

module.exports = function (config) {
  config.set({
    browsers: [ 'Chrome' ],
    // karma only needs to know about the test bundle
    files: [
      'tests.bundle.js'
    ],
    frameworks: [ 'chai', 'mocha' ],
    plugins: [
      'karma-chrome-launcher',
      'karma-chai',
      'karma-mocha',
      'karma-sourcemap-loader',
      'karma-webpack',
    ],
    // run the bundle through the webpack and sourcemap plugins
    preprocessors: {
      'tests.bundle.js': [ 'webpack', 'sourcemap' ]
    },
    reporters: [ 'dots' ],
    singleRun: true,
    // webpack config object
    webpack: {
      devtool: 'inline-source-map',
      module: {
        loaders: [
          {
            exclude: /node_modules/,
            loader: 'babel-loader,
            test: /.jsx?$/
          }
        ],
      }
    },
    webpackMiddleware: {
      noInfo: true,
    }
  });
};

Rather than duplicating your webpack config, you can require it in the Karma config file and override the devtool value to get sourcemaps working.

var webpackConfig = require('./webpack.config');
webpackConfig.devtool = 'inline-source-map';

module.exports = function (config) {
  config.set({
    ...
    webpack: webpackConfig
  });
};

That’s all you need to do to configure Karma to use webpack to load your JSX, ES6 React components.

Nieder, Rolf, author

Online Resource

For a third year in a row, exits accounted for over 80% of total proceeds