Forem: Hana Klingová

Automate GitHub Issues with AI and n8n to Get More Time for Coding

Hana Klingová — Tue, 16 Sep 2025 14:51:35 +0000

When I first read the now famous tweet from Joanna Maciejewska

I want AI to do my laundry and dishes so that I can do art and writing, not for AI to do my art and writing so that I can do my laundry and dishes.

I could not agree more. I love writing code and I do not want AI to take over what I enjoy so much. But I would like AI to do the boring stuff that is part of a developer’s day-to-day life. If you know me, then you probably know that I like to keep the number of meetings to a bare minimum, and I do not like spending a lot of time on triage, planning, and retrospectives. So when I first heard about the n8n automation tool, my immediate thought was to see if it could handle GitHub issue triage, using AI to do the thinking part.

TL;DR: Yes, it can and it is easy to set up. 😎

What is n8n

n8n is an open-source workflow automation tool that lets you wire up APIs and services without spending hours reinventing the wheel. It has built-in nodes for things like GitHub, Slack, Jira, Google Drive, Notion, and many, many more, but you can also drop down to raw HTTP requests or custom functions when you need control or something custom. It lets you automate things quickly, so you don’t waste hours writing all the code yourself.

Plus, n8n comes with an intuitive drag-and-drop interface that makes the whole process even easier and more straightforward. You can visually design workflows, connect nodes with a simple drag, and see exactly how the entire workflow looks.

The plan

Let’s first lay down the overall plan and then elaborate more on each step once we get there.

Set up n8n locally.
Create a GitHub repository and prepare some issues.
Create the workflow logic
- Fetch all GitHub issues that need triaging.
- Send a prompt to AI for each issue with detailed instructions on how to perform the triage and what data to extract (labels and summary).
- Update each GitHub issue with the labels and summary returned by the AI.

Setting up n8n

Getting started is straightforward with the official documentation on how to get started. You can use n8n Cloud (they offer a free tier) or run a self-hosted version. If you just want to experiment, I recommend the self-hosted option: pull the Docker image and run it locally. Later, if you decide to deploy it more seriously, the documentation covers Docker Compose and Kubernetes setups.

Setting up GitHub repository

First we will need to create a GitHub repository and several issues so we can test the idea. I created a demo repository with 6 issues. My idea was that when the issue is created, it will get the needs-triage label (this part is handled by GitHub workflow and it is part of the repository), so the automation can target only those and we do not triage the same issues multiple times.

Since I am now just trying to verify my idea, I kept the issue description minimal and just made sure that they are diverse.

After the automated triage I want to sort my issues and assign to each a type, priority and complexity label.

type: bug, enhancement, question, documentation or tech-debt
priority: priority: high, priority: medium or priority: low
complexity: good-first-issue, regular , or complex

The automation flow will be:

get all GitHub issues with needs-triage label
let AI analyze them and assign labels and generate a short summary of the issue
update the labels on GitHub

You will need to create a GitHub Personal Access Token with repo permissions (the token needs to be able to read and update issues) and and API token for the AI node - I will use OpenAI.

So let’s start building it up!

Workflow Trigger

There is a Schedule Trigger node that allows us to schedule an execution daily, weekly, etc. I decided to also use When clicking 'Execute workflow' trigger node so I can test the flow easily.

Fetching Issues from GitHub

The next step is fetching issues from GitHub with the needs-triage label. Luckily n8n has already build-in GitHub integration, so just search for GitHub and then select Get issues of a repository. My node configuration looks like this:

And we just connect the node to the trigger(s).

Triage Logic Implementation

The GitHub node returns all the issues, so now we need to configure the workflow so it:

loops through the items
for every item it uses the AI to do the triage
update the labels on GitHub

So let’s first add the Loop over Items node and set the batch size to 1 (because we will be handling items one by one). And after our loop node we connect the Open AI Message a model node. Select your API key and which model you want to use (I used the GPT-5 model).

The most important part is the prompt. Here is the prompt I used - at the end you can see me passing the actual title and body of the issue we are currently looping.

You are a GitHub triage assistant. 
Given the title and body of a new issue, return a JSON object with the following keys:

{
  "type": "bug | enhancement | question | documentation | tech-debt",
  "priority": "priority: high | priority: medium | priority: low",
  "complexity": "good-first-issue | regular | complex",
  "summary": "<short summary of the issue in less than 50 words>"
}

Rules:
1. Type classification:
   - "bug" = broken functionality.
   - "enhancement" = feature request or improvement.
   - "question" = user inquiry or clarification.
   - "documentation" = docs-related issue.
   - "tech-debt" = refactoring, internal cleanup, maintenance tasks.
2. Priority classification:
   - High = critical or urgent.
   - Medium = important but not urgent.
   - Low = minor, trivial, or cosmetic.
3. Complexity classification:
   - "good-first-issue" = simple, well-defined, easy for a new contributor (e.g., styling, copy changes, small fixes). Priority is NOT high.  
   - "regular" = standard issue that requires some experience or understanding of the codebase.  
   - "complex" = difficult issue, may involve multiple components, advanced knowledge, or high-risk changes.
4. Summary should be concise (<50 words).
5. Return valid JSON ONLY, no extra text.

