DEV Community: Andrew McKeever

Cleaner short circuits with optional chaining.

Andrew McKeever — Mon, 23 Mar 2020 17:06:15 +0000

Support for the optional chaining operator came to some major browser releases, allowing for easier and cleaner retrieval of nested object methods and properties given that they exist.*

What is Optional Chaining(?.)

One of the most common operations that us developers need to perform on objects is retrieving its properties and methods. Many times these properties/methods contain other properties/methods that we have to drill down to. However, not every object will have said properties/methods and we end up breaking our code. A common way to handle these errors is to use the && operator when drilling down the object, creating a short circuit if the property is returns undefined

const Boat = {
   name: {
     first: 'Boaty',
     last: 'McBoatface'
   },
   cargo: {
     // additional props could reside here
   }
}

/** 
  * check if boat has cargo 
  * then an item 
  * then return the quantity of item
  */
const boatQuantity = 
  boat.cargo && 
  boat.cargo.item && 
  boat.cargo.item.quantity

We can see that even trying to go only a couple layers deep into an object with the && operator things are getting a little messy. However, the optional chaining operator cleans up our code a lot.

// such clean, much readability
const boatQuantity = boat.cargo?.item?.quantity;

Support

Outside of Safari, the latest version of all major browsers now support the optional chaining operator. Alongside them, Babel also provides support so if you're already using Babel in your projects, upgrade to 7.8.3 (maybe earlier? this was the earliest release I could find) and you're good to go.

Thanks for reading! Stay safe and healthy out there everyone

A use case for the Object.entries() method

Andrew McKeever — Wed, 05 Feb 2020 07:15:03 +0000

Perhaps you already know about Object.keys() and Object.values() to create an array of an objects keys and values respectively. However, there's another method Object.entries() that will return a nested array of the objects key and values. This can be very helpful if you'd like to return only one of these pairs based on the other's value.

A clean way to return keys in an Object

Often times in form with form data there will be a list of choices presented to users that are selectable with radio buttons. The object's data returned from this will look something like this...


const myListValues = {
  'selectionTitle': true,
  'anotherSelectionTitle': false
}

We could store these objects with their keys and value in our database as they are, however just adding the key name for any truthy value would be sufficient. By passing our myListValues object into Object.entries() we can filter out any falsey values from our newly created array and then
return the keys as a string.

Execution

We'll make use of not only Object.entries(), but also the very handy array methods filter() and map(). The output from Object.entries(myListValues) will be...


 const separatedList = [
   ['selectionTitle', true ], 
   ['anotherSelectionTitle', false ]
 ];

We now have an array that can be utilise .filter() and .map() to return our desired result. So let's clean up our separatedList array a bit.


 const separatedFilteredList = 
   Object.entries(myListValues).filter([key, value] => value);

 const selectedItems = separatedFilteredList.map(item => item[0]);

There we have it. Our selectedItems array is now just a list of the key names from our objects who's value was truthy. This is just one of many use cases for perhaps a lesser know object method. I'd love to see some more interesting use cases you may have come up with.

Using CSS modules

Andrew McKeever — Wed, 15 Jan 2020 14:30:33 +0000

Breaking larger code bases into smaller chunks using component based architecture has made it much easier for us developers to architect a clean project; it can even improve productivity. However, one of the biggest challenges in creating unique names for all of these components, since many of them tend to function similarly or are the same type with a few style modifiers. This overlap can cause a huge mess in our CSS. The popular solution to this problem has been to use CSS in JS and many libraries have been built each with their own take on how to do it. However, plain CSS offers a solution with a simple amount of configuration, allowing us to avoid depending on a library.

Why use CSS Modules?

The main benefit of CSS modules is that classes are locally scoped. Every classname generated in a CSS file will have a unique name given to it at build time. How is this handled? Well we will need to set up Webpack to do this for us, but don't worry it's not too bad.

