DEV Community: Lukie Kang

JetBrains State of Developer Ecosystem

Lukie Kang — Mon, 27 Nov 2023 10:57:58 +0000

The JetBrains State of Developer Ecosystem dropped recently and well worth a read if you are involved in the developer space in some way and want to get a sense of how things are trending.

A few things I thought notable were:

Rust and Typescript growing in popularity, it seems at the expense of languages like C++ and JavaScript respectively.
91% of developers are male. In 2021 it was 93%. So I guess at that rate it will be 50/50 by 2066 or so!
46% of developers use GitHub Copilot. I suspect the % that admit that to their colleagues might be lower though 😉 In terms of AI, most developers feel it will help them rather than become a threat to their jobs.
Three to Five years is the median range of professional coding experience. Curious where they go from that point, management perhaps? In an entirely unrelated note, 73% of developers also have experienced burnout...
Top three job incentives for a developer are good hours, good pay and a job in which you feel you can achieve something. There seems to be a gender difference where women value more holidays and societal impact notably more than men.

But there is lots of interesting stuff in the report, its worth flicking through even if its to just challenge our own anecdotal experiences. Though I would love to have seen the results with a by country breakdown to see how that impacts the responses. I also wonder about the kinds of developer that will find the time to answer surveys and if that skews the results in a general direction.

Javascript Maps

Lukie Kang — Tue, 14 Nov 2023 12:33:26 +0000

The annoying thing about development is that there is always something you don't know about. The great thing about development is that there is always something new to learn. Life is all about perspectives. So the other day I came across this in a codebase:

const person = new Map()

And my reaction was... what is that Map thing, it isn't even an array?!

So it turns out I have managed to avoid all knowledge of this JS data structure over my years with JS. I don't know how that happened but either I can feel inferior about it or I can do something about it. So I decided to take a little time out to learn about this Map data structure...

Whats a Map?

So MDN would say:

The Map object holds key-value pairs and remembers the original insertion order of the keys. Any value (both objects and primitive values) may be used as either a key or a value.

Sounds like an object right? You are not wrong but there are some key (no nerdy pun intended) differences:

In objects the key field must be an string or as a symbol. Whereas in map it can be any datatype.
Map is an instance of an object but an object is not an instance of a map.
Maps retain the order of the elements added. Objects...kinda have thier own order too but its complicated.

Creating a Map

Whereas objects have object literal syntax: const rabbit = {} as a handy shortcut. We have to use a constructor for a Map:

const empty = new Map()

const filled = new Map([
    [1, 'Apple'],
    [2, 'Banana'],
])

Accessing and Modifying Map properies

For objects we can use dot or []'s to access properties. However for Maps we use a built-in get method:

 const saladObj = {
    tomatoes: 5
    potatoes: 3
 }

 saladObj.tomatoes // 5

 const saladMap = new Map([
    ['tomatoes', 5],
    ['potatoes', 3]
 ])

 saladMap.get('tomatoes')

Unsuprisingly, changing maps involve a .set method:

   saladMap.set('tomatoes', 10)

   saladMap.get('tomatoes') // 10

Other Handy Map methods:

.has

 const saladMap = new Map([
    ['tomatoes', 5],
    ['potatoes', 3]
 ])

 saladMap.has('tomatoes') // true
 saladMap.has('beans') // false

## .size

const saladMap = new Map([
    ['tomatoes', 5],
    ['potatoes', 3]
])

 saladMap.size // 2

## .delete

  saladMap.delete('tomatoes') // true
  saladMap.has('tomatoes') // false

## Iterating over a map

Yup, you can forEach a map...

 const saladMap = new Map([
    ['tomatoes', 5],
    ['potatoes', 3]
])

saladMap.forEach((value, keys) => {
    console.log(value, keys)
})

// 5 'tomatoes'
// 3 'potatoes'

You can also use a good old fashioned for...of:

   for (const [key, value] of saladMap) {
    console.log(value, key)
   }

// 5 'tomatoes'
// 3 'potatoes'

Map.groupBy

This one is quite an interesting way of splitting out data.

 const saladMap = new Map([
    ['tomatoes', 5],
    ['potatoes', 3]
])

const lowInventory = {needsMore: true};
const goodInventory = {needsMore: false};
const groupedSalad = Map.groupBy(saladMap, ([key, value]) => value < 4 ? lowInventory : goodInventory)

groupedSalad.get(lowInventory) // [potatoes, 3]
groupedSalad.get(goodInventory) // [tomatoes, 5]

The Object method Gotcha:

Now you could try to add things like you would an object like saladMap['tomatoes'] = 20 however this would use the underlying Object logic and thus none of the map specific mehods would work on it as intended. And it is super confusing to boot:

    const mealMap = new Map()
    mealMap['beans'] = 10 // 10
    console.log(mealMap) // Map(0) {beans: 10, size: 0}
    mealMap['beans'] 10
    mealMap.has['beans'] // undefined

Be very careful to avoid using object methods as it creates some weird results as you can see above.

Why use it instead of an object?

Objects are quick and easy to use, in most small cases they are probably fine but there is some notable occasions I can think of:

There is a clear order in how Maps are ordered.
You can use any value for the key which might be handy
There is more control and simplicity in the way the get/set/has/size works. Objects can be a little wild west and provide odd results in edge cases.
A little easier to iterate over
Faster when it comes to actions that involve a rapid additions and removal of key value pairs

However it is not natively supported in JSON so requires a little more effort if thats part of the workflow to be supported.

My takeaway on Maps.

Overall, Maps are something I will add to my mental JS toolkit and reach for them in scenarios where they make sense as, in my mind, they are a bit more structured and predictable than regular Objects though I will have to play with them more to truly grok any pitfalls I have not considered. Browser support is also good with only the .groupBy being a recent addition. I want to benchmark that performance benefit as I am curious how quantifiable that would be but I certainly will bear maps in mind for complex algorithms using hashmaps.

What's new in WCAG 2.2

Lukie Kang — Mon, 13 Nov 2023 12:43:43 +0000

Whats a WCAG? What you on about?

The WCAG (Web Content Accessibility Guidelines) is the guide for designing and building accessible applications. It has a number of success criteria over a number of categories and in 2023, there really is not much of an excuse to ignore these guidelines not just because it is the right thing to do but because a design that is accessible also is one that is very usable for everyone. Most people would rather spend their cognitive capacity on thinking of kittens and food rather than trying hard to navigate their way through an application no matter how beautiful and cool it looks.

As always its important to bear in mind that they are guidelines, not simply a set of checkboxes to hit, thinking through the lens of accessibility is what counts. There is a system of A, AA, AAA to denote the level of accessibility reached. My shorthand for this is as follows:

A - You have not made things unusable for people with accessibility needs. But you can do better.

AA - You have done a decent job in making this a good experience, can you do better without huge effort though?

AAA - This is the gold standard, well done. Now see if your users with accessibility needs agree before you get too smug.

While AA is a reasonable standard to hit in general, if you work on a governmental, utility or banking app, I would strongly argue for greater levels of accessibility since access to those services is pretty much mandatory for all abilities in the modern age.

The WCAG is freely available to read and follow so at least be aware of it though I admit it is not the most exciting of reads. So recently WCAG moved to version 2.2 in October 2023, so I was curious to see what new and exciting things this means for accessibility standards

So whats in 2.2? Is it a big deal?

... drumroll ... not really. There are 9 new success criteria introduced in this release and, in my opinion, they fall under the category of 'Well, yes obviously it should do that....'. However, having it officially in the WCAG is great for those of us that who have had to advocate pretty strongly for doing so before it was codified.

2.4.11/12 - Focus Not Obscured (AA/AAA)

2.4.11 - Ensure when an item gets keyboard focus, it is at least partially visible.

2.4.12 - Ensure when an item gets keyboard focus, it is fully visible.

Keyboard focus is one of the pillars of accessibility access to a web app. If a user cannot use a mouse/finger then navigating via a keyboard matters. Hit tab a few times and you'll see what I mean. Having the 'focus ring' is essential in letting a user know where they are on the site, if it is hidden, the user has no idea where they are. Keep it visible.

This one is quite commonly an issue simply because all the banners and pop-overs modern web sites have. If a site has a cookie prompt, newsletter sign up, or something like that, more often than not keyboard focus tends to suffer. While things have gotten a lot better recently (hello Dialog element) any time a banner/pop-over is introduced my accessibility-sense tingles. Be sure it tingles you too.

2.4.13 Focus Appearance (AAA)

2.4.13 - Use a focus indicator of sufficient size and contrast.

That focus ring I mentioned earlier? It might look cool if you made it a thin wispy off-white outline on your cool button but that really screws over people who actually need to see it. Make sure it is clearly visible. The WCAG goes on to say that it should be 2pm thick and with a contrast ratio of at least 3:1 between the pixels in the focused and unfocused states. I try to not get too much into the maths when thinking about accessibility, it should be clear and obvious, do that.

One common gotcha here is that you might make a lovely clear blue focus indicator which is fine 99% of the time and thus it gets forgotten about... At some point someone introduces a blue button and.... suddenly that focus ring isn't as visible as you thought it was! In a nutshell, this Success Criteria isn't hard to hit but watch out for edge cases that need ot be handled in a different way.

2.5.7 Dragging Movements (AA)

For any action that involves dragging, provide a simple pointer alternative.

The WCAG would point out this is for the user that has a hand tremor and thus is unable to drag and drop. I would add that sometimes (e.g. on a phone screen) it is bloody annoying trying to drag and drop things into your UI. I know how cool your drop and drop looks and feels on your 32inch 4k screen and fancy mouse, but for others it is annoying at best, inaccessible at worst. Try using buttons to allow an alternative to drag and drag, your users will thank you.

2.5.8 Target Size (Minimum) (AA)

Ensure targets meet a minimum size or have sufficient spacing around them.

This has happened to everyone I can guarantee it, especially on a mobile device. You have a bunch of icons, you tap on one and no, you actually hit another one because your finger is far bigger than the icon you were going for! Everyone is upset by this, not just those who might be impaired by pointing devices. Let your buttons breathe people, you you need to menu them away then do so, clutter is annoying for everyone. And yes I have been guilty of squeezing 'just one more icon' into a space that really shouldn't take any more. It happens but lets do better!

3.2.6 Consistent Help (A)

Put help in the same place when it is on multiple pages.

I am of the generation that stubbornly refuses to click on help in any circumstance. I am also not a good role model. For others, a help option on an app is a first point of call to know what to do. It is fairly obvious but if you have a help functionality, make sure it is in a consistent place on the page to avoid confusing people. This is also just good design in general however, keeping things in a consistent place makes it easier to understand and fly through your lovingly crafted user journeys.

A gotcha here is the aforementioned banners and pop-overs, it does no good to have the help function in the same place but occasionally it gets hidden by other elements.

3.3.7 Redundant Entry (A)

Don't ask for the same information twice in the same session.

The WCAG will say that this helps those with cognitive disabilities who have difficulty remembering what they entered before. I would add, it bloody annoying to keep on providing info I entered before. I don't think this one warrants much discussion as if you are not trying to make your input processes as frictionless as possible for everyone then we probably need to chat about more basic things than WCAG.

3.3.8/9 Accessible Authentication (Minimum/Enhanced) (AA/ AAA)

3.3.8 - Don’t make people solve, recall, or transcribe something to log in. (AA)

3.3.9 - Don’t make people recognize objects or user-supplied images and media to login. (AAA)

Oh, now I have saved the best till last. I love it when one important principle (accessibility) is rubbing shoulders with another (security), so now you have decide if you want a secure app or an accessible app. Pick one.... Ok, ok, it isn't actually so bad, the key things to bear in mind here for are:

Allow password managers and autocomplete to work to reduce memory need
Allow copy and paste to reduce cognitive burden

If you are going to have a cognitive function test (i.e. click all the 'motorcycles' captcha things) then:

Allow an alternative authentication method that avoids a reliance on cognitive function (easier)
Support is provided to assist the user in completing the cognitive function test (more risky)

Since most people reading this are not coding up their own captcha tooling this has already been addressed for the most part by providers. But certainly its worth being mindful of this as captchas continue to be more sophistated/harder to do.

Conclusion

I stand by my original view that these success criteria should be obvious to those of us who care about a great UX in general. But having it in the WCAG allows us to make the case for these things far more easily when dealing with people who cannot conceive of things existing outside of checkboxes and metrics... you know you have met those people before.