Example input:
Title: "Fix typo in README"
Body: "There's a small typo in the installation instructions."

Example output:
{
  "type": "documentation",
  "priority": "priority: low",
  "complexity": "good-first-issue",
  "summary": "Correct typo in README installation instructions."
}

Now classify this issue:
Title: {{$json["title"]}}
Body: {{$json["body"]}}

💡Tip: Don’t be afraid to use an AI tool to help you generate the prompt itself.

So our flow now looks like this:

Now we come to the more technical part. The AI node returns only the labels and summary for each issue, but in order to be able to edit the issue we will also need the issue number. Luckily n8n has a Merge node which enables us to merge data from multiple nodes. When adding the merge node, we can choose how we want the merge to happen. Since our data source has no common fields we will use the append mode and 2 inputs. And we connect our AI and our Loop nodes as the inputs.

Now we successfully merged the data from GitHub and the data from AI and we are ready for the next step.

Next we need to access the data from both sources and we will do it by using the Code node. This is a very powerful node because we can write any custom logic we want. For demo purposes we will keep it simple and we will just extract and return the final data we need by adding this simple JavaScript code:

const data = $input.all();

const aiResponse = data[0].json.message.content;
const loopItemData = data[1].json;

return [{
  json: {
    issueNumber: loopItemData.number,
    type: aiResponse.type || "",
    priority: aiResponse.priority || "",
    complexity: aiResponse.complexity || "",
    summary: aiResponse.summary || ""
  }
}];

And the last step will be adding the GitHub node, but this time it will be Edit an issue node. And we can configure this node to use the issue number and labels we returned from previous node to update the item.

Final workflow looks like this:

Now we only need to trigger the flow and check the result on GitHub. It really did a good job and did the triage the same way I would do it myself. Of course in real world and with way too many issues we may need to tweak the prompt, but I am pretty confident that this would work very well in production settings as well.

Conclusion

I have to say, I am impressed by what n8n can do. Most of the heavy lifting is covered by built-in integrations with tools like GitHub, Slack, Jira, Google Drive, Notion, and more, making automation fast and simple. For anything the built-in nodes don’t cover, the Code block lets you write custom logic, call APIs directly, or manipulate data however you need.

The UI for building workflows is intuitive, so prototyping solutions is quick and straightforward. And if you don’t want to start from scratch, n8n offers pre-built workflow templates that can be just simply customized to your needs. You can even build your own custom nodes to extend n8n’s functionality beyond what’s available out of the box.

Some ideas of what can be automated:

Slack/Discord notification when a PR is created or merge
PR review notifications
Pulling data from multiple sources and creating reports
Pulling RSS feed and create a newsletter
Onboarding new employees - automatically create accounts and even assign first JIRA or GitHub tasks based on labels/priorities

In the end, there are no limits except your own imagination.

React 19 Makes Forms Fun Again: A Deep Dive into the New Hooks

Hana Klingová — Tue, 02 Sep 2025 14:49:11 +0000

React 19 has been around for a while (the stable RC candidate was released in December 2024), but it still seems to be flying under the radar. Most developers I talk to either aren’t familiar with the new features or haven’t bothered upgrading yet. One area where the changes really stand out is form handling. Forms are one of the most tedious parts of building a web app - juggling pending state, tracking errors, and maybe even throwing in an optimistic update if you’re feeling fancy. Sounds simple, but without a third-party library, it rarely is.

The best way to understand the changes is to dive into the code itself. Let’s have a look at a demo app, you can find the source code on GitHub. It is just a simple app with a form. For simplicity, we’re using local state and a short delay to mimic how a backend would respond. In a real app, you would be calling an actual API or, in a framework like Next.js, you would be using server actions.

The first example is the React 18 one - it means we need to handle the state for the form inputs, the form pending state and also the errors. Quite a lot of work that we need to write over and over again for every single form.

const Form: React.FC<FormProps> = ({ createReminder }) => {
  const [title, setTitle] = useState<string>("");
  const [description, setDescription] = useState<string>("");
  const [isPending, setIsPending] = useState<boolean>(false);
  const [error, setError] = useState<string>("");

  const handleSubmit = async (e: FormEvent<HTMLFormElement>) => {
    e.preventDefault();

    setIsPending(true);
    const result = await createReminder(title, description);
    setIsPending(false);

    if (result?.error) {
      setError(result.error);
      return;
    }

    setTitle("");
    setDescription("");
  };

  return (
    <form autoComplete="off" onSubmit={handleSubmit}>
      <p className="error-text">{error}</p>

      <label htmlFor="title">Title</label>
      <input
        type="text"
        name="title"
        disabled={isPending}
        value={title}
        onChange={e => setTitle(e.target.value)}
      />
      <label htmlFor="description">Description</label>

      <textarea
        name="description"
        rows={5}
        disabled={isPending}
        value={description}
        onChange={e => setDescription(e.target.value)}
      />
      <button type="submit" className="create-button" disabled={isPending}>
        {isPending ? "Creating..." : "Create"}
      </button>
    </form>
  );
};

useTransition

Now let’s have a look at how we can simplify the code using one of React 19’s new hooks - the useTransition hook. This hook defers low-priority state updates. Simply wrap them in startTransition(), and React treats them as non-urgent. Why? Complex updates can block the main thread, making the UI unresponsive and impacting user experience. When using a transition, React schedules and prioritizes rendering so the UI stays responsive, even if other state changes are happening.

