Here are two ways to include HTML5 elements in your WordPress post content without WordPress’ wpautop function wrapping them in p tags or littering your code with line breaks.

HTML5 has several new elements that you may want to use in your post content to markup document sections, headers, footers, pullquotes, figures, or groups of headings. One way to safely include these elements in your posts is simple; the other way is a bit more complicated. Both ways rely on hand-coding the HTML5 markup in the WordPress editor’s HTML view.

If you are adding HTML5 elements to your post content then you should use an HTML5 doctype.

Disable wpautop for your theme

This is the simple way. Disable the wpautop function so that WordPress makes no attempt to correct your markup and leaves you to hand-code every line of your posts. If you want total control over every line of your HTML then this is the option for you.

To disable wpautop entirely add these lines to your theme’s functions.php:

remove_filter('the_excerpt', 'wpautop');
remove_filter('the_content', 'wpautop');

However, wpautop is generally quite useful if most of your posts are simple text content and you only occasionally want to include HTML5 elements. Therefore, modifying wpautop to recognise HTML5 elements might be more practical.

Modify wpautop to recognise HTML5 elements

WordPress’ wpautop is part of the core functions and can be found in this file within your WordPress installation: wp-includes/formatting.php. It controls how and where paragraphs and line breaks are inserted in excerpts and post content.

In order to create a modified version of WordPress’ core wpautop function I started off by duplicating it in my theme’s functions.php file.

What I’ve experimented with is disabling wpautop and adding a modified copy of it – which includes HTML5 elements in its arrayss – to my theme’s functions.php file.

Add the following to your theme’s functions.php file and you’ll be able to use section, article, aside, header, footer, hgroup, figure, details, figcaption, and summary in your post content. (Probably best to try this in a testing environment first!)

/* -----------------------------
MODIFIED WPAUTOP - Allow HTML5 block elements in wordpress posts
----------------------------- */