The true hotness to get excited about is version 3.0 which is still very much a work in progress. If you are interested in the future of accessibility, or if you got bones to pick about the WCAG then why not get involved ?

A Very Rough Guide to solving Coding Challenges

Lukie Kang — Wed, 08 Nov 2023 12:15:23 +0000

This post is all about how I break down a coding challenge. How I think might be brilliant for you, it might just make you angry. Who knows, but we know we can always rely on the Internet to offer constructive feedback and support!

Be confident in your toolkit: Data structures and Algorithms.

Data structures are different ways of collecting information, an array/list vs an object/dictionary and another douzen or so common ones. Algorithms are a set of steps to accomplish a certain task, often working with one data structure and working it into another one. You need both of these to be in your mental toolbox.

Explaining whats recommended in that toolbox is worth a blog post of its own but the takeaway is that you need the toolkit. Sure, some people are better at solving problems than others, but more often its more a case of just not having the right tool in your mental toolkit.

Problem Solving Steps

Breathe
Understand the problem
Explore Concrete Examples
Break it down
Solve/Simplify
Look back and refactor

0. Breathe

Some people can tap into their 'problem-solving' brain without too much issue in a high-pressure situation. Others, like me, go into panic mode and make it really hard to think. I can barely type in such situations let alone access 'problem-solving' mode. For me it works to take 10 seconds or so to acknowlege the situation is hard and remind myself to just be methodical and see what happens with some long deep breaths. I think it is my ADD brain trying to run all the problem solving steps at the same time causing a confusing mess as a result. Step by step, thats all you need though thats easier said than done.

Practice solving problems under some kind of pressure at home, be it a timer or on a screen recording... it does get easier.

1. Figure out the problem

Before we can solve the problem, we must first need to understand what we need to do. Investigate the requirements and ask questions, resist the urge to jump to code, there is always a hidden gotcha to watch for.

Can you restate the problem in your own words?
What are the inputs that go into the problem?
what are the outputs that should come from the solution to the problem problem? What does it look like?
Can the outputs be figured out from the inputs? (if you can figure that out at this stage)
How can I label the important pieces of data that are a part of the problem? What matters here to solve the problem?

If you can't do the above before leaping into code. It is likely going to give you a bad day!

Another tip, I think in diagrams: Drawing out boxes and arrows to map out what I think we are trying to do, you might find this may help you too. If I can put the what onto paper I often find it gives me more room in my head to focus on the how. Do it slowly and well, you don't want to be trying to decipher an unintelligble squiggle later on! (Ask me how I know...)

2. Come Up With Examples

Basically plug in some default values to see what you expect. These are effectivley simple log machines: given a particular input what is our output?

You shouldnt do this willy-nilly, but consider the following scenarios, in a designing a function that just adds two numbers:

Simple examples (2,2)
Complex Example ( 20000.54 + 200000000.32 )
Empty inputs ( 2, )
Invalid Inputs (2, "fish")

Also consider how the output should be presented. Should it just be the value? does it need rounding? does it need to come back in a string etc?

Playing around with examples, is an extension of understanding the problem and might help uncover some key things to pay attention to when building your solution. This i s where having your mental toolkit polished and ready to go is so important.

In my experience, people are very good at telling you what they want, but even better at thinking they have given you all the details you need to deliver. Don't be afraid to ask those dumb questions as it will save you time in the long run!

Final point, we don't have to address every edge case to focus on the solving the core problem, acknowledging that it exists is important however and if it can be solved later then its generally best to have something that 90% works you can tweak later than getting bogged down trying to solve everything perfectly...which leads to.

Break it Down

This is all about the How. You should have a decent idea on WHAT you are trying to do, WITH what values. Now lets look at the HOW.

4 easy problems is better than 1 hard problem.

So lets break the problem down into smaller pieces, outlining the basic steps you need to take. This will give you a framework to write your code without worrying about the code.

Using comments to outline your approach is a good way to do this.

You don't have to be wedded to what you put down. You might start with one comment, and break that down further. The smaller the pieces, the easier the code for that is to write.

function addNumbers(a, b){
    //check if a and b are numbers
        //if not number, handle the error
    //add a and b together
    //return string that presents the result correctly with rounding.
}

This is really handy for an observer (say, an interviewer) to know what you are thinking about when you are code.

Lets solve it, or make it simpler!

So now that you have an idea of HOW you can do it, try and solve it! If you can, great! but if you can't... try to solve a simplified version of it.

Obviously you want to solve it. However the logic behind simplfying is that it lets you begin exploring the issue and may trigger some further understanding.

When you are simplfying you can use the following steps:

Identify the tricky part of what you are trying to do.
Ignore that tricky part
Swap it with an easy part
Then explore the differences between the two.

Some examples of simplifying:

If you have an array to iterate through, just try and make a solution for just the first element.
If you can't recall a method (for rounding a number, say) just refer to it in your comments and see if you can research it later (if you can't figure it out in a minute or two)

Look back and Refactor, I heard you say...

Ok, so you have got your function working. Good job! But, unless you are under a really tight deadline, you aint quite done yet.

Your first successful attempt is rarely your best attempt so there are some things you can ask yourself in order to improve what you have done.

Can you check it works for all inputs? See Step 2 earlier.
Can you get to the answer to a different way, what other ways are out there?
Can you understand it when you look at it? Can you make it clearer and neater?
Does this solve or help with another problem?
Can you improve the performance of your solution?
Can you simplify it in other ways?

Those points may be more or less relavent depending on what you are doing.

So lets take what we have learnt...

Lets apply our new found problem solving plan to a simple problem your imaginary boss/interviewer gives you:

Write a function that will remove specified numbers from an array of numbers

Understand the problem

We can restate the problem as Check an array for certain numbers and remove them

We can learn the following from our boss:

The numbers we need to check for will be provided in an array.
The output should be an array of numbers
The key pieces of information are the source array, the array of numbers we need to check against and the output array. How these interact is key to solving this.

Come up with Examples

You can jot down some arrays to visualise what the function should do. First you come up with the simplest version to help you see the big picture:

Input 1 - sourceArray = [1,2,3,4]
Input 2 - checkArray = [1,3]

Function does something

Output Array = [2,4]

Secondly you should consider what would constitute a complex example, at this point you should ask your boss what values are expected. Especially floating points and huge numbers. Luckily, she tells you no to both but the arrays could have over a thousand elements.

So your complex example could have a thousand elements in both the sourceArray and the numbers you are checking on....don't write it out.

Lastly, figure out if there is any need to deal with blank or non-integer values. For the same of this blog post, we are assuming she says no, its all nice simple integers.

Break it Down!

Now you should have a decent idea of what the solution should do and roughly what to expect in terms of inputs you should be able to sketch out an initial approach to the solution.

const removeNumbers = function(sourceArray, checkArray){
    //1. Get the first number in the checkArray
    //2. check each element in source array for this number
    //3. where we find it, remove the element
    //4. Repeat for the next number in the checkArray
}

If its really easy code feel free to write it, otherwise just stating in plain english should suffice for now.

Solve or Simplify

Ok, so you are happy with the initial approach, now you can take your skeleton and put some tasty flesh (or code) onto it.

Based on our approach above we decide to first build the algorithm as follows:

const removeNumbers = function (sourceArray, checkArray) {
    //4. Loop for the next number in the checkArray
    for (let i=0; i<checkArray.length; i++) {
        //1. Get the first number in the checkArray
        let numberToCheck = checkArray[i];
        //2. check each element in source array for this number, starting with 0
        for (let j=0; j<=sourceArray.length; j++) {
            //3. where we find it, remove the element
            if (numberToCheck === sourceArray[j]) {
                sourceArray.splice(j,1);  
                j--
            }
        }
    }
    return sourceArray;
}

You plug in a few test values and it seems to give you the right answer!

Are we done? Lets do this Choose your own Adventure style!

If you said Yes
You show your boss the input and outputs working. She is happy enough, but too busy to look too closely. You go on to throw together a number of other functions on the system. At some point this will probably catch up to you... but for now you have survived.

If you said No

You furrow your brow and realise there might be a better way of doing this, you roll up your sleeves and look again at the code...

Reflect and Refactor

Well done, a little extra time spent trying to improve your code is well spent.

By playing around with it for a few minutes you decide:

Those ForLoops are hard to read, as you are dealing with arrays you think to use ForEach and Some methods instead.
Now its clearer you probably don't need those comments for every part.
You recall that its not a good idea to mutate the original array so you use a new array for your results.

const removeNumbers2 = function (sourceArray, checkArray) {
   let newArray = []
   sourceArray.forEach(sourceNum => {
        if (!checkArray.some(checkNum =>  sourceNum === checkNum)){ //check if the Source array element is NOT found in the checkArray
            newArray.push(sourceNum)
        }
    })
   return newArray
}

Now that still works but is a little more robust and clearer. If you were to think about it some more, you would probably kick yourself for not using the filter method in some way.

The point is that a little time reviewing your code can make a difference, but it might take a couple of iterations to get to 'perfection'

Now you note I didn't talk about the performance of our example much. There are certain patterns you should look out for when trying to look for efficiencies. That is also a topic for another time because really if you can solve the problem, that is worth appreciating as an accomplishment in and of itself. Perfection can, and really should, wait...

Dipping my Toes into Typescript in React

Lukie Kang — Mon, 08 Feb 2021 10:41:57 +0000

I recently attended a webinar by Roy Derks and it inspired me to get into type systems since they are an awfully dry subject to try and get the concept and usefulness across.

Type systems are getting more popular in the Javascript world with Typescript by far the most popular as we begin 2021. With React being pretty popular with me, I wanted to get into Typescript via the world I am familiar with. And write about the landmines I step on along the way! By the way, I am assuming you know a little bit about React but nothing about Typescript.

In this post I will look at:

What is Typescript
What Types are
Starting a React App with Typescript support built-in
Our first TSX Component, and Typescript error.
Common Types in Typescript
Examples in Functions, Events and Children

The post ends fairly abruptly. As I often do, this is just a post to whet the appetite and get the ball rolling to get into things enough to research when using it for other things. Sound fair? Ok let's go...

What is Typescript, how is it different to use Javascript?

Typescript is known as a superset of Javascript. In other words, it adds extra functionality on top of Javascript. Javascript with Types is a good, if simplified, 3-word explanation.

The nice thing about Typescript is that it has a compile step which turns it back into Javascript. So that means it is quite easy to dip your toe into Typescript without having to do anything radically different to writing Javascript.

Having a compile step does mean that it has to be run before your browser can make sense of it. If you have been using frameworks like React however, this shouldn't be an alien concept.

Typescript files have a .ts extension as opposed to js in case you stumble across them. In React, components will use the tsx extension.

Ok, sooo... whats the Type in Typescript all about?

Programming languages come in two flavours. Statically typed or dynamically typed. Dynamically typed languages like Javascript don't make it something we need to consider, at least when writing the code initially

In statically typed languages we say what datatype it is before running it (i.e Age is an integer, Name is a string). In Javascript we never do that so we can do things like this without a thought:

const age = 12;
const another_age = "12yo";
const book = '1984';
const year_of_birth = 1984;

JS doesn't ask you what datatype you intended, which is nice except then it takes that decision itself which leads to some interesting results. In the example above, adding two of those variables can result in a variety of results. With Javascript, we don't see these errors till the code is running, and is so much harder to debug

Static typing allows us to catch errors much easier. If something is not defined with a type, or against its type definition. It gets thrown up at the compile step allowing us to address it before it gives us a headache later on.

There is more to TS than just that but let's keep it simple for now.

"OK, lets get started with it"

Let's get started with installing create-react-app with typescript installed.

npx create-react-app my-app --template typescript

If you already have an existing create-react-app app you want to convert to use typescript you can see see the relevant create react app guide

If you rolled your React app without Create-React-App, then there are too many possibilities to advise.

Anyhow after a fresh new Create-React-App, you will notice that the typical starter JS files Index and App now have the TSX extension. You will also see some other new TS files. It's slightly disturbing seeing something familiar become slightly weird but we will get there../

It's important to note, it will still allow us to use regular JS components if we wanted to (say if you have old components you want to migrate to TS later). If you check the tsconfig.json in the root of the application, there is an option to change this called 'allowJs'. As I said earlier, once you have Typescript setup it doesn't mean you have to always use it... but yeah, this would be a pointless blog post if I didn't! Quick note: If you are converting JS files to JSX files you may need to restart the server to get React to realise it.

Speaking of which, you can start the server as you would any create-react-app with an npm start or yarn start depending on which one you like using.

Our first TS component, let's do proper props.