Moreover the hook also keeps track of whether the transition is ongoing.

We can use it to simplify our form implementation, but it also has other use cases - if you need logic for switching tabs or filtering/searching a long list, useTransition can do the job.

const Form: React.FC<FormProps> = ({ createReminder }) => {
  const [title, setTitle] = useState<string>("");
  const [description, setDescription] = useState<string>("");
  const [error, setError] = useState<string>("");

  const [isPending, startTransition] = useTransition();

  const handleSubmit = async () => {
    startTransition(async () => {
      const error = await createReminder(title, description);
      if (error?.error) {
        setError(error.error);
        return;
      }
      setTitle("");
      setDescription("");
    });
  };

  return (
    <form autoComplete="off" action={handleSubmit}>
      <p className="error-text">{error}</p>

      <label htmlFor="title">Title</label>
      <input
        type="text"
        name="title"
        disabled={isPending}
        value={title}
        onChange={e => setTitle(e.target.value)}
      />
      <label htmlFor="description">Description</label>

      <textarea
        name="description"
        rows={5}
        disabled={isPending}
        value={description}
        onChange={e => setDescription(e.target.value)}
      />
      <button type="submit" className="create-button" disabled={isPending}>
        {isPending ? "Creating..." : "Create"}
      </button>
    </form>
  );
};

useActionState

But what if we want just a simple way of handling form and we want to get rid of handling the state? In that case, we can use the useActionState hook.

This hook returns 3 values:

The first one is the result we get from our “backend“- in our case, the error value.
The submitAction, which we can pass to the form component.
The isPending state.

It also gives us access to previousState and formData. The formData can be used to extract the values from input. The previousState can be handy for example in case we need to calculate some value based on its previous state or we need to compare the previous and current values.

const Form: React.FC<FormProps> = ({ createReminder }) => {
  const [error, submitAction, isPending] = useActionState(
    async (previousState, formData) => {
      const title = formData.get("title");
      const description = formData.get("description");

      const error = await createReminder(title, description);

      if (error) {
        return error;
      }

      // any logic for the successful submission
      return null;
    },
    null,
  );

  return (
    <form autoComplete="off" action={submitAction}>
      <p className="error-text">{error?.error}</p>

      <label htmlFor="title">Title</label>
      <input type="text" name="title" disabled={isPending} />

      <label htmlFor="description">Description</label>
      <textarea name="description" rows={5} disabled={isPending} />

      <button type="submit" className="create-button" disabled={isPending}>
        {isPending ? "Creating..." : "Create"}
      </button>
    </form>
  );
};

useOptimistic

Now we have a very simple and elegant way to handle a form, but let’s take it even one step further by adding an optimistic update. We can leave the form implementation as it is, and add the logic for updating the UI in an optimistic way just to the parent component. And it is easier than you might assume.

The useOptimistic hook takes the state and function to update the state as arguments and it will return to us the state value and a function we can use to add an item to the state before we trigger the actual function that saves the data.

This way the UI presents the data to the user immediately and in case there is an error, the value will be removed. If you ever tried to implement this yourself, I am sure you really like this new simple way.

const UseOptimisticPage = ({ reminders, createReminder }) => {
  const [optimisticReminders, addOptimisticReminder] = useOptimistic(
    reminders,
    (state, newReminder) => [...state, { ...newReminder, isPending: true }],
  );

  const createReminderOptimistic = async (title, description) => {
    const optimisticReminder = {
      id: Date.now(),
      title: title.trim(),
      description: description.trim(),
    };

    addOptimisticReminder(optimisticReminder);

    return await createReminder(title, description);
  };

  return (
    <>
      <RemindersList reminders={optimisticReminders} />
      <FormUseActionState createReminder={createReminderOptimistic} />
    </>
  );
};

React 19 is not only introducing improvements in form handling, but much more. Let’s have a look at some changes that may seem small, but I found them very handy.

useFormStatus

If you’re using a reusable button for your forms, you will definitely appreciate the new useFormStatus hook.

How does it work? It finds the parent form component and returns the pending status of the last form submission (basically whether the form is currently being submitted).

import { useFormStatus } from "react-dom";

function Button() {
  const { pending } = useFormStatus();
  return <button type="submit" disabled={pending} />;
}

use API

Have you ever wished you could read a context or a promise inside of a component conditionally? If so, this new API (yep, it is an API, not a hook) allows you to do so.

function MyComponent = ({ data }) => {
    if(data.length > 0) {
        return null;
    }

    const theme = use(ThemeContext);
}

The use API enables us also read a promise - and React will automatically suspend until the promise is resolved. So it works well together with Suspense and Error boundaries.

In this example we have a promise function that loads data. Until the promise is resolved and the data are loaded, the UI will show the Suspense boundary.

const Page = ({ promiseFn }) => (
  <Suspense fallback={<div>Loading...</div>}>
    <Comments promiseFn={promiseFn} />
  </Suspense>
);

const Component = ({ promiseFn }) => {
  const data = use(promiseFn);
  return data.map(item => <Item item={item} />);
};

