DEV Community: Christopher Kade

4 signs you’re over-engineering ⚓️

Christopher Kade — Tue, 10 Jan 2023 16:52:40 +0000

During my first years as a Software Engineer I consulted for firms of different sizes (from 20+ to 5000+ people) and it exposed me to various levels of over-engineering. This can happen for a lot of reasons and is usually a collective issue that tends to get worse as time goes on.

This short list goes into some concrete(ish) examples of pitfalls and how to avoid them. Of course, this list in non-exhaustive and can be improved upon, so feel free to let me know if I’ve missed any glaring signs of this issue !

1. You always go for 100% test coverage 🧪

The Pareto Principle states that 80% of the consequences come from 20% of causes. In our case, the majority of our coverage will be done with a limited amount of tests, and the remaining percentage might take a lot of effort for little reward.

I recommend reading about the ISTQB testing principles, the second of which states that exhaustive testing is impossible.

One of the most important skills a testing expert possesses is the ability to identify the most important functions to test.

2. You have excessive indirection and abstraction in your code 🚩

Have you ever been confronted with a bug in production, felt the rush of adrenaline while trying to fix it as quickly as possible and not being able to pin point where the exact source of the problem is? Did you have to go through layers upon layers of files, wondering why previous authors (yourself included) hid away details by placing them in some external function, four layers deep?

This is not as much of a problem when building a feature, as you’re focused on creating code that is clean and reusable, but it requires a lot more mental gymnastics when trying to understand it when you’re not the original author. Over abstraction can create unmaintainable & untestable monoliths, that’s why I believe writing concrete code first and then abstracting is important.

If you ever review code and can’t understand the underlying business logic within, that should already raise a red flag.

Always remember the Rule of Threes: an abstraction without at least three usages isn’t an abstraction. Good abstraction are extracted and not designed.

3. You use micro-frontends wherever, whenever 🧩

Micro-frontends (dividing parts of your application into smaller, self-contained units) can be beneficial in terms of DX & performance, as it:

Allows you to only build the relevant part of your application in your CI, making it faster
Allows you to ship parts of your app using different tech stacks
Allows to load only the relevant files to your client, making your application more performant
Allows teams to work independently in a "standalone” version and iterate faster on features
And many more advantages I won’t get into ! I recommend this article if you want to dive deeper.

With all these benefits, why would it be a bad idea to use this architecture too quickly?

Can add complexity and little reward: Ask yourself: what are the concrete benefits to using them for our project specifically? Does your project have a lot of independent moving parts?
Can add little to no benefits for a lot of work: Setting up an MFE takes a lot of configuration & work side-by-side with your infrastructure team.
Can increase the size of your payloads: if you have a diversity of technology stacks used, it may end up slowing down your user’s experience. This can manifest through duplication of common dependencies - let’s say two of your MFEs use React, you’d then have to download the dependency twice. A solution to that issue would be to use the same version of that dependency across your MFE, but that would introduce a form of build-time coupling of our MFEs which goes against a huge benefit mentioned above.
Makes it harder to test your features: Here’s an example: say a banner on your homepage appears only when the user navigates to it from their profile, if both of these pages are individual MFEs, then you’d have a hard time reproducing that behavior locally as you’d probably be working on a standalone version of any given page.

The general ideas here also apply to micro-services, but I recommend this article if you want more information on the subject.

4. Ignoring the YAGNI principle (You Aren’t Gonna Need It) 🙅

The YAGNI principle (created as part of Extreme Programming by Ron Jeffries) states that a feature should only be developed when required and not by anticipation. The main point being that developers should not waste time on creating extraneous elements that may not be necessary and can hinder or slow the development process.

If you try to future proof your code all the time, you’ll end up more often than not with unused code gathering dust in your repository.

Let’s say you need to declare a class User that has a method getAllUsers, you might start thinking that you’ll eventually need getUserById and getUserByEmail and code them right away. But that’s when YAGNI comes in - you should probably reconsider it and only code it when a feature requires it, and for a couple of reasons:

The requirements might change in the future and make you update already unused methods
The methods might simply never be used and take up space for no reason

Just like other programming principle (KISS, DRY etc.), YAGNI is pretty straight forward

This list was inspired by this tweet from Cory House, I recommend going through it as it'll show you some other mistakes that can cause over-engineering.

Have you every been faced with obvious over-engineering in a previous project or jobs? I’d love to hear some of your stories !

Thanks for reading, I hope you got something out of this list 😄. And feel free to follow me on Twitter, I'm always happy seeing my circle of dev friends grow 🥰

Optimize your data fetching with React Query ⚛️

Christopher Kade — Fri, 23 Dec 2022 14:27:02 +0000

I’ve been introduced to React Query at work last year and I wouldn’t be the first to say that it was a bit jarring initially. For the sake of personal growth, let’s document an introduction to it with actual use cases !

The complete Codesandbox with examples is available here.

What’s React Query?

React Query is a library for managing asynchronous data in React applications. It helps with tasks such as fetching, caching & updating data.

At a high level, React Query works by providing a set of hooks that can be used to fetch and manage data. These hooks allow developers to declaratively specify the data that their components need, and React Query takes care of the rest.