We can create a component as we would otherwise but this time rocking the new tsx extension:

import React from 'react'

export const OurFirstTSXComponent = () => {
    return (
        <div>
            <h1>Hey this is in Typescript!</h1>
        </div>
    )
}

That shouldn't be too shocking. If you are running the React server you should see the component works as you'd hope. Regular JS is fine till we start using some of the things Typescript cares about. Like, say, props...

import React from 'react'

export const OurFirstTSXComponent = ({username, isMorning}) => {
    return (
        <div>
            <h1>Hey this is in Typescript!</h1>
            <h3>Hello {username}</h3>
            {isMorning && <h3>Good Morning</h3>}
        </div>
    )
}

If you have the server running, this is the point Typescript starts to get interesting.

Basicially we have two props, a string and a boolean...and our first Typescript error!

Type '{}' is missing the following properties from type '{ username: any; isMorning: any; }': username, isMorning

Which is it a polite way of saying you haven't said what those props are! Note that the linting rules will do its best to highlight where issues exist. Anyhow let's sort that out in three steps:

Step 1: Define our props.

In the component, let's say what props we are going to have.

type Props = { //'Props' is an arbitrary choice 
    username: string,
    isMorning: boolean
}

Step 2: Assign the props given to that Props object.

export const OurFirstTSXComponent = ({username, isMorning}: Props ) => {

Step 3: Actually give the component props in the parent component. Since we said it was going to have username and isMorning props, we better provide them:

 <OurFirstTSXComponent username="tom" isMorning={true}/> //really regret that component name now!

To those of you who are used to Proptypes, that should not be too shocking. But as we have just seen, typescript tells you if there is an issue on compile which ensures it gets dealt with.

What if a prop is Optional?

Short answer, using ? makes the prop optional:

type Props = {
    username?: string,
    isMorning?: boolean
}

In regular React, props are generally optional which, if you are like me, means I often include things that later on I don't need. Typescript, as you have just seen, makes us very explicit about the props we want and optional props are now the exception which is probably for the best.

And what about default Props?

Thats a fair point. As a quick reminder, default props in react allows us to ...well, set a default value for our props:

OurFirstTSXComponent.defaultProps = {
    username: "Alice"
    isMorning: false
}

In Typescript we can use classic JS ways of setting default values inside of Parameters:

export const OurFirstTSXComponent = ({username = "Alice", isMorning = false }) => {

Easy! If you don't do anything else with Typescript you already are getting some benefits. But sorting our props was just paddling in the lake of Typescript so lets get swimming into some deeper waters and look more closely at types and how they relate to functions.

So what are some types in Typescript?

This probably won't shock you but types are the foundation of Typescript, we touched on a few when looking at props. It's good to get more familiar with at least the ones you use in regular JS.

Common Garden Types

First of all let's cover off the ones that should not need explaining:

String
Number (also bigInts)
Boolean

But wait? How do you say a variable is a string exactly? Well this is the syntax you will see a lot when it comes to Typescript:

let isHappy: boolean = false;

As opposed to a two-step process with let isHappy = false there are three steps which I call assignment-type-value. The typescripty bit is the : boolean in the middle that says what type we want the variable to be.

New Types on the Block

Here are a few more basic types you might come across that are found in Typescript:

Arrays can be declared stating what you expect them to contain: let scores: number[] = [1,2,3,4] is an array of numbers.
Tuples are Arrays' more formal sibling and allows you express an array of fixed length where the types are known:

let product: [string, number]
product = ["Shoes", 34] //will work
product = ["Shoes", "34"] //will NOT work

Enums are common in other languages like C#, which basically allows you to map a word to a number. In other words, making it easier for a human to assign:

emum Size {
    Small,
    Medium,
    Large
}

let s: Size = Size.medium

So we can call the text value by calling it like an array so let sizeName: string = Size[1] would map to Medium.

As quick aside, unions which are something I will go into at a later point but one quick takeaway is we something like this to specify the valid parameters for that variable.

meal: "breakfast"|"lunch"|"dinner"

Which is cool.

Weird metaphysical types

Unknown is what it says when we don't know what it is. If its something provided by the user for example. We should probably know what the vast majority of our inputs are if we are coding them ourselves!

Any is any type, and effectively is doing what JS has been doing. Why use it? Sometimes it might genuinely be needed or as part of a hybrid TS/JS/3rd party library situation. Just try not to lean on it too much!

Void is like the opposite of any. It won't have any type. This is typically used in functions where it won't be returning anything explicitly.

Never is a weird one. Basically saying it will never exist. Typically in functions that do not complete and so won't be able to return anything (undefined or otherwise)

Function Types

Assigning types to variables is fairly simple based on the above but what about using them with functions? Let's take a better look at that!

Let's take a basic button component which is fed a function via props:

import React from 'react'

export const Button = ({onClick}) => {
    return (
        <button onClick={onClick}>Hello!</button>
    )
}

//In the parent component we can have something like:

<Button 
    onClick={() => {
        console.log("How is it going?")
    }}
/>

Linting rules for typescript will be pointing out that because we have not specified the output of the function, it is considered an Any type. This is not good typescripting so let's fix it up.

As we are not returning something we can use that mysterious void type, in a similar format to before.

type Props = {
    onClick: () => void  // or...
    onClick:(text:string) => void
    // if, for example, we were passing in a string value to the function
}
export const Button = ({onClick}: Props) => {
    //etc

There is a bunch of ways we can define functions in TS but this is the most typical approach.

Handling React Events in Typescript

Events, in this case, relate to interacting with the component in some way.

In JS world we just specify e and off we go:

const handleClick = (e) => {
    //stuff
}

In typescript it will complain that the event hasnt been specified so we can do something like this:

type Props = {
    onClick: (e: React.MouseEvent),
    onChange: (e: React.ChangeEvent)
    => void; //Mouse Event  
}

But this is just saying we have a mouseevent, Its good to be specific with typescript for it to offer the best advice as you code. So we can say especially it is, for example, a form element, or button element:

type Props = {
    onClick: (e: React.MouseEvent<HTMLButtonElement>),
    onChange: (e: React.ChangeEvent<HTMLFormElement>)
    => void; //Mouse Event  
}

There are a whole bunch of Events and Elements you can specify. VSCode's IntelliSense is a good way fo figuring out what you should reach for a given event.

Dealing with Child Props

Simple props are easy enough to plan for as we did earlier. But what about children of the component. For example, what if we had a button with an image tag:

   <Button 
    onClick={(e) => {
        e.preventDefault()
        console.log("How is it going?")
    }}>
      <img alt="something" src="somewhere.png"/>
    </Button>

If its just a string, from a < H1 > instead of an < IMG > we could just explicitly say the component has a child that returns a string:

type Props = {
    children: string,
    onClick: (e: React.MouseEvent<HTMLButtonElement>) => void; //Mouse Event  
}

However if we were using more complex or unknown children, this can start getting hard to manage in the props. This is where we have a little help in the form of refactoring our component to useReact.fc:

export const Button:React.FC<Props> = ({onClick}) => {
    return (
        <button onClick={onClick}>Hello!</button>
    )
}

This ensures the children of a component are correctly typed. Note how props are using the angled bracket syntax we used for events earlier. You will get an error if you use two sets of :. It is fair to say, however, that this pattern is debated but this is how I tend to operate.

Wrap Up

This post was supposed to be a quick look at how to get started with Typescript with React and what you might commonly find in your initial steps with it. Hope it has helped.

As for Typescript itself. Definitely consider picking it up if you are using React. Having a build process is something you are already familiar with and, while it is a little extra typing (no pun intended) It helps avoid issues later down the line when they are much harder to spot. The main takeaway here is that even a little typescript seasoning can be a tasty benefit to your apps even if you don't know all the ins and outs of it. And hopefully, it gives you a taste for learning more!

Don't be afraid of ... Testing Fetch requests in React (Part 4 of 4)

Lukie Kang — Sun, 31 Jan 2021 23:19:17 +0000

So this is more for my own reference as part of a series on testing. Since I picked up testing React, what I have learnt has become stale so I'd really recommend a browse of Kent C.Dodds's post to really boost your testing game in React and avoid some of the common issues people do in testing... which I do here!

In previous posts, I have been going over how to test common things we would do in React such as:

Component Elements
Forms
Props

That is quite a few things in our testing toolbox. Now another common thing you might do in react is fetch data from a backend or external API. This can get a little hairy so I wanted to break it down and go slowly through it. In this post we will cover.

Mocking APIs
Asynchronous Testing
Additional Information

Mocking APIs

Now let's assume we have a Book component which fetches data from an external API when it provides an ID.

From previous posts, we know how to provide props and variables to a test, so we could easily give the test an ID to then fetch from the external API. This is doable but perhaps not a good idea. Still, we need to set up that initial step of the fetch request as that is a param we pass in when using the book component:

const match = {
    params: {
        id: 'abc1234567'
    }
}

We don't want to actually hit the API as that takes a little time to do and introduces a dependency to the API which makes it harder to reliably test.

Instead, we want to make up a result we can use for the test. To make generating fetch requests a snap I reach for a library called jest-fetch-mock which can be installed by:

npm install --save-dev jest-fetch-mock

Now, if this is something you are expecting to do a lot of, I recommend following the setup steps provided. For the sake of a punchy blog post we will do things quicker and dirtier.

Once we have it installed we can override global fetch with our new package:

global-fetch = require('jest-fetch-mock') allows us to override the normal fetch for our test suite and instead allow us to provide our own JSON.

Now we have global fetch configured we need to perform the fetch in our test, here is an example, obviously, we need to tailor it according to the fetch we would want to perform. Its a really common error for me to fail to replicate what is coming back from the fetch so its worth triple-checking your mocked response is in the right format!:

fetch.mockResponseOnce(JSON.stringify({
    title: "1984",
    author: "George Orwell"
}))

So let's see how our test now looks with all that information:

import React from 'react'
import { render, cleanup } from 'react-testing-library'; 
import Book from './Book';

global.fetch = require('jest-fetch-mock'); // Makes the test use 'jest-fetch-mock

afterEach( () => {
    cleanup
    console.error.mockClear()
})

console.error = jest.fn()

const match = { //our params to grab the book info from the ID provided.
    params: {
        id: 'abc1234567'
    }
}

test('<Book />' , () => {
    fetch.mockResponseOnce(JSON.stringify({
      title: "1984",
      author: "George Orwell"
    }))
  const {debug}  = render(<Book match={match}/>)
  debug()
});

We are not actually testing anything yet but that will come... first we have a little problem.

If you check the debug (making sure to use the fetched data in some way in the book component) you'll notice that the data we fetched isn't being used. This starts to make sense when you consider it is a fetch request and they are asynchronous. We need a way to wait for the result to come back before proceeding. Handily enough, my next section is called...

Asynchronous Tests

How do we get this data to show?

waitForElement is some magic in React Testing Library that waits for the element to show up before proceeding. We grab it from React Testing Library like so:

import {render, cleanup, waitForElement} from 'react-testing-library

As with previous tests we need to define a target using a query such as getByText. But of course the problem is that we need to wait for that to exist on the page, to do that we need to make the test asynchronous. That is not as scary as it may sound as we can use the async and await syntax, like so..

test(<Book/>, async () => {

  //other stuff

  const book = getByText('1984') //This will NOT work as the element doesn't exist.
  await waitForElement(() => getByText('1984')) //This waits for the element to exist so that...
  expect(getByTestId('book-title').textContent).toBe('1984') //...this WILL work.
})

And.... you should have the book data coming through in the debug view. A common issue is getting the mock fetch in the correct format your component is expecting. Let's have a look at the test in full:

import React from 'react'
import { render, cleanup, waitForElement, getAllByTestId} from 'react-testing-library'; 
import Book from './Book';

global.fetch = require('jest-fetch-mock');

afterEach( () => {
    cleanup
    console.error.mockClear()
})

console.error = jest.fn()

const match = {
    params: {
        id: 'abc1234567'
    }
}

const book = {  //makes life easier as we can reference this in multiple places in the test.
    title: "1984",
    author: "George Orwell"
}
test('<Book />' , async () => {
  fetch.mockResponseOnce(JSON.stringify(book))
  const {getByTestId}  = render(<Book match={match}/>)
  await waitForElement(() => getByTestId('book-title'))

  expect(getByTestId('book-title').textContent).toBe(book.title)
});

As for the JS, this is a snippet of how it might look like:

class Book extends Component {
  state = {
    book: {},
  }

  async componentDidMount() { //Example API call
    try {
      const res = await fetch(`https://somebookapi.com`);
      const book = await re,hs.json();
      this.setState({
        book,
      });
    } catch (e) {
      console.log(e);
    }
  }

  render() {
    const { book } = this.state;
    if(!book.title) return <h1 data-testid='loading'>Loading</h1>; //This check is important as it stops the element existing before it has the content from the API. You could add a test to check for this prior to the waitForElement.
    return ( 
      <h1 data-testid='book-title'>{book.title}</h1> //The element we are looking for
      <h3>{book.author}</h3>
    )
  }
}

Phew, there is a number of steps to getting it up and running but as long as you take it step-by-step and know the right react testing library magic you should get through it.

As always this was just a look at one way of getting async tests to work, depending on what exactly you are doing there may be a better approach. The Jest docs has good info about several async methods. So I would give that a good read when you start thinking about it.

Neater Testing with the tests folder

There is plenty you can test, and I have only covered a few testing angles for the sake of simplicity. Before you know it you will have test files everywhere and I haven't really mentioned a convention of how to organise them.

For react apps I try and group components that related to a particular model, say Books. We don't have to have our tests sitting in the same folder as the component, there is a special folder __tests__ where it is expected to place our tests. Remember that you need to update the component imports in the tests as well as any other components that rely on the moved files.

Code Coverage

You may hear people that are really into testing say things like, "our app has 95% test coverage" which sounds pretty impressive but what do they mean? Let's see if we can work it out by checking our own coverage:

npm test -- --coverage

Wierd syntax but it will spit you out a table breaking down, on a component by component basis how much of your code is covered by a test, splitting it up by Statements, Branches, Functions and Lines.

--------------------------|----------|----------|----------|----------|-------------------|
File                      |  % Stmts | % Branch |  % Funcs |  % Lines | Uncovered Line #s |
--------------------------|----------|----------|----------|----------|-------------------|
All files                 |    46.07 |    19.35 |    46.67 |    60.66 |                   |
 App.js                   |       50 |      100 |        0 |       50 |                13 |
 Book.js                  |      100 |      100 |      100 |      100 |                   |
 Book Form.js             |      100 |      100 |      100 |      100 |                   |
 BooksList.js             |    90.91 |      100 |      100 |       90 |                22 |
 NewBook.js               |      100 |      100 |      100 |      100 |                   |
 index.js                 |        0 |        0 |        0 |        0 |     1,2,3,4,5,7,8 |
 registerServiceWorker.js |        0 |        0 |        0 |        0 |... 25,126,127,128 |
--------------------------|----------|----------|----------|----------|-------------------|

I wouldn't lose too much sleep over 'All Files' value as there is a bunch of files that you typically don't care for testing.

Code Coverage can point out testing gaps in the code but it does not say if the tests are actually good ones. Use it as a pointer where improvements might be needed but not as a score for how good your testing is.

That's a wrap

Ok, I have written a fair amount of words with regards to testing and I feel like I have only scratched the surface! Since writing this, this information is already getting superseded. But hopefully how I picked it up is a good starting point in general. There is much more the tools used can do with regards to testing so all I can say is to have the Jest and React Testing Library docs handy when starting to build out your own tests and see what works best for you.

Don't Be Afraid of ... Snapshot Testing and Mocking Forms and Props in React

Lukie Kang — Sun, 24 Jan 2021 23:20:22 +0000

In our last post, we got introduced to React Testing via React Testing Library. For the sake of keeping things short and sweet, we left out a few extra things to talk about. For that reason, this post will be quite a mixture of things. In this post we will look at:

Snapshot Testing
Mocking a Form submission
Testing for errors
Testing Specific Input Values
Negative Assertions

Snapshot Testing.

Snapshot testing sounds a bit like what it sounds like. If you took a photo of the resulting code, did something then happen that makes it look different to that photo? Because we take the snapshot at a high-level on the component, typically the enclosing Div Snapshot testing lets us watch for changes across everything under that element. However, since Snapshot testing compares to a moment frozen in time, it works great for components that are static in nature, but ones with dynamic changeable elements, they will just be noise. Certainly, they get in the way while actually doing TDD. Anyhow. let's look at implementing it.

Implementing Snapshot Testing

Jest makes this a doddle. First we need to grab container from our render:

const {container} = render(<NewBook/>)

Container being the contents of the rendered component including any child components. Then we want to say what we expect to match the Snapshot:

expect(container.firstChild).toMatchSnapshot();

The firstChild in this regard is the enclosing div.

Soon as you have done that for the first time, Jest will do something cool, it will create the snapshot for us in the __snapshots__ folder. If you check it out you will see it is basically the output of the enclosing div. That's cool but here what I said about it being best for things that done change very often, what if you decide you wanted to add or tweak something? For example, an extra

tag? Soon as you have done that the test suite will be pointing out it no longer matches the snapshot:

expect(value).toMatchSnapshot() Received value does not match stored snapshot 1. - Snapshot

Snapshot Summary
1 snapshot test failed in 1 test suite. Inspect your code changes or press u to update them.`

If it was a tweak that was intended, then as it says, it's straightforward to update the snapshot with a tap of the u key. This also makes it easy to accept something that has not been intended so be careful that Snapshot does not make things too easy for you to the point you snapshot intended stuff.

Still, snapshot testing is a very useful way of quickly flagging when something changes and definitely should be considered for less dynamic components. This not intended as a replacement for unit testing, and it's not really practical to write a snapshot so they are not really compatible with TDD principles but provide a good quick additional layer of testing. You can learn more from the JEST Documentation about Snapshots

Mocking and Spying a Form Submission

Ok, so let's take another look at Mocking which I touched on in my first testing post. But this time we can apply it to a more complex real-world example. Namely, let's look at a testing a form component. This is a common use case for mocking a function as we don't want to actually submit data to the database when we test things. I am sure we all have databases that are full of entries like "test" and "aaaa" from our manual testing days, let's see about reducing that a little!

So let's go with a New Book Form that takes a book title and submits it, not too complex but will do as an example. First of all let's build out the test to:

Check the button exists,
And tell the test suite to click it.

import React from 'react'
import { render, cleanup, fireEvent} from 'react-testing-library'; //Added FireEvent from React Testing Library
import BookForm from './BookForm';

afterEach(cleanup)

test('<BookForm>', () => {
  const {debug, getByText} = render(<BookForm/>)
  expect(getByText('Submit').tagName).toBe('BUTTON') //Looks for an element with the text Submit, just for the sake of being different.
  fireEvent.click(getByText('Submit'))
  debug()
});

So let's build the component with the button and also a little cheeky function when the form is submitted:

import React, { Component } from 'react'

export default class BookForm extends Component {
    render() {
        return (
            <div>
               <form data-testid='book-form' onSubmit={ ()=> console.log("clicked the button!")}>
                   <button type="submit">Submit</button>
               </form>
            </div>
        )
    }
}
```



The reason I added that click function is to show that when we run the test, we can see that `clicked the button!` appears in the log:

PASS src/BookForm.test.js
● Console
console.log src/BookForm.js:10
clicked the button!




That might be useful in testing things work in a quick and dirty way. But if that form submission actually did something, then our tests would start getting dangerous so we need a safe way to submit the form when testing. To do this we need to consider the pattern we use for the component so we can safely mock it. This involves providing the function that runs on submit via props. The component we will end up with looks like this:



````js
export default class BookForm extends Component {

    state = {
        text: ''
    }
    render() {
        const {submitForm} = this.props
        const {text} = this.state
        return (
            <div>
               <form data-testid='book-form' onSubmit={ ()=> submitForm({text})}>

                   <button type="submit">Submit</button>
               </form>
            </div>
        )
    }
}

Ok, so the big question here is, why have we bumped the submitForm function to props? Because we need to change what that function does if it is run by our test compared to its normal job in the application. This will make sense when we look at the test we have written:

import React from 'react'
import { render, cleanup, fireEvent} from 'react-testing-library'; 
import BookForm from './BookForm';

afterEach(cleanup)
const onSubmit = jest.fn(); //Our new Spy function

test('<BookForm>', () => {
  const {debug, getByText, queryByTestId} = render(<BookForm submitForm={onSubmit} />) // The spy function is used to for the submit form

  //Unit Tests to check elements exist
  expect(queryByTestId('book-form')).toBeTruthy()
  expect(queryByTestId('book-form').tagName).toBe("FORM")
  expect(getByText('Submit').tagName).toBe('BUTTON')

  //Check Form Submits
  fireEvent.click(getByText('Submit'))
  expect(onSubmit).toHaveBeenCalledTimes(1); //This tests makes sure we van submit the spy function
  debug()
});
```



So to repeat what the comments say, we...:

1. Create a spy function that does nothing
2. This function is passed via props when we render the component.
3. We test to see if it runs with a `expect(onSubmit).toHaveBeenCalledTimes(1)`. Which hopefully it does.

This is all very clever but we have not done much but tested the form submits ok. Which is important but let's take things a step further looking at the inputs that are submitted.


### Bonus: Spying on Console Errors

We can spy on pretty much anything we like. Even errors when a component is not called properly. Let's say, for example, we had a component that needs a bunch of props with specific proptypes defined, we may want to test what happens when we don't provide them. So we can use the mocking function to handle the console errors like so:



````js
console.error = jest.fn()
test('<ExampleComponent'>, () => {
  render(<ExampleComponent />)
    expect(console.error).toBeCalled()
});
```
{% endraw %}


Of course, while this gets rid of the console error, this will still show any errors that may occur due to the lack of props passed in.

Right, back to our scheduled blogging.

## Specifying Input Values for testing

To make our testing more aligned to real-life we may want to write a test that checks that a form can be submitted with certain specified inputs. In our example, we want our Book Form to have a text input for a title. The way you might approach this is as follows:

1. Find a way to target the relevant part to be tested (i.e. the input field)
2. Change the value of the input.
3. Check that the form was submitted with the value we wanted.

That is pretty good but there is a gotcha you need to be aware of. Changing the value of the input does not cause React's state to update in our test, we need to use a **change* event to update the value for the change to occur. Here are the additional parts we need to add to do this:
{% raw %}



````js
test('<BookForm>', () => {
  const {getByLabelText} = render(<BookForm submitForm={onSubmit} />) //Adding the getByLabelText

  //1. Unit Test to check our input element exists
  expect(getByLabelText('Title').tagName).toBe('INPUT') //test to make sure the input is there

  //2. change the Input Value using the change event.
  fireEvent.change(getByLabelText('Title'), {target: {value: "Girl, Woman, Other"}}) //This event sets the value of the input and lets the change affect the state. 

  //3. Check Form Submits as expected
  fireEvent.click(getByText('Submit'))
  expect(onSubmit).toHaveBeenCalledWith({title: 'Girl, Woman, Other'}) //This checks that the submission has the title we asked it to have earlier.

```



  Note that I am using a new query, *getByLabelText* which, unsurprisingly looks at the text of the label to find the element we are after. Step 2, is where we use our fireEvent. since our target is the input element, we need to drill down to find our value and change it. Finally, we can check what our Spy function used with the *toHaveNeenCalledWith* method which is hopefully an easy one to understand. 

So we better see what the React code looks like that passes these tests:



  ```js
import React, { Component } from 'react'
export default class BookForm extends Component {

    state = {
        title: '' //what gets sent on submit
    }

    render() {
        const {submitForm} = this.props
        const {title} = this.state
        return (
            <div>
               <form data-testid='book-form' onSubmit={ ()=> submitForm({title})}>
                   <label htmlFor="title">Title</label> //Remember that it is the text of the element our test is looking for not the HTMLFor
                   <input id="title" type="text" onChange={(e) => this.setState({title: e.target.value})}></input> //Quick and Dirty input controlling
                   <button type="submit">Submit</button>
               </form>
            </div>
        )
    }
}
```



Cool, now it isn't the most complex form in the world but hopefully, you can see how the techniques can be scaled up accordingly and also are getting a grasp of how simply we test dynamic content. If you set up the snapshot test earlier you will now see they can be a little annoying when you are writing out the code!

### Bonus: Negative Assertions

In our test we had the following line: 

> expect(onSubmit).toHaveBeenCalledWith({title: 'Girl, Woman, Other'})  

Which is checking if that assertion is true if it **did** happen. There might be occasions where passing means checking if something **did not** happen. In Jest that's as easy as adding a `not` as part of the method like so:

> expect(onSubmit).not.toHaveBeenCalledWith({title: 'Girl, Woman, Other'}) 

This can be useful when, for example, you are testing what happens when data is not provided by props to a component that needs them. Which is handy as our next topic is...


## Mocking Props

So we are able to emulate form data, but another thing we commonly deal with in React is props. If our component needs props, we need a way of providing some. On a basic level, this is quite straightforward if all the above-made sense. In our test we need to: 

1. Mock out what the props should be 
2. Include those props when we render:



````js
console.error = jest.fn()

const book = {
  title: "The Stand"
}

test('<Book> without Book props', () => { //No props so 
  render(<Book />)
  expect(console.error).toHaveBeenCalled();
})

test('<Book> with Book Props', () => {
  render(<Book book={book}/>)
  expect(console.error).not.toHaveBeenCalled();
})
```



Pretty cool right? Well yes but now we are into multiple tests, we have a little gotcha to be aware of. In the example above we have two places where we check if the console.error has been called. Once without props and a second time without props where we expect that it will not run. However, if you run this it will fail as it will say that console.error was run the second time.... what gives?!

Put simply, console.error was called when it ran the first test so it thinks it was called when doing the second. The fix for this is fairly simple and requires a tweak to our clean up function.



````js
afterEach( () => {
  cleanup
  console.error.mockClear()
})
```



Now the memory of the console error is cleared between tests and things are more normal.

There are unfortunately lots of little gotchas you will hit as you start testing real-world components. A common one is around React Router expecting things that are not found in the test by default, it's beyond the scope of this blog post to cover all use cases but its the kind of thing that is going to [need some research](https://stackoverflow.com/questions/43771517/using-jest-to-test-a-link-from-react-router-v4) when you encounter them. 

Taking a step by step approach when writing tests and code does help narrow down and help search for solutions to such issues.

## Wrapping things up

This is one of those annoying blog posts where I touch on some things and ignore others. hopefully testing props, forms and inputs are useful to most users of React. My goal is to give a grounding in 60% of what you would typically test and give you a little context to search for the other 40%

Next time we can look at testing APIs and the async fun that brings!

Don't be Afraid of... Testing React with React Testing Library

Lukie Kang — Mon, 18 Jan 2021 00:01:46 +0000

Last time I explained a little about testing concepts and basic testing. As a React developer primarily, I tend to test things that are in React. So let's take a React-specific focus on testing, using tools that are the simplest ones to reach for. If you use React but have never bothered with testing, this might be useful to get started with minimal fuss.

In this post we will look at:

React Testing Library
Unit Tests with Data Test Ids
Interactive Tests with FireEvent
Clean up
Integration Testing with a little gotcha.

Introduction to React Testing Library

To be able to test React code life is much easier with React Testing Library to allow us to properly query whats going on with React to build our tests. The other popular dog in this world is Enzyme. Which is better is a debate for an internet search. But React Testing Library has more of a focus on the DOM and what the user actually sees whereas Enzyme focuses on the component itself. Remember that for later...

If you are using create-react-app then the good news is that React Testing Library is built-in, otherwise, we can add it with:

npm install --save-dev @testing-library/react

Quick note: For the sake of clarity and brevity, I'll be breezing over the step by step TDD approach, namely:

RED: Start with the simplest test that proves something is missing.
GREEN: Write the simplest way to make the test pass.
Refactor, improve the code till you are happy with it

But hopefully, you can see where those steps would exist in the process.

Unit Tests with Data Test IDs

Let's pretend we want to have a component called Greeter whose job it is to show a div that says 'Howdy'. In the test file, we can provide assertions using a bunch of queries made available to us via React Testing Library (and DOM testing Library which is merged into it).

import React from 'react'
import { render } from 'react-testing-library';
import Greeter from './Greeter';

test('<Greeter/>', () => {
  const {debug, getByTestId}= render(< Greeter/>);
  debug(); //outputs the dom to see what it is, useful for building tests so handy for building the test.
  expect(getByTestId('greeter-heading').tagName).toBe('div');
  expect(getByTestId('example-heading').textContent).toBe('Howdy');
})

So what's this getByTestId business? Data Test IDs let us identify elements so we can see what's going on there. We can assign a test id by simply adding the id in our JSX we write to pass the test:

import React, { Component } from 'react'
export default class Greeter extends Component {
    state = {
      greeting: "Howdy" //Let's assume it is in the state because it might change
    }
    render() {
      const { greeting } = this.state
      return (
        <div data-testid='greeter-heading'> 
                { greeting }
        </div>
        )
    }
}

Of course, we don't have to use data test ids. To get a fuller taste of what you can query look at the cheatsheets for React Testing Library and DOM Testing Library. It should cover everything you might want to query so I don't have to!

Building More Interactive Tests

React is all about interactions so we need to test that the interface actually works by testing the interactivity of React.

For this let's dream up a component that is a counter that ticks up every time we click the button. Let's jump to the point where we have a test and js file that is not yet interactive, in other words, a dumb button that says 0:

//Test File
import React from 'react'
import { render} from 'react-testing-library';
import Counter from './Counter';

test('<Counter />', () => {
  const { debug, getByTestId } = render(<Counter />);
  const counterButton = getByTestId('counter-button')
  debug();

  expect(counterButton.tagName).toBe('BUTTON');
  expect(counterButton.textContent).toBe('0');
});

//JS
import React, { Component } from 'react'

export default class Counter extends Component {
    state = {
      count: 0
    }
    render() {
      const {count } = this.state
      return (
        <div>
            <button type="button" data-testid='counter-button'>
                {count}
            </button>
        </div>
        )
    }
}

Ok, so we need a test to define what happens when there is an event on that button. So first we need a way of watching events that are fired...

//Test File
import React from 'react'
import { render, fireEvent} from 'react-testing-library'; //Added FireEvent from React Testing Library
import Counter from './Counter';

test('<Counter />', () => {
  const { debug, getByTestId } = render(<Counter />);
  const counterButton = getByTestId('counter-button')
  debug();
  expect(counterButton.tagName).toBe('BUTTON');
  expect(counterButton.textContent).toBe('0');
  fireEvent.click(counterButton) //sends a click to the counter button
  expect(counterButton.textContent).toBe('1'); //expect it to be one after the first click.
  fireEvent.click(counterButton) //sends another click to the counter button
  expect(counterButton.textContent).toBe('2'); //expect it to be two after the second click
  debug() //This will output the DOM in the terminal after the additional clicks so its a good place to check whats happening.
});

At this point, our test suite should be telling us we are failing the test. Well, that's what happens if you have a button that does nothing so let's fix that...

import React, { Component } from 'react'

export default class Counter extends Component {
    state = {
      count: 0
    }

    count = () => {
        this.setState( (prevState) => ({
            count: prevState.count +1
        }))
    }

    render() {
      const {count } = this.state
      return (
        <div>
            <button type="button" 
            onClick={this.count}
            data-testid='counter-button'>
                {count}
            </button>
        </div>
        )
    }
}

Cleanup, because testing isn't just always fun.

One little housekeeping touch. We want to ensure that after each test we clean things back up so it's all fresh for the next step. Handily React Testing Library gives us a cleanup method just for that purpose if we add that, that will make sure each test has a clean slate.

import { render, fireEvent, cleanup} from 'react-testing-library'; //Added from React Testing Library
afterEach(cleanup)

test('<Counter />', () => { //etc

Without that, you will get duplicate values in the DOM which is not ideal. It's easy to forget about but please don't!

Integration Testing with Forms

Ok so we have the basics down let's try and apply what we have learnt to a slightly more challenging but realistic example (but not that realistic, as you'll see)

Let's imagine we have a React app that is all about books and one of the features we want is the ability to add a new book. For that we might want a component for a new book with a book form component that is used inside :

NewBook
BookForm

I like to scaffold empty components before we get into the tests, but of course, that's up to you.

So I would like the NewBook component to:

Show a heading that says "Enter a New Book"
Show the Book Form

If we hold onto our test-id pattern from before it will be straightforward right? Here is our test...

import React from 'react'
import { render, cleanup } from 'react-testing-library'; 
import NewBook from './NewBook';

afterEach(cleanup)

test('<NewBook>', () => {
 const {debug, getByTestId} = render(<NewBook/>) //Grab the tools we need for this next.

//Check Page Title is present and correct
 const heading = getByTestId('page-title') //This id might be a good pattern between multiple components
 expert(heading.tagName).toBe("H1") //Note the caps in 'h1'
 expert(heading.textContent).toBe("Enter a New Book")

//Check Book Form is present
 expert(queryByTestId('book-form')).toBeTruthy(); //Lets talk about this line.
 debug()
});

We use queryByTestID where we are a bit less sure about if it exists or not.

And... after checking that the test fails correctly, let's look at a first attempt New Book component:

import React, { Component } from 'react'
import BookForm from './BookForm'

export default class NewBook extends Component {
    render() {
        return (
            <div>
                 <h1 data-testid='page-title'>Enter a New Book</h1>
                 <BookForm data-testid='book-form'/>
            </div>
        )
    }
}

And we get a Failure message like this:

expect(received).toBeTruthy() Expected value to be truthy, instead received null

What gives?!

Remember at the start of the post, I said now React Testing Library looks at the resultant DOM whereas Enzyme looks at the Component. This is what makes it different.

In this case, the Component BookForm doesn't exist in the DOM, just its contents. So we need the data-testid to be on the form within the BookForm component. It is possible to mock the BookForm component (that's for another post) so that it can be picked up in the test, but the default 'thinking' of React Testing Library wants us to consider the result in the DOM. In other forms, it is integrated with the Book Form component.

Soon as we create the BookForm component with something that has the testId we can pass the test (though maybe not very robustly):

import React, { Component } from 'react'

export default class BookForm extends Component {
    render() {
        return (
            <div>
               <form data-testid='book-form'></form>
            </div>
        )
    }
}

The resultant HTML from the debug output might help show what is going on if you are a bit lost:

    <body>
        <div>
          <div>
            <h1
              data-testid="page-title"
            >
              Enter a New Book
            </h1>
            <div>
              <form
                data-testid="book-form"
              />
            </div>
          </div>
        </div>
      </body>

Phew, let's wrap this up

We covered the basics of React Testing using React Testing Library. In order to do this, we are going lightly over a few concepts and breezing over the quality of the tests. Hopefully, that is something I'll find time to do a deeper dive of later, my main goal is to get people up and running with the infrastructure of React testing.

However next time I think I will talk about the cool kid of Testing, Snapshot testing as that is cool... in the world of testing anyhow.

Don't be afraid of ...Test-Driven Development

Lukie Kang — Sun, 10 Jan 2021 23:52:35 +0000

Test-Driven Development (TDD) is a term that gets a subset of people really excited and a larger chunk with dread. As I have been playing around with it more and more I wanted to reflect on my own understanding and the theory behind it as well as provide a small, non-scary example to help get things started. In this post we will cover:

My own introduction
What TDD is, and common concepts.
A simple unit test using Jest
A quick overview of Integration Testing and Mocks.

My Introductions to TDD as a former business analyst.

"Well if I don't have the code, what am I supposed to test?" - Me, several years ago.

As a business analyst at the time, it turns out I actually was very test-orientated but just hadn't realised it:

In a traditional project, the business analyst is the person who talks to the business and understands their needs and turns that into a set of requirements for the development team to implement. These requirements should be clear, measurable and actionable so that the development team builds what the business has asked for (which is debatable, to say the least).

The point is that we are already thinking about the outcomes we'd like before we begin to make it happen. In coding, we get so wrapped up in the challenge of making it happen, TDD makes us consider what success actually looks like before we get started.

What is TDD as others see it??

Researching online it seems it is quite confusing, people have different views on how tests should be used with development.

Test Oriented Development, AKA lots of test are written for the code
"Test-First Development", AKA We write the tests first, then write code.
"Test-Driven Dev and Design", AKA the tests we write inform us of how we expect the code to function and be designed.

The point here is that the Internet holds many opinions on what TDD should be, so do different organisations. This is going to be my take on it because it's my blog. But as you learn more, try to keep an open mind and be flexible about how different people approach it.

One term you might hear often is production code. In the context of TDD, that is code that is not a test. Maybe it will be in the Production environment, maybe it won't but that's what we see it as.

The origins of TDD comes from eXtreme Programming, a framework about how development should be. Slowly many elements of it have been getting adopted so it's no longer viewed as quite so extreme. From there the idea developed with Kent Beck writing his 2003 book "Understanding Test Driven Development". That's a good place to start if you want to get into the theory and have a reliable source of truth. But let's look at the common drawback of TDD you may hit early on...

It takes so long to write tests AND the code!

Well yes, in a new team using TDD, it does take much longer to implement, but the bug fixing and testing steps are much more reduced. Overall it goes take longer but it comes with some benefits:

Better design
Fewer bugs in production
Easier Integration Testing

In other words, TDD feels like a lot of faff because, yes it takes take much longer to produce the code when you have to write tests. As a new coder, writing code is what you focus on, so TDD feels like it just doubles your time.

In the world of real shippable code we have to consider:

Ensure it works as intended a whole
Ensure it works with the rest of a bigger application or system (Integration Testing)
Ensure old features didn't break when we added the new feature (Regression testing)

This is a significant chunk of time overall, and this is where TDD really trims things down. Its annoyingly sensible, more work now to save work later.

As we will see soon, it is also like having a team member who can point out when things go wrong so you don't have to. When it is done well, it makes a coder a happier coder, which is also a Good Thing.

Skills of TDD

TDD isn't like, say using camelCase, where you either do or don't do. Its a discipline, like any physical exercise, that will feel uncomfortable and pointless, to begin with, but with practice and more complex scenarios, you will start developing the skills that make it worthwhile.

Writing Good tests, regardless of if you do it before or after.

If your test doesn't test your code in a meaningful way, if there are special cases we don't consider, for example, then the test won't do its job properly. Learning how to write a good test, or set of tests is an important skill.

Write the Test First

Trying to think in terms of the test without code makes it easier. You get to think about requirements without getting hung up on in the implementation. However, this is a shift in mindset compared to building a function in a linear (e.g. Input, Do Something, Output) fashion.

Design Thinking with Tests

This is hard and something that comes with time but taking a step back to consider the requirements for the software itself in your testing is the key to writing the code you need to write and no more.

Red, Green, Refactor.

If there is one thing to remember from this post, here it is.

RED: Start with the simplest test that proves something is missing.

Think of a missing feature as a bug in your code. The test should fail because it doesn't exist yet. This is where design comes in, thinking smart about what you want to exist before you make it allows us to consider design rather than jump straight into the code. We want it to fail before we make it pass, this lets us prove the test is good, in other words, we test the test so we are confident in the test.

Green: Write the simplest way to make the test pass.

The next step is to pass the test. At this point, you can be confident that the code works for that specific test because you have a test that works.

Refactor, improve the code till you are happy with it.

This might happen several times, repeating till the code is where you would like it, reducing duplicate code or tightening it up. This is important to ensure the code is something you enjoy working with over the long run.
Additionally, when you have the tests in place you can quickly see if your refactoring is breaking things which makes it a more relaxing proposition.

However, make sure the refactor is within the constraints of the test. the golden rule here is, we cannot write new functionality without writing a test. It is so easy once our initial functionality works to instantly hop to the next bit of functionality but its an art to stop yourself and return to the test spec and plan the next move forward.

Why 1 test first instead of writing 10?

One by one forces us to work on one piece of functionality at a time, which leads to simpler maintainable code. When we have a dozen tests to pass, we often end up writing something that attempts to pass all of them efficient but opening up gaps of additional functionality. It's not something easily adopted I know but consider going test by test when starting, and see if, over time, that habit can form.

"Ok, cool I'm In but how do we do it?"

To get started with it? Read on.

To actually get good at it? Practice. Sorry, I wish there was an easier answer.

The way I learnt was to look at a problem that is really straightforward so my brain doesn't need to worry about that side but instead focus on the test side of things. An example of which we are about to get into. Using something called Jest.

Jest, making life easy for testing in React but also Javascript.

Jest is built into Create React App. Jest is a test runner that is easy and quick to run, as a React guy its what I turned to. It also can be installed via npm/yarn for JS. It's by no means the only test runner in town but its the one I will focus on.

To learn more go to (https://jestjs.io/). The docs are really easy to get going with some examples and some of the different things to do.

We can launch Jest with npm test automatically in a React app created with Create React App. Or in Node follow these steps

There are several ways to have test files that Jest can use. I typically create a FILENAME.test.js in the same place as the code.

Our First Unit Test

For the sake of quickness let's just create a function we are going to test in App.js of a new React App. We are going to try and build a function that adds two numbers. Though we should write the test first as stated earlier, some prefer to have the stub of the future code to exist before writing the test like so:

export const add = () => return {
    null
}

In your App.test.js file, lets import the function and then write our first test:

import {add} from './App';

test('add', () => {
  const value = add(1,2);
  expect(value).toBe(3)
})

So let us go through the key elements of this:

We open a test function and we call it whatever name we like, something that explains what we are testing
We declare a constant value which has an example of how we'd use the function.
We expect value to be 3

The expect line is the key one, there are a number of methods we can use to say what we expect to happen.

Now we have written it, let's look at what the terminal where we ran npm test is saying:

 FAIL  src/App.test.js
  ✕ add (3 ms)

  ● add

    expect(received).toBe(expected) // Object.is equality

    Expected: 3
    Received: null

       5 | test('add', () => {
       6 |   const value = add(1,2);
    >  7 |   expect(value).toBe(3)
         |                 ^
       8 | })
       9 |
      10 |

      at Object.<anonymous> (src/App.test.js:7:17)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 1 total
Snapshots:   0 total
Time:        3.241 s
Ran all test suites related to changed files.

Ok, the test failed. This is good, we have ticked off the first step of TDD: Write a test that fails!

Next step, lets make it work however we can, hmm, this will do:

export const add = ( a,b ) => {
  let total = 0
  total = total + a
  total = total + b
  return total
};

And if we check our test terminal (as I like to call it):

 PASS  src/App.test.js
  ✓ add (2 ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        3.342 s

Woohoo, we have done it! Time to go party right? Ah no, making the test pass was just step 2. There is probably a refactor or two we can do to this code, so let us see what we can do.

export const add = ( a,b ) => a * b

Look how efficient that is now, we are such great coders! But wait, what is happening in the test terminal?:

FAIL  src/App.test.js
  ✕ add (4 ms)

  ● add

    expect(received).toBe(expected) // Object.is equality

    Expected: 3
    Received: 2

       5 | test('add', () => {
       6 |   const value = add(1,2);
    >  7 |   expect(value).toBe(3)
         |                 ^
       8 | })
       9 |
      10 |

      at Object.<anonymous> (src/App.test.js:7:17)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 1 total
Snapshots:   0 total
Time:        0.962 s
Ran all test suites related to changed files.

Ah nuts, it has failed! Just as well we had a test in place to tell us we made a mistake when refactoring! This is my favourite aspect, having something to watch our back while we get creative in making the code neater. Because it gives us information such as what is expected and what it got, it helps us narrow down the issue (which I am sure you can figure out yourself!).

Since the above function would pass the test if we just returned 3 or even (-1, -3) we might want to consider adding another assertion:

expect(add(-1,-3)).toBe(-4)

Now both assertions have to be true for the test to pass, adding additional assertions increases the bulletproof nature of the function.

Now this example wasn't the most complex in the world but its a start. If we want to add extra functionality, TDD makes us write the test first to make sure we develop decent test coverage.

Testing an individual function that stands alone is called a Unit Test as opposed to testing, say a React Component that in turn renders or integrates other components. That requires a different type of test...what would be a good name for them...

Integration Tests

So some functions rely on other functions which impacts how we test, let's run through an example.

Lets say we wanted to return a string that said how many people were at a school using the add function from before (arguably this would come in a refactor but lets be brief), we would write a test like this:

test("schoolPopulation", () => {
    expect(schoolPopulation(10,100)).toBe("There are 110 people at the school"))
})

As per step 1, we write something that fails the test:

const schoolPopulation = (teachers, students) => {
    return add(teachers, students)}
}

As the next step we write the thing that hopefully passes the test:

const schoolPopulation = (teachers, students) => {
    return `There are ${add(teachers, students)} people at the school`
}

Just because we can refactor now because mean we have to. It looks good to me.

Now the thing to bear in mind here is that while the test is similar to the one we wrote for the Unit Test. It isn't a Unit Test because it depends on the add function working too. If we broke the add function this would break this test too even if, on its own, it works fine. What we need is a unit test for the schoolPopulation function as this would help highlight which part of the chain is broken. This needs something we call Mocks.

Mocks, or Mock Functions.

This will be a quick dip into the subject as I think it's creeping beyond the scope of my little introduction to TDD.
In a nutshell, a mock is basically a fake function for our tests. While it can be useful to provide unit tests to a function that relies on other functions. It also is handy for testing functions that call an API or database, in other things you get want to actually run for the sake of testing.

So if we look at our school population and add functions what Jest allows us to do is essentially intercept the function call to the add function and provide a fake result to use in the school population function.

This is better shown first:

//In the schoolPopulation.test.js file

import {schoolPopulation } from './schoolPopulation'
import {add} from './add';

jest.mock('./add', () => ({ //Instead of the add function we imported...
    add: jest.fn() => 50) //... use this fake function which returns 50 always.
}))

test('school population', () => {
    expect(schoolPopulation(10, 50)).toBe('There are 50 people at the school') //
    add.mockImplementation(() => 30) //if we wanted, for some reason,  we can change what the fake add function gives us.

     expect(schoolPopulation(5, 25)).toBe('There are 30 people at the school')

})

This starts getting more important as you dive deeper into the world of testing. But its important to understand that creating a mock dependence so the test can run without being affected by outside factors.

Conclusion

Phew, this was supposed to be a very quick primer on what TDD is and how to actually get started without getting bogged down in the details. There is a whole world under the little bit I have shown but hopefully, this is useful to understand how I leant and how you might be able to get your feet wet into quite a growing movement towards TDD.

10 things I Learned about Accessibility from UK News Sites

Lukie Kang — Wed, 30 Dec 2020 21:41:58 +0000

I recently performed a brief analysis of the accessibility of UK News sites, for two reasons:

Digital News Media is really important in allowing people to take part in society, democracy, and stay connected in an ever-complicating world. I was curious if there would a real impact on those who rely on accessibility features.
I also wanted to improve my knowledge to let accessible design become my natural thought process so I can make strides on that in 2021.

Combining my two interests, I decided to take a slice of UK News sites and see how they approach accessibility in order to grow my own thinking. The sites I chose are:

BBC News
The Guardian
The Daily Mail
The Telegraph
The Mirror
The Times
The Sun

Now a bunch of what I am going to say is very much opinionated and from the perspective of a regular Joe but hey, that's the point of a blog. For example, when I say something was not possible, that means that I couldn't figure it out. I might not be the sharpest of internet users out there but honestly, that's who is using your sites!

1. There is more done right than done wrong.

It's easy to criticise, as I am about to do but it's important to say that overall they have done a good job, covering many of the basics to a point they don't get mentioned. But of course, that just means where they drop the ball becomes even more glaring.

To all the developers and designers I'd say Great work. learn from each other, if you took the best accessibility practices from each site you'd be perfect.

2. Cookie Prompt Pain

You all know the fun of cookie prompts news sites or not. One of the first things a keyboard-only user might have to do is try and find a way to get rid of it. So let's make that as painless as possible.

Good: Have your cookie prompt at the top of the screen and the first thing to focus on. (BBC).

Hmmm...: Sticking the cookie prompt on the bottom can be a bit more confusing for tab logic, especially when you tab past it into the main content that is obscured (Mirror)
Not Great: Now allowing the cookie prompt to be focusable at all. And also have a video popup you can focus on while you are at it. (Mail Online)

3. Please take my accessibility user money!

Some news sites need people to pay for their content and there is nothing wrong with that. Subscription prompts tend to one of the first things we see and would be a chance to show all users the site is usable for them. So I was a little surprised to find that subscription prompts are generally less friendly than the content behind them! This is money left on the table when the content itself is often fine.

OK: Redirect the user to a subscription page with big clear elements explaining the options (The Times... though the tab order here could be improved)
Not Great: Ask for support with a popup in the footer, but don't allow it to be focusable (The Guardian)
Really Not Great: Use a subscription popup over content which is not focusable or screen readable and obscures the cookie prompt which means you have no idea where focus has gone. (The Telegraph)

4. Tab Order Vs Cool Layouts

It is important for news sites to have a visually compelling layout, much like their physical versions, I get that. However, while a mouse pointer can follow wherever a user wants, it can be disorienting when the tab order does not follow what makes sense. This is such an easy thing to test but did throw up some odd results.

Good: Small elements, that follow a logical pattern. Allowing a keyboard user can follow without thinking too hard (The BBC)
Okish: Occasional long elements, causing the tab focus to jump large distances and giving keyboard users the chance to play "hide and seek" with the focus highlight (The Guardian)
Not Great: Letting your tab focus follow a course no regular pair of eyeballs would. Occasionally vanishing somewhere for a few tabs before returning (The Times)
Also Not Great: Have a sidebar you can see but cannot focus on till you have reached the bottom of a very long main column (The Mail)

5. Alt tags for images, sometimes silence is golden

It's great if there is a description to your images, certainly, it is something that accessibility tests flag up easily. However, that doesn't mean that any text is better than no text.

Good: Provide a short helpful description of what is found in the picture (BBC News)
OK, fair enough... : Don't provide a description and just let the screen reader skip over it. (The Guardian)
Really Not Great: Set the alt text to be a copy of the headline text it is next to, making screen readers effectively say the same thing twice. Annoying no matter how cute the story is. (The Sun, The Times, The Mail)

6. Highlighting Interactive Elements highlights plenty of differences.

Without moving a mouse, can you see what bits of the page would do something if you clicked/tapped on it? What about if you moved the mouse over it? And what if you tabbed onto it? It is clear then?

The answers to those questions were so variable across news sites and quite subjective. More research is required but I personally found that a combination of color and underlining provided the clearest experience.

Mre tangible issues stem from elements that don't appear to be interactive that actually are either due to formatting matching non-interactive areas.

Good: Use of both colour and underlining when an interactive element is focused (The BBC)
Hmmm...: Make the background a similar colour to the tab focus effectively making the element not highlight when focused. (The Guardian)

Really Not Great: No colour or text formatting when focused or hovered over (The Mirror)

7. Your 3rd party content does matter

It is understandable that news sites use advertisements and sponsored content to keep the money coming in. However while the main site can be made accessible, 3rd party content also needs to be held to the same standard as it affects the user's experience just the same as the rest of the content.

I am not sure why advertisements wouldn't want to do something snappy for folks using screen readers but it doesn't appear to be the case in the test.

Good: Allowing a screen reader to recognise an ad, state that is an ad and moves on. (The Mirror)
Hmmm...: Make the screen reader recognise ad content as simply web content making it confusing what it is exactly (The Sun)
Really Not Great: Have sponsored content that makes no concessions to screen readers and makes them read out ID numbers and such. (The Times)

8. A site can be experienced in different ways, screen reading tends to be where most issues lay.

Following on from #4. There are actually three journeys through a site.

Your eyes as you look at what's there. Studies have shown it is isn't just left-to-right up-to-down. It's interesting seeing how different sites use this to their advantage, but this can open up challenges for the other journeys.
Tabbing through content. Typically this will go along the navigation before following the article sequentially. Generally, this is logical on sites, by which I mean it follows what we see fairly well.
Being guided through it by a screen reader. This is one that most often exhibited strange behavior and most, unlike the visual experience. I am sure part of this is my lack of familiarity with screen readers but I definitely recognised things that did not quite make sense. Going through a site with a screen reader does take a relatively long time, they don't have the same ability to skip over irrelevant content as eyeballs do, so it's important to be respectful of the user's time.

Good: Providing 'Skip to content' or 'Jump to navigation' functionality to allow a little agency in the tab and screen reader journey. (The Telegraph, The Sun)

Hmmm...: Providing multiple links in an element adding additional complexity to screen readers and tab focusing. (The Mail)
Really Not Great: Having visibly collapsed menus but making screen readers read through each option anyhow. (The Times)

9. Lighthouse shines a helpful light, but plenty of shadows remain.

I think a lot of people's plan of action for accessibility is to use Chrome's Lighthouse to make the numbers go higher. When it's high, job's done right? Not really, most of the sites had scores in the 80s but still had issues. Conversely, the BBC News site, which was perhaps the best all-round actually had the worst lighthouse score of the sites I tested.

As mentioned in #5, meeting the criteria isn't as important as that criteria providing a net positive for accessibility. I do wonder if doggedly chasing perfect Lighthouse score incentives a few bad practices along the way.

It also does not appear to give much weight to the frequency of a particular issue. Having a lot of different issues happen on one or two elements, is arguably better than one consistent issue that occurs everywhere.

It is a good guide but to build for accessibility will involve getting more familiar with the WCAG to really take the details to heart.

10. There is much more to look at!

My analysis was only scratching the surface of what makes a web site accessible. For a first look, it has some value but there are more areas that I would have loved to go into.

Alignment to WCAG2.1 and the upcoming WCAG2.2 for a more comprehensive analysis
Looking at the different pages found on each site.
Mobile users and devices beyond the standard desktop.
Behaviour across different browsers, I noticed some issues in this regard but want to do a proper job on this.
Involving actual users of common accessibility features. (I am sure this would be a good Fiverr type service)

Wrap up, my full results, and my secret shame...

I collated my findings at my site, newsa11y.com. Which, embarrassingly, needs a lot more accessibility work itself. It was intended as a quick MVP template to get something going. I hope to do the exercise again next year to perform a proper, deeper, clearer, and yes, accessible, analysis of the state of UK News media when it comes to accessibility, feel free to get in touch if this is something you'd love to help out with.

Figuring Out Gatsby #5 - GraphQL - How Gatsby eats data

Lukie Kang — Tue, 29 Dec 2020 10:15:46 +0000

In my last post I actually didn't talk much about Gatsby and instead set up a Sanity backend for Gatsby to ingest somehow.

The gist of the Sanity backend is that we have the following data for our restaurant app to use:

dishes, our meals
intolerances, things like gluten that can be in dishes
employees, who work at the restaurant
jobs, the jobs at the restaurant which an employee has

Regardless of how that data exists we need a way to show it for visitors to our Gatsby site so that's what we will talk about in this post. There are a few steps to get there:

Setting up Gatsby config to use plugins
Connect Gatsby to Sanity using the API securely 3.

Set up Gatsby Config

gatsbyconfig.js which may need creating on your root folder, and sets up things that apply across your site. The most common things to set up are:

Site Metadata - Basic properties of your site
Plugins - Extra stuff out there to be used.
Flags - To allow experimental/non-standard features
Prefix - To set up Gatsby in a particular location on the domain, i.e. for blogs

module.exports = {
  siteMetadata: {
    title: `The Cat and Bear Restaurant`
    siteUrl: `whatever.com`
    description: 'Purrfect Food. Roarsome ambiance'
  }
}

Now we actually have some data we can head to localhost:8000/___graphql to build our first query:

query MyQuery {
  site {
    siteMetadata {
      title
    }
  }
}

Should return:

{
  "data": {
    "site": {
      "siteMetadata": {
        "title": "The Cat and Bear Restaurant"
      }
    }
  },
  "extensions": {}
}

Hol' Up, what's this GraphQL stuff?

If you haven't seen graphql before then it. Put simply graphQL can let make queries (reading data) and mutations (changing data) using the syntax that is a little bit like working with JSON (...not really true but best I can do in a sentence.) Its more fun than writing an SQL query at least.

It will be quite the detour to explain it fully but I can recommend the video series by The Net Ninja to get the general gist of it. Watch the first few videos at least, I find the visualisations help a lot in making sense of how it works.

GraphQL is the backbone of how Gatsby handles data so it's important to get it understood.

Pluggin' In to Gatsby Plugins

Plugins are a superpower of Gatsby, taking what already exists and hooking it up in your own app. At the time of writing there are 2516 plugs available. You can view the Gatsby Plugin Library to get a flavour of what things are available.

Adding a plugin is as easy as specifying the name of the plugin:

module.exports = {
  siteMetadata: {
    title: `The Cat and Bear Restaurant`
    siteUrl: `whatever.com`
    description: 'Purrfect Food. Roarsome ambiance'
  },
  plugins: [
    'PLUGIN_NAME'
  ]
}

This gets it working in the most default manner possible but the documents usually have options we can configure. For the site map plugin we can do something like this:

plugins: [
  //assume other plugins exist in this array
  {
    resolve: `gatsby-plugin-sitemap`,
    options: {
      sitemapSize: 5000
    }
  }
]

Important Note: It won't do much till you also npm install the relevant plug in by its name.

Getting plugins in Gatsby is a doddle, any complexity will come from the Plugin itself so it will require studying the docs for each one. In my case, we have to get Gatsby talking to Sanity so let's take a deeper look at that:

Deploy graphQL for Sanity. In your Sanity folder type sanity graphql deploy <dataset_name>
Back in the Gatsby folder, get it installed with npm install gatsby-source-sanity
Get some details of your Sanity Project. Assuming you have set up a project at (https://manage.sanity.io/projects/) we will need:

Project ID
The name of the dataset
Token. This is a bit more involved. We can create a token by going to 'settings', 'api' and 'add new token'. Give it a label for your own info and copy the long string that appears somewhere. While you are in the API settings, take a mental note that we should specify CORS origins for the URL that will allow us talk to Sanity when it is in production.

plugins: [
    {
      resolve: `gatsby-source-sanity`,
      options: {
        projectId: `<YOUR SANITY PROJECT ID`,
        dataset: `<PRODUCTION IN MY CASE>`,
        watchMode: true, //Allows changes to be reflected in Realtime for development
        token: process.env.SANITY_TOKEN, //DO NOT put you token in here. We need to keep our token secret. So we stick it into a .env file. See below...

      },
    },
  }
]

ENV files, to stop ENVious hackers.

Quick aside, API tokens are sensitive, if people have access to them, they can do bad things. Our gatsby-config will be included in version control such as GitHub so we can put the token there. Instead, we just place a reference to an env file that contains secrets and doesn't go into version control. As an aside to our aside, having environment variables is also handly for things that do change between environments, such as connecting to a test database as opposed to a production one, without changing the

npm install dotenv which allows us to use environment files easily
Create a .env in the root of our gatsby site.
Specify what SANITY_TOKEN is:

SANITY_TOKEN=reg4ergGW...etc

Lastly we need to configure dotenv in our gatsby config file:

import dotenv from 'dotenv'
dotenv.config({path: '.env'})

This will get the config file using our API Key securely.

Lastly, we should test it all works, a quick way is to console log the variable (if local) in gatsby-config to see if it is working properly. But if it is all hooked up as intended, when we go to our GraphiQL we should start seeing the contents of our Sanity popping in. Sanity data should start with allSanity so that:

query MyQuery { 
  allSanityMeals {
    nodes {
      name
    }
  }
  }

Should return all the names of our meals in our hypothetical restaurant site. Phew, the above looks fairly tricky if you have never done something like this before but compared to hooking up a separate backend, I promise, it's a relative breeze!

3. Getting it visible via Gatsby Queries

So far we have gotten Gatsby to talk to our Sanity via GraphQL. The last step is getting the data from GraphQL onto our pages. Pretty much the whole reason for two wholly unrelated blog posts. As before all my examples revolve around a hypothetical restaurant site that cares about showing off what it has on its menu.

In Gatsby, at present, there can are two types of queries we can write to get data into our components and onto the page

Page Queries. These allow variables but only can be run on a top-level page
Static Query - Do not allow for variables, but can exist everywhere

Images are a special bit of data we can look at in more detail.

Page Queries

Page queries are pretty straightforward. Here is how we might get the dishes from the database by adding the following GraphQL query to the Food page where we might see all the dishes:

import React from 'react';

function FoodPage() {
  return (
    <div>
      <p>This is the Food page, where the dishes we serve are listed</p>
    </div>
  );
}

export const DishQuery = graphql`
  query DishQuery {
    dishes: allSanityDish {        //rename the output something nicer
      edges {
        node {
          id
          name
          price
          intolerences { 
            name
          }
          image {                // We will talk images in a bit
            asset {
              fluid(maxWidth: 400) {
                src
              }
            }
          }
        }
      }
    }
  }
`;

export default FoodPage;

If that works, you can use React Dev tools to see that the dish data has appeared in props. A good step but let's see if we can manipulate it some more by accessing the props in our code.

In our FoodPage component we can access the data by passing in the props, or more exactly the data field within props. At this point we can use that data however we like in the component:

function FoodPage({ data }) {
  const dishes = data.dishes.edges;
  return (
    <div>
      <h1>We currently serve {dishes.length} dishes.</h1>
    </div>
  );
}

From there you can build extra components for mapping over the array if you so wish to pass dishes down as props. I won't get into that but if you have worked with React that should be fairly straightforward, here is the component file I ended up with:

import React from 'react';

function DishItem({ dish }) {
  return (
    <div>
      <h2>
        {dish.name} - {dish.price}{' '}
      </h2>
      <h3>Intolerence information:</h3>
      <p>
        {dish.intolerences.map((intolerence) => intolerence.name).join(', ')}{' '}
      </p>
    </div>
  );
}

export default function DishList({ dishes }) {
  return (
    <div>
      {dishes.map((dish) => (
        <DishItem key={dish.id} dish={dish.node} />
      ))}
    </div>
  );
}

Conclusion

If you have never hooked up a separate backend to a frontend, the above might look a little scary but trust me, compared to most options, the configuration is a breeze. Though I use Sanity, most headless CMSes work on a similar basis bar some syntactical (is that a word?) differences.

When doing a full stuck app, setting up the conversation between front-end and back end is something I don't enjoy but by breaking it down into smaller steps, it is a bit less scary.

Figuring out Gatsby #4 - A detour to the world of Sanity.

Lukie Kang — Fri, 18 Dec 2020 15:06:32 +0000

In my previous posts I have discussed:

Setting up Gatsby
Making Pages
Styling those pages

That is enough for a basic site, but if we need to make something a little more dynamic we need a:

Database to keep data that can be changed
Way of changing what's in the database
Way to show what we have in the database on our pages.

The cool kids call this a Backend, and this is something that one can dedicate a whole career to building out. We will not do this, we will use something called Sanity.

If you like using something else for data, that's cool, Gatsby doesn't really care too hard about what you use but for the app I am building, that's what I will be using. The concepts in later posts are pretty transferable.

What the hell is Sanity?

Sanity is a headless CMS. Headless just means that it doesn't have a frontend for users to see what's there, that's what we have Gatsby for. CMS stands for Content Management System which is a system that manages content 😸... fine, it's a tool that handles all ways we can change data, primarily... Create, Read, Update, Delete. AKA CRUD.

There is a whole bunch of headless CMSes on the market, some cater for simplicity, some for more control. Sanity is a good mix of the two, and the general principles here should work more or less whatever you use.

In a hypothetical restaurant app, we will have a bunch of dishes on the menu, menus change often. We don't want this to be a hassle, we might even want something that a semi-skilled client could manage without you. This is one reason why having a CMS to make this smooth is a good idea. However, it doesn't mean that setting it up is all that easy. So let's walk through it.

How do I get some of this Sanity?

You can probably figure most of it out by following the guidance on the Sanity Website.

I am going to focus on getting it up and running via the command line.

Step 1 - Install Sanity CLI and Initialise

This is as simple as typing npm install -g @sanity/cli && sanity init

This is will get it installed globally and the second command will initialise a blank Sanity instance in the location you are in.

You can check it is all version as intended with a sanity --version.

Once you have the starter files up and running, you weirdly should init again...

Step 2 - Reconfigure

It's time to introduce yourself to Sanity.

First, type sanity init --reconfigure and it will prompt you to create an account with Sanity (unless you have done this before). It's a fairly straightforward process that can use GitHub or Google as authentication providers to make it easier.

Second, give your project a name.

Thirdly it will ask if you want a private or public dataset and allows you to set up different datasets for testing etc. For your first time stick to the default which sets up a public production dataset but this is important to know for real life.

Step 3 - Intro to Sanity Studio

We have everything set up, so we can type npm start or sanity start and if all has gone well it will tell you Sanity is running on localhost:3333. If you open that in your browser, you will be prompted to logon and...

It will tell you that you have an empty schema. How dull.

We better go make something to look at here then.

Step 4 - Our first schema

The empty schema message will link to a guide. This a good step by step guide that provides more detail than I will type here. But I will go over what I did below.

Since I have a hypothetical restaurant site, I want to store content regarding the dishes that are served.

In the schemas folder, I create a new schema called dish.js. This file exports an object defining what a dish actually is. Hopefully, it makes sense with my comments:

export default {
  name: 'dish', // what sanity will know it as
  title: 'Dishes', // what we see it called in Sanity Studio
  type: 'document', // We will get to this later, document will do for now
  fields: [
    // what fields does a dish have?
    {
      name: 'name', // What Sanity will know it as
      title: 'Dish Name', // What we see it called in Sanity Studio
      type: 'string', // The datatype, this could be lots of things.
      description: 'Name of the Dish', // Just explains what the field is.
    },
  ],
};

Once we have the dish schema set up, we need to add it to the overall schema.js file with a import dish from './dish and modifying the createSchema object as follows:

types: schemaTypes.concat([dish]),

Hopefully, you begin to see how multiple schemas can be built up in this fashion.

Step 5 - Bask in our incredible Back End skills

Let's hop back to Sanity Studio. If all has gone well we can see we have Dishes on the left-hand side. But no content. We can fix that by clicking the new icon in the right-hand side and add our first Dish!

Of course, it isn't all that interesting just storing the names of dishes, so once you are happy it works as intended you can delete it via the menu on the bottom right-hand side.

Let's make it better!

Well, the possibilities are limitless at this point. The Sanity docs are really good for figuring out how to build upon it but here is what I did:

import { check } from 'prettier';

export default {
  name: 'dish',
  title: 'Dishes',
  icon: () => '🥣', // Lets give it a cool icon!
  type: 'document', //
  fields: [
    {
      name: 'name',
      title: 'Dish Name',
      type: 'string',
      description: 'Name of the Dish',
    },
    {
      name: 'vegetarian',
      title: 'Vegetarian',
      type: 'boolean',
      description: 'Is it Vegetarian?',
      options: {
        layout: 'checkbox',
      },
    },
    {
      name: 'vegan',
      title: 'Vegan',
      type: 'boolean',
      description: 'Is it Vegan?',
      options: {
        layout: 'checkbox',
      },
    },
    {
      name: 'price',
      title: 'Price',
      type: 'number',
      description: 'Price of dish in pence',
      validation: (Rule) => Rule.min(99).max(10000), // Limits what can be entered for price
    },
    {
      name: 'image',
      title: 'Dish Image',
      type: 'image',
      options: {
        hotspot: true, // clever thing that lets us edit where to focus the picture when resizing
      },
    },
    {
      // Add a slug to deal with pesky spaces in names
      name: 'slug',
      title: 'slug',
      type: 'slug',
      options: {
        source: 'name',
        maxLength: 50,
      },
    },
  ],
  preview: {
    select: {
      name: 'name',
      vegetarian: 'vegetarian',
      vegan: 'vegan',
    },
    prepare: (fields) => ({
      title: `${fields.name} ${
        fields.vegan ? '- 🌱  Ve' : fields.vegetarian ? '-🍆 Veg' : '' //Nesting Ternaries is a naughty thing to do btw.
      }`,
    }),
  },
};

Which results in:

Starting to look tasty! Note that we:

Added Vegan and Vegetarian Options (and somehow I decided Fish and Chips was vegetarian)
Added a preview property that lets us get some of the info without having to go into it.

But let's start getting even more clever and look at some related data.

Relational Data with a Second Content Type

Ok cool, we have some dishes in our restaurant but we don't want our customers with special dietary requirements to be worried about what we are serving up so we want to capture data around the use of dairy, nuts, gluten. That sort of thing.

Multiple dishes use dairy products and maybe later we could filter out dairy products from the menu. To do this and save effort in the long run. it needs to exist as a separate content type rather than just be a piece of info buried within each dish.

A dish can fit many intolerances, i.e it could have Gluten and Shellfish. So we call this a one to many relationships as ONE dish may have MANY ingredients that we care about.

Ok so first we need a new schema, called intolerance.js and we want to keep it fairly simple at first:

export default {
  name: 'intolerance',
  title: 'Dietary Intolerances',
  icon: () => '⚠️',
  type: 'document',
  fields: [
    {
      name: 'name',
      title: 'Name',
      type: 'string',
      description: 'Name of the Dietary Tolerance',
    },
  ],
};

Don't forget to add to the schema.js file as before:

types: schemaTypes.concat([dish, intolerence]),

Linking it up

Now that we have done that we need to link dishes to their intolerances. This requires us to make an addition to the pizza schema:

  {
      name: 'Intolerences',
      title: 'Contains',
      type: 'array',
      of: [{ type: 'reference', to: [{ type: 'intolerance' }] }],
    },

So what are we doing here? We are adding an array to our dish schema, and then we are saying that the array will contain references to our intolerances. This results in the following:

Its a bit fiddly in the UI but allows us to link our previously created intolerances to our item. This isn't the most complex data ever for the sake of a short blog post but it's easy to see how this can be developed.

My final (At least for now) dish schema looks like this:

export default {
  name: 'dish',
  title: 'Dishes',
  icon: () => '🥣', // Lets give it a cool icon!
  type: 'document', //
  fields: [
    {
      name: 'name',
      title: 'Dish Name',
      type: 'string',
      description: 'Name of the Dish',
    },
    {
      name: 'vegetarian',
      title: 'Vegetarian',
      type: 'boolean',
      description: 'Is it Vegetarian?',
      options: {
        layout: 'checkbox',
      },
    },
    {
      name: 'vegan',
      title: 'Vegan',
      type: 'boolean',
      description: 'Is it Vegan?',
      options: {
        layout: 'checkbox',
      },
    },
    {
      name: 'price',
      title: 'Price',
      type: 'number',
      description: 'Price of dish in pence',
      validation: (Rule) => Rule.min(99).max(10000), // Limits what can be entered for price
    },
    {
      name: 'image',
      title: 'Dish Image',
      type: 'image',
      options: {
        hotspot: true, // clever thing that lets us edit where to focus the picture when resizing
      },
    },
    {
      // Add a slug to deal with pesky spaces in names
      name: 'slug',
      title: 'slug',
      type: 'slug',
      options: {
        source: 'name',
        maxLength: 50,
      },
    },

    {
      name: 'Intolerences',
      title: 'Contains',
      type: 'array',
      of: [{ type: 'reference', to: [{ type: 'intolerance' }] }],
    },
  ],
  preview: {
    select: {
      name: 'name',
      vegetarian: 'vegetarian',
      vegan: 'vegan',
    },
    prepare: (fields) => ({
      title: `${fields.name} ${
        // eslint-disable-next-line no-nested-ternary, naughty naughty
        fields.vegan ? '- 🌱  Ve' : fields.vegetarian ? '-🍆  Veg' : ''
      }`,
    }),
  },
};

Customising our Inputs

One last thing, mostly optional. We are not limited to how Sanity renders the inputs by default. We can make our own version of the inputs using React components, we just need to tell Sanity to do that.

The basics

First, we want to create a components folder and inside of that the component we want to use.

We create a simple React component and import it into the schema as we would in React. In the relevant field object add the following property to tell it to use the component for the input:

inputComponent: nameOfComponent

Its a good idea to get a basic component rendering something basic to check it works before moving on.

Actually customising the input

There are a few things that are special because we are using Sanity in order for our input to talk to it properly.

1. Get Props from Sanity

This is Because we told Sanity that we want to use this component for the input, it gives us a whole bunch of Props we have access to that relate to the data in Sanity. Some key ones are:

Type, the filed object, contains the title and description and other things
Value, what is in the input
onChange, what to do when it changes
inputComponent, reference to input itself so Sanity knows what to look at.

2. Setting up Patching function

Sanity has its own method of updating its data, and it requires some Santity magic as follows:

We import the following:

import PatchEvent, {set, unset} from 'part:@sanity/form-builder/patch-event'

Build the following function:

function createPatchFrom(value){
  PatchEvent.from(value === '' ? unset() : set(value))
}

Basically, Sanity will set the value if the input value exists and unset it if it does not.

3. Build our input and complete our component

So I am building an input for an employee's age here, which is a bad idea for real life but for the sake of showing you the whole component:

import React from 'react'
import PatchEvent, {set, unset} from 'part:@sanity/form-builder/patch-event'

function createPatchFrom(value){
  PatchEvent.from(value === '' ? unset() : set(value))
}

export default function AgeInput({ type, value, onChange, inputComponent }){
  return (
    <div>
      <h2>{type.title} {value ? value : ''</h2> 
      <p>{type.description}</p>
      <input
        type={type.title}
        value={value}
        onChange={event => onChange(createPatchFrom(event.target.value)})
        ref={inputComponent}
      />
    </div>
  )
}

Conclusion

Phew, if you don't care about Sanity this would be a dull one but since Gatsby doesn't involve itself in backend stuff we need something to handle our data. Sanity is a good pick for something fairly easy to work with and will be used in my posts going forward.

Next time, we will next get to look at hooking up our Gatsby to our Sanity so we can see the fruits of our hard work on the backend.