Metadata support

You can define title, link and meta directly in your components and they will be hoisted and injected to the head element. This improves the SEO of the application and removes the need of a third party library (like react-helmet). But in case you have a more advanced scenario, you may still need a library.

const UseOptimisticPage = ({ reminders, createReminder }) => {
  // page logic

  return (
    <>
      <title>useOptimistic example</title>
      <meta name="keywords" content="React 19, useOptimistic" />
      <RemindersList reminders={optimisticReminders} />
      <FormUseActionState createReminder={createReminderOptimistic} />
    </>
  );
};

Stylesheets

In case of SSR (server side rendering) <link> tags are included in the <head> so the browser will not paint the UI until the the stylesheet is loaded.

In case of CSR (client side rendering) React will wait until the stylesheet is loaded before committing a render.

ref improvements

ref can be passed as prop, no need for forwardRef.

const Input = ({ ref, ...props }) => <input ref={ref} {...props} />;

We can also now specify the cleanup function that executes when the element is removed from DOM.

const Input = ({ ref, ...props }) => (
  <input
    ref={element => {
      return () => {
        // cleanup
      };
    }}
    {...props}
  />
);

Context as Provider

You can render just <Context> instead of <Context.Provider>.

const ThemeContext = createContext("");

const App = ({ children }) => (
  <ThemeContext value="dark">{children}</ThemeContext>
);

Conclusion

Those are the features and improvements that caught my eye the most. There’s much more to explore - from Server Components and Server functions to the new React Compiler.

You probably won’t use Server Actions or Server Components on their own, because they aren’t designed to be standalone features in plain React apps. They rely on framework-level tooling (like Next.js or React Router) for routing, data fetching, and bundling. Without that integration, you can’t easily run them in production.

I hope you found your favorites too and that your next application will be built with React 19. If you’re planning an upgrade, the official guide is the best place to start.

React 19 isn’t just an update - it’s a shift in how we write React apps. Better stay ahead of the curve.

Code Reviews in a Galaxy Far, Far Away

Hana Klingová — Mon, 18 Mar 2024 09:00:35 +0000

Code reviews are a huge part of our day-to-day job and over the years I realized it takes time to learn how to write them in a way that is helpful and also encouraging. As developers we tend to be very direct when we communicate, but when it is not done face to face or when we work on remote team and do not know each other well, very direct communication can make an impression of being rude or harsh. Also sometimes the feedback is just too vague or cryptic or reflects a personal preference, making it hard to understand what should be fixed. Let me demonstrate how bad comments might look like and then suggest how we can do better.

Let’s start by thinking about what comments might have different characters from Star Wars write.

Chewbacca

Chewbacca would probably not bother to attach his comment to a specific line of code. He would just leave all comments together. Just by reading it, you see a Wookiee screaming at you.

Argh... Coding style. Grrrr! Argh! Not working code. Argh! Code duplication. Grrrr! Argh! Inconsistent naming. Argh! Performance. Grrrr!

This feedback is too generic, missing a context and does not help anyone to understand how to fix it. It also does not indicate how big the issue is - does it have to be fixed, is it just a suggestion for improvement or should it be fixed in separate PR because it may be something that is not related entirely to your changes and needs to be solved in generic way? Moreover it may just make the author of the changes demotivated because he may feel like every single line is bad.

Wookiees make great companions and loyal friends. But when writing your reviews, please remember, let's not channel our inner Chewbacca.

Master Yoda

Master Yoda is the kind of reviewer who gives you cryptic advice. You will have to spend a lot of time figuring out what to do.

Hmm, indentation, consistent it must be. Readable code leads to the light side, it does.

Ah, error handling missing, it seems. Prepared for failure, your code must be. Robust it shall become.

Ah, magic numbers found. Constants, you should define. Understandable code, it will make.

Sometimes it may be very generic without any hint what is wrong - leaving you in complete dark.

Hmm, design patterns overlooked, they are. Powerful tools, they can be. Study them, you must.

Master Yoda is very wise, but remember to provide constructive feedback. Leaving your colleagues in the dark, similar to Luke leaving Dagobah before completing his training, does not help anyone. May the Force of clear communication be with you.

Darth Vader

Darth Vader would give you feedback in the form of commands, and you would be scared to ask any questions or to explain why you may disagree.

Your lack of error handling disturbs me. Correct it immediately, or face the consequences.

Unit tests are a shield against the weaknesses of your code. Write them, or face the full power of the dark side.

Duplication is a sign of your weakness. Eliminate it, or face my anger.

This kind of feedback is not helpful at all. Instead of relying on your inner Darth Vader, try to awaken your inner Anakin instead. Write your reviews with ambition and empathy.

Anakin

Anakin would strive for the best code possible. He would motivate everyone to think creatively and not rely on repeating the same thing over and over again. He would ensure that you fix all the issues that may lead to problems and make sure that the code will be easy to maintain going forward. Most likely, he may suggest new ways of doing things, teaching his Padawans not to be afraid to evolve and become more powerful.

Commented-out code is a relic of the past. Remove it, and let the Force guide your refactoring efforts.

Long functions are like tangled webs in the Force. Let's break them down into manageable, focused units of logic.