If you're used to using naming conventions like BEM to prevent class styling overlap, you'll know that classnames can become incredibly long. This makes it harder to read your code and really know which styles am element is receiving from which modifiers. With CSS modules, you can drop naming conventions as you only have to worry about unique names inside of the locally scoped file(e.g. two elements in separate JS and CSS files can have the same name).

How to get started.

Getting started doesn't require too much setting up, but can be a little confusing if you're unfamiliar with Webpack. However, even if you've got very little experience it's one of the easier configurations to get working. We'll need to install the css-loader package from npm to use it in our webpack.config file.

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/i,
        loader: 'css-loader',
        options: {
          modules: true,
        },
      },
    ],
  },
};

Here we're telling Webpack to use css-loader to handle all files with the CSS extension. From there we just set the module option to true and that's it! Pretty straight forward.

Once we've configured Webpack we're ready to get started. We can create our style sheet like we normally would; we'll create a styles.css for this example.


  .someComponent {
      width: 100%;
      height: 250px;
      background-color: #ebebeb;
   }

Then we import simply import our style sheet into our JS file.

import style from './styles.css'


component.innerHtml = `<div class={style.someComponent}>I'm using CSS modules></div>`

As mentioned, CSS modules will become locally scoped. Our output then at build time will look something similar to this

html

<div class="style_someComponent__3N3nB">I'm using CSS modules</div>

css

  .style_someComponent__3N3nB {
      width: 100%;
      height: 250px;
      background-color: #ebebeb;
   }

That's all there is to it! We can now easily prevent any stylings from overriding components where they shouldn't without changing much at all on how we style our html.

Happy New Year!

Andrew McKeever — Tue, 31 Dec 2019 05:37:31 +0000

Happy New Year 🎉 to everyone in this awesome Dev.to community, It's been a great alternative to other blog platforms. I also would like to thank everyone for reading and following me this year. When I started I had a goal of reaching 500 followers at the year's end; I've now reached 2800 followers! Thank you all for taking interest in my writing and being a wonderful community. I hope everyone has been relaxing and enjoying time with families and loved ones this past week.

See you all in 2020! 🥳

Beef up your HTTPS sites with a Content Security Policy

Andrew McKeever — Fri, 13 Dec 2019 08:22:42 +0000

HTTPS is quickly becoming a standard implementation when creating a website or application. Most hosting platforms make it rather simple to host our sites over HTTPS. Github pages even makes it totally free and as simple as a button click. However, without setting up a strict Content Security Policy, you're still leaving your sites vulnerable. Content Security Policies aren't exactly a 'sexy' part of development to learn though and strict ones can break your site. The goal of this article is to help clarify some common issues you may run across when setting up a CSP.

Overview

