
<Image
  publicId="external-references/fullstack-dev-article-aquent/cover"
  alt="Article screenshot: What the Heck is a Fullstack Developer? Aquent UK blog"
/>

An interview with my former employer (and parent company of [Gymnasium](https://www.thegymnasium.com/)), [Aquent](https://aquent.com) about my thoughts on what it means to be a Fullstack Developer.

Description from the article:

<Aside>
  To shed light onto what is for many a mysterious role—Full Stack Developer—we
  talked to our own Star of the Full Stack, Mike Bifulco. Currently the Director
  of Technology for Aquent Gymnasium, he was previously a User Experience Lead
  and Program Manager at Microsoft.
</Aside>

Full article is available to read on [Aquent UK's blog](https://aquent.co.uk/blog/what-the-heck-is-a-full-stack-developer).


What the Heck is a Fullstack Developer? Aquent UK

## What does .filter(Boolean) do on Arrays?

This is a pattern I've been coming across quite a bit lately in JavaScript code, and can be extremely helpful once you understand what's going on. In short, it's a bit of [functional programming](https://mikebifulco.com/tags/functional-programming) which is used to remove `null` and `undefined` values from an array.

```js
const values = [1, 2, 3, 4, null, 5, 6, 7, undefined];

console.log(values.length);
// Output: 9

console.log(values.filter(Boolean).length);
// Output: 7

// note that this does not mutate the value original array
console.log(values.length);
// Output: 9
```

## How does the Boolean part of .filter(Boolean) work?

We're using a function built into arrays in JavaScript, called [Array.prototype.filter](https://developer.mozilla.org/en-US/docs/web/javascript/reference/global_objects/array/filter), which _creates a new array_ containing all elements that pass the check within the function it takes as an argument. In this case, we're using the JavaScript `Boolean` object wrapper's constructor as that testing function.

`Boolean` is a helper class in JavaScript which can be used to test whether a given value or expression evaluates to `true` or `false`. There's a subtle, but **really important point** here - `Boolean()` follows the JavaScript rules of _truthiness_. That means that the output `Boolean()` might not always be what you imagine.

In this context, passing `Boolean` to `.filter` is effectively shorthand for doing this:

```js
array.filter((item) => {
  return Boolean(item);
});
```

which is also approximately the same as

```js
array.filter((item) => {
  return !!item; // evaluate whether item is truthy
});
```

or, simplified


```js
array.filter(item => !!item)
```


I suspect that you may have seen at least one of these variations before. In the end, `array.filter(Boolean)` is just shorthand for any of the other options above. It's the kind of thing that can cause even seasoned programmers to recoil in horror the first time they see it. Near as I can tell, though, it's a perfectly fine replacement.

### Examples of Boolean evaluating for _truthiness_


```js
// straightforward boolean
Boolean(true)   // true
Boolean(false)  // false

// null/undefined
Boolean(null)       // false
Boolean(undefined) // false

// hmm...
Boolean(NaN)  // false
Boolean(0)    // false
Boolean(-0)   // false
Boolean(-1)   // true

// empty strings vs blank strings
Boolean("")   // false
Boolean(" ")  // true

// empty objects
Boolean([]) // true
Boolean({}) // true

// Date is just an object
Boolean(new Date()) // true

// oh god
Boolean("false")                     // true
Boolean("Or any string, really")     // true
Boolean('The blog of Mike Bifulco')  // true
````



## Warning: Be careful with the truth(y)

So - `someArray.filter(Boolean)` is really helpful for removing `null` and `undefined` values, but it's important to bear in mind that there are quite a few confusing cases above... this trick will remove items with a value of `0` from your array! That can be a significant difference for interfaces where displaying a `0` is perfectly fine.

**EDIT: ** Hi, Mike from The Future™️ here - I've edited the next paragraph to reflect the _actual_ truth... I had confused `-1` with `false` from my days as a BASIC programmer, where we'd sometimes create infinite loops with `while (-1)`... but even that means "while `true`"!

I also want to call some attention to cases that evaluate to `-1`. <s>for _many_ programmers, `-1` is synonymous with `false`, because that is _absolutely_ the case in many langauges... but not here.</s> The `-1` case can also be unintuitive if you're not expecting it, but true to form, in JavaScript, `-1` is a truthy value!

## Array.filter(Boolean) For React Developers

I tend to come across this pattern being used fairly often for iterating over collections in React, to clean up an input array which may have had results removed from it upstream for some reason. This protects you from scary errors like `Can't read property foo of undefined` or `Can't read property bar of null`:

```jsx

const people = [
  {
    name: 'Mike Bifulco',
    email: 'hello@mikebifulco.com',
  },
  null,
  null,
  null,
  {
    name: "Jimi Hendrix",
    email: 'jimi@heyjimihimi@guitarsolo',
  }
]

// display a list of people
const PeopleList = ({people}) => {
  return (
    <ul>
      {people.map(person) => {
        // this will crash if there's a null/undefined in the list!
        return (
          <li>{person.name}: {person.email}</li>
        );
      }}
    </ul>
  );
}

// a safer implementation
const SaferPeopleList = ({people}) => {
  return (
    <ul>
      {people
        .filter(Boolean) // this _one weird trick!_
        .map(person) => {
          return (
            <li>{person.name}: {person.email}</li>
          );
        }
      }
    </ul>
  );
}
```

## Functional Programming reminder

Like I mentioned above, this is a handy bit of functional programming -- as is the case with nearly all clever bits of functional programming, it's important to remember that we're not _mutating_ any arrays here - we are creating new ones. Let's show what that means in a quick example:

```js
const myPets = [
  'Leo',
  'Hamilton',
  null,
  'Jet',
  'Pepper',
  'Otis',
  undefined,
  'Iona',
];

console.log(myPets.length); // 8

myPets
  .filter(Boolean) // filter null and undefined
  .forEach((pet) => {
    console.log(pet); // prints all pet names once, no null or undefined present
  });

console.log(myPets.length); // still 8! filter _does not mutate the original array_
```

## Wrapping up

Hopefully this has helped to demystify this little code pattern a bit. What do you think? Is this something you'll use in your projects? Are there dangers/tricks/cases I didn't consider here?

Tell me all about it on twitter <a href="https://twitter.com/irreverentmike">@irreverentmike</a>. Thanks for reading!

_note: Cover photo for this article is from <a href="https://unsplash.com/@pawel_czerwinski?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Pawel Czerwinski</a> on <a href="https://unsplash.com/s/photos/array?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>_

JavaScript Tips: Using Array.filter(Boolean)


If you're a user of Visual Studio Code, you may find that over time it feels like new IDE windows are slow to load. In my experience, loading an environment from a cold start (firing up VS Code when it isn't running at all), or opening a window for a new project (`File >> New Window`) when Code is already running tend to take about the same amount of time.

This is notably different from opening a new tab within the IDE - again, in my experience, once Code is up and running, new tabs take almost no time to fire up.

## Why is it slow?

In its most basic form VS Code is fairly performant - a fresh install of the IDE opens very quickly. Over time, if you're anything like me, you've probably installed any number of community-built [extensions from the VS Code Marketplace](https://marketplace.visualstudio.com/VSCode)

## The Solution

Well, the good news is that this one is exactly as easy as it sounds - you can gain quite a bit of startup performance by **removing unused and unnecessary extensions from VS Code**, by opening your Extensions pane (`Shift + command + X` on a mac, likely `control + shift + X` on Windows/Linux), and typing `@installed` into the search bar at the top of the list to see which extensions are currently installed. In my case, it looks like this:

<Image
  publicId="posts/make-vs-code-load-faster-by-removing-extensions/vscode-extensions-pane"
  alt="VS Code Extensions pane highlighted in red"
  caption="My installed extensions pane, highlighted in red"
/>

Extensions with particularly long load times will have their "Activation Time" highlighted in this list. It's currently shown in the upper-right corner of the extension list item with a load time in milliseconds listed next to it:

<Image
  publicId="posts/make-vs-code-load-faster-by-removing-extensions/extension-load-time"
  alt="VS Code Extensions pane highlighted in red"
  caption="My installed extensions pane, highlighted in red"
/>

## How to remove extensions with long activation times from Visual Studio Code

1. Scan through your list of installed extensions, and remove any you don't use
2. If there are remaining extensions which have high activation times listed, consider whether there's better options available (and install those!)
3. If there aren't better options available, you'll either need to live with the load time for a given extension, or choose to bid it farewell. Worth noting here: these extensions are (generally) open-source, so you may want to visit the repo for that extension and [search for "activation time"](https://github.com/prettier/prettier-vscode/issues?q=activation+time) to see if anyone else is running into the same problem. If not, you might want to open an issue and let the maintainers of that extension know you're having trouble, or open a PR if you have a solution to offer up.

...and that should do ya! If you're still running into performance issues after this, it could be any number of things. Are you running out of disk space on your computer? Maybe you're running out of available RAM? Are you running other applications that slow your machine down?

Additionally, if you're a JavaScript or Node app developer, you may want to check out my article on [Reclaiming Disk Space from `node_modules`](https://mikebifulco.com/posts/reclaimed-10gb-of-disk-space-from-node-modules).

I hope this helps! Feel free to share it with a friend if you found it useful.

This post was inspired by a tweet I let fly recently after playing with load times in [Visual Studio Code](https://code.visualstudio.com/):

<Tweet
  tweetLink="https://twitter.com/irreverentmike/status/1454054616027574283"
  align="center"
/>

_note: Cover photo for this article is from by <a href="https://unsplash.com/@loic?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Djim Loic</a> on <a href="https://unsplash.com/s/photos/time?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>._


How to make VS Code load faster with a little bit of housekeeping


import CenteredTextDemo from '../../components/demos/CenteredTextDemo';

<Aside type="note">

This is an experimental post, meant to demonstrate to you the topic we're discussing. I'd love to hear what you think about it. [Drop me a line](https://twitter.com/irreverentmike) if you find this compelling - I'm hoping to create more like it!

</Aside>

<CenteredTextDemo>

This is -- without exception -- my biggest design-related pet peeve. You've probably come across it yourself from time to time, and if you're lucky, it's not something you noticed. Centering text on a web site, email, or flyer is an easy way to make it appear like a designer's spin has been put on a document. It's an easy change to make in most editors, and in many cases it's probably done without a second thought.

I'll cut to the chase: _center-aligning text is really bad_ in most cases. From a young age, we're trained to read text by starting at the beginning of the line and moving our eyes across the page to the end of the line. From there, it's a relatively low-effort thing to move your eyes back to the beginning of the next line. That all changes when text is centered, since the start of each line is aligned inconsistently. It takes more effort to find the beginning of the next line, to make sure you've only moved down _one_ line, and to continue reading.

## Three great reasons you shouldn't center-align text:

1. A ragged leading-edge makes it harder to move your eyes to the next line of text
2. People with dyslexia may find centered text challenging to read.
3. Lists (like this one) become disorienting to read, and harder to scan

The British Dyslexia Association provides a <a href="https://www.bdadyslexia.org.uk/advice/employers/creating-a-dyslexia-friendly-workplace/dyslexia-friendly-style-guide" target="_blank">dyslexia-friendly style guide</a>, which calls out a simple rule for text:

<Aside type="note">Left align text, without justification.</Aside>

As a designer, this is _such_ an easy win. As a developer, it's often as easy as:

```css
/* change this */
.some-style-rule {
  text-align: center;
}

/* ...to this! */
.some-style-rule {
  text-align: initial;
}
```

## When you _can_ use centered-text

Generally speaking, if you're certain that your text will fit on _one line,_ it may be okay to center it. This generally applies to page titles, captions on pictures, and things of that nature. Even then, generally speaking my guidance is to avoid it. Like many other things in design, if there's not a good reason _to_ do it... you're better without.

## Summary

If you're working on a design that relies on centered text, consider other options. If you come across a big blob of centered text in your workplace, or out in the world somewhere, please feel free to use this post as a demo.

</CenteredTextDemo>


Don't center align paragraph text


As of _this very post,_ I've added support for [MDX](https://www.gatsbyjs.org/docs/mdx/plugins/) to my site. It should make writing new content _much_ easier for me. By removing lots of process that has proven unnecessary, I'll be able to get back to writing more here, an I'm very excited about that.

And it works great! Here's an example of a custom shortcode I wrote, called `<Aside />`:

<Aside>These can be used to highlight important things.</Aside>

And the relevant code for Aside:

```jsx {1,3}
const Aside = (props) => {
  const theme = useTheme();
  return (
    <Box
      borderLeft="8px solid"
      padding="1rem 0 1rem 2rem"
      borderColor={theme.colors.pink[400]}
      backgroundColor={theme.colors.pink[50]}
      margin="2rem 0 2rem 0rem"
      {...props}
    />
  );
};
```

Its use is fairly simple, too -

```jsx
<Aside>These can be used to highlight important things.</Aside>
```

# h/t

This is on the heels of last night's [Reactadelphia Meetup](https://www.meetup.com/Reactadelphia/), where a very talented developer named [Prince](https://prince.dev/) gave a fantastic talk on MDX. I found it particularly inspiring -- it was that rare talk which had substance _and_ motivation. I already had a pretty good grasp of what one might use MDX for in practice, but Prince made some great points about why MDX is such a game changer.


MDX - I should have done this sooner


This morning, I fully switched my personal site from Google Analytics to [Fathom](https://usefathom.com/) - something that I had been considering for a while, and finally decided to go all in on.  Thanks to my colleagues [@andrewpmiller](https://twitter.com/andrewpmiller) and [@jeremias](https://twitter.com/jeremias) for planting this seed months ago - I'm glad I finally made the switch.

## What is Fathom?

In their words, Fathom is "simple analytics for website owners & businesses".  Near as I can tell, that's a perfect distillation of what they've built.  Fathom provides an easily digestible single page analytics view of your site's traffic.

It's a service that rids you of some of the heft of having Google watch you and your users' every move.  They're open and transparent about being [Privacy First](https://usefathom.com/privacy) - something which has long since melted away from Google's ethos.

In addition to giving you information about the traffic coming and going from your web property, fathom also lets you set goals for your site traffic - so that you can keep an eye on performance of what matters to you.  Maybe you want to see how many people are visiting your "about me" page, or track newsletter subscriptions -- with Fathom, it's a straightforward javascript call to make that happen.

## Why Fathom?

For me, the functionality it provides is perfect - [my personal site](https://mikebifulco.com) is slowly growing in traffic, which is great! I had been using Google Analytics to keep an eye on my site's traffic, but honestly - I spent a disproportionate amount of time getting lost in all of the bells and whistles of GA.  That time wasn't giving me more usable insight... I was just getting lost in the tool.

I also love the idea of Privacy First tooling, which Fathom hits out of the park.  When you visit my site, I'm not keeping any of your PII, or doing anything creepy with your browsing behavior.  I just want to know how various articles perform, so that I can make better decisions about what to write in the future.

Another benefit was the install process - getting Fathom set up was a breeze. You may know that my site is built on [Gatsby](https://gatsbyjs.org/) - it turns out there's a reasonably well-featured [plugin for gatsby](https://github.com/lgraubner/gatsby-plugin-fathom) created by a member of the community. In addition to that, they're reportedly shipping their own plugin in the next few weeks. 


<Tweet tweetLink="usefathom/status/1256954976238055424" align="center" />

<Aside>
  Note: it looks like in the coming weeks, Fathom will be providing their own Gatsby plugin!
</Aside>

## Looking for a free option?

**Fathom also has a self-hosted product** called "[fathom lite](https://github.com/usefathom/fathom)" which you can run yourself if you want to use their service for free.  It isn't as full-featured as full blown fathom, but it will give you a good idea of what you're in for.  I set it up on Heroku (using [these instructions](https://gist.github.com/gmolveau/78f88af3f5951ba6e093f93a07caa302)) for a few weeks before deciding to take the plunge and pay for Fathom's SaaS service.

## Try it yourself!

Thinking about giving it a whirl? One of the perks of being a Fathom customer is their affiliate program - you can use my link to [sign up for Fathom](https://usefathom.com/ref/DPSSYB) for a $10 discount on your first invoice.  Sweet!






Why I switched to Fathom for analytics


So, like all good things, the idea for this post comes from a tweet:

<Twitter tweetLink="irreverentmike/status/1141169316273897536" />

This is something I've been ruminating on for a bit.  I've even tried to build it - a few times! I keep starting in on the work and getting lost in the millions of directions I could take it. 

Here's what I'd like: When I publish a new post to [my gatsby site](https://mikebifulco.com) (you're on it now!), I'd like for that post to appear on [dev.to](https://dev.to) automatically.

## It should:

- recreate my post verbatim, from its original markdown source
- use the `canonical_url` frontmatter field to make sure I retain SEO goodness on my post
- happen without my intervention
- be agnostic of where my posts are coming from.  I use [takeshape.io](https://takeshape.io) as a headless CMS for my site, so my individual posts aren't in source control
- only take posts from my `master` branch, since I use feature branches for draft posts from time to time
- use the [dev.to API](https://dev.to/api), of course

## Nice to have:

- maybe posts should be set to `published: false` at first, so I can preview/review/update them as needed for dev.to?

## Possible approaches for this:

1. Tap into GitHub's webhooks somehow, and fire off a post here 
1. Come from a job kicked off after CI, maybe? I use CircleCI, but would like this feature to be fairly implementation agnostic.
1. Use a [GitHub App](https://developer.github.com/v3/apps/)?
1. ...or a [GitHub Action](https://github.com/mbifulco/thepraticaldev-crosspost-action)?
1. Perhaps just a lamba function deployed to AWS or [Netlify Functions](https://functions.netlify.com/).

So - here's where I ask for your help.  Surely there's a simple approach here I haven't thought of, or maybe it's a matter of collecting a few scenarios and building something based on 80/20.

What else am I missing here? I'd love your help.  What use cases would you have for a cross-poster from your gatsby site? How would you implement it? How can we help each other?



Do you have your own Gatsby site? Let's brainstorm a dev.to cross-poster



This is a follow-up to my [first post](https://mikebifulco.com/solve-all-your-problems-with-promise-allsettled) on the upcoming `Promise.allSettled()` function, coming soon to a node application near you. 

Earlier today I was greeted by a [Pull Request](https://github.com/mbifulco/blog/pull/14) on my first post from GitHub user `@j-f1`.  

  
<Image
  publicId="posts/promise-all-settled-pt-2-its-partly-settled/pr"
  alt="Screenshot of a github pull request on my last blog post"
  caption="PR on my last post, showing how to use Promise.allSettled() now!"
/>

It turns out there _is_ a handy way to add `Promise.allSettled()` to your apps _right now!_ 🎉.  It's fiendishly simple to use, too.

## **The core-js npm package**

That's right - [core-js](https://github.com/zloirock/core-js).  From their `README.md`, it is exactly what it sounds like:

<Aside>

  It is a polyfill of the JavaScript standard library, which supports:  
  - The latest ECMAScript standard.  
  - ECMAScript standard library proposals.  
  - Some WHATWG / W3C standards (cross-platform or closely related ECMAScript).  

  It is maximally modular: you can easily choose to load only the features you will be using.  
  It can be used without polluting the global namespace.  
  It is [tightly integrated with `babel`: this allows many optimizations of `core-js` import.](https://github.com/zloirock/core-js/blob/master/docs/2019-03-19-core-js-3-babel-and-a-look-into-the-future.md#Babel)

</Aside>

[Looking further down in the readme](https://github.com/zloirock/core-js/blob/master/docs/2019-03-19-core-js-3-babel-and-a-look-into-the-future.md#Babel), there's a list of supported features in the polyfill:

<Aside>

  [Promise.allSettled](https://github.com/tc39/proposal-promise-allSettled) stage 2 proposal

</Aside>

Well hot damn! That'll do it! 

## **How to use core-js**

As `@j-f1` indicated, in any project that uses `babel` as a transpiler, all you need to do is add core-js to your project, and include it at your app's entry point:

First, add the dependency to your project

```bash
    > yarn add core-js
```

Then, at your app's entry point (usually something like `index.js`, or `app.js` in the root of your project):

```js
  import 'core-js';
```

or, if you want to include _just_ the `Promise.allSettled()` polyfill, and nothing else, use:

```js
  import 'core-js/proposals/promise-all-settled';
```

That's it! 🍻

Promise.allSettled() Pt.2 - it's partly settled!


Note: this is a follow-up to my [first post](https://mike.biful.co/deconfusing-javascript-destructuring-syntax) on destructuring.  Import syntax uses destructuring pretty liberally, and it can be really confusing for folks who are new to using it. Give my other article a read first if this all seems confusing!

Let's talk about importing dependencies into your node projects.  As your work gets more complex, you will inevitably come across syntax like this:

```js
  import React, { useState, useEffect } from 'react';
  import { Link } from 'gatsby';
  import Button from '@material-ui/core/Button';
  import moment from 'moment';
  ​
  import { Layout } from '../components';
```

At first glance, it's pretty straightforward.  We're importing a handful of bits to use in a React component.  As you might imagine, though, I've selected these four lines of code because each one is unique.  In fact, during my journey as a blossoming Node/React developer, I've found ways to mess up _every single one_ of these.  

You're gonna mess this stuff up, too, and that's perfectly fine! For now, I'm here to help.

We're going to look through each one of these, in order of complexity, and I'll do my best to explain what the hell is going on, and the way I think about imports as I work.

## **Straightforward import syntax - the easiest case**

```js
  import moment from 'moment';
```

If you've worked in .Net languages, or Python, or Ruby, or one of many other languages under the sun, this should be second nature to you.  I'm calling it out here specifically because some of us may never have seen it before.

### **What's going on here?**

Well, it turns out it's pretty easy.  [moment](https://www.npmjs.com/package/moment) is a JavaScript library, which has been included in our node project's `package.json` file's `dependencies` or `devDependencies`.  If you're new to node and are unfamilar with `package.json`, read more about it [here](https://nodesource.com/blog/the-basics-of-package-json-in-node-js-and-npm/).

This line of code creates a reference to everything made available in the `moment` library, and puts it into what is effectively a variable that we can use to access it.  the `'moment'` bit (in quotes) is what tells the compiler which library to get.  The other one, `moment` (_not_ in quotes) is the variable.  So from here in, we can access moment just like any other variable in this file:

```js
  import moment from 'moment';
  console.log(
    moment().get('year')
  );
  // 2019
```

### **The un-obvious bit**

Behind the scenes, this is just taking everything that is made available by the `moment` library through `export default` [in its main file](https://github.com/moment/moment/blob/develop/src/moment.js#L95) , and stuffing it into a variable - and that variable can have _any valid name_ we want!  

It may be confusing, but you absolutely could do this, if the this name made more sense to you:

```js
  import ThatReallyUsefulDateLibrary from 'moment';
  console.log(
    ThatReallyUsefulDateLibrary().get('year')
  );
  // 2019
```

## **Importing a component from somewhere within a library** 

Next up - this slightly more complex beast:

```js
  import Button from '@material-ui/core/Button';
```

Here we're grabbing the `<Button />` component from the [@material-ui library](https://material-ui.com). Again, this is fairly straightforward - but it may be helpful to think of this in terms of the structure of the material-ui project.  Material-ui exports _loads_ of great stuff, and it's all organized into logical groupings.  Think of it a bit like this:

```js
  // material-ui exports
  const muiExports = {
    core: {
      Button: () => {}, // some component
      TextField: () => {} // another useful component
      // and loads more
    }
  }
```

With the import syntax for `Button` above, we're telling the compiler to give us a reference to the exported thing called `Button`, which is found in the `@material-ui` library under `/core/Button`.  The compiler essentially treats this like the JSON object in the snippet above.

Here's the thing - that _also_ means we can destructure it! 😁. This syntax would also work to import `Button`:

```js
  import { Button } from '@material-ui/core';
```

That also means we can import _multiple things_ from `/core` in a single line!

```js
  import { Button, TextField} from '@material-ui/core';
```

Cool, huh? I know this can be confusing, but try to stick with it.  It'll all start to make sense to you before long.  This brings us to our next example:

### **Importing a subset of a library by way of destructuring**

```js
  import { Link } from 'gatsby';
```

Boom! This should be easy by now.  One of the things that `Gatsby` makes available is their [`link`](https://www.gatsbyjs.org/docs/gatsby-link/) component.  We're importing _just that component_ to use here.

### **Renaming an import**

But what if we already have a component called `Link` in our project? Or, what if we're making a Legend of Zelda fan-site, and `Link` is already defined in a component or variable that we can't rename?  Well, it turns out renaming something in an import is as easy as renaming something in a destructured statement.   We can rename the same component from `gatsby` like this:

```js
  import { Link as GatsbyWebLink } from 'gatsby';
```

We can also rename _one or many destructured imports_ in a single statement:

```js
  import { 
    Link as GatsbyWebLink,
    graphql as graphqlQuery,
    useStaticQuery
  } from 'gatsby';
```

Piece of cake! 🍰

## **Relative imports**


One more quick thing - the compiler knows to look for something _you_ exported if you use a _relative path_ in your import location string:

```js
  import { Layout } from '../components';
```

Just like anywhere else, you can combine and rename things to your heart's content here:

```js
  import {
    Layout,
    Button as SuperButton
  } from '../components';
```

## **Putting it all together**


The best isn't alway last, but this is certainly the last example I've got to share today:

```js
  import React, { useState, useEffect } from 'react';
```

If you've been playing along at home, this should all be familiar now - we're grabbing the default export from `react`, which we've put into the variable `react`.  We also destructured `useState` and `useEffect` from _the same library_.  If you're asking yourself "Well couldn't we also access `useState` as a child of `React`"? The answer is - well, actually, yeah!

This is perfectly valid

```js
  const [loading, setLoading] = React.useState(false);
```

… but it's not as nice to type or to read as 

```js
  const [loading, setLoading] = useState(false);
```

They're both equally functional from an execution standpoint, but the latter is used by convention.

## **I think that's it.**

I think.  It turns out this was a really tricky post to write - there's a billion ways to import a file, and there's probably loads of cases I've missed here.  There are _definitely_ also performance and bundle size implications for some of the varieties of import syntaxes shown here.  While they're absolutely real constraints, and have real implications on your app's performance, I left that discussion for another day - purely for the sake of simplicity.

There's also the not-so-small matter that using [import](https://caniuse.com/#feat=imports) requires a transpiler like Babel or Webpack right now.  That's another super-complex universe that I'm not sure i'm equipped to explain in a single blog post.  This also means I've skipped showing how any of the above syntax works with `require()`.  There's frankly an exhausting amount to explain here - future improvements to EcmaScript and node will make it all better.

## **Say hi!**

As always, if I've gotten anything wrong here, I'd love to know about it! Drop me a line [@irreverentmike](https://twitter.com/irreverentmike).  I'd love to hear from you. 👋

Picking apart JavaScript import syntax


(Note: This post was inspired by a talk from [Wes Bos](https://twitter.com/wesbos) at JAMstack_conf_nyc. Thanks for the tip, Wes!)

Of late, I've found myself building JavaScript web applications with increasing complexity. If you're familiar with modern JavaScript, you've undoubtedly come across [`Promise`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) - a construct which helps you execute code asynchronously. A `Promise`  is just what it sounds like: you use them to execute code which will (promise to) return a value at some point in the future:

Check out this somewhat-contrived example, wherein we asynchronously load comments on a blog post:

```js
  const loadComments = new Promise((resolve, reject) => {
    // run an asynchronous API call
    BlogEngine.loadCommentsForPost({ id: '12345' })
      .then(comments => {
    // Everything worked! Return this promise with the comments we got back.
    resolve(comments)
      })
      .error(err => {
    // something went wrong - send the error back
    reject(new Error(err))
      })
  })
```

There's also an alternative syntax pattern, `async` / `await`, which lets you write promises in a more legible, pseudo-serial form:

```js
  const loadComments = async () => {
    try {
      const comments = await BlogEngine.loadCommentsForPost({ id: '12345' })
      return comments
    } catch (err) {
      return new Error(err)
    }
  }
```

## Dealing with multiple promises

Inevitably, you'll find yourself in situations where you need to execute multiple promises. Let's start off simply:
```js
  const postIds = ['1', '2', '3', '4', '5'];
  postIds.each((id) => {
    // load the comments for this post
    const comments = await loadComments(id);

    // then do something with them, like spit them out to the console, for example
    console.log(`Returned ${comments.length} comments, bru`);
  })
```

Easy! A quick loop gets us comments for every post we're interested in. There's a catch here, though - the `await`  keyword will stop execution of the loop until `loadComments`  returns for each post. This means we're loading comments for each post _sequentially_, and not taking advantage of the browser's ability to send off multiple API requests at a time.

The easiest way to send off multiple requests at once is wit `Promise.all()`. It's a function which takes an _array of_ `_Promise_`_s_, and returns an array with the responses from each promise:

```js
  const postIds = ['1', '2', '3', '4', '5'];
  const promises = postIds.map(async (id) => {
    return await loadComments(id);
  };

  const postComments = Promise.all(promises);

  // postComments will be an Array of results fromj the promises we created:
  console.log(JSON.postComments);
  /*
  [
    { post1Comments },
    { post2Comments },
    etc...
  ]
```

There is **one important catch (lol)** with `Promise.all()`. If _any_ of the promises sent to `Promise.all()` fails or `reject`s,  *everything*  fails. From the \[MDN Web Docs\](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global\_Objects/Promise/all) (emphasis mine):

> The `Promise.all()`  method returns a single `Promise`  that resolves when all of the promises passed as an iterable have resolved or when the iterable contains no promises. **\*\*It rejects with the reason of the first promise that rejects.\*\***

Well damn, it turns out that `Promise.all()`  is fairly conservative in its execution strategy. If you're unaware of this, it can be pretty dangerous. In the example above, it's not great if loading comments for _one post_ causes the comments for _every post_ not to load, right? Damn.

## **Enter** `**Promise.allSettled()**` 

Until fairly recently, there wasn't a spectacular answer for scenarios like this. \_\_However\_\_, we will soon have widespread access to [`Promise.allSettled()`](https://github.com/tc39/proposal-promise-allSettled), which is currently a Stage 3 proposal in front of the ECMAscript Technical Committee 39, the body in charge of approving and ratifying changes to ECMAscript (aka "JavaScript", for the un-initiated).

You see, `Promise.allSettled()`  does exactly what we'd like in the example above loading blog comments. Rather than failing if _any_ of the proments handed to it fail, it waits until they all finish executing (until they all "settle", in other words), and returns an array from each:

(this code sample is cribbed from the github proposal - go give it a look for more detail)

```js
  const promises = [fetch('index.html'), fetch('https://does-not-exist/')]
  const results = await Promise.allSettled(promises)
  const successfulPromises = results.filter(p => p.status === 'fulfilled')
```

## **Using** `**Promise.All()**` ** now (updated!)**

**4/26/19 Update:**

Install the [`core-js`](https://github.com/zloirock/core-js) package and include this somewhere in your codebase:

```js
  import 'core-js/proposals/promise-all-settled'
```

**Original post:**

Ok, here's the thing - that's the tricky part. I wrote this post thinking it'd be as easy as telling you to use a `stage-3` preset in the `.babelrc` config on your project. As it turns out, as of v7, Babel has [stopped publishing stage presets](https://babeljs.io/blog/2018/07/27/removing-babels-stage-presets)! If that means anything to you, you ought to read their post.

The answer right now is that it's _not_ yet a great idea to use `Promise.allSettled()`, because it isn't widely supported. To boot, as far as I can tell, there's not a babel config extension which will add support to your projects. At the moment, the best you'll get is a polyfill or an alternative library which implements `allSettled()`.

I know that can be disappointing - be sure that I've got a dozen problems that would be well-served with this new bit of syntax. What I want you to focus on, though, is how amazing it is that JavaScript is continuing to grow. It's exciting and really freaking cool to see that these additions to the language are also being worked on in [public](https://github.com/tc39/proposal-promise-allSettled). Open Source is such a beautiful thing!

If you're really motivated to use `Promise.All()`  in your code, you'd do well to contribute to the process in some way. This may be something as small as writing your own polyfill, or giving feedback to the folks involved with tc39, or one of the alternative libraries to use.

## Footnote

I'll do my best to keep this post up to date. When `allSettled` is released, I'll let y'all know. 👍


Solve* all your problems with Promise.allSettled()


## I really don't like my laptop.

I've been using a 2017 Macbook Pro for the past couple years.  As I'm sure you've heard, it is a fiercely disappointing device largely due to its courageous lack of ports, flawed keyboard design, and astonishing sticker price.  My personal machine is a 13" version, with 16GB of memory, _no_ touchbar, and a 256GB SSD. When I bought it, upgrading to 16GB of memory seemed far more important splurging on processor speed or disk space.  That's probably still true - but I've found myself endlessly frustrated by the tiny capacity of the SSD in my day to day work.

Roughly once every 6 weeks, my machine grinds to a halt as I run out of disk space, so I have to suffer through all the usual suspects for clearing up some room:

*   empty the trash
*   delete unused applications
*   make sure all my photos are moved to my NAS, cloud storage, and offsite archives
*   remove old virtualbox VM images

## A new kind of purge

Last week, however, I came across a surprising new way to free up some disk space: clearing out `node_modules` directories.  

Curiosity hit me, and I searched my mac for folders named `node_modules`. This is what I found:

*   My machine has `7,731` _total_  `node_modules` folders.  Wow!
*   Under `~/src/**`, where I keep all of my dev projects, I had a grand total of 7,719 `node_modules`
*   These folders contain _hundreds of thousands of files_ (which should be no surprise), and took up nearly **10GB** of disk space!

## Turtles all the way down 🐢🐢🐢

That last number was a bit of a revelation to me at first.  If you're unfamiliar, `node_modules` contains a copy of each of the [npm packages](https://npmjs.com) which you add to your project (with `npm install` or `yarn add`, etc) on projects which use node.  Each of them are pinned to a specific version, which is typically specified in `package.json`.  

Somewhat logically, each of the dependencies in your project's `node_modules` directory may also have a `node_modules` directory, containing their dependencies, each pinned to a specific version (again, defined in the `package.json` file of that dependency).  

This is where file and disk space bloat happen - the libraries you add to your project may each contain dozens of dependencies, each of which have dozens more, etc etc, all the way down to super basic node and C libraries which make up the fundamental building blocks of node.

(Mind you - This is oversimplifying things a bit - depending on how you set up `npm` or `yarn` , there is _some_ optimization done here. If one version of a given npm module is required more than once by your dependency tree, it may only appear once.)

## The fix

Actually, this was pretty easy to fix.  I did a search for all of the `node_modules` folders under `~/src/**`, and deleted all of them, right from finder (sorry, terminal apologists).  I then emptied the trash on my mac, and I was 10GB richer.  

<Image
  publicId="posts/reclaimed-10gb-of-disk-space-from-node-modules/disk-space"
  alt="Screenshot of MacOS folder info for a node_modules search"
  caption="10 GB of space, just for node_modules!"
/>

## What did it break?

It's been a week since I've done this. So far the only inkling of a downside is that when I revisit projects I'm actively working on, I need to run `yarn install` to recreate the `node_modules` directory there. I switch between a good handful of projects, and I'm back to a fair few directories, but at least these are just the ones I'm currently using. I'm good with that.

<Image
  publicId="posts/reclaimed-10gb-of-disk-space-from-node-modules/terminal"
  alt="Terminal search for directories called node_modules"
  caption="A week later, I'm back up to 1209 node\_modules directories"
/>

## Can we do better?

There is an alternative to `npm` and `yarn` called [`pnpm`](https://pnpm.js.org/), which claims to be a "Fast, disk space efficient package manager".  Its primary feature looks promising:

<Image
  publicId="posts/reclaimed-10gb-of-disk-space-from-node-modules/pnpm"
  alt="pnpm's value prop - one version of each package saved to disk"
  caption="One version of each module sounds great"
/>

I haven't tried it yet, but will certainly be giving it a shot.

## Epilogue 

I think it's fair to say that this is a problem that the folks at npm and Facebook (who maintain yarn) are also looking closely at. My guess is that some healthy competition will improve this disk space nightmare... hopefully before I'm forced to buy a laptop with 1TB of storage. 🥳


* * *


### More reading

I'm certainly not the first one to write about this.  Some more great reading for you to check out, if you're interested:

*   [The node\_modules problem](https://dev.to/leoat12/the-nodemodules-problem-29dc)
*   [What Happened When I Peeked Into My Node\_Modules Directory](https://medium.com/s/silicon-satire/i-peeked-into-my-node-modules-directory-and-you-wont-believe-what-happened-next-b89f63d21558) (this is the infamous tongue-in-cheek Guy Fieri article)
*   [What’s really wrong with node\_modules and why this is your fault](https://hackernoon.com/whats-really-wrong-with-node-modules-and-why-this-is-your-fault-8ac9fa893823?gi=1ff87c0f83ba)

I reclaimed 10GB of disk space from node_modules


(note: the header photo from this article is from [Dakota Roos](https://unsplash.com/photos/dSRhwPe6v9c?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/structure?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText).  Thank you for your work!)

[Destructuring](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment) syntax in es6 (or es2015, etc) JavaScript is a wonderfully useful bit of the language.  It allows you to extract values from an `Object` and assign them to a new variable in one statement.  If you've not come across destructuring before, a fairly basic case looks like this:

    const person = {
      name: 'Mike Bifulco',
      height: 556,
      fears: ['heights', 'fire'],
    };
    const { name } = person;
    console.log(name); // this will print 'Mike Bifulco'

So - what's happening here is pretty simple.  We are creating a `const` called `name`, and filling it with the value found in `person.name` . This is accomplished using the bracket structure to the left of the `=`.  

(If you haven't seen or used this before, it can definitely be confusing.  Don't fault yourself for that - it'll become second-nature before long.)

There's are many other useful things you can do by way of destructuring.  For me, the most common among them are:

## Renaming

If you want to pluck a value from within an object, but also need to rename it (for purposes of code readability, perhaps), you can do so in one line:

    const person = {
      name: 'Mike Bifulco',
      height: 556,
      fears: ['heights', 'fire'],
    };
    
    const { height: currentHeight } = person;
    
    console.log(currentHeight); // 556
    console.log(height); // undefined!

Just like that, we've assigned `person.height` to `currentHeight` in one line.  Sweet!

## Extracting

You can extract one value from an object, and create another variable with everything else, you can do that, too:

    const person = {
      name: 'Mike Bifulco',
      height: 556,
      fears: ['heights', 'fire'],
    };
    
    const { fears, ...fearlessPerson } = person;
    
    console.log(fearlessPerson.fears); // undefined!
    console.log(fears[0]); // heights

This is a combination of destructuring syntax and the spread operator (`...` ). Very handy!

## Hard mode: complex destructuring

So both extracting and renaming things with destructuring are fairly straightforward.  I've been using both of those tricks comfortably for a while now.  In the past few months, I've been poking around with [GatsbyJS](https://gatsbyjs.org) for a few different projects (including my own website).  When I was starting to customize and implement my own Gatsby theme, I started to see some _really_ complex looking destructuring syntax, used to pull nested values from GraphQL queries throughout the site.  

I was really thrown - at first glance, it's not obvious what's going on.  Let's take a look at an example, pulled from a React component used to render a single page in a Gatsby theme:

    const singlePage = ({
      data,
      location,
      pageContext: { nextPagePath, previousPagePath },
    }) => {
      return (
        <p>...react component markup</p>
      );
    };

There's a combination of things happening in the definition of the `singlePage` React component.  Let's look at just that destructure, and simplify it a bit:

    const {
      data,
      location,
      pageContext: {
        nextPagePath,
        previousPagePath,
      },
    } = props;

It took some staring, and some playing around to figure out what was being accomplished here, so let's run through it step by step:

1.  The right side of this `const` is `= props` which tells us that all of these values are being destructured from an object called `props` .
2.  The first two values, `data` and `location` make good sense - they look just like the examples above.  This line will create a `const` from each of those two paths in the `props` object.
3.  `pageContext` is where things get interesting -  this is _another_ destructuring.  Somewhat confusingly, the values that are being pulled from `props` here are `nextPagePath` and `previousPagePath` . There is no variable being created for `pageContext` .

If that description didn't help - I don't blame you.  It really took some practice for me to understand what's going on.  I'm not even sure I would recommend using this syntax - it's not particularly easy to read, especially when tools like `prettier` squish it onto fewer lines.  

With that said, it seems to be the way-to-go when pulling data from GraphQL queries on Gatsby (and likely elsewhere). If you're going to be working in that world, it's a good idea to familiarize yourself with what's going on here. 

## Homework

I think the best way to get used to this syntax is just play around with it yourself.  I've created a JSBin which you can use to experiment a bit.  I'd love to hear how you do with it! [Check it out here](https://jsbin.com/kifizij/2/edit?js,console).

Some challenges for you:

*   Rename the variable `displayName` to `currentUserName` 
*   Extract `editedBy` into its own variable
*   Create an object called `meta` which contains everything in `directions` except for the `contactNumber` 

  

## Wrapping up

I'd love to hear how you fare with this - I found myself writing this post as a matter of self-help.  Often times these things won't be made concrete until I practice in isolation for a while.  What creative uses do you have for destructuring? Did I get anything wrong here? Let's talk about it.


Understanding JavaScript Destructuring Syntax


# The Problem

Earlier tonight, my Macbook Pro decided it was done having disk space, and in the middle of a Time Machine backup, it started gnawing through every last bit of free space I had left.  Great.

In a frenzy of panic-and-uninstall, I came across an install of [Postgres](https://www.postgresql.org/) 9.x which I haven't used in quite a long time.   I wanted to carefully uninstall it, in part because I knew that the Postgres install process does loads of not-easy-to-clean things to your mac, including adding a user account to your device, and an app, and a bunch of settings.

My goodness, what a ride.

# The Solution

There's not a simple uninstaller for _everything_, so far as I can tell.

Eventually, the gods of web search brought me to [this beautiful gist](https://gist.github.com/Atlas7/b1a40a2ffd85728b33e7) on GitHub, which listed everything I needed to do to complete the uninstall safely. (I've also [forked](https://gist.github.com/mbifulco/1e44a2e9b7e3bd784f01ef5a138da829) the gist, in case the original ever disappears 😅).

I don't want to take any credit for the work - it seems to have originally come from [this blog post](http://hzchirs-blog.logdown.com/posts/142678-how-completely-uninstall-postgresql-9x-on-mac-osx) from 2013, which was not returned by my Bing-fu (yeah, you read that right).  

I'm posting it here in the hopes that will help some other soul in the future who is going through this experience.  Good luck out there!

Quick tip: Here's how to uninstall Postgres from your Mac


[Prettier](https://prettier.io/) is "an opinionated code formatter", built to fit into your developer workflow. It's been out in the world for quite a while now, but until today, I had never successfully used it in any project I worked on. In truth, there's a few reasons for this:

1. I was really used to (and really happy with) using [`eslint-config-airbnb`](https://www.npmjs.com/package/eslint-config-airbnb) for all of my projects. Across the board, I'd configured every node/react/js-based project to use the same airbnb config, and had a functional workflow for ensuring code quality at some level through those lint checks.  
1. I was too busy to switch. This is a bit of a bullshit answer, since one of prettier's biggest advertised features is its lightweight setup. That's not to mention the amount of time that prettier _should_ save me once in use. A bad excuse.  
1. **I could never get it to work(!)** So - despite being adept at reading through docs, every single time I started down the path of setting up prettier on a project, I couldn't get it to work. Despite my peers shouting from the rooftops about how deliciously sublime prettier makes the development workflow, it seemed like a permanent impasse.

## So what was the problem, then?

Well, it all came down to a formatting issue. The header image for this article tells the story: every time I installed prettier, when I triggered formatting with Visual Studio Code's `formatOnSave` setting, my React/jsx components would get scrambled. After some squinting, it appears that something was telling my IDE to treat these jsx files as pure Javascript, where `<` means "less than", and shouldn't ever be treated as the start of a component `<tag>`.

## The Fix

In my case, it came down to a conflicting extension for Visual Studio Code. It turns out that the [beautify](https://marketplace.visualstudio.com/items?itemName=HookyQR.beautify) plugin takes precedence over Prettier in its default configuration. After some plucking around, I determined that if I _disable_ Beautify in the workspace where I'm using prettier, everything just suddenly... works. 😍

<Image
  publicId="posts/embracing-prettier/disable-beautify"
  alt="VS Code's extension interface showing the Beautify plugin, with an arrow pointing to the option that says 'Disable (workspace)'"
  caption="Disable beautify in your project workspace, and everything gets better"
/>



In my case, that was it! Prettier is now working as advertised.

The jury's still out on whether prettier is life-changing for me, but it's working, at the very least. My next step was to jump into `.prettierrc`, and override _just a few_ settings:

```js
    {
      "trailingComma": "es5",
      "semi": false,
      "singleQuote": true,
      "jsxSingleQuote": false,
      "tabWidth": 2
    }
```

_(note: this is my first time writing JavaScript without semicolons. I'm really breaking the rules now!)_