Your commit messages are as vague as a Jedi prophecy. Provide clear and informative messages that leave no room for ambiguity or misinterpretation.

Conventional comments

For me, the most important thing is to be clear about what is an actual issue, what is an improvement, and what is just a nitpick. This helps the author of the PR to know where to focus and what they can omit if they don't agree with me. To make this easier, I started using conventional comments.

You may find several articles about how to approach it, for example, this one. The main idea is to use prefixes to indicate the type and importance of your comment (if you are familiar with conventional commits, this is very similar).

Here is the list of prefixes I use with my own descriptions:

issue - for raising problems like non-working code, not fixing the bug properly, or when the implementation has significant flaws.
fix - for smaller issues that need to be addressed.
suggestion - when the code works but can be improved, such as for refactoring or using an alternative approach.
nitpick - just comments I have when reading the code, but they can be omitted, mostly reflecting my personal preferences.

I also like the idea of using praise to give positive feedback. However, personally, I prefer leaving a positive overall comment with emojis and a personal message. When I'm very impressed, I might even leave a haiku praising the code.

So, what makes a good review?

Utilizing conventional commits.
Providing feedback and information when it makes sense. If there is an issue, explain why it is an issue and how it can be fixed. Include links to related documentation or articles.
Ensuring the tone is not too direct (no Darth Vader). Adding an emoji or two can often soften the tone.
If you know the other person, don't be afraid to use internal jokes or speak in a familiar tone.
Remember that the goal is not for everyone to write code the same way you would. There are multiple ways to reach the destination, and usually, more than one of them is correct.
Avoid nitpicking excessively, especially if there are many other comments.
When reviewing the work of a junior developer, take the time to leave some positive feedback, even when approving the changes. It can make a difference.

I'm sure there are many other things that may contribute to better and more constructive feedback. Feel free to share yours in the comments!

May the conventional comments be with you!

Copilot: Weapon For Laid Back Developers

Hana Klingová — Tue, 06 Feb 2024 19:49:58 +0000

Lately, we've seen an explosion of AI tools that help us to be more effective and productive. Luckily, so far, they are here to help us and not to replace us. As a developer one of the tools I am using the most is Copilot. GitHub advertises it as “Your AI pair programmer” and this is exactly what it is to me: a junior colleague who writes the code with me. Yay, finally not feeling alone while writing code all day.

I recently presented at FrontKon, a Czech conference for frontend developers, where I showcased some of my most common use cases. And since the talk was in Czech, I decided to write an article about it in English as well.

Fun fact - I even gave my Copilot name - Alfred. Why? Because I am still the superhero (yes, this is Batman reference) and he is here to guide me, support me and help me.

1. Advanced autocomplete

Most of the time I use Copilot “just” as advanced autocomplete in my IDE. It might seem kind of trivial, but, in my opinion, this is where it truly excels. Sometimes it just drops in a line or two, while other times it goes all out and suggests an entire code block. As a frontend developer it saves me time mostly when writing logic related to state management or any utility functions.

In my example I am using Redux Toolkit and I got a prompt for actions to login and logout the user. If I need more functions, I can simply start typing the name, and Copilot provides the completion. For instance, in the example, I'm adding a function to update the user. And of course at the end of the file it suggests the exports.

To be honest I did not realize how much I am used to the autocomplete until the GitHub has an outage and my IDE stop being so powerful.

2. Explaining code

Copilot now offers also chat interface perfect for asking code-related questions. I'm not just talking about basic questions, you can also ask Copilot to explain a code snippet or decode error messages. This feature is a game-changer and can help a lot while learning a new technology or tackling unfamiliar parts of your code base.

In my example you can see some code written in Go and I have highlighted the function I am interested in. On the left side I have my Copilot Chat interface opened and all I have to do is type /explain and Copilot will explain what the function does. And since this is chat interface, it is of course possible to ask follow up questions. Pretty powerful, right?

3. Terminal commands

I love using my terminal for as much as possible, but I have trouble to remember the commands. This is where Copilot can be very helpful as well. And when using the chat interface to ask for the right command, there is also an option to paste the suggested command to my terminal right away.

4. Unit tests

Unit tests are important, but who actually enjoys writing them? It's definitely not the part of my job I enjoy. Luckily, Copilot is able to generate unit tests pretty well, especially for not very complex code. So, whenever I have a function or UI component, I simply ask Copilot to generate unit tests for me, and then I do the review. This way, the process is more fun. I just check if the tests might be improved or if some of them are redundant or missing.

And the chat interface again has a very useful option to just insert the generated code at the current position of the cursor. Cool, right?

5. Generating code

Copilot can also generate a whole block of code. I find it very useful, for example, when writing a GitHub workflow. Because I am still learning, it is very helpful to request the code in plain English and then reverse engineer the solution. This way, I am able to deliver the automation I need and also learn something new.

Yes, Copilot is an amazing tool for learning as well. The chat interface enables me to ask questions and follow-up questions. If needed, I can also ask questions about my code, and it has the context of the file I am working on. This is much more powerful than just using Google.

In my example, I am asking Copilot to 'write a GitHub workflow that will run lint for a React application and then generate a unit test coverage report using the yarn coverage-ci command and upload the result to Codecov.' I receive not just the code itself, but also a reminder to set up the environment variable on GitHub.