Chris, show me an example please 😬

Here it is:

import { useQuery } from "react-query";

function BasicExample() {
  const { data, isLoading, error } = useQuery("fetch-user-example", () => {
    return fetch("https://random-data-api.com/api/v2/users").then((res) =>
      res.json()
    );
  });

  if (isLoading) {
    return <p>Loading...</p>;
  }

  if (error) {
    return <p>An error occurred: {error.message}</p>;
  }

  return (
    <>
      <h1>Basic example of data fetching</h1>
      <p>Random user: {data.username}</p>
    </>
  );
}

In this example, the useQuery hook is used to fetch data from the /api/v2/users endpoint. The hook takes two arguments: a key and a function that returns a promise. The key is used to uniquely identify the data being fetched, and the function is responsible for making the network request and returning a promise that resolves with the data.

What other cool things can React Query do?

React Query is so much more than just a request framework it offers a lot of tools such as caching, refetching, pre-fetching & pagination. Let’s go over them one by one and see why they might justify using this library.

Caching

One of the key features of React Query is its ability to cache data. When a component makes a request for data using one of the React Query hooks, the library will first check its cache to see if the data is already available. If it is, React Query will return the cached data immediately, eliminating the need to make a network request. This can greatly improve the performance of an application, especially when dealing with data that doesn't change very frequently (for example, on an online training platform offering static courses).

Refetching

React Query allows you to refetch data when certain conditions are met, such as when a component is re-rendered or when the user navigates to a new page. This helps ensure that data is always up-to-date and consistent across your application.

Let’s take our previous example and check out how it works in action:

import { useQuery } from "react-query";

function Refetching() {
  // The hook returns a refetch method that can be called anytime
  const { data, isLoading, error, refetch } = useQuery(
    "refetch-user-example",
    () => {
      return fetch("https://random-data-api.com/api/v2/users").then((res) =>
        res.json()
      );
    }
  );

  function handleRefetch() {
    refetch();
  }

  if (isLoading) {
    return <p>Loading...</p>;
  }

  if (error) {
    return <p>An error occurred: {error.message}</p>;
  }

  return (
    <>
      <h1>Refetching</h1>
      <div className="wrapper">
        <p>Random user: {data.username}</p>
        <button onClick={handleRefetch}>Refetch</button>
      </div>
    </>
  );
}

Pre-fetching

Let’s say your user might need certain data soon, then you can use React Query’s pre-fetching functionality to optimize the performance of your application. This way you can show it almost instantly to your user once they will actually need it.

Once more, let’s build up our example with pre-fetching:

import React, { useEffect, useState } from "react";
import { useQuery, useQueryClient } from "react-query";

function Prefetching() {
  const [showData, setShowData] = useState(false);
  const queryClient = useQueryClient();

  const fetchData = () => {
    return fetch("https://random-data-api.com/api/v2/users").then((res) =>
      res.json()
    );
  };

  const { data, isLoading, error } = useQuery(
    "prefetch-user-example",
    fetchData
  );

  useEffect(() => {
    // Data will be prefetched here once the component is mounted
    queryClient.prefetchQuery("prefetch-user-example", fetchData);
  }, [queryClient]);

  if (isLoading) {
    return <p>Loading...</p>;
  }

  if (error) {
    return <p>An error occurred: {error.message}</p>;
  }

  return (
    <>
      <h1>Prefetching</h1>
      <button onClick={() => setShowData(true)}>Show prefetched data</button>
      {showData && <p>{data.username}</p>}
    </>
  );
}

Pagination

What if you want infinite scrolling or pagination for your website? When working with large datasets it’s often impractical (and downright not recommended, depending on your use case) to load all the data at once. React Query makes it easy to paginate data and load new pages as needed, while also providing the ability to infinitely scroll through large datasets.

Here’s what a basic example would look like:

import React, { useState } from "react";
import { useQuery } from "react-query";

function MyComponent() {
  const [page, setPage] = useState(1);
  const { data, isLoading, error } = useQuery(
    ["pagination-example", page],
    () => {
      return fetch(`/api/my-data?page=${page}`).then((res) => res.json());
    },
    { keepPreviousData: true }
  );

  function handleNextClick() {
    setPage(page + 1);
  }

  function handlePrevClick() {
    setPage(page - 1);
  }

  if (isLoading) {
    return <p>Loading...</p>;
  }

  if (error) {
    return <p>An error occurred: {error.message}</p>;
  }

  return (
    <div>
      {data.map((item) => (
        <p key={item.id}>{item.name}</p>
      ))}
      <div>
        <button onClick={handlePrevClick} disabled={page === 1}>
          Previous
        </button>
        <button onClick={handleNextClick} disabled={!data.hasMore}>
          Next
        </button>
      </div>
    </div>
  );
}

Rapid fire of other cool React Query features