function html5autop($pee, $br = 1) {
   if ( trim($pee) === '' )
      return '';
   $pee = $pee . "
"; // just to make things a little easier, pad the end
   $pee = preg_replace('|<br />s*<br />|', "

", $pee);
   // Space things out a little
    // *insertion* of section|article|aside|header|footer|hgroup|figure|details|figcaption|summary
   $allblocks = '(?:table|thead|tfoot|caption|col|colgroup|tbody|tr|td|th|div|dl|dd|dt|ul|ol|li|pre|select|form|map|area|blockquote|address|math|style|input|p|h[1-6]|hr|fieldset|legend|section|article|aside|header|footer|hgroup|figure|details|figcaption|summary)';
   $pee = preg_replace('!(<' . $allblocks . '[^>]*>)!', "
$1", $pee);
   $pee = preg_replace('!(</' . $allblocks . '>)!', "$1

", $pee);
   $pee = str_replace(array("
", "
"), "
", $pee); // cross-platform newlines
   if ( strpos($pee, '<object') !== false ) {
      $pee = preg_replace('|s*<param([^>]*)>s*|', "<param$1>", $pee); // no pee inside object/embed
      $pee = preg_replace('|s*</embed>s*|', '</embed>', $pee);
   }
   $pee = preg_replace("/

+/", "

", $pee); // take care of duplicates
// make paragraphs, including one at the end
   $pees = preg_split('/
s*
/', $pee, -1, PREG_SPLIT_NO_EMPTY);
   $pee = '';
   foreach ( $pees as $tinkle )
      $pee .= '<p>' . trim($tinkle, "
") . "</p>
";
   $pee = preg_replace('|<p>s*</p>|', '', $pee); // under certain strange conditions it could create a P of entirely whitespace
// *insertion* of section|article|aside
   $pee = preg_replace('!<p>([^<]+)</(div|address|form|section|article|aside)>!', "<p>$1</p></$2>", $pee);
   $pee = preg_replace('!<p>s*(</?' . $allblocks . '[^>]*>)s*</p>!', "$1", $pee); // don't pee all over a tag
   $pee = preg_replace("|<p>(<li.+?)</p>|", "$1", $pee); // problem with nested lists
   $pee = preg_replace('|<p><blockquote([^>]*)>|i', "<blockquote$1><p>", $pee);
   $pee = str_replace('</blockquote></p>', '</p></blockquote>', $pee);
   $pee = preg_replace('!<p>s*(</?' . $allblocks . '[^>]*>)!', "$1", $pee);
   $pee = preg_replace('!(</?' . $allblocks . '[^>]*>)s*</p>!', "$1", $pee);
   if ($br) {
      $pee = preg_replace_callback('/<(script|style).*?</\1>/s', create_function('$matches', 'return str_replace("
", "<WPPreserveNewline />", $matches[0]);'), $pee);
      $pee = preg_replace('|(?<!<br />)s*
|', "<br />
", $pee); // optionally make line breaks
      $pee = str_replace('<WPPreserveNewline />', "
", $pee);
   }
   $pee = preg_replace('!(</?' . $allblocks . '[^>]*>)s*<br />!', "$1", $pee);
// *insertion* of img|figcaption|summary
   $pee = preg_replace('!<br />(s*</?(?:p|li|div|dl|dd|dt|th|pre|td|ul|ol|img|figcaption|summary)[^>]*>)!', '$1', $pee);
   if (strpos($pee, '<pre') !== false)
      $pee = preg_replace_callback('!(<pre[^>]*>)(.*?)</pre>!is', 'clean_pre', $pee );
   $pee = preg_replace( "|
</p>$|", '</p>', $pee );

   return $pee;
}

// remove the original wpautop function
remove_filter('the_excerpt', 'wpautop');
remove_filter('the_content', 'wpautop');

// add our new html5autop function
add_filter('the_excerpt', 'html5autop');
add_filter('the_content', 'html5autop');

The results are not absolutely perfect but then neither is the original wpautop function. Certain ways of formatting the code will result in unwanted trailing </p> tags or a missing opening <p> tags.

For example, to insert a figure with caption into a post you should avoid adding the figcaption on a new line because an image or link appearing before the figcaption will end up with a trailing </p>.

<!-- this turns out ok -->
<figure>
  <a href="#"><img src="image.jpg" alt="" /></a><figcaption>A figure caption for your reading pleasure</figcaption>
</figure>

<!-- this turns out not so ok -->
<figure>
  <a href="#"><img src="image.jpg" alt="" /></a>
  <figcaption>A figure caption for your reading pleasure</figcaption>
</figure>

Another example would be when beginning the contents of an aside with a paragraph. You’ll have to leave a blank line between the opening aside tag and the first paragraph.

<aside>

This content could be a pullquote or information that is tangentially related to the surrounding content. But to get it wrapped in a paragraph you have to leave those blank lines either side of it before the tags.

</aside>

Room for improvement

Obviously there are still a few issues with this because if you format your post content in certain ways then you can end up with invalid HTML, even if it doesn’t actually affect the rendering of the page. But it seems to be pretty close!

Leave a comment or email me if you are using this function and find there that are instances where it breaks down. I ran numerous tests and formatting variations to try and iron out as many problems as possible but it’s unlikely that I tried or spotted everything.

Hopefully someone with more PHP and WordPress experience will be able to improve upon what I’ve been experimenting with, or find a simpler and more elegant solution that retains the useful wpautop functionality while allowing for the use of HTML5 elements in posts. Please share anything you find!

Using within-page links presses the jumped-to content right at the very top of the viewport. This can be a problem when using a fixed header. With a bit of hackery, there are some CSS methods to insert space between the top of the viewport and the target element within a page.

Demo: Jump links and viewport positioning

Known support: varies depending on method used.

This experiment is the result of a post Chris Coyier made on Forrst. Chris’ method was to add an empty span element to the target element, shift the id attribute onto the span, and then absolutely position the span somewhere above it’s parent element.

That method works but it requires changes to the HTML. The comments on Chris’ post suggested the use of psuedo-elements or padding. This experiment expands on, and combines, some of those suggestions to show the limitations of each method and document their browser support.

Simplest method

If you need to jump to an element with simple styling then using the :before pseudo-element is a quick and simple approach.

#target:before {
   content: "";
   display: block;
   height: 50px;
   margin: -30px 0 0;
}

The drawbacks are that it requires browser support for pseudo-elements and it will fail if the target element has a background colour, a repeated background image, padding-top, or border-top as part of its rule set.

More robust method

The more robust method uses a transparent border, negative margin, and the background-clip property. If a top border is required then it can be mimicked using a pseudo-element, as described in Multiple Backgrounds and Borders with CSS 2.1.

#target {
   position: relative;
   border-top: 52px solid transparent;
   margin: -30px 0 0;
   -webkit-background-clip: padding-box;
   -moz-background-clip: padding;
   background-clip: padding-box;
}

#target:before {
   content: "";
   position: absolute;
   top: -2px;
   left: 0;
   right: 0;
   border-top: 2px solid #ccc;
}

There are still drawbacks: it requires browser support for background-clip if there is a background color, gradient, or repeating image set on the target element; it requires browser support for pseudo-elements and their positioning if a top border is desired; and it interferes with the standard use of margins.

To see these methods in action – as well as more details on the code, browser support, and drawbacks – have a look at the demo page. Please let me know if you know of better techniques.

Research into improving the cross-browser consistency of both the “clearfix” and “overflow:hidden” methods of containing floats. The aim is to work around several bugs in IE6 and IE7.

This article introduces a new hack (with caveats) that can benefit the “clearfix” methods and the new block formatting context (NBFC) methods (e.g. using overflow:hidden) of containing floats. It’s one outcome of a collaboration between Nicolas Gallagher (that’s me) and Jonathan Neal.

If you are not familiar with the history and underlying principles behind methods of containing floats, I recommend that you have a read of Easy clearing (2004), Everything you know about clearfix is wrong (2010), and Clearfix reloaded and overflow:hidden demystified (2010).

Consistent float containment methods

The code is show below and documented in this GitHub gist. Found an improvement or flaw? Please fork the gist or leave a comment.

Micro clearfix hack: Firefox 3.5+, Safari 4+, Chrome, Opera 9+, IE 6+

.cf {
  /* for IE 6/7 */
  *zoom: expression(this.runtimeStyle.zoom="1", this.appendChild(document.createElement("br")).style.cssText="clear:both;font:0/0 serif");
  /* non-JS fallback */
  *zoom: 1;
}

.cf:before,
.cf:after {
  content: "";
  display: table;
}

.cf:after {
  clear: both;
}

Overflow hack (NBFC): Firefox 2+, Safari 2+, Chrome, Opera 9+, IE 6+

.nbfc {
  overflow: hidden;
  /* for IE 6/7 */
  *zoom: expression(this.runtimeStyle.zoom="1", this.appendChild(document.createElement("br")).style.cssText="clear:both;font:0/0 serif");
  /* non-JS fallback */
  *zoom: 1;
}

The GitHub gist also contains another variant of the clearfix method for modern browsers (based on Thierry Koblentz’s work). It provides greater visual consistency (avoiding edge-case bugs) for even older versions of Firefox.

The only difference from existing float-containment methods is the inclusion of a CSS expression that inserts a clearing line-break in IE 6 and IE 7. Jonathan and I found that it helps to resolve some of the visual rendering differences that exist between these browsers and more modern ones. First I’ll explain what some of those differences are and when they occur.

Containing floats in IE 6/7

In IE 6 and IE 7, the most common and robust method of containing floats within an element is to give it “layout” (find out more: On having Layout). Triggering “layout” on an element in IE 6/7 creates a new block formatting context (NBFC). However, certain IE bugs mean that previous float containment methods don’t result in cross-browser consistency. Specifically, this is what to expect in IE 6/7 when creating a NBFC:

1. The top- and bottom-margins of non-floated child elements are contained within the ancestor element that has been given “layout”. (Also expected in other browsers when creating a NBFC)
2. The bottom-margins of any right-floated descendants are contained within the ancestor. (Also expected in other browsers when creating a NBFC)
3. The bottom-margins of any left-floated children are not contained within the ancestor. The margin has no effect on the height of the ancestor and is truncated, having no affect outside of the ancestor either. (IE 6/7 bug)
4. In IE 6, if the right edge of the margin-box of a left-floated child is within 2px of the left edge of the content-box of its NBFC ancestor, the float’s bottom margin reappears and is contained within the parent. (IE 6 bug)
5. Unwanted white-space can appear at the bottom of a float-container. (IE 6/7 bug)

There is a lack of consistency between IE 6/7 and other browsers, and between IE 6 and IE 7. Thanks to Matthew Lein for his comment that directed me to this IE 6/7 behaviour. It was also recently mentioned by “Suzy” in a comment on Perishable Press.

IE 6/7’s truncation of the bottom-margin of left-floats is not exposed in many of the test-cases used to demonstrate CSS float containment techniques. Using an IE-only CSS expression helps to correct this bug.

The CSS expression

Including the much maligned <br style="clear:both"> at the bottom of the float-container, as well as creating a NBFC, resolved all these inconsistencies in IE 6/7. Doing so prevents those browsers from collapsing (or truncating) top- and bottom-margins of descendant elements.

Jonathan suggested inserting the clearing line-break in IE 6/7 only, using CSS expressions applied to fictional CSS properties. The CSS expression is the result of many iterations, tests, and suggestions. It runs only once, the first time an element receives the associated classname.

*zoom: expression(this.runtimeStyle.zoom="1", this.appendChild(document.createElement("br")).style.cssText="clear:both;font:0/0 serif");

It is applied to zoom, which is already being used to help contain floats in IE 6/7, and the use of the runtimeStyle object ensures that the expression is replaced once it has been run. The addition of font:0/0 serif prevents the occasional appearance of white-space at the bottom of a float-container. And the * hack ensures that only IE 6 and IE 7 parse the rule.

It’s worth noting that IE 6 and IE 7 parse almost any string used as CSS property. An earlier iteration used the entirely fictitious properties “-ms-inject” or “-ie-x” property to exploit this IE behaviour.

*-ie-x: expression(this.x||(this.innerHTML+='<br style="clear:both;font:0/0">',this.x=1));

However, this expression is evaluated over and over again. Using runtimeStyle instead avoids this. Sergey Chikuyonok also pointed out that using innerHTML destroys existing HTML elements that may event handlers attached to them. By using document.createElement and appendChild you can insert the new element without removing all the events attached to other descendant elements.

Containing floats in more modern browsers

There are two popular methods to contain floats in modern browsers. Creating a new block formatting context (as is done in IE 6/7 when hasLayout is triggered) or using a variant of the “clearfix” hack.

Creating a NBFC results in an element containing any floated children, and will prevent top- and bottom-margin collapse of non-floated children. When combined with the enhanced IE 6/7 containment method, it results in consistent cross-browser float containment.

The other method, known as “clearfix”, traditionally used a single :after pseudo-element to clear floats in a similar fashion to a structural, clearing HTML line-break. However, to prevent the top-margins of non-floats from collapsing into the margins of their float-containing ancestor, you also need to use the :before pseudo-element. This is the approach taken in Thierry Koblentz’s “clearfix reloaded”. In contemporary browsers, the micro clearfix hack is also suitable.

The method presented in this article should help improve the results of cross-browser float containment, whether you predominantly use “clearfix” or the NBFC method. The specific limitations of both the “clearfix” and various NBFC methods (as outlined in Thierry’s articles) remain.

Problems

Using a CSS expression to change the DOM in IE 6/7 creates problems of its own. Obviously, the DOM in IE 6/7 is now different to the DOM in other browsers. This affects any JavaScript DOM manipulation that may depend on :last-child or appending new children.

This is still an experimental work-in-progress that is primarily research-driven rather than seeking to become a practical snippet of production code. Any feedback, further testing, and further experimentation from others would be much appreciated.

Thanks to these people for contributing improvements: Jonathan Neal, Mathias Bynens, Sergey Chikuyonok, and Thierry Koblentz.

Future CSS implementations should allow for some form of responsive images via CSS alone. This is an early idea for how that might be done. However, a significant drawback is that it would not prevent both “mobile optimised” and larger size images from being requested at larger screen resolutions.

Note that the CSS presented here is not supported in any browsers at the time of writing.

This method relies on the use of @media queries, CSS3 generated content, and the CSS3 extension to the attr() function.

The principles are basically the same as those underpinning Filament Group’s work on Responsive Images. The source image is “mobile optimised” and the urls of larger size images are included using HTML data-* attributes.

<img src="image.jpg"
     data-src-600px="image-600px.jpg"
     data-src-800px="image-800px.jpg"
     alt="">

Using CSS @media queries you can target devices above certain widths. Within each media query block, images with larger alternatives can be targeted using an attribute selector.

CSS3 generated content allows you to replace the content of any element using the content property. At the moment, only Opera 10+ supports it. In CSS 2.1, the content property is limited to use with the :before and :after pseudo-elements.

By combining the content property with the CSS3 extension to attr(), you will be able to specify that an attribute’s value is interpreted as the URL part of a url() expression. In this case, it means you will be able to replace an image’s content with the image found at the destination URL stored in a custom HTML data-* attribute.

@media (min-device-width:600px) {
  img[data-src-600px] {
    content: attr(data-src-600px, url);
  }
}

@media (min-device-width:800px) {
  img[data-src-800px] {
    content: attr(data-src-800px, url);
  }
}

Fork the Gist

Issues

Unfortunately, there are a number of issues with this technique.

1. It doesn’t prevent multiple assets being downloaded at larger screen widths because network activity kicks in before CSS is applied. That means, for example, that desktop environments would make 2 HTTP requests for an image and have to load more assets than if they had been served only the larger image in the source.
2. It makes the assumption that wider screens are tied to better internet connections.
3. It forces authors to create and maintain multiple image sizes for each image.
4. At present, using the context menu (or drag and drop) to copy the image will result in the source file being copied and not the replacement image.
5. It doesn’t account for devices with different pixel densities.

Taking a “mobile first” approach to web development poses some challenges if you need to provide a “desktop” experience for legacy versions of IE. Using a CSS pre-processor like Sass can help.

As of Sass 3.2, there is another way of catering for IE, described by Jake Archibald.

One aspect of a “mobile first” approach to development is that your styles are usually gradually built up from a simple base. Each new “layer” of CSS adds presentational adjustments and complexity, via CSS3 Media Queries, to react to and make use of additional viewport space. However, IE 6/7/8 do not support CSS3 Media Queries. If you want to serve IE 6/7/8 something more than just the base CSS, then you need a solution that exposes the “enhancing” CSS to those browsers.

Popular existing options

An existing option is the use of a CSS3 Media Query polyfill, such as Respond.js. However, there are some drawbacks to this approach (see the project README), such as the introduction of a JavaScript dependency and the XHRing of your style sheets, which may introduce performance or cross-domain security issues. Furthermore, adding support for CSS3 Media Queries is probably not necessary for these legacy browsers. The main concern is exposing the “enhancing” CSS.

Another method, which Jeremy Keith has described in his post on Windows mobile media queries, is to use separate CSS files: one basic global file, and an “enhancing” file that is referenced twice in the <head> of the document. The “enhancing” file is referenced once using a media attribute containing a CSS3 Media Query value. This prevents it being downloaded by browsers (such as IE 6/7/8) which do not support CSS3 Media Queries. The same file is then referenced again, this time wrapped in an IE conditional comment (without the use of a CSS3 Media Query value) to hide it from modern browsers. However, this approach becomes somewhat cumbersome, and introduces multiple HTTP requests, if you have multiple breakpoints in your responsive design.

Getting Sass to help

Sass 3.1 provides some features that help make this second approach more flexible. The general advantages of the Sass-based approach I’ve used are:

1. You have full control over how your style sheets are broken up and reassembled.
2. It removes the performance concerns of having to reference several separate style sheets for each breakpoint in the responsive design, simply to cater for IE 6/7/8.
3. You can easily repeat large chunks of CSS in separate compiled files without introducing maintenance problems.

The basic idea is to produce two versions of your compiled CSS from the same core code. One version of your CSS includes CSS3 @media queries and is downloaded by modern browsers. The other version is only downloaded by IE 6/7/8 in a desktop environment and contains no CSS3 @media queries.

To do this, you take advantage of the fact that Sass can import and compile separate .scss/.sass files into a single CSS file. This allows you to keep the CSS rules used at any breakpoint completely separate from the @media query that you might want it to be a part of.

This is not a CSS3 Media Query polyfill, so one assumption is that IE 6/7/8 users will predominantly be using mid-size screens and should receive styles appropriate to that environment. Therefore, in the example below, I am making a subjective judgement by including all the breakpoint styles up to a width of 960px but withholding those for any breakpoints beyond that.

The ie.scss file imports numerous other files, each containing a layer of CSS that builds upon the previous each layer of CSS. No CSS3 @media queries are contained within the files or the ie.scss file. It then compiles to a single CSS file that is designed to be served only to IE 6/7/8.

// ie.scss

@import "base";
@import "320-up";
@import "480-up";
@import "780-up";
@import "960-up";

The style.scss file imports the code for each breakpoint involved in the design (including any beyond the limit imposed for legacy versions of IE) but nests them within the relevant CSS3 @media query. The compiled version of this file is served to all browsers apart from IE 6/7/8 and IEMobile.

// style.scss

@import "base";
@media (min-width:320px) {
    @import "320-up"; }
@media (min-width:480px) {
    @import "480-up"; }
@media (min-width:780px) {
    @import "780-up"; }
@media (min-width:960px) {
    @import "960-up"; }
@media (min-width:1100px) {
    @import "1100-up"; }

The resulting CSS files can then be referenced in the HTML. It is important to hide the ie.css file from any IE-based mobile browsers. This ensures that they do not download the CSS meant for desktop versions of IE.

<!--[if (gt IE 8) | (IEMobile)]><!-->
<link rel="stylesheet" href="/css/style.css">
<!--<![endif]-->

<!--[if (lt IE 9) & (!IEMobile)]>
<link rel="stylesheet" href="/css/ie.css">
<![endif]-->

This Sass-enabled approach works just as well if you need to serve a basic style sheet for mobiles without CSS3 Media Query support, and prevent those devices from downloading the CSS used to adapt the layout to wider viewports. For example, you can avoid importing base.scss into the ie.scss and style.scss files. It can then be referenced separately in the HTML.

<link rel="stylesheet" href="/css/base.css">
<link rel="stylesheet" href="/css/style.css" media="(min-width:320px)">

<!--[if (lt IE 9) & (!IEMobile)]>
<link rel="stylesheet" href="/css/ie.css">
<![endif]-->

You’ll notice that I didn’t wrap the style.css reference in a conditional comment to hide it from legacy versions of IE. It’s not necessary this time because the value of the media attribute is not understood by legacy versions of IE, and the style sheet will not be downloaded.

In different circumstances, different combinations of style sheets and media attribute values will be more appropriate.

Summary

Even if you want to don’t want to use any of the Sass or SCSS syntax, the pre-processor itself can help you to write your CSS in a “mobile first” manner (with multiple breakpoints), provide a “desktop” experience for IE 6/7/8, and avoid some of the performance or maintenance concerns that are sometimes present when juggling the two requirements.

I’m relatively new to using Sass, so there may be even better ways to achieve the same result or even to prevent the inclusion of IE-specific CSS unless the file is being compiled into a style sheet that only IE will download.

I recently moved from London to San Francisco to work at Twitter, as a Software Engineer. This is a rough guide – in the spirit of @chanian’s tutorial for Canadians – based on my experience of relocating, the mistakes I made along the way, and some information I wish I’d had. Use it at your own risk – don’t assume any legal truths; research things for yourself before making decisions!

I’m not going to cover anything about the US visa process. The company that has offered you employment in the US is likely to work with immigration lawyers who will handle (or guide you through) the visa application and processing. I’m also going to assume that your employer is providing temporary accommodation or that you are organising your own (e.g., via Airbnb) while you search for an apartment. Most of this article relates to things you will need to do once you arrive in San Francisco and soon after, but that you should spend some time thinking about beforehand.

Get a phone

You’ll need a US mobile/cell number pretty quickly, especially if you’re apartment-hunting.

The US telecom market isn’t great and will leave you nostalgic for the halcyon days of the EU-regulated, pro-consumer market you’ve left behind. For example, it’s now illegal to unlock a phone from a carrier unless you have that carrier’s permission to do so. Furthermore, if you do get a phone from a carrier (as part of your contract deal), you should be aware of whether or not you will be locked into a proprietary network, like Verison’s CDMA. Without a US credit history, you should expect to pay a sizable deposit when entering into a contract.

One way to reduce the cost of a phone contract is to bring your own phone to the party. If you bring a phone from the UK, make sure to check that your charger will work on US voltage. With an unlocked, GSM-supporting phone you can look to carriers like T-Mobile who offer various “value” and no-annual-contract plans. These prices are significantly cheaper because they don’t subsidise the purchase of a new phone. You’re likely to find “unlimited” data plans easier to come by than they are in the UK.

You’re shit-out-of-luck if you’re thinking you’d prefer a European-style pay-as-you-go (PAYG) approach. The options are thin on the ground. Any airtime you buy means just that – any time you spend talking or texting – so you pay to send and receive calls or SMS’s. My experience suggests that some networks recycle phone numbers or sell on your details. I still receive random texts addressed to previous owners of my phone number, and get messages from marketing companies who have miraculously acquired my personal details, an irritation that is compounded by the fact that it costs you money to be harassed.

If you’re determined to go the PAYG route, the nearest US equivalent is probably AT&T’s GoPhone SIM or Net10. You’ll have to purchase a phone and credit up front; top ups can be purchased in store, at some supermarkets, or done over the phone. This may also be the first time you encounter the US concept of a “restocking fee” – a method of dissuading you from returning items by charging you to do so. The restocking fee for the burner phone I first purchased was almost as much as the phone itself.

Open a bank account, transfer money

Make this a top priority. You should open a bank account as soon as you arrive in the US, especially as some banks will initially let you do so without a Social Security Number or permanent address.

Until you open a US bank account, you’ll be haemorrhaging money on fees levied by your UK bank for dollar transactions, and subject to poor exchange rates.

Choose a bank

San Francisco has a large range of different bank brands to choose from, but you’re probably best sticking to the big name banks that have branches and ATMs throughout the city, such as Bank of America, Chase, or Wells Fargo. There are co-ops and niche services if that’s your thing. Be sure to do some preparatory research on which bank is best suited to your needs. It’s also worth checking if your bank in the UK has a reciprocal agreement with any bank operating in San Francisco; it may cut down the cost of moving your money. Friends recommended going with either Bank of America or Chase. I went with Bank of America, where the customer service was personal and friendly.

Banking fees are a matter of course in the US. In contrast to the UK, you’ll almost certainly be charged for withdrawing money from any ATMs that aren’t owned by your bank. You have to buy cheque books (“check” in American English) and pay a fee to transfer your money to accounts outside your bank. Accounts usually involve a monthly fee, although this is waived in certain situations, such as setting up your salary to be directly deposited. Expect to set up a current (“checking”) and savings account, and to be asked to make a minimum cash deposit to complete the process (at Bank of America it was $100).

Once you’re all set up, your debit card will be sent in the post – so make sure you’ll be at that address for at least another week. In the meantime you may get a temporary cash card to get at what you’ve already deposited. Even if you transfer more money in, your bank can limit the amount you can withdraw within the first 30 days of the account being open – presumably to combat fraud/laundering.

Transfer money

It’s essential that you transfer money from your UK bank as soon as possible. There are many factors to consider when calculating how much money you want to transfer.

• You may enter the US up to 10 days before your visa is valid and you can start work.
• You need money for food, transport, going out, a phone (and deposit), apartment applications, an apartment deposit, buying furniture, etc.
• You might not be able to get paid until you have a Social Security Number.
• You’re unlikely to get paid until the middle or end of the month you start working.
• You’re very likely to get your first pay cheque given to you as a real cheque; your bank is then likely to withhold the vast majority of the cheque’s value for up to 28 days.
• It will cost you several thousand dollars – a deposit and at least one month of rent – to secure an apartment. In general, landlords will not accept a UK banking cheque.
• You’ll have to buy furniture and general household items if you aren’t shipping any from the UK.

All in all, this means you may end up without any significant US-earned money in your account for 30-45 days while making some of the biggest expenses you’re likely to have made for a while.

Transferring money to a US bank account can be done online via wire transfer between banks. Unfortunately, my bank in the UK – Santander – didn’t allow online wire transfers so I had to look for alternatives. You may want to research this prior to leaving the UK!

The Post Office provide a simple, secure, and fee-free service, but a poorer exchange rate. Looking around, I came across Currencyfair – a peer-to-peer currency exchange service. They provide online quotes without the need to sign up, they were very prompt and helpful in their replies to questions I had, and the exchange rate was very good. Overall, I saved quite a bit of money and I’d rely on them in the future.

Get a Clipper card

The Clipper card is San Francisco’s equivalent of London’s Oyster card. Getting one will take some of the pain out of using the various modes of public transport in San Francisco. You can get a Clipper card online and I’d suggest setting up “Autoload” (you’ll need a bank account) to get the card for free and never worry about remembering to top up your credit. Alternatively, you can buy them on the high street from shops like Walgreens.

Get a Social Security Number

Social Security recommend that you only apply for a Social Security Number once you’ve been in the US over 10 days.

My experience was that the process is quick and simple. You complete a short SSN application form ahead of time and take it to the nearest Social Security office along with the documentation they advise you to bring. Arrive first thing in the morning to avoid any wait. It can take a few weeks for your Social Security card to arrive so you may want to have it sent to your employer’s address if you don’t have a permanent address yet.

Once you have your Social Security Card, you should keep it safe and be judicious in giving your SSN out. However, you should provide it to your bank and employer as soon as possible.

Find somewhere to live

Living in the city of San Francisco is just one of the (more expensive) options available to you. I chose to live in the city but many of my friends and colleagues live in other areas, like the East Bay. Have a look around before making up your mind.

Rent is very expensive in San Francisco, even compared to prices in London, especially since it’s very rare to find furnished accommodation. It also appears to be rising at a staggering rate. However, buildings constructed before June 1979 are covered by San Francisco Rent Control which heavily constrains the rate at which your rent can increase once you become a tenant. Therefore, it’s worth taking the time to find somewhere that you could imagine living for a few years.

The rental market is extremely competitive. Many places rely on one-off, brief, herd-style viewings where you’re in the apartment with half a dozen other desperate people at the same time, and more arriving every minute. People hand over all their paperwork and a cash application fee (if applicable) there and then.

Things are made slightly harder because you’re unlikely to have any US credit history, which is something quite important over here. But an offer letter and salary details from a tech company seems to put you in good shape. It’s in your best interest to put together a dossier of papers to provide alongside any application you make. You should include scans of your employer’s offer letter, your visa, and ideally character references from a previous landlord, etc. Print out several copies to take with you to viewings. You might have to pay $30-$40 to make an application (which is meant to cover credit history checks), but I never did.

I found that using Craigslist or a listing aggregator like Lovely was the best way to find apartments for rent in the city. They will also help you to narrow your focus to the neighbourhoods that you’re most interested in (spend some time learning about the city). Before moving to San Francisco, I heard a lot of stories about how it was essential – if you are to have any hope – to be “first” to make contact with the poster of a listing, but my experience was that you’re generally given the date and time of a mass-viewing to attend. This means that making a good impression in person, and having a bit of a chat with your potential landlord or building-manager, is likely to improve your chances and help you make a decision. Be prepared for it to take a while to find an apartment – it took me over a month of searching.

Once you’ve found a place to rent and signed all the paperwork, call PG&E to create an account to pay for your heat and electricity. You can set up e-bills and automatic payments online once your account has been processed. It’s a good idea to sort out an ISP before you move in – I went with Sonic.net. Again, the monthly cost (which I was told includes 17 different taxes and “renting” of the router) is a little higher than you’d expect in the UK, and you can expect to pay an installation fee. Other things to do: get Renters Insurance and have your bank automatically mail out your monthly-rent check to your landlord or building manager. All these things are quick and easy to do.

If you’re interested in your renters rights, you can search the California Department of Consumer Affairs for information.

Buying stuff for your place

You’re going to need furniture and basic household items. There’s always Ikea, which is located in Emeryville across the bay. If you have any previous Ikea experience, you’ll know that it’s one of the most stressful shopping experiences imaginable. The Ikea in Emeryville is even worse but the prices are pretty good. You can get there by bus from San Francisco and have large items delivered, or sort out your own transport.

Other stores to look at include West Elm and Crate & Barrel; they sell nicer things but are significantly more expensive. Alternatively, there are a lot of independent and second-hand furniture shops in San Francisco, particularly in the Mission district and a few along Van Ness. They’re well worth checking out. Van Ness also has 3 or 4 stores that sell mattresses – Sleep Train came particularly well recommended. I’d suggest that you leverage the lower costs of similar mattresses online in order to significantly reduce the price of your purchase, while benefiting from the great service, free delivery, and returns policy of the high-street stores. And if you have no idea what you’re doing: home decor tips, infographics, and cheat sheets

Get a California I.D.

Once you have your SSN and have found a permanent address, you should apply for a California I.D. at the DMV. This is handy if you don’t want to carry your passport (with visa) around and don’t have alternative I.D., such as a driver’s licence. You should register for an appointment to avoid a long wait in line. It can take up to 60 days for your California I.D. to arrive.

Get a credit card

The U.S. revolves around consumer credit. You need to start building up a credit history as soon as possible if you want to avoid paying large deposits or higher prices. Ask your bank about the soonest that you can apply for a credit card and then start using it – buying on credit even if you don’t need to.

Inform HMRC and the Student Loans Company

Once you’re settled, you should make time to inform HMRC that you’ve left the UK. They’ll be able to assess your tax status. If you are repaying student loans, after 3 months in the US you’re expected to contact the Student Loans Company by completing an overseas income assessment form. They will then work out your repayments.

Welcome to the United States of America

Hopefully you settle in within a couple of months and get to know San Francisco. There are many faces to this city, but the social scene is pretty diverse and there are many restaurants, bars, cafes, parks, and attractions – plenty of places to explore and things to do while you find your feet.

For the first time since coming back to San Francisco in January, I had everything I needed for a saunter across the city in the sun: a means of taking photos / videos, a pair of sunglasses, no work, no plans, and no excuse.

On the morning of July 4th, I decided to spend the next couple of days offline. I read a book, and decided to go for a walk the rest of the day. I didn’t have any expectations or intended destination. I left my apartment at 2pm and decided to walk west, as I haven’t spent any proper time on that side of the city.

I passed through a couple of small parks and quiet neighbourhoods before hitting the edge of The Presidio.

At this point, I realised how long it had been since I’d seen a large expanse of something approximating nature. The Presidio was beautifully tranquil, with just a handful of people strolling or running through the trees. Walking off the trails, I saw a lizard for the first time in years; probably a San Francisco Alligator Lizard.

I exited The Presidio somewhere near the golf course and picked a long road to keep walking west.

On the way, I hit a main road and stood at the traffic lights. While I waited a young woman walking her dog struck up the first of several impromptu conversations I had with strangers that day. She must have seen me looking around for the street name, as she asked, “Are you lost? Are you a tourist? Where are you going?”

“I’m not sure. That way”, I said pointing down the long road before us.

She laughed. “See, you are lost!”

We chatted for a few blocks before our paths diverged. She told me that I would find some nice trails, and a good view of the Golden Gate Bridge, in the woodland near Lands End. It was dead ahead for another 30 minutes. So that’s where I went.

I hit the trails at about 4:30pm. It must have been close to perfect weather. Really sunny, warm, only a mild breeze, and the bay was completely clear. I wandered around for over an hour; perching near the edge of cliffs, taking in the sight of the Golden Gate Bridge on my right and a vast expanse of ocean to my left. Such a relaxing place.

I made time for a Dorsey-like Vine (my first Vine)…

On the way back, I crossed a road to take a photo. A post-middle-age man crossed my path, struck up a conversation, and began to tell me about his life in San Francisco “back in the day”. As if he could peer into my soul, he assured me that there was nothing wrong with being a software engineer (although he did initially think I was an estate agent; that was one of the first things he said to me).

My spirits further lifted by a stranger’s validation, I continued home. For last 30 minutes all I could think about was lying down, resting my feet, and eating. I’d been walking for nearly 6 hours. I’ll definitely do it again, but a skateboard would be helpful next time.

Did you know that you can build your own CSS preprocessor with Node.js libraries? They can be used alongside established preprocessors like Sass, and are useful for defining tasks beyond preprocessing.

Libraries like Rework and PostCSS let you create and assemble an arbitrary collection of plugins that can inspect or manipulate CSS.

At the time of writing, Twitter uses Rework to perform various tasks against our CSS source code for twitter.com.

Creating a CSS preprocessor with Rework

At its core, Rework is a module that accepts a string of CSS, produces a CSS abstract syntax tree (AST), and provides an API for manipulating that AST. Plugins are functions that have access to the AST and a Rework instance. Rework lets you chain together different plugins and generate a string of new CSS when you’re done.

The source string is passed into the rework function and each plugin is applied with .use(fn). The plugins transform the data in the AST, and .toString() generates the new string of CSS.

Below is an example of a custom preprocessor script using Rework and Autoprefixer. It’s a simplified version of the transformation step we use for twitter.com’s CSS.

var autoprefixer = require('autoprefixer');
var calc = require('rework-calc');
var rework = require('rework');
var vars = require('rework-vars')();

var css = fs.readFileSync('./css/main.css', 'utf-8');

css = rework(css)
  .use(vars)
  .use(calc)
  .toString();

css = autoprefixer().process(css);

fs.writeFileSync('./build/bundle.css', css)

The script runs rework-vars, rework-calc, and then passes the CSS to Autoprefixer (which uses PostCSS internally) to handle the addition of any necessary vendor prefixes.

rework-vars provides a limited subset of the features described in the W3C-style CSS custom property spec. It’s not a polyfill!

Variables can be declared as custom CSS properties on the :root element, prefixed with --. Variables are referenced with the var() function, taking the name of a variable as the first argument and an optional fallback as the second.

For example, this source:

:root {
  --width-button: 200px;
}

.button {
  width: var(--width-button);
}

yields:

.button {
  width: 200px;
}

There are many different Rework plugins that you can use to create a custom preprocessor. A more complete list is available on npm. In order to limit the chances of long-term divergence between our source code and native CSS, I’ve chosen to stick fairly closely to features that are aligned with future additions to native CSS.

Creating your own Rework plugin

Rework plugins are functions that inspect or mutate the AST they are provided. Below is a plugin that rewrites the value of any font-family property to sans-serif.

module.exports = function plugin(ast, reworkInstance) {
  ast.rules.forEach(function (rule) {
    if (rule.type != 'rule') return;

    rule.declarations.forEach(function (declaration, index) {
      if (declaration.property == 'font-family') {
        declaration.value = 'sans-serif';
      }
    });
  });
};

Rework uses css-parse to create the AST. Unfortunately, both projects are currently lacking comprehensive documentation of the AST, but it’s not difficult to piece it together yourself.

Beyond preprocessing

Since Rework and PostCSS expose an AST and provide a plugin API, they can be used for other CSS tasks, not just preprocessing.

At Twitter, our CSS build pipeline allows you to perform custom tasks at 2 stages of the process: on individual files and on generated bundles. We use Rework at both stages.

Individual files are tested with rework-suit-conformance to ensure that the SUIT-style CSS for a component is properly scoped.

/** @define MyComponent */

:root {
  --property-MyComponent: value;
}

.MyComponent {}

Bundles are preprocessed as previously described, and also tested with rework-ie-limits to ensure that the number of selectors doesn’t exceed IE 8/9’s limit of 4095 selectors per style sheet.

Other tasks you can perform include generating RTL style sheets (e.g., css-flip) and extracting detailed information about the perceived health of your CSS (e.g., the number of different colours used, duplicate selectors, etc.).

Hopefully this has given you a small glimpse into some of the benefits and flexibility of using these tools to work with CSS.

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.

Internet Explorer 9–11 suffer from various bugs that prevent proper scaling of inline SVG’s. This is particularly problematic for SVG icons with variable widths. This is the canvas-based hack I’ve been using to work around the issue.

A popular way to use SVG icons is to generate a spritemap of SVG symbol‘s that you then reference from elsewhere in a document. Most articles on the topic assume your icon dimensions are uniformly square. Twitter’s SVG icons (crafted by @sofo) are variable width, to produce consistent horizontal whitespace around the vectors.

Most browsers will preserve the intrinsic aspect ratio of an SVG. Ideally, I want to set a common height for all the icons (e.g., 1em), and let the browser scale the width of each icon proportionally. This also makes it easy to resize icons in particular contexts – just change the height.

Unfortunately, IE 9–11 do not preserve the intrinsic aspect ratio of an inline SVG. The svg element will default to a width of 300px (the default for replaced content elements). This means it’s not easy to work with variable-width SVG icons. No amount of CSS hacking fixed the problem, so I looked elsewhere – and ended up using canvas.

canvas and aspect ratios

A canvas element – with height and width attributes set – will preserve its aspect ratio when one dimension is scaled. The example below sets a 3:1 aspect ratio.

<canvas height="1" width="3"></canvas>

You can then scale the canvas by changing either dimension in CSS.

canvas {
  display: block;
  height: 2rem;
}

Demo: proportional scaling of canvas.

Fixing SVG scaling in IE

This makes canvas useful for creating aspect ratios. Since IE doesn’t preserve the intrinsic aspect ratio of SVG icons, you can use canvas as a shim. A canvas of the correct aspect ratio provides a scalable frame. The svg can then be positioned to fill the space created by this frame.

The HTML is straightforward:

<div class="Icon" role="img" aria-label="Twitter">
  <canvas class="Icon-canvas" height="1" width="3"></canvas>
  <svg class="Icon-svg">
    <use fill="currentcolor" xlink:href="#icon-twitter"></use>
  </svg>
</div>

So is the CSS:

.Icon {
  display: inline-block;
  height: 1em; /* default icon height */
  position: relative;
  user-select: none;
}

.Icon-canvas {
  display: block;
  height: 100%;
  visibility: hidden;
}

.Icon-svg {
  height: 100%;
  left: 0;
  position: absolute;
  top: 0;
  width: 100%;
}

Setting the canvas height to 100% means it will scale based on the height of the component’s root element – just as SVG’s do in non-IE browsers. Changing the height of the Icon element scales the inner SVG icon while preserving its 3:1 aspect ratio.

Demo: proportional scaling of svg in IE.

Creating an Icon component

The hack is best added to (and eventually removed from) an existing icon component’s implementation.

If you’re generating and inlining an SVG spritemap, you will need to extract the height and width (usually from viewBox) of each of your icons during the build step. If you’re already using the gulp-svgstore plugin, it supports extracting metadata.

Those dimensions need to be set on the canvas element to produce the correct aspect ratio for a given icon.

Example React component (built with webpack):

import iconData from './lib/icons-data.json';
import React from 'react';
import './index.css';

class Icon extends React.Component {
  render() {
    const props = this.props;
    const height = iconData[props.name.height];
    const width = iconData[props.name.width];

    // React doesn't support namespaced attributes, so we have to set the
    // 'use' tag with innerHTML
    const useTag = `<use fill="currentcolor"
                      xlink:href="#icon-${props.name}">
                    </use>`;

    return (
      <span className="Icon">
        <canvas className="Icon-canvas"
          height={height}
          width={width}
        />
        <svg className="Icon-svg"
          dangerouslySetInnerHTML={{__html: useTag}}
          key={props.name}
        />
      </span>
    );
  }
}

export default Icon;

When I introduced this hack to a code base at Twitter, it had no impact on the the rest of the team or the rest of the code base – one of the many benefits of a component-based UI.

Twitter Lite uses Redux for state management and relies on code-splitting. However, Redux’s default API is not designed for applications that are incrementally-loaded during a user session.

This post describes how I added support for incrementally loading the Redux modules in Twitter Lite. It’s relatively straight-forward and proven in production over several years.

Redux modules

Redux modules comprise of a reducer, actions, action creators, and selectors. Organizing redux code into self-contained modules makes it possible to create APIs that don’t involve directly referencing the internal state of a reducer – this makes refactoring and testing a lot easier. (More about the concept of redux modules.)

Here’s an example of a small “redux module”.

// data/notifications/index.js

const initialState = [];
let notificationId = 0;

const createActionName = name => `app/notifications/${name}`;

// reducer
export default function reducer(state = initialState, action = {}) {
  switch (action.type) {
    case ADD_NOTIFICATION:
      return [...state, { ...action.payload, id: notificationId += 1 }];
    case REMOVE_NOTIFICATION:
      return state.slice(1);
    default:
      return state;
  }
}

// selectors
export const selectAllNotifications = state => state.notifications;
export const selectNextNotification = state => state.notifications[0];

// actions
export const ADD_NOTIFICATION = createActionName(ADD_NOTIFICATION);
export const REMOVE_NOTIFICATION = createActionName(REMOVE_NOTIFICATION);

// action creators
export const addNotification = payload => ({ payload, type: ADD_NOTIFICATION });
export const removeNotification = () => ({ type: REMOVE_NOTIFICATION });

This module can be used to add and select notifications. Here’s an example of how it can be used to provide props to a React component.

// components/NotificationView/connect.js

import { connect } from 'react-redux';
import { createStructuredSelector } from 'reselect';
import { removeNotification, selectNextNotification } from '../../data/notifications';

const mapStateToProps = createStructuredSelector({
  nextNotification: selectNextNotification
});
const mapDispatchToProps = { removeNotification };

export default connect(mapStateToProps, mapDispatchToProps);

// components/NotificationView/index.js

import connect from './connect';
export class NotificationView extends React.Component { /*...*/ }
export default connect(NotificationView);

This allows you to import specific modules that are responsible for modifying and querying specific parts of the overall state. This can be very useful when relying on code-splitting.

However, problems with this approach are evident once it comes to adding the reducer to a Redux store.

// data/createStore.js

import { combineReducers, createStore } from 'redux';
Import notifications from './notifications';

const initialState = /* from local storage or server */

const reducer = combineReducers({ notifications });
const store = createStore(reducer, initialState);

export default store;

You’ll notice that the notifications namespace is defined at the time the store is created, and not by the Redux module that defines the reducer. If the “notifications” reducer name is changed in createStore, all the selectors in the “notifications” Redux module no longer work. Worse, every Redux module needs to be imported in the createStore file before it can be added to the store’s reducer. This doesn’t scale and isn’t good for large apps that rely on code-splitting to incrementally load modules. A large app could have dozens of Redux modules, many of which are only used by a few components and unnecessary for initial render.

Both of these issues can be avoided by introducing a Redux reducer registry.

Redux reducer registry

The reducer registry enables Redux reducers to be added to the store’s reducer after the store has been created. This allows Redux modules to be loaded on-demand, without requiring all Redux modules to be bundled in the main chunk for the store to correctly initialize.

// data/reducerRegistry.js

export class ReducerRegistry {
  constructor() {
    this._emitChange = null;
    this._reducers = {};
  }

  getReducers() {
    return { ...this._reducers };
  }

  register(name, reducer) {
    this._reducers = { ...this._reducers, [name]: reducer };
    if (this._emitChange) {
      this._emitChange(this.getReducers());
    }
  }

  setChangeListener(listener) {
    this._emitChange = listener;
  }
}

const reducerRegistry = new ReducerRegistry();
export default reducerRegistry;

Each Redux module can now register itself and define its own reducer name.

// data/notifications/index.js

import reducerRegistry from '../reducerRegistry';

const initialState = [];
let notificationId = 0;

const reducerName = 'notifications';

const createActionName = name => `app/${reducerName}/${name}`;

// reducer
export default function reducer(state = initialState, action = {}) {
  switch (action.type) {
    case ADD_NOTIFICATION:
      return [...state, { ...action.payload, id: notificationId += 1 }];
    case REMOVE_NOTIFICATION:
      return state.slice(1);
    default:
      return state;
  }
}

reducerRegistry.register(reducerName, reducer);

// selectors
export const selectAllNotifications = state => state[reducerName];
export const selectNextNotification = state => state[reducerName][0];

// actions
export const ADD_NOTIFICATION = createActionName(ADD_NOTIFICATION);
export const REMOVE_NOTIFICATION = createActionName(REMOVE_NOTIFICATION);

// action creators
export const addNotification = payload => ({ payload, type: ADD_NOTIFICATION });
export const removeNotification = () => ({ type: REMOVE_NOTIFICATION });

Next, we need to replace the store’s combined reducer whenever a new reducer is registered (e.g., after loading an on-demand chunk). This is complicated slightly by the need to preserve initial state that may have been created by reducers that aren’t yet loaded on the client. By default, once an action is dispatched, Redux will throw away state that is not tied to a known reducer. To avoid that, reducer stubs are created to preserve the state.

// data/createStore.js

import { combineReducers, createStore } from 'redux';
import reducerRegistry from './reducerRegistry';

const initialState = /* from local storage or server */

// Preserve initial state for not-yet-loaded reducers
const combine = (reducers) => {
  const reducerNames = Object.keys(reducers);
  Object.keys(initialState).forEach(item => {
    if (reducerNames.indexOf(item) === -1) {
      reducers[item] = (state = null) => state;
    }
  });
  return combineReducers(reducers);
};

const reducer = combine(reducerRegistry.getReducers());
const store = createStore(reducer, initialState);

// Replace the store's reducer whenever a new reducer is registered.
reducerRegistry.setChangeListener(reducers => {
  store.replaceReducer(combine(reducers));
});

export default store;

Managing the Redux store’s reducer with a registry should help you better code-split your application and modularize your state management.

Using SVG is currently the best way to create icon libraries for apps. Icons built with SVG are scalable and adjustable, but also discrete, which allows them to be incrementally loaded and updated. In contrast, icons built as fonts cannot be incrementally loaded or updated. This alone makes SVG icons the better choice for high-performance apps that rely on code-splitting and incremental deploys.

This post describes how to make a package of React components from a library of SVG icons. Although I’m focusing on React, making any other type of package is also possible. At Twitter I used the approach described here to publish the company’s SVG icon library in several different formats: optimized SVGs, plain JavaScript modules, React DOM components, and React Native components.

Using the icons

The end result is a JavaScript package that can be installed and used like any other JavaScript package.

yarnpkg add @acme/react-icons

Each icon is available as an individually exported React component.

import IconCamera from '@acme/react-icons/camera';

This allows your module bundler to package only the icons that are needed, and icons can be efficiently split across chunks when using code-splitting. This is a significant advantage over icon libraries that require fonts and bundle all icons into a single component.

// entire icon library is bundled with your app
import Icon from '@acme/react-icons';
const IconCamera = <Icon name='camera' />;

Each icon is straightforward to customize (e.g., color and dimensions) on a per-use basis.

import IconCamera from '@twitter/react-icons/camera';
const Icon = (
  <IconCamera
    style={{ color: 'white', height: '2em' }}
  />
);

Although the icons render to SVG, this is an implementation detail that isn’t exposed to users of the components.

Creating components

Each React component renders an inline SVG, using path and dimensions data extracted from the SVG source files. A helper function called createIconComponent means that only a few lines of boilerplate are needed to create a component from SVG data.

import createIconComponent from './utils/createIconComponent';
import React from 'react';
const IconCamera = createIconComponent({
  content: <g><path d='...'></g>,
  height: 24,
  width: 24
});
IconCamera.displayName = 'IconCamera';
export default IconCamera;

This is an example of what the createIconComponent function looks like when building components for a web app like Twitter Lite, which is built with React Native for Web.

// createIconComponent.js
import { createElement, StyleSheet } from 'react-native-web';
import React from 'react';

const createIconComponent = ({ content, height, width }) =>
  (initialProps) => {
    const props = {
      ...initialProps,
      style: StyleSheet.compose(styles.root, initialProps.style),
      viewBox: `0 0 ${width} ${height}`
    };

    return createElement('svg', props, content);
  };

const styles = StyleSheet.create({
  root: {
    display: 'inline-block',
    fill: 'currentcolor',
    height: '1.25em',
    maxWidth: '100%',
    position: 'relative',
    userSelect: 'none',
    textAlignVertical: 'text-bottom'
  }
});

Setting the fill style to currentcolor allows you to control the color of the SVG using the color style property instead.

All that’s left is to use scripts to process the SVGs and generate each React component.

Creating icon packages

A complete example of one way to do this can be found in the icon-builder-example repository on GitHub.

The project structure of the example tool looks like this.

.
├── README.md
├── package.json
├── scripts/
    ├── build.js
    ├── createReactPackage.js
    └── svgOptimize.js
└── src/
    ├── alerts.svg
    ├── camera.svg
    ├── circle.svg
    └── ...

The build script uses SVGO to optimize the SVGs, extract SVG path data, and extract metadata. The example packager for React then uses templates to create a package.json and the React icon components shown earlier.

import createIconComponent from './utils/createIconComponent';
import React from 'react';
const ${componentName} = createIconComponent({
  height: ${height},
  width: ${width},
  content: <g>${paths}</g>
});
${componentName}.displayName = '${componentName}';
export default ${componentName};

Additional packagers can be included to build other package types from the same SVG source. When the underlying icon library changes, it only takes a couple of commands to rebuild hundreds of icons and publish new versions of each package.

The previous night, they had called up relatives in Madhya Pradesh to say they were in a helpless state

43 cases from Ganjam district; State’s total mounts to 271

TrueNat machines will be used for the first time in the State for virus screening

"We don’t want anything from the government. We just want to be dropped home," says a migrant worker from Chhattisgarh.

‘U.P. government crushing their rights’

The Centre said it feared that the order may have a “cascading effect” on migrants of other States as well

Material brought illegally in vehicles that had permission to carry fruits and vegetables

Court wants decision on levying costs for transport of migrant workers

This has been the highest spike in the number of cases in the State in a single day, taking the number of cases to 1,678