Co-pilot can be very powerful and speed up the development process. You can use it as an advanced autocomplete, as your pair programming buddy, or as a learning tool. Or all of it! But you need to keep in mind that it does not always write the best code - the code might fail, be outdated, or not optimal. Remember, you are the Batman, and Co-pilot is your Alfred.

Do you use Copilot? And how it helps you? Don't forget to share in comments! 👇

Git Battle: YOLO Mode vs. Clean History

Hana Klingová — Tue, 06 Feb 2024 19:17:35 +0000

If you use Git at work or even for your own projects, you may have encountered a situation where you need to modify one of your previous commits, right? It doesn't matter if it's a typo in a variable name, forgetting to include a file in a commit, or simply needing to change the commit message or anything else.

Be honest, have you ever seen a message history like this?

feat: fetch user profile from server
fix: fix error
fix: now really fixing the error
fix: noooow it should work
fix: fix typo

So what can you do about it? 🤔 Over the years, I've seen various approaches which I want to share with you.

Committing Chaos: YOLO Mode

We live only once, so why should you even care about it? If the code works, who cares about the git history, right? Or maybe you just do not know how to fix it in git properly and might fear what can go wrong, so you decide not to care. Frankly, I understand that approach, and if it is 'just' for a personal project, why not? 🤷‍♀️ But if you decide to take this approach at work, you will probably make your colleagues very unhappy.

One Commit to Rule Them All

If you are in this category, you realize the need for a clean git history but decide to ~~take a shortcut~~ think outside of the box, and come up with the idea to just squash all the commits into one with a nice commit message. This might work very well for some use cases. However, if it means that you are putting more features and bug fixes into one commit, this is not the best approach, and I might even argue that the previous approach would be better in this case. 🙈

Unleashing the Wizard of Clean Commits

Personally, I think that most developers need to find their way to realize why a clean commit history is beneficial. For me, it was hours of digging into the history and trying to find something, constantly scratching my head because commits that were supposed to fix styling issues also changed business logic. 😢 So let's take a look at how we can achieve a nice and clean commit history using rebase and fixup.

Imagine that your commit history looks like this:

80316d8 (HEAD -> master) style: redesign profile page
95ca0cd feat: fetch user profile
bbf0488 feat: add user authentication
df7c600 initial commit

💡I am using git log --oneline to see only compact version of the commit history.

Now, you need to make a change that you want to append to one of your previous commits - 95ca0cd feat: fetch user profile because the changes are related to this commit. First, you need to add the changes to the staged area. You can use git add . if you want to commit all files, or add only the files that should be included in your commit. Then, commit changes using the magic word fixup with the command:
git commit --fixup=95ca0cd.

Git will create a new commit, and the history will look like this:

0e09e61 (HEAD -> master) fixup! feat: fetch user profile
80316d8 style: redesign profile page
95ca0cd feat: fetch user profile
bbf0488 feat: add user authentication
df7c600 initial commit

💥 Most likely you need to adjust your git configuration in order to make the autosquash work. I recommend doing it globally. You can do it in your terminal by typing

git config --global rebase.autosquash true

Now you can easily rebase your branch using git rebase -i --autosquash HEAD~4 (you can specify how many commits you want to include in the rebase process). The fixup commit will be moved up and then automatically squashed into the right commit.

This is how it will look like in case you are using a terminal and text editor. In case you are using some GUI I guess your result will look similar. At this point you can also select what other changes you want to do during the rebase. You can reword the commit message, squash commits into one and more!

pick bbf0488 feat: add user authentication
pick 95ca0cd feat: fetch user profile
fixup e5bf471 fixup! feat: fetch user profile
pick a183fc0 style: redesign profile page

Git rebase is very powerful and if you mix it with the fixup commits you have a very powerful tool at hand. I hope you will give it a try next time you will need to solve a similar problem. 😎

Level up: 10 Tips for Writing Better Code

Hana Klingová — Tue, 06 Feb 2024 18:50:47 +0000

You've probably heard about clean code - whether you're an experienced developer or a total newbie. But what the heck is clean code, and why should you even care? If you ask Google or ChatGPT, you might get several definitions, but in a nutshell, clean code is the kind of code that's easy to read, easy to understand, and easy to maintain. It makes debugging, changing, or extending the code in the future easier. So, by writing clean code, you're doing a huge favor not only to your coworkers but also to your future self. I'd like to share 10 tips that, in my opinion, are a good starting point if you're beginning your journey to writing better code. 👩‍💻

Naming variables and functions
Avoid using magic values
Guard statements
Ternary & nullish coalescing operators
Optional chaining
Default parameters
Single responsibility functions
DRY - Don’t Repeat Yourself
Object destructuring
Minimize unnecessary comments

💡 The code snippets are written in JavaScript. Almost all of the principles are applicable for other programming languages as well.

1. Naming variables and functions

When it comes to naming variables and functions, it's important to choose names that are descriptive. Even though the computer doesn't care about the names you use, opting for descriptive names makes your code easier to understand. Sure, using a single character as a variable name might save you a few seconds of typing, but it'll make your code really hard to read.

You can declare your variables like this:

let a = "Mario";
let b = 5; 
const c = 50;