Refetch on window focus (using the refetchOnWindowFocus option, that's true by default)
Cache invalidation, you can specify when the data is stale and should be refetched
Mutation functions, using a set of helper functions to create, update and delete data
Error handling using the onError callback or the error object returned by the query

Are there any risks when using React Query?

As with any framework out there, there's always the risk of introducing additional complexity to your codebase. React Query provides a lot of features and options for managing asynchronous data, and it can be tempting to use them all in an effort to optimize your application. However, this can lead to code that is difficult to understand and maintain, especially if you have multiple developers working on the same codebase.

Another risk to consider is the possibility of introducing performance issues. While React Query can greatly improve the performance of your application, make sure to use it correctly in order to avoid introducing new performance issues. For example, if you're using the keepPreviousData option to paginate data, it's important to use a cache key that's specific enough to avoid caching unrelated data. If you're not careful, you may end up with a large cache that negatively impacts the performance of your project.

Just like any other library out there, it’s important to weigh the benefits and risks it may offer.

Conclusion

Overall, React Query is a powerful tool for managing asynchronous data in React applications. Its caching and lifecycle management features make it easy to build performant and scalable applications, and its support for pagination and infinite scrolling make it well-suited for working with large datasets.

Once you get the hang of it, it's a very potent tool to add to your toolbelt and I hope this quick article pushed you over the edge to try it out.

As always I'd love to stay in touch on Twitter (which surprisingly, hasn't imploded yet) so feel free to connect with me there.

Creating a custom CSS loader of a Yu-Gi-Oh card flipping 🃏

Christopher Kade — Wed, 07 Dec 2022 21:03:41 +0000

You read that right, it's time to bring out your Blue Eyes White Dragon and d-d-d-d-deliver some nice animations to your side projects. Bear with me while I revisit my childhood please, and in the meantime, let's have some fun with CSS 🥰

If you wish to jump right into the solution, here's the Codesandbox link, enjoy !

Step 1: Create the wrapper 🎁

 <div class="card-wrapper">

 </div>

// Our card flip animation, simply rotates the element on the Y 
// axis and then goes back to its original state
@keyframes cardFlip {
  0% {
    transform: rotateY(0deg);
  }
  50% {
    transform: rotateY(180deg);
  }
  100% {
    transform: rotateY(0deg);
  }
}

.card-wrapper {
  position: relative;
  transform-style: preserve-3d;
  animation: cardFlip 3s ease-in-out infinite;
  width: 100px;
  height: 150px;
}

Here transform-style defines each children element as 3D. When used in conjunction with backface-visibility and transform, it will allow us to use the back and front as tangible 3D objects that can be rotated.

Step 2: Create each card face 🎴

 <div class="card-wrapper">
    <img class="card" src="front.jpg" alt="" />
    <img class="card card-back" src="back.jpg" alt="" />
 </div>

.card {
  position: absolute;
  backface-visibility: hidden;
  width: 100px;
  height: 150px;
}

// By default, we rotate the back of the card out of view
// This way, when the animation triggers, the front and back
// swap places back and forth
.card-back {
  transform: rotateY(180deg);
}

backface-visibility defines the back of the card as hidden by default, this way, when it turns, we won't simply see the same face twice.

And that's it, short and sweet.

I struggled a bit to implement it at first and figured it would be worth documenting !

Whether you play Magic: the Gathering, Yu-Gi-Oh!, Flesh and Blood, Vanguard or any other TCG, I'm sure you'll find that animation a bit nostalgic.