A Content Security Policy (CSP) is a HTTP header, built for protecting against various site attacks, mainly cross site scripting attacks (XXS). A good CSP is strict as possible, only allowing external JS and CSS scripts from third parties that are needed to run the site. Another good (pretty much essential) practice is to provide a nonce tag or an sha based hash for any inlined JavaScript (I'll explain how to do this a bit later).

All this blocking can quickly become a serious issue however, since any script not listed in a CSP will be blocked and if this particular script is essential to run the site (e.g. a runtime script for a JS library) it'll break the whole page. Testing a CSP on a staging environment before implementing it on production is a must.

How to implement

There are a couple ways to implement a CSP, one is by directly adding it in the meta tag of your index.html, the other is via server side. Directly adding it to the meta tag is quite convenient, especially for statically hosted sites and/or you only have a few external scripts tags you need allow in the CSP. However, server side gives you the added benefit of being able to dynamically add scripts as you need them and can create allow you to create an extra layer or security.

No matter which direction you choose, there will be a few directives you'll need to consider when adding your scripts.

default-src: As the name implies, this is the default fall back for any directives that aren't applied in your CSP. A common source for this would be 'self', which would allow only scripts that come from the origin.
script-src: This directive defines what sources are allowed to include their JS. Defining these is one of the more crucial directives to protect your site, but keep in mind this is also the one that will cause the most breaks if not set correctly.
style-src: CSS style sheets from different sources. If there's any library that requires to embed their own CSS then include them here, but 'self' is again a standard choice.
font-src: Using google fonts or other font sources? You'll want to add these here.
frame-src: This directive is for those sources that will embed iFrames into your page. Stripe or Google Maps come to mind here.

There are a host of others out there available, just be sure to check the browser support for them. You can find more from the Mozilla Docs.

There's one more thing, the unsafe-inline value. You can set this value to allow any source to set inlined resources, like JS or CSS. This may prevent your site from breaking, like an inline React runtime, but this is leaving your site almost as vulnerable as it was without setting up a CSP. Avoid this as much as you can.

Avoid unsafe-inline with hashing

The point of only granting certain sites the ability to add their scripts is to protect you from outsiders wanting to sneak malicious code into your code. The unsafe-inline rule allows any third party to add inlined JS directly into a script tag. To get full advantage of a CSP you'll need to avoid this property by using either a nonce or a generated hash following at least the sha256 algorithm.

You may have noticed by now, if you've tried setting any of the script-src or frame-src directives that Chrome (assuming you use it) may have generated a hash for you, This is possibly the easiest and most straightforward way to add a hash. However, Chrome may not do this for every script or style attribute that is being inlined.

Another popular way is to use Node.js or a backend language to generate them for you and then add them to the CSP dynamically. If you're server-side rendering (SSR) then doing this shouldn't be too difficult. There are some libraries out there to help you generate a hash or nonce; Node.js has crypto for example. If you're using AWS to host a static site with CloudFront, then you could use a Lambda function installed with Node or Python to do something similar. I'm unsure of other serverless services, but they may also have something comparable.

Syncing up Google Ads and Analytics to your React App.

Andrew McKeever — Thu, 05 Dec 2019 05:23:37 +0000

Getting setup

Google has made it quite simple to integrate Ads and Analytics. To get started you'll need an account for both services. You'll need to obviously enter in personal info, leaving that feeling like you're selling your soul to the devil. For Analytics you'll also need the URL of your site. Once you're setup head over to Analytics then proceed to admin -> property -> tracking info -> tracking code to fetch your trackingID. Keep the trackingID handy as you'll need it later in our App.

your trackingId should look something like

UA-XXXXXXX-X

We'll also need to to setup a GoogleAds account. Follow Google's setup process of creating an account and choosing a plan (more soul selling). Once you've gone through the initial setup, we'll want to link our Ads account to our Analytics Account. On the Ads dashboard, select the tools -> setup -> linked accounts. Select details and you should be prompted to add in the trackingID you grabbed from Analytics. Thats pretty much all there is to it.

Creating and using an event

React-ga is a package built off the Analytics API offering a variety of config options making it a breeze to implement Analytics in our App.

yarn install react-ga

Once installed we'll need to import react-ga inside of the main page where our app is built (App.js or Index.js). Then we'll pass it our Analytics trackingId we got earlier during setup, react-ga will handle all the boilerplate code needed in our app.

ReactGA.initialize('UA-XXXXXXX-X')

This next part is left up to you. Where ever in your code you'd like to place GoogleAds, you'll need to create a new Analytics event using ReactGA.event. No matter where you place your event, there are a few parameters that are important to remember because you'll need to set them exactly the same in Analytics. The event will look something like this


  ReactGA.event({
    category: 'some category',
    action: 'example_action',
    label: 'example label',
  })

There are some configurations you can add to the event object, but these three are the important ones. Once this is done, head on back over to GoogleAnalytics and back under the admin page, find Goals and select Create A New Goal.

You'll want to create a new custom goal in the initial setup and then provide a description and select Event for the type. Now, under goal details place fill in Category, Action and Label exactly as you did before in the ReactGA.event(). Once you're done save your event.

Tying it all together.

Head on over to your GoogleAds dashboard and under Tools & Settings select conversions. There'll be a nice blue + sign in the upper left corner to add a new conversion, give it a click and then select import. By syncing our Ads and Analytics accounts up earlier, we're now able to import our newly created goal in Analytics as a conversion in Ads and BOOM! we're all set. Any Ad campaigns you've set up for the conversion should now be tracked in Google Ads.

Agencies or In-house, which do you prefer?

Andrew McKeever — Wed, 27 Nov 2019 09:37:16 +0000

I spent my first few years of as a developer working for agencies, but recently moved to an in-house company.

Since each project usually has a short deadline, agencies give you the option of changing up the tech stack, which is great for learning. The main differences I've noticed so far...

Testing is a larger concern for in-house. Outside of VC pressure, there's not as tight of deadlines in-house compared to agency projects. However, because we're not handing-off the project(s) to clients, maintenance is also a larger responsibility.
More discussions happen before a solution is decided on when working in-house.
Implementing hot-fixes and coming back to them later is possible in-house. This option isn't really there when you're going to be handing your code off for someone else to maintain.

Which do you prefer? What are some differences you've noticed between the two?

More time coding, less time debugging. Interfaces in TypeScript applications

Andrew McKeever — Mon, 18 Nov 2019 03:29:11 +0000

The goal of this article is to deepen your understanding of what interfaces are, not just how to build them. Building a solid foundation of programming concepts will strengthen you as a developer, better preparing you for interviews and your career

If you've happened to come across an application written in Typescript you've probably ran across something like this...

 interface Person {
  hairColor: string;
  height?: number;
  [prop: string]: any;
}

We call this an interface and they're great because they allow us to define the structure of our objects an input, preventing unwanted properties or methods from creeping into our data. Interfaces do this by checking that the input our code is receiving adheres to the data types we've set inside the interface. This helps our applications to run as expected.

However, if you're like me and never really worked with a strict data types, like those found in Java or C#, programming to interfaces can present a challenge. After all, dynamic languages (duck typing) like JavaScript don't require us to declare data types, which makes them easy to learn. So if programming to strictly typed interfaces can be difficult, why use them at all? Let's explore this idea.

Where do interfaces come from?

Now, while I think it's pretty important to understand the full reasoning behind programming to interfaces, I will briefly summarise it as a) there's a lot to cover, which would it's own post and b) many a greater developers than myself have written said as articles on this very thing. In a nutshell, the language we write in is a set of instructions for our computer to run our applications. These instructions can only be handled between 4 or 8 bytes at a time so declaring which data types are in our code before its compiled does some of the leg work already, allowing the computer optimally perform.

Concatenating two different data types, a string and a number for example, make it more work for our computer; especially if these different data types were actually meant to be of the same type. By declaring our data types as we code, we cut down on the amount of time it takes our computer to read our instructions. This is why strictly typed languages exist.

Why should I use interfaces?

Spending time debugging code or trying solve issues QA has found in your code can be a major headache. For me, the only thing worse than being stuck on a problem, is having a feeling of relief finishing a new feature, only to have to go back and fix a load of bugs in said feature.
If you're in an environment using sprints, the time spent debugging isn't usually considered in the initial estimation to develop said feature. Structuring your code around interfaces will take more time, but that's more time coding allowing you and your team to better estimate new features in the sprint plan.

So I should always use interfaces then?

No, like any language or framework, there's a time and a place for strict typing with JavaScript. If you're working on a smaller project with a two month deadline and no backend, then strict typing will probably just slow you down. While projects like these wont be bug free, unless you've added maintenance into the budget, time isn't on your side here.
However, less time fixing bugs means more time implementing new features so ultimately consider how much time you have vs. how long you think it'll take to yourself and you team to become productive with strict types.

Personal preference is another consideration although you can't build a preference without first trying the alternative. I'll admit that I get frustrated programming to interfaces (this was especially true early on), but they're growing on me the more I use them. Still, strict typing isn't for everyone just like dynamic typing isn't either and that's totally fine. Multiple languages exist for a reason, but I've you haven't tried strict typing yet, I recommend giving it a chance.

VScode extensions and shortcuts to improve your productivity

Andrew McKeever — Mon, 11 Nov 2019 05:12:55 +0000

Since I started using VSCode a couple of years ago, I've learned quite a few handy shortcuts and installed some incredible extensions to make my day to day not only easier, but also quicker and more productive. Perhaps many of you are familiar already with some of these, but I hope to introduce you to some new ones too!

Shortcuts

⌘ K ⌘ C: This command is by far my favorite one I've learned. It's used to add comment lines, but it can also be used to comment out lines if you're wanting to quickly test a piece of code.
⌘X: Cut away a whole line of code. It'll get saved into your clipboard allowing you to either delete or paste it somewhere else with ⌘V.
⌥⌘↑: Multi-cursors are great for editing, removing or commenting multiple lines of code at the same time. Using the ↑ or ↓ directional keys will add a cursor to a line above or below respectively.
⇧⌘L: Select all occurrences of selected piece of code. This comes in really handy for changing variable names.

Extensions

Project Manager: So much of my day is switching between repositories wether thats due to bugs in one project causing problems in another or implementing many features in one day. This extension allows you to save projects and easily switch between them via ⌘⌥P shortcut.
Jira and Bitbucket Extension: For the many of use who are using Jira boards to handle ticketing our issues or features, this extension allows you to create and modify Jira tickets directly in your editor. It will even give you the option to create a ticket directly from a /**TODO:**/
Better Comments: Speaking of writing TODOs, Better Comments provides syntax highlighting and comment formatting to make your life and the lives of other developers who read your code easier.
Bracket Pairing: When I first started learning to program I would easily get lost trying to figure out which brackets were closed and which were open, let alone trying to figure out which one I actually need to delete. Nested brackets in any code base can be a pain to navigate through without a colorizer.
VSCode-Spotify: I'm not sure about your office, but mine tends to be pretty damn quiet with all of us developers hacking away behind the computer. I couldn't get through my day without listening to music or podcasts. This handy little extension connects the Spotify application to VSCode, creating a handy toolbar to skip, pause and play songs or podcasts directly in the editor. Really nice if you just need to quickly pause to ask or answer a question.

I hope I introduced you to some new shortcuts or extensions, feel free to comment down below some of your favorites!

What's some of your favorite experiences with onboarding?

Andrew McKeever — Mon, 04 Nov 2019 21:05:03 +0000

Today was my first day at a new company and after a briefing on the company history along a partner to help guide me with their workflow, I was also given a detailed list of what needed to be setup. While this might not seem like much, previous companies never did something as detailed as this. What have been some of your best experiences with onboarding?

Improve accessibility with prefers-reduced-motion

Andrew McKeever — Mon, 28 Oct 2019 12:42:35 +0000

Making our sites or apps accessible is a major responsibility for all of us developers. Many of us know about adding descriptive alt tags to images or choosing the appropriate color contrast for text with a background, however there are a few out there you may not know about including prefers-reduced-motion.

One of the biggest joys in front-end development is getting the opportunity to implement really cool animations. Many hours can be spent working alongside designers tweaking a cubic-bezier to make that fade out scrolling animation just right. A well thought out animation can take your site from something simple and bland to lively and interactive. However, not every user enjoys them. Some might be very sensitive to too much motion causing them to feel ill. Fortunately it's become trivial to help these users out by adding a simple CSS property, prefers-reduced-motion.

What it does

Prefers-reduced-motion attempts to stop any non essential animations from being triggered when a user specifies so. For example, any fading or sliding animations that are triggered when a user scrolls for an interactive feel, but not essential to the actual site should be left out at the user's request.

How to work with it.

Nearly all of us web developers have used media queries in some fashion or another and prefers-reduced-motion is as simple to implement as a media query.

.myAnimation {
   animation: 3s infinite alternate bounce;
}

@media (prefers-reduced-motion: reduce) {
  .myAnimation {
     animation: none;
  }
}

That's it to disable any animations you feel aren't essential to the user experience, giving relief to those who may be susceptible to motions. What is essential is left up to you and the designer. Animations that give users feedback like button clicks or successful form submissions would probably be considered essential, but most could be considered unessential. We can also slow animations down or decrease their frequency instead of disabling them all together.

Browser Support

In terms of browser support, the latest two versions of Chrome, Firefox and Safari all support prefers-reduced-motion. The latest Edge also supports it, however IE11 doesn't.

A quick glimpse into Server side rendering a React App

Andrew McKeever — Thu, 17 Oct 2019 15:52:43 +0000

Server side rendering took a bit of a back seat with the initial popularity boom of client side frameworks. On the other hand, SPAs create a challenge with SEO since many web crawlers aren't capable of crawling client side JS bundles. However, SSR is making a comeback with the ease of implementing our beloved client side frameworks on the server. This gives us some nice advantages while still utilizing the performance power from a client side framework. In the this article I'd like to take a brief look into server side rendering a React App.

Why use SSR

There really are two main advantages of server-side rendering

Better SEO
Faster initial page loads

With a client-side application, we're only generating a small HTML file with basically zero content outside of a script tag with something like

<script type="text/javascript">
  <div class="app"></div>
</script>

This makes it pretty difficult for web crawlers to read what kind of content is on our site, killing our SEO. By generating our React components as HTML files on the server, we avoid this problem.

Browsers load HTML, CSS then the JS of our web pages and Apps. If all the content of our SPA written is inside our React components users won't see any content until after our CSS and JS is fully loaded. By handling our JSX content as HTML markup on the server our SPA's initial load time will be much faster. There is a downside to this though, which I'll explain a bit later.

A bit on how it works

I'm going to make the assumption that you're familiar with setting up an Express server with Node.js as going through that setup is beyond the scope of this article. If you've never setup an Express server before, have a look at this Express example. To get your React SPA from client to server side you'll follow the basic Express app setup. Our server will also need React the ReactDOMServer object to convert our component to markup. This object comes with a few important methods, one in particular.


ReactDOMServer.renderToString(someComponent)

The renderToString() method accepts a React component and converts it to our HTML markup, allowing crawlers to work their magic. On the client side, our components don't change much in terms of their regular syntax, however instead of ReactDom.render() we must now use ReactDOM.hydrate().

Reading the initial documentation on hydrate feels slightly more complex than it actually is. When we send an HTML file to the client via server side, we're sending static content along with it. However, we know that with a React app, that many of our components will need to be updated with state changes. Handling these state changes by generating our HTML on the server, sending it to the client, client making a request for an update to the server and then the server sending back the updated HTML is time consuming (why we have client side frameworks in the first place).

We can however, send a static version of our App as an HTML string to the client. This "dehydrated" version will then receive event listeners to any DOM nodes we specify in our react components which can then be referenced for changes in our applications state, similar to any other client-side only React App you may have created in the past.

Caveats

Setup for React Apps via SSR are quite complex. Webpack configurations need to be set up for JS bundles, like any application from scratch setup, however servers also can't read JSX which requires more configuring. Thankfully, frameworks like Next.js and Gatsby have emerged to make this setup easier.
SSR can help speed up first paint, but time to interactive can cause users to be deceived since only our static content is loaded on the server side, but our bundled JS still needs to load.

Thanks for reading this very brief introduction into how server side rendering works with a React application. As always comments, questions and constructive criticisms are always welcomed.