However, when you later need to change the values stored in those variables, you'll have no clue what should be stored there. So, it's better to use more meaningful names like name and level because they clearly indicate what values they hold.

In addition, when dealing with constants, it's useful to use uppercase names. This convention makes it evident that the value is a constant. I also strongly recommend using underscores as separators to enhance readability. In our example, MAX_LEVEL is much easier to read than MAXLEVEL.

let name = "Mario";
let level = 5;
const MAX_LEVEL = 50;

The same logic applies to naming functions. Imagine a function that looks like this:

function x(a, b) {
  return a + b;
}

Later in your code, if you see this function being called as x(13, 21), it's not clear what it does, and you'll have to check its implementation. It would be much better if you can call the function like this: sum(13, 21). This way, it's obvious what the function does. Here's an example of how the implementation might look:

function sum(number1, number2) {
  return number1 + number2;
}

2. Avoid using magic values

Whenever you are having a constant in your code, create a variable with a descriptive name and do not just use it as a magic value.

Imagine following code.

if(level < 50) {
  // do something
}

Well what is so special about number 50? Why not 49 or 51? Let’s now create a variable and make the code easier to understand.

const MAX_LEVEL = 50;

if(level < MAX_LEVEL) {
  // do someting
}

3. Guard statements

You don't want to have excessive nesting of if statements in your code. Too much indentation makes the code hard to read. Guards are a simple pattern that allows you to exit the code execution early, with the main logic not being nested in the else statement.

Let’s have a look at the following example:

function onUploadFile(event) {
  if (event.target.files.length > 0) {
    const file = event.target.files[0];
    if (!isFileSupported(file)) {
        throw new Error("Wrong file format.");
      } else {
        // main logic
      }
  }
}

As you can see, there is excessive nesting, requiring considerable effort to understand what is happening. Let's rewrite the same code, but this time we will utilize guard statements.

function onUploadFile(event) {
  if (!event.target.files.length) {
    throw new Error("No file was selected.");
  }
  const file = event.target.files[0];
  if (!isFileSupported(file)) {
    throw new Error("Wrong file format.");
  }
  // main logic
}

Now the code is more linear, with reduced nesting, making it easier to read. Just by looking at the code, you immediately know the cases where the function will throw an error due to invalid input parameters.

4. Ternary & nullish coalescing operators

Another way to avoid nesting in your code is by using ternary operators, which provide a shorthand for writing simple if/else statements. Consider the following scenario:

function greetUser(user) {
  if (user.name) {
    return `Hello, ${name}`;
  } else {
    return "Hello, stranger";
  }
}

The first improvement is that we can omit the else statement if we are using return in the if clause.

function greetUser(user) {
  if (user.name) {
    return `Hello, ${name}`;
  }
  return "Hello, stranger";
}

However, we can further improve the code by utilizing the ternary operator, which allows us to express the logic in just one line of code.

function greetUser(user) {
  return user.name ? `Hello, ${name}` : "Hello, stranger";
}

Sometimes, you may need to conditionally assign a value to a variable. This can also be achieved using the ternary operator:

const GREETING = user.name ? `Hello, ${name}` : "Hello, stranger";

Now let's assume you only want to store the value of the user name and assign a fallback in case the user name is undefined or has null value. In such situations, you can use the nullish coalescing operator to simplify your code even further.

const DISPLAY_NAME = user.name ?? "stranger";

5. Optional chaining

Optional chaining is especially useful when working with nested objects or accessing properties that may or may not exist. It simplifies your code and makes it more readable by avoiding excessive null checks.

You have probably come across a condition written like this:

if(user && user.preferences && user.preferences.theme === "dark") {
  // do something
}

This condition is a result of having optional keys in the schema. However, with optional chaining, you can express this condition in a cleaner manner:

if(user?.preferences?.theme === "dark") {
  // do something
}

Furthermore, there are use cases where you might combine optional chaining with the nullish coalescing operator:

const THEME = user?.preferences?.theme ?? "dark"

6. Default parameters

In some cases, you may have a function with one or more optional parameters, and it becomes necessary to specify a fallback value. Let's begin by writing the code like this:

function splitText(text, separator) {
  const SEPARATOR = separator ?? ";";
  return text.trim().split(SEPARATOR)
}

Instead of declaring the fallback separator within the function, we can utilize default parameters to initialize the value of the separator in case the function is called without passing this parameter or if the value is undefined.

function splitText(text, separator = ";") {
  return text.trim().split(separator)
}

By doing this, your IDE will also display the function signature, making it clear which parameter is optional and what the default value is.

7. Single responsibility functions

Each function in the code should do just one thing and do it right. If you are using descriptive names for your functions, it should help you with this principle as well. If you are struggling to find a name that accurately describes the behavior of a function, it is a sign that the function might be performing multiple tasks. Therefore, it's a good idea to break down such function into smaller, more focused functions. This approach brings several advantages: it helps with code reusability and simplifies the testing process.

Let's imagine the following code snippet.

async function createComment(request, comment) {
  const session = await sessionStorage.getSession(request.headers.get("Cookie"));
  const userId = session.get("userId");
  if (!userId) {
    return new Response("Unauthorized", { status: 401 });
  }

  if(!comment.length) {
    return new Response("Comment can't be empty", { status: 400 });
  }

  return prisma.prescriptions.create({
    data: {
      userId,
      comment,
    },
  });
}