Feel free to follow me on Twitter (if it's still around by the time you read this article) - it's always fun chatting with some of you and sharing tips & tricks together 😄

Goodbye Typescript, hello native typing for Javascript ✨

Christopher Kade — Wed, 30 Nov 2022 11:09:29 +0000

Typing. Love it or hate it, it has many advantages: better DX (through intellisense auto-completion), better code documentation, less time consuming errors. Its benefits greatly outweigh its cost, so why do some people still avoid it? One word: Typescript. You have to set it up and make sure your tooling is working correctly which can add a layer of frustration to any project.

So what if I told you that native typing might be coming to Javascript? Christmas is right around the corner and boy do I have a gift for you 🎅

The proposal 📄

TC39 is the comity in charge of Javascript's specs - they help maintain and evolve the definition of JS. If you're curious, I wrote a section about them in a previous article.
They recently moved the Type Annotations proposal to Stage 1 (out of 4), which means it's time to widely speculate on the impact and implications of this feature !

As much as I love being dramatic, this will not sign the death of TS by any means, it will simply allow for cleaner and more reliable JS code for projects that don't plan on using TS or that wish to use both in conjunction.

What will native JS typing look like if this proposal passes?

It would be very close to what we currently have with Typescript and Flow, namely:

// both parameters are numbers, and this method returns a number
function add(a: number, b: number): number {
  return a + b;
}

These annotations will not stop you from passing a string or any other variable type as parameter. They will be ignored at runtime and are just there as guidelines that can be used by 3rd party type checkers such as your IDE.

The argument for strict typing has its place in this discussion in my opinion. In its current proposal, these types are just type annotations, which is something we already have thanks to JSDoc. So the question remains: why?

What's the point? 🤷

We're in an odd situation: Javascript is one of the only languages that has us write in one language (Typescript) to then have it transpiled to another one (Javascript). These layers add complexity to any project, so the more tools we add to our default tool belt, the better.

The need for Typescript creates a form of monopoly on current available tooling, where each and everyone of them needs to evolve with TS in order to not be left behind. The State of the Octoverse 2022 shows the impressive popularity of Typescript in 2022, which means this need to evolve becomes almost mandatory for your linters, bundlers etc.

Having this feature already bundled with our dear Javascript will only make it a more complete package and help us slow down the obvious tooling bloat we're currently facing.

What do you think? Would you see yourself using this feature if it releases? What are the risks that come to mind, especially if you're an avid user of Typescript?

Feel free to follow me on Twitter (if it doesn't implode by the time you finish this article), it's always a pleasure connecting with some of you 😄

The dangers of async/await

Christopher Kade — Thu, 16 Jan 2020 13:24:01 +0000

After a few months consulting on the rewriting of a large-scale application, I've come to realize that async/await was used de facto for most asynchronous operation and parallel executions seemed to be out of the picture. For example, consider this Vue code snippet:

 async initStore(query) {
    await this.getConfig();
    await this.getUser();
    await this.checkRussianContext(query);

    await this.getBasket(this.$store.state.config.selectedCurrency),

    await this.$store.dispatch('options/fetchOptions', {
      basket : this.$store.state.basket,
    });
 },

Here, each line of code is executed when its predecessor is completed. Meaning getUser will wait for getConfig to finish fetching data before being executed.

Here are a few points that come to mind when seeing this snippet:

What if one line does not need data from the previous one? Why block its execution and slow down our application?
Could we run unrelated methods in parallel using something like Promise.all?
Related methods should probably be using a then block to avoid blocking the rest of the method

The point this article will be to help you catch this code smell by showing you that using async/await by default in some cases can have a drastic impact on performance and UX.

Unrelated queries should be executed in parallel

Let's see some concrete data, shall we?

Here's the code snippet we'll be analyzing:

const getUserData = async () => {
  // Get a random dog as our user's avatar
  const res = await fetch('https://dog.ceo/api/breeds/image/random')
  const { message } = await res.json()

  // Get our user's general data
  const user = await fetch('https://randomuser.me/api/')
  const { results } = await user.json()

  // ...
}

Running this snippet 100 times on fast 3G (using Chrome's dev tools), the average execution time is 1231.10ms.

But why block the second query when it doesn't need the result of the first? Let's change our code to the following and re-run it 100 times.

const getUserDataFaster = async () => {
  // Execute both requests in parallel
  const [res, user] = await Promise.all([
    fetch('https://dog.ceo/api/breeds/image/random'), 
    fetch('https://randomuser.me/api/')
  ])
  const [{ message }, { results }] = await Promise.all([res.json(), user.json()])

  // ...
}

We now have an average execution time of 612.50ms, half the time needed when both queries were executed one after the other.

The point is: if you can execute time-consuming queries in parallel, do it.

Try it out yourself on this codepen.

Unrelated code should not have to wait

Let's take my first example but with a twist:

 async initStore(query) {
   await Promise.all([
     this.getConfig(),
     this.getUser(),
     this.checkRussianContext(query)
   ])

   await this.getBasket(this.$store.state.config.selectedCurrency),

   await this.$store.dispatch('options/fetchOptions', {
     basket : this.$store.state.basket,
   });

   await initBooking()
 },

Here, the first 3 requests are executed in parallel, whereas the next ones rely on data fetched beforehand and will therefore be executed afterwards. Although this snippet poses a problem, did you spot it?

Poor little initBooking will have to wait for both getBasket and fetchOptions to finish before executing even though it has nothing to do with the data they'll fetch.

An easy solution is to trade the await with a simple then block.

  async initStore(query) {
    await Promise.all([
      this.getConfig(),
      this.getUser(),
      this.checkRussianContext(query)
    ])

    this.getBasket(this.$store.state.config.selectedCurrency).then(async () => {
      await this.$store.dispatch('options/fetchOptions', {
        basket : this.$store.state.basket,
      });
    })   

   await initBooking()
 },

This way, both getBasket and initBooking will be executed alongside one another.

Want to see it for yourself? Check out this codepen illustrating my example.

I'll stop the article there so I don't overload you with examples, but you should get the gist of it by now.

async/await are wonderful additions to the Javascript language but I hope you'll now ask yourself if they have their place in the specific method you're working on and more importantly: if some of your queries could be executed in parallel.

Thank you for reading, I'd love it if you gave me a follow on Twitter @christo_kade, this way we'll get to share our mutual skepticism towards awaits ❤️

Developer health - taking care of yourself as you code

Christopher Kade — Wed, 20 Nov 2019 15:36:06 +0000

I've recently contracted tendonitis in both of my hands, it's nothing major and can be treated of course, but it made me realize how I have been passive about my health as a developer up until then. I'm not talking about going for a run or hitting the gym multiple times a week, but all the other, seemingly little things that can have a major impact on our careers.

Who would've thought: my hands are pretty important to code 🤦‍♂️

Let's cover a few topics: what you can do right now both actively and passively, and what you can invest in to prevent certain problems.

Passive behavioral changes

Watch your back posture 📏

Start by sitting all the way back in your chair. If you have good lumbar support it should be rather easy to keep a straight posture. If you tend to forget and end up perched over your screen, try reminding yourself every few minutes until it becomes a habit.

It's often said that a 90° or 130° angle is good for your back.

Rest your forearms on your armrest 💪

And if you don't have any, try to get some !

Your arms should be resting comfortably on your armrests, no pressure should be felt on your shoulders or elbows. If you do feel pressure, adjust the height of your armrests to be aligned with your desk.

Your arms or wrists should not be pressing on the hard edge of the desk, it should lay there comfortably.

Align yourself with your desk 👨‍💻

As mentioned above, you should be aligned with your desk. This was probably my biggest mistake due to a bad chair I had at home: your arms should not be reaching up or down to your work station.

Additionally, your feet should be resting flat on the ground with your legs at an 90° angle.

Position your primary and secondary monitor(s) correctly 🖥

Ideally, your monitor(s) should be at eye height and in front of you, avoiding you to constantly turn your head.

Working with laptops often means your neck will be at an angle which can create aching over a long period of time. To solve this issue, grab a laptop stand and add an external keyboard !

Position your hands correctly on your keyboard 🤚

I can't stress that enough: your hands should be straight on your keyboard, you shouldn't type diagonally. They should also not be bent over the keyboard.

Grip your mouse correctly 🐭

First off, don't grip it firmly and rest your hand on it, avoid having a talon-like grip. Try to use your whole arm and wrist to move it to allow for larger and stronger muscles to do the work. Finally, try to have your upper arm close into your side.

Active behavioral changes

Take. breaks. ⏳

Ideally, you should do a 5-10 minute break every 50 to 60 minutes of work.

I know, this might be infeasible in your current working conditions, but try to sneak in break little by little for the sake of your health.

If your job requires you to stay for a very long period of time in front of the keyboard, try longer breaks after a longer amount of time, even though the former method is recommended.

Stretch your hands 🙆‍♂️

I've found the following exercises after finding out I had tendonitis. They allow me to get my hands warmed up and ready to type and only take a few minutes every few hours. You can even pair them up with the breaks mentioned above 🤯

There are many hand stretches out there, but we often forget to get ourselves ready for work and omit them.

Take your time 🐌

I think of myself as a fast typer, but it's sometimes worth it to slow down in order to avoid straining on your hands.

Stay hydrated kids 💧

One of the best remedies for tendonitis is water ! So always keep a water bottle near your work station.

Investments

Ergonomic mouse (mice?)

Your average computer mouse is not comfortable and pushes you to have a bad grip over a long perid of time. Ergonomic mouses allow for a comfortable position where your wrist is not twisted. I know it looks weird, but trust me, it works !

Note the pad with a foam support for my wrist 😄, it's worth keeping in mind that some types of wrist rests are not recommended as they can block blood circulation.

My own mouse & pad, 17 & 9 € respectively

Ergonomic keyboard

In order to have an optimal posture on your keyboard, some people recommend purchasing an ergonomic keyboard. They apparently take time to get used to (if ever), although I wouldn't know, as I don't have one. But I've heard great things about them so they're worth considering.

When needed, purchase hand or wrist braces 🤲

When injured, a wrist brace like the one bellow can be of great help ! It adds pressure on your hand to avoid unecessary movements and allows faster recovery ! It can be found at any sports shop or pharmacies.

Fall style 2019, 10€

Wrapping things up

Our job/hobby is easy physically, but it doesn't mean we shouldn't watch out and anticipate problems. Health is everything, so take care of yourself and happy coding ! 😄

If you've learned something or want to help me heal faster, be sure to hit that ❤️ & 🦄 or to bookmark it for future reference ! Otherwise feel free to chat with me @christo_kade.

18 DevTools for productivity 🚀

Christopher Kade — Tue, 05 Nov 2019 09:47:01 +0000

This may sound crazy, but developers are lazy. I know, unbelievable. Some of us are, we need to automate lots of our tasks because repetition can be tiring. So let me show you some tools I find extremely useful, either because they make my life easier or because they push me to write more accessible code.

We've all done it. Type ls you lazy, lazy person !

These tools will either be browser/IDE extensions, web apps or CLIs.

Web apps

Bundlephobia

You'd like to use a new dependency but you're not sure if it'll have a major impact performance-wise?

➡️ bundlephobia

Coolors

Looking for a cool color combination for a personal project and you're tired of looking around the room for inspiration?

️➡️ coolors

Carbon

You'd like to share a code snippet with style for a presentation? (Keep in mind that these pictures are not accessible)

➡️ carbon.now

Snippet generator

You have a live-coding session and you'd like to use code snippets to be more efficient?

Generate them using this tool & add them to your IDE of choice.

➡️ snippet generator

Wolfram Alpha

You have a complex mathematical problem on your hands? Or a complicated if statement you'd like to simplify? Input it in this tool and retrieve its truth table, venn diagram & other useful data to make your life easier !

➡️ Wolfram Alpha

DevHints

You keep on forgetting the syntax of that one framework or tool?

➡️ DevHints

Caniuse

Want to check if a feature is supported by a specific browser?

➡️ caniuse

Browser extensions

headingsMap

Are your headings accessible to screen readers? Do you want to see if your headings are in the wrong place?

➡️ Chrome

➡️ Firefox

WCAG Color contrast checker

Looking to avoid contrast problems with your application? Do you want an understanding of which elements of your screen have a bad contrast ratio at a glance?

➡️ Chrome

➡️ Firefox

Screencastify

Want to record your web app for a demo?

➡️ Screencastify (for Chrome only)

Axe

Want to execute automated accessibility tests very easily? (Axe won't test every accessibility concerns you may have, manual testing is also recommended)

➡️ axe

VSCode extensions

Bracket Pair Colorizer

Lost in a forest of { and }?

➡️ Bracket Pair Colorizer

Git graph

Sick of living in the console for your Git commands?

➡️ Git Graph

GitLens

Want to see who coded what?

➡️ GitLens

Live Share

Want to live-edit a file collectively in your IDE?

➡️ Live Share

CLIs

ngrok

You're working on a project and want to show your local environment to someone who's not here?

➡️️ ngrok

svgo

Want to optimize your svg files and remove all the noise?

➡️ svgo

tldr

Someone told you to RTFM (as much as I hate this expression) and you despise the usual man display?

➡️ tldr

fkill

Want to kill that pesky process but kill won't do it?

➡️ fkill

gitmoji CLI

Want to easily commit something following the gitmoji syntax?

➡️ gitmoji CLI

gitmoji changelog

Do you wish to generate a beautiful changelog based on your gitmoji commits?

➡️ gitmoji changelog

I hope you've found at least one tool that will make your life easier.
If you'd like to share one of your own, feel free to send them to me on Twitter @christo_kade or right here in the comments!

Celebrating my 10 000th follower on DEV 🎉

Christopher Kade — Tue, 29 Oct 2019 12:58:00 +0000

Alright, I know these posts are annoying but I just wanted to express how great this platform is & thank everyone for making it grow so much week after week.

// Detect dark theme var iframe = document.getElementById('tweet-1189133325371359232-205'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1189133325371359232&theme=dark" }

I've been able to improve on my technical writing skills & share some things I'm passionate about. Here are some people I look up to, motivating me to improve post after post, either because they teach a whole lot or because they have a positive influence on our community:

Ali SpittelFollow

Passionate about education, Python, JavaScript, and code art.

[Deleted User]

Ben HalpernFollow

A Canadian software developer who thinks he’s funny.

Samantha MingFollow

Frontend Developer sharing weekly JS, HTML, CSS code tidbits 🔥Discover them all on samanthaming.com 💛

Charlie GerardFollow

I am a senior developer advocate, passionate about creative coding and building interactive prototypes mixing science, art & technology. I also spend time mentoring, contributing to OSS and speaking.

John PapaFollow

Husband, father, & Catholic enjoying life with my family. Working @ Microsoft. Disney fanatic, web and mobile developer

Lastly, allow me to list some of my favorite articles I wrote in the last 2 years ❤️

First off, my latest piece about features to look forward to in Javascript:

The future of Javascript - features to keep an eye on

Christopher Kade ・ Oct 24 '19

#javascript #webdev #beginners

Thanks to you, I now have an amazing list of tools I use on a weekly basis:

What's one resource most devs don't know that you use regularly?

Christopher Kade ・ Jun 4 '19

#discuss #webdev #productivity #beginners

One of my most successful articles, about something I was afraid of just a few years ago:

Up your Git game and clean up your history

Christopher Kade ・ Jun 18 '19

#webdev #tutorial #git #beginners

Some tips on improving how we write components:

Tips to write elegant and resilient components

Christopher Kade ・ Aug 8 '19

#javascript #webdev #tutorial #beginners

And my very first article on this platform, it's NOT good but I'm glad it started there:

Defining quality requirements for a project

Christopher Kade ・ Jan 30 '18

#requirements #agile

Thanks again ❤️

The future of Javascript - features to keep an eye on

Christopher Kade — Thu, 24 Oct 2019 07:33:22 +0000

We take a lot of Javascript features for granted, map, filter, reduce, const/let, ternaries... each one of these had a major impact on our code bases when they were introduced & allow for us to write cleaner and often times more performant code.

Let's cover who decides on the future of Javascript briefly, and then introduce some features that should arrive in the near & not so near future.

If you're only interested in concrete features, skip to the next section below by clicking here 👇

ECMA? TC39?

In 1959, computers were being used more and more, which brought in multiple new manufacturers. Something was clear: they needed to find a way to standardize technical operations such as (but not only) programming.

And so, the 27th of April 1960 in Brussels, the European Computer Manufacturers Association (or ECMA) was born, looking to standardize this mess.

Note: in 1994, ECMA became ecma international, where they dropped the acronym and used the latter word to show their international scale.

ECMA elects a new president every single year, usually someone from a major actor in computer science: IBM, HP, Siemens, Philips etc. Jochen Friedrick from IBM currently resides as president for the 2018-2019 period.

Here's how it's structured:

The general assembly includes ordinary members of ecma and is its highest authority. It controls its management, secretariat & executive committee. It's currently composed of some of the biggest names in tech, including Apple, AirBnb, Facebook, Netflix & Google. Full list of members

It's the secretariat's role to organize and create Technical Committees (TCs) and Technical Groups (TGs) who handle specific aspects of computer science.

Each TC manages the evolution & future of things such as Programming Languages, Product Safety and of course: ECMAScript.

You now have a general overview of how things work, but what's the lifecycle of a new JS feature?

TC39 proposals

So TC39 manages the evolution of our beloved (and sometimes hated) language, almost everything they do is open-sourced so it's always cool to check out new proposals and how they evolve over time.

The stages of an ECMAScript feature

A new ECMAScript feature goes through 5 stages:

Stage 0 (Strawperson): which allows initial input into the specification
Stage 1 (Proposal): allows to make the case for the addition, describe the shape of the solution & identify potential challenges
Stage 2 (Draft): allows to precisely describe the syntax and semantic using formal specification language
Stage 3 (Candidate): indicates that further refinement will require feedback from implementations & users. Basically requires that all semantics, syntax and APIs are completely described
Stage 4 (Finished): Indicate that the addition is ready for inclusion in the formal ECMAScript standard

You can get more information and dive into great details about these stages here.

Stage 4 features

Let's get to concrete stage 4 features, meaning features that are finished and that will be included in the soonest practical standard version of ECMAScript. I'll also display their current browser support.

`Object.fromEntries`

`Array.flatMap`

The MDN docs mention that it's even slightly more efficient.

`BigInt`

`globalThis`

`String.trimStart` & `String.trimEnd`

`Promise.allSettled`

Stage 3 features

Stage 3 features won't get released in the near future, but some of them are so cool that it's worth mentioning them.

I won't mention their browser support though, as it's not relevant.

Optional chaining

This one might be my favorites, bye bye user && user.name !

Nullish Coalescing

Do you know how Javascript can be weird sometimes? When you need to do some validation with a value equal to 0 but forget that it's considered as falsy?

Did you learn anything new? What feature excites you the most? I'd love to here your thoughts either here or on Twitter @christo_kade !

Improving your Git workflow

Christopher Kade — Wed, 14 Aug 2019 14:31:38 +0000

Whether you are on your own or with a team, having an efficient Git workflow can go a long way to boost your productivity.

For the past month, I've been consulting with a team that truly values the points I'll share with you today, and I've been able to see the positive effects they've had on a large-scale project.

Naming conventions

Git naming conventions are key. They allow you to understand the context of somebody's work in a matter of seconds and can help you filter through your team's work when well executed.

There isn't a perfect naming convention out there, but some of them, like Vincent Driessen's make a lot of sense and will clarify the mess that can be naming Git branches.

In short, other than your usual master and dev branches, your supporting branches can be of the following types:

Feature branches (feature-*): takes the form of a user story, or a feature that will be merged later on
Release branches (release-*): support the preparation of new product release, say a future rebranding of your website and will be eventually merged when ready
Hotfix branches (hotfix-*): your typical bug fix. You could, for example, branch off in order to fix a bug in production

But naming conventions also apply to commit messages. I truly recommend Chris Beam's "How to Write a Git Commit Message" in order to grasp the importance of carefully naming your commits. But I think the following guidelines are a good summary:

Separate subject from body with a blank line
Limit the subject line to 50 characters
Capitalize the subject line
Do not end the subject line with a period
Use the imperative mood in the subject line
Wrap the body at 72 characters
Use the body to explain what and why vs. how

A good rule of thumb is to use the sentence: if applied, this commit will... and end it with your commit's title. If it makes no sense, you might want to reconsider it.

For example: if applied, this commit will remove all deprecated methods sounds great, whereas if applied, this commit will fix bug #123 doesn't.

Note: if you're using a tool such as Jira you could incorporate your ticket numbers in both your branch names and commit messages in order to make it easier to cross check.

Also, don't forget that these are just tips, and that at the end of the day you can always follow your own path. We'll all end up with some 'please work' commit messages here and there. 😄

Github labels

Github labels are another great way of filtering through your pull requests. So here are some labels I've found useful in the past and their meaning (when it isn't obvious):

Good first issue: especially great when your project is open-source and looking for new contributors. It's a great entry point for anyone too afraid to help out
Feature
Bug
Tech: means the associated pull request isn't about a client-facing feature. It could be about your project's eslint or storybook configurations for example
Critical: helps your team know which PRs are worth reviewing first, especially when on a tight deadline
Help wanted
In progress
XS, S, M, L and XL: represents the size of the PR at a quick glance. It's hard to determine how many lines changed will make up for any of these sizes, it's all up to you
Review needed
Reviewed

Labels can be changed by clicking on the following link in your pull requests page:

It's now as simple as clicking on "New label", setting a name, optional description and a color.

Protecting Git branches

You can limit branch manipulation by, for example, enforcing a required status before merging a given branch. This is great when you've set code review rules and don't want anyone to mistakenly merge a branch.

As admin of a project, go to Settings => Branches => Add rule and input the name of the branch you wish to protect.

You can chose from a number of rules, including:

Requiring X pull request reviews before merging
Requiring status checks to pass before merging, great when you have a robust CI process in place

Creating Git hooks

I'll quote the official docs for this one:

Git hooks are scripts that Git executes before or after events such as commit, push and receive. Git hooks are a built-in feature - no need to download anything.

Every Git repository has a .git/hooks folder with a script for each hook you can bind to. You're free to change or update these scripts as necessary, and Git will execute them when those events occur.

I'd recommend using awesome tools such as Husky in order to create them easily.

Automatically executing your tests and blocking a push if they fail will go a long way to avoid polluting your git history.

Honorable mentions

I'd like to mention something I use regularaly on personal projects such as Foodpicker, Banner Generator or Gitignore It (if you're curious, check out their Git history): 🎨 ⚡️ Gitmoji 🔥 🐛! It's a way of codifying your commit messages using emojis, this way you can understand the context of a commit at a glance. Some might dismiss it right away due to its colorful nature, but I've found it very useful to generate changelogs for example.

Some awesome tools such as gitmoji-cli and gitmoji-changelog make my Git experience smoother on a daily basis, so make sure to check them out if you're interested !

I hope you've learned a couple of things reading this article ! As always, I'd love for you to tweet at me @christo_kade if you have any questions 😄

Take care, and don't forget: always rebase locally ❤️

Tips to write elegant and resilient components

Christopher Kade — Thu, 08 Aug 2019 11:18:26 +0000

As a Front-end developer, building resilient and reusable components is a top priority of mine, and there are so many arguments in favor of well thought out components.

Thankfully, most of today's UI libraries and frameworks go a long way to help you build the best components possible for your projects (and more importantly, for your team). Nevertheless, keeping a few guidelines in mind can help us avoid pitfalls, especially when it comes to large-scale applications.

In this article, we'll go through concepts I follow everyday that are library and framework agnostic, meaning they apply to UI components as a whole.

Have a modular approach
Name your components well
Keep your props simple
Keep your business logic in container components

Have a modular approach

Ideally, your components should follow the FIRST principle:

Focused: one component, one responsibility, if a component is doing too much, ask yourself if you can extract that logic somewhere.
Independent: ideally, a component should not depend on another one to function. Passing simple and straight to the point props can help you create independent elements. If you've ever used Storybook, think of it that way: Can I extract this component into a story easily?.
Reusable: UI components are lego bricks, they should fit anywhere pretty easily. Once again, a component's reusability is often determined by the simplicity of its props (more on that topic later).
Small: I was horrified to see components reaching the 1000 lines mark on a project I'm currently consulting on. Keep 👏 them 👏 small. A small component can be read and explained easily and is simpler to test.
Testable: How much mocking is required to test this component? is usually a good question to ask yourself, complex components will require a complex context to mock beforehand. Keeping in mind that the easiest components to test are known as pure components, meaning that for a given input, the component will always render the same output, produces no side effects and relies on no external mutable states.

Of course, you'll be working on elements that are truly dependant on your business logic, meaning you probably won't be able to follow these guidelines completely, and that's okay. Some components aren't meant to be reusable and some components won't be independent; but keeping this principle in mind is a good start.

Name your components well

I tend to try and keep my component names short, meaningful and easy to pronounce.

Here are some good and bad examples:

<!-- Good -->
<user-button></user-button>
<payment-details></payment-details>
<user-card></user-card>

<!-- Bad -->
<user-btn></user-btn> <!-- hard to pronounce -->
<user-guarantee-payment-tab></user-guarantee-payment-tab> <!-- too long -->
<ui-dropdown></ui-dropdown> <!-- every component is a UI element, no need to mention it -->

Keep your props simple

As mentioned in the first tip, props can make or break a component.

Avoid passing down complex object structures, favour individual attributes as props whenever possible
Use simple names for your props. We should be able to understand its purpose (even partially) upon reading it

Basically, try using Javascript primitives (strings, numbers, booleans) and functions as props whenever possible.

Keep your business logic in container components

Container components (such as layouts) should take care of computation and business logic as a whole in order to pass its results as props to presentational components.

This pattern isn't always valid, but the idea it promotes is important to keep in mind: complex and stateful logic is easier to maintain when kept separate. In the case of a React application for example, this business logic can be extracted in a custom hook, so this "smart/dumb" component pattern really is about separation of concern.

Often times, having each component handle their own logic can lead to them being hard to re-use throughout your application as they will be bound to a specific context.

Don't overdo it

These are just general tips for building efficient components. Of course, each project has different requirements and may not allow for you to follow these guidelines all the time.

As Dan Abramov says in his Writing Resilient Components article: Don’t Get Distracted by Imaginary Problems. Keep in mind that it's not worth it to over-engineer all of your components and to enforce rules that may not bring meaningful differences.

I hope this short list will help some of you build better UI components in your day-to-day. As always, if you have any questions, tweet at me @christo_kade ❤️

Introducing Food Picker, the best way to pick what to eat with your colleagues !

Christopher Kade — Mon, 05 Aug 2019 20:45:23 +0000

It's lunchtime, you look up from your monitor and meet your colleague's gaze, they whisper: sushi, you whisper back: no way Jose.

You then share with them a link to Food Picker, and both select what you'd like to eat and BAM, an accord was reached: pizza.

This could be you if you used Food Picker with your team, no more debating where to eat, no more tears and anger, only food.

I hope some of you actually find this useful, otherwise here are some other projects I did recently:

A banner generator for DEV ➡️ Link
A .gitignore generator CLI ➡️ Link

If you like it, feel free to give it a ⭐️ right here!