SVGs are here to stay, and React seems to be sticking around for a while as well. So how do you go about combining them?

Even though IE 11 still struggles a bit with properly scaling SVG files, SVGs are now supported by all modern browsers. That is, at least according to Can I Use. To cite Jake Giltsoff:

Scalable Vector Graphics can look crisp at all screen resolutions, can have super small file sizes, and can be easily edited and modified.

So why use any other image format, ever? Well, except for the times when you need an actual image of course. But let's leave the "why" with this brief introduction, and jump straight into the "how".

How to use an SVG in a React app, slightly depends on the rest of your website architecture, but most importantly whether the SVG should respond to any kind of interactions. Let's start with the simplest example:

Static SVGs

The easiest way of implementing a static SVG in a React app is like this:

After all, the img tag simply refers to an image, either through an absolute or a relative path. However, SVGs are often pretty small, and in these cases we are usually better off inlining the images as Data URLs, limiting the amount of requests a browser has to make to the server in order to render the webpage.

To transform an image into a Data URL, we need an appropriate loader in our bundler. I'm going to be using loaders written for webpack in my examples, but alternatives should be available for most other popular bundlers. For transforming files into Data URLs, the most common webpack loader is url-loader, which can be added in the following manner

Install as a devDependency:

Add to webpack.config.js:

Import the file in your React app:

The output in the DOM will be something like this

Now, url-loader actually transforms the images into base64 URIs. Seeing as an SVG is a human-readable xml string, using base64 encoding is not mandatory. Instead, we can use the more explicitly named svg-url-loader, which loads SVG files as an UTF-8 encoded Data URL string. The benefits of this are according to the README:

Resulting string is shorter (can be ~2 times shorter for 2K-sized icons);

Resulting string will be compressed better when using gzip compression;

Browser parses utf-8 encoded string faster than its base64 equivalent.

In the example above, I defined a limit in the options object of the loader. This tells webpack to only encode images that does not exceeds 10 kB in size. Both url-loader and svg-url-loader uses file-loader as a fallback, for files that exceeds this limit. What file-loader does, is basically to create a copy of the image file in your output directory. So if the SVG in the example above had exceeded 10 kB, the output in the DOM would look more like this:

This can be a bit cryptic though, so in order to get a more sensible naming of files in your output directory, you can add name: '[path][name].[ext]' to the loader options, like this:

Notice how I used svg-url-loader in this example, and also limited the test regex to only include .svg.

These loaders also work if you want to use SVGs as background-image or content in CSS. Fun fact though: Beware of using background-size if you intend to change background-image on hover or focus. Safari doesn't like this very much.

Static, but animated, SVGs

Say you have an animated spinner, or some other kind of fancy loader, created in SVG. You might think that you would need to inline this SVG, in order to animate its properties with CSS. Good news: You don't!

It is true that an SVG loaded as an image, as described above, can't be modified from "the outside". However, as long as the animation is either applied as CSS within the SVG itself (with a <style> element), or with an SVG <animate> element, this animation will run however the SVG is implemented on the page.

Interactive SVGs

Now, to the really fun part! If you want to have full control of your SVGs from within your app, and how they respond to different interactions, inlining them is the way to go. In theory, you don't necessarily need a loader for this, you could just copy the SVG code directly into a component. There are a few reasons why this might not be the best way to go though. Say you were to change some part of the SVG through a visual editor, such as Sketch or Adobe Illustrator. Wouldn't it be decidedly easier to just switch the SVG file, and not have to copy paste over the SVG code within the respective component? In order to avoid this, you can use react-svg-loader:

Notice how I prefixed the test regex with inline. This is because you likely don't want all SVGs in your app to be inline. Say you were to only have this loader, and then used an SVG as a background-image. Your resulting CSS would look something like this:

So usually, we want to use both react-svg-loader and svg-url-loader. To avoid the latter trying to parse an SVG file supposed to be inline, we need to exclude them from the loader. In this case, where inline SVGs include inline before the file extension, the full set of loaders for SVGs would look like:

Of course, you could also choose to put the files in different folders, and rather use the exclude and include options on each loader. Furthermore, there are a couple of other loaders that does more or less the same as the ones I've mentioned here. But hopefully this has been useful anyway.

Happy SVGing!

How to use SVGs in React

Imagine pulling up a search on Google for something web tech related. Let's say you look up how the text-align property works in CSS. The two first hits are from w3schools.com. A little further down we find Mozilla Developer Network's (or MDN) article on the subject.