As you can see this function gets userId from a session, validates the input and then saves data to database. This clearly breaks the single responsibility principle. So let’s improve it by breaking it down into multiple functions.

async function getUserIdFromSession(request) {
  const session = await sessionStorage.getSession(request.headers.get("Cookie"));
  const userId = session.get("userId");
  if (!userId) {
    throw new Error("Unauthorized", { status: 401 });
  }
  return userId;
}

export function validateComment(comment) {
  if (!comment.length) {
    throw new Error("Comment can't be empty", { status: 400 });
  }
}

async function createComment(request, comment) {
  try {
    const userId = await getUserIdFromSession(request);
    validateComment(comment);
    return prisma.prescriptions.create({
      data: {
        userId,
        comment,
      },
    });
  } catch (error) {
    return new Response(error.message, error.status);
  }
}

Now we have 3 functions. You probably see that the function to get the userId might be helpful somewhere else in the code as well. Also the validateComment function might be used for example if we add the edit feature as well. By splitting the code we got smaller pieces that we can reuse elsewhere, which brings me to another principle - DRY.

8. DRY - Don’t Repeat Yourself

Avoid duplicating code segments. If you encounter a situation where you need to reuse the same logic that already exists elsewhere in the code, extract that logic into a separate function and reuse it. This might require some refactoring to make it more generic, but it is worth the effort. By doing so, if you need to modify the behavior later on, you will only have to make changes in one place instead of multiple places. By following the DRY principle, you are writing code that is easier to maintain in the long run.

9. Object destructuring

This JavaScript syntax allows you to extract values from an object and assign them to variables. You can also rename the variables or provide fallback values if needed.

Imagine you have an user object. By using distinct variables, you can avoid the need to prefix user. every time you access a property.

Let's examine the following code snippet:

let { id: userId, name, verified = false } = user;

In this case, we are creating 3 variables:

userId will be assigned the value of user.id
name will be assigned the value of user.name
verified will be assigned the value of user.verified, and if it is not specified, the value will default to false

This is very powerful syntax as it enables you to write clean and concise code.

10. Minimize unnecessary comments

Cut down on unnecessary comments - the code itself should ideally be self-explanatory, reducing the need for comments that just describe what the code does.

Comments should primarily explain why the code is written in a particular way. This can include cases where a workaround is implemented due to an ongoing issue with a dependency. By focusing on the reasoning behind the code, comments become more valuable and meaningful.

Another scenario where comments are typically used is when indicating what needs to be done in the future. To differentiate these types of comments, it is common practice to use prefix TODO: at the beginning of the comment. Your IDE most likely has extensions that can list all those comments which might be very helpful.

How Automation Saved Me from Oops Moments: Never Skip Tests in Production Again!

Hana Klingová — Tue, 06 Feb 2024 18:25:19 +0000

Every time I have to troubleshoot and fix a unit test (or Cypress test), I end up running just that one test locally—using the .only suffix in my test case. This syntax allows me to ignore all other tests in the same file, which is exactly what I need at the moment.

But you might know the feeling—sometimes I am just too excited that I finally managed to fix the problem, and I forget to remove the .only from the test case. And since we are all humans, the colleague who does the code review might also just not notice it, and it makes its way to production. As a result, we end up skipping some of tests because of a small mistake. 😬

As a developer, I prefer to write code that helps me avoid all the boring stuff and also spot issues like this. So, I decided I wanted to have some automation in place that would help catch this issue and fit into our project workflow. In this article, I want to share my solution with you; maybe it might inspire you to automate the same or a similar problem you might be facing.

I decided to address this problem on two levels:

Write a pre-commit hook that will notify the developer about this issue.
Write a GitHub action that will run for every pull request.

Pre-commit hook

We were already using lint-staged and have a pre-commit hook in place using Husky in our project for linter and prettier. So it made sense to add a check here.

So first I created a file pre-commit.sh which is a bash script that checks all the staged files and looks for the .only text.

Then I just had to specify for which files I want to run this script in my lint-staged.config.js configuration file. In my case I wanted to run the script only for the JavaScript and TypeScript files.

(For simplicity the code snippet below contains only my custom script).

module.exports = {
  "*.{js,jsx}": ["bash pre-commit.sh"],
  "*.{ts,tsx}": ["bash pre-commit.sh"],
};

In my case both files, the configuration and the script, were on the same level in my file structure. Otherwise I would have to specify the relative path to the script.

Perfect! Now we have a check in place for every commit made by a developer… but wait, what if a developer decides to just ignore the warning (using the --no-verify flag for a commit) or does not install the pre-commit hook locally at all? 🤔

GitHub action for each Pull Request

This scenario can be addressed by a GitHub Action that runs on every pull request to the main branch. I've added a new job to the workflow to perform a similar check. However, I had to make some adjustments to the script. The one I initially used for pre-commit hooks compares the staged files. Considering that there could be multiple commits in the pull request, and some of them might involve force pushes, I wanted to ensure a thorough comparison of all the JavaScript and TypeScript files modified in the pull request.

Yes, automation can save us a lot of time and help avoid issues caused by silly mistakes.