MDN is obviously run by the altruistic, open-web freedom fighters at Mozilla, but what's the deal with w3schools, and why does some people dislike it so much?

Here's the deal

It's actually being run a by a Norwegian family near the nation's oil capital of Stavanger on the west coast. There, an IT-professional in the 90s suddenly found himself needing to learn some HTML, and decided to make a simple guide on how to create a web page while he was at it. Over time that snowballed into what we know as w3schools today.

In Norwegian newspapers, the family behind it has been at the center of several news stories. In 2017 it was revealed that they had over 45 million unique monthly users, putting them at 186th place over the world's most visited web sites (!). That alone nets them around $350 000 per month in pure ad revenue from Google (w3schools is actually one of Google's biggest ad distributors).

So what's the problem?

The controversy

Critics pointed out that some of the material on the site (and especially the longread tutorials) was full of errors and inconsistencies. Also, some would point out that w3schools did little to make their lacking affiliation with the world wide web consortium (w3c) clear to readers, causing a big misinterpretation that this was actually an official site ran by someone having anything to do with how the web is run.

It went so far that a united web developer elite created the site w3fools.com to bring light to the issue. This is an excerpt from w3fools back in 2011:

We are passionate about the web, learning, and craftsmanship. We want you, as web designers and developers, to be successful in your careers. We feel, though, that W3Schools is harming the community with inaccurate information. Like any other authoritative educational resource, W3Schools should both hold itself to, and be held to, the highest standards.



We hope we can illuminate why W3Schools is a troublesome resource, why their faulty information is a detriment to the web, and what you (and they) can do about it.



– members of the Front-end Dev Community, January 14th, 2011

This was signed by well-known people like Addy Osmani of Google, then-maintainer of jQuery Alex Sexton, current V8 engineer Mathias Bynens, @kangax from caniuse.com and lots of other people.

What's happened since

When you're a family business that's raking in $350 000 a month from simply keeping your website up and running, it's in your best interest to respond to the critique when many of the most visible web technology people of the world point at your site and laugh.

As of Dec 18 2018, w3fools.com has changed their message and tone:

[…] Today, W3Schools has largely resolved these issues and addressed the majority of the undersigned developers' concerns. For many beginners, W3Schools has structured tutorials and playgrounds that offer a decent learning experience. […]

So, is w3schools worth a visit these days? Should we all keep using MDN instead? I don't know. I don't care. I've always used MDN and will keep using it, partly because it looks nicer and I like Mozilla. You use whichever resource you like!

None the less, this is an interesting story worth remembering.

The W3schools Controversy

As the end of the year closes in, there are no shortage of tips on how to get your home ready for the festive season. We think you should take a time out, and consider which application should still have access to your social accounts.

Proving who we are on the internet is not an easy task and giving away more or less personal information to random websites just to be able to test the latest social network of the day or be able to comment on someone’s blog post was for some time a bothersome process where one had to create accounts for all the different services.

This issue was solved by several major companies, predominantly social networks, where most of use already had registered already.

The social login

Services as “Login with Facebook”, “Google Sign-In” with more, provide third parties a frictionless way to authenticate users on their site without requiring their users to create a new account on their site. In return the selected login provider receives more information on which sites you visit and an probably sell your more native content or advertisements. This can be a fair trade, the third party can authenticate the user, the user can use the service without creating a new account.

Reduce attack surface

For the purpose of this posting, we will not go in to the technical implementation nor the privacy implications, but we think that reducing your attack surface will improve your security and privacy online.

We suggest you login to your various social networks and see if you have given access to your personal information to any service or application your do not use.

We have found that doing it a yearly task, we are able to keep the number of services that have access to our Google account or Facebook profile to a bare minimum.

A few examples

Facebook

Go to the Apps and Websites tab under Settings in Facebook. There you can see which applications and websites can access some of your Facebook profile, or in some cases, your friends profiles.

https://www.facebook.com/settings?tab=applications§ion=removed

Google

Login to your Google account and go the Google Account. Under Sign-in & security a link which open a list of connected applications can be found.

https://myaccount.google.com/security#connectedapps

Twitter

The Twitter web page let your access which applications are connected to your account. https://twitter.com/settings/sessions

Closing thoughts

We for sure had forgotten all about several of the application we had given access to our Twitter account back in 2015. So, let 2019 begin with a clean start.

18-Dec

Today's posts

How to use SVGs in React

The W3schools Controversy

Time to clean up your social logins