DEV Community: David

Build Your Own AI Code Review Workflow in 5 Minutes with Github Actions

David — Tue, 27 May 2025 03:55:12 +0000

Curious how well a large language model (LLM) can review your code? In this post, I'll show you how to set up a custom AI-powered code review tool in just 5 minutes using GitHub Actions.

Prerequisites

This article assumes some level of familarity with Javascript and Github Actions.

The Idea

We'll build a GitHub Actions workflow that passes a pull request's changeset to ChatGPT. We'll prompt ChatGPT to review the changes and provide feedback. We'll then take its response and post it back to the original PR so that the PR author can see the feeback.

This is a very simple and straight forward way to see how simple it is to integrate LLMs into your workflow right now.

Step 1: Get an API Token for your LLM

First, you'll need an API token to programmatically access ChatGPT. You'll also need permission to add secrets to your GitHub repository or organization.

Once you have your API token, add it to your repo or org secrets. We will reference the secret in our Github Actions workflow. A good name for your Open API token would be OPEN_API_KEY.

Step 2: Create a Github Action

With your API token ready, it's time to wire everything up into Github Actions. Our workflow should run whenever a PR is created or when new commits are pushed to an existing PR. When the workflow runs, it will:

Pull down the changeset and then pass the changeset into our code review script.
Use daves-dead-simple/open-ai-action to pass our prompt to Open AI
Comment the output back to the original pr.

Here's what a workflow file may look like:

name: LLM Code Review
on:
  pull_request:
    branches:
      - whichever-branch-you-want-code-review-for
    types:
      - opened # when a PR is opened
      - synchronize # when code is pushed to a pr

jobs:
  code-review:
    runs-on:
      - ubuntu-latest
    steps:
      - name: Checkout PR branch
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Get Diff
        id: diff
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          echo "changeset<<EOF" >> $GITHUB_OUTPUT
          echo "$(gh pr diff ${{ github.event.pull_request.number }} --repo "${{ github.repository }}")" >> $GITHUB_OUTPUT
          echo "EOF" >> $GITHUB_OUTPUT

      - name: Run AI code review
        uses: daves-dead-simple/open-ai-action@main
        id: code-review
        env:
          OPEN_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        with:
          prompt: |
            Please code review the following changeset: ${{ steps.get_diff.outputs.changeset }}

      - name: Comment on PR with AI review
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          gh pr comment ${{ github.event.pull_request.number }} \
            --repo "${{ github.repository }}" \
            --body "${{ steps.code-review.outputs.completion }}"

This workflow will run everytime a PR is open or updated (i.e., when new commits are pushed). It uses the github CLI to fetch the diff and then pass it along to Chat GPT along with instruction for what to do with the changeset we are sending it. The LLM will in turn give us its response which we post back to the original PR.

Conclusion

This is a very simple way to integrate OpenAI or any other LLM into your dev workflow. You can easily iterate on this idea to not only let users pick the model and provider of their choice, but even provide custom rules or instructions to the LLM.

Why Dead Code Is Hurting Your Team — and How to Fix It

David — Mon, 27 Jan 2025 17:53:50 +0000

Dead code is a silent form of technical debt, and it's slowing your team down. Dead code increases the complexity of your codebase which makes it harder to implement new features, improve existing functionality, or refactor code efficiently. Ignoring it can lead to slower development cycles, frustrated developers, and unnecessary costs.

What Is Dead Code?

Dead code is any code in your codebase that isn’t actively used in your application. This could range anywhere from unused files all the way down to unused exports, dependencies, or even enum properties. While it might seem harmless at first, dead code contributes to clutter, confusion, and wasted effort. Removing it is crucial to maintaining a clean, efficient, and scalable codebase.

The Hidden Costs of Dead Code

The impact of dead code is often subtle but highly consequential. To understand its effects, let’s look at a simple example in TypeScript:

type Params = {
  value: number;
};

function unusedFunction(params: Params) {
  // does things
}

function realFunction(params: Params) {
  // does things
}

Now, imagine you need to change the value property from a number to a boolean. This small update forces you to modify both realFunction and unusedFunction—even though unusedFunction isn’t being used anywhere in your code.

If unusedFunction is complex, you’ll spend critical dev cycles deciphering its purpose, dependencies, and downstream implications. Worse, you might need input from other developers to understand its original intent. All this extra work delays your task, increases development costs, and risks missing tight deadlines.

The Bigger Picture: Dead Code Across Your Codebase

Removing dead code requires a deliberate and systematic approach. Here are two main strategies to consider:

1. Manual Auditing

One way to remove dead code is by manually reviewing your codebase. This approach works for smaller projects but quickly becomes impractical for larger codebases. It’s time-consuming, error-prone, and may lead to accidentally removing active code or missing significant dead code paths.

2. Automated Tools

For larger projects, automating the detection and removal of dead code is a game-changer. Tools like remove-unused simplify this process by analyzing your TypeScript codebase, identifying unused files, and providing actionable reports.

remove-unused works by inspecting your Typescript codebase. It builds your project's dependency graph by looking at all of your code's import and require statements. It then flags files that aren't referenced anywhere. This accounts for aliases or custom paths, and ensures unused code is accurately flagged.

remove-unused is also designed to work seamlessly with modern frameworks like Next.js. It automatically recognizes critical directories such as app or pages and even supports MDX files.

Using tools like remove-unused to automatically remove dead code will save your team time, reduce errors, and allow your to focus on solving core business problems instead of wrestling with outdated code.

Why Dead Code Shouldn’t Be Ignored

Dead code isn’t just an annoyance—it’s a productivity killer. It adds complexity to your codebase, increases maintenance costs, and slows down feature delivery. Addressing dead code proactively improves code quality, boosts team morale, and accelerates development.

Start cleaning up your codebase today. Whether you use manual auditing for small projects or automated tools like remove-unused for larger ones, taking action now will set your team up for success.

Ready to eliminate dead code? Learn more at removeunused.com.

What's with the Weird Elixir Function Names

David — Tue, 04 Jun 2024 05:08:28 +0000

Have you ever noticed that in all of the documentation related to Elixir, functions are referenced like function_name/2? This is by design- Elixir itself identifies functions by its name and the number of arguments it takes. The documentation, in turn, follows suite.

So, whenever you see Elixir docs (or, ahem, error pages) referencing function_name/2, you will know that it's referencing function_name that accepts 2 arguments.

Rust vs Typescript Variables

David — Tue, 04 Jun 2024 04:58:35 +0000

Jumping into Rust from Typescript requires that you change the way you think about code.

A Simple Log Statement

It is trivial to log a variable Typescript. Simply declare the variable and then pass it console.log. This is totally fine:

let value = 'string';
console.log(value);

It doesn't really matter what happens between the variable declaration and the log statement. The output will be logged as expect. For example, this is also perfectly fine:

let value = 'string';
let otherValue = value;
console.log(value);

In both of these examples, value is declared and then logged. There is nothing surprising here. In order to get this same functionality in Rust, we have to change our approach and the way we are thinking about the code.

Ownership

What happens if you do this in Rust?

let value = String::from("string");
let otherValue = value;
println!("{}", value);

It certainly looks like value will be logged, but what you actually get is a super fun compiler error:

move occurs because `value` has type `std::string::String`, which does not implement the `Copy` trait

When it comes to variable assignments, Rust and Typescript come from completely different planets. In Typescript, it's perfectly fine to create variables, reassign them, and, in most cases, mutate them. You don't need to think about heaps, stacks, or how memory is cleaned up after the fact. The runtime handles all of that for you.

Rust, on the other hand, requires you to think about memory allocation, how you are accessing that memory, and how that memory gets cleaned up (sort of).

In the Rust code above, we create a String and assign it to the variable value. value now "owns" that string and, in Rust, values are only allowed to have one owner.

When we assign value to otherValue, we aren't just copying the value or creating a reference to it like we would be doing in Typescript. Instead, we are transfering ownership or moving the String to otherValue. After the value is moved, we are no longer allowed to reference value, and how could we? It no longer owns anything!

Borrowing

Fortunately, changing "ownership" isn't the only way to assign values in Rust. Instead of changing ownership, we can have otherValue "borrow" value. All we need to do is add a & to the assignment:

let value = String::from("string");
let otherValue = &value; // Borrowing!
println!("{}", value);

Instead of taking full ownership of value, otherValue creates a pointer that points to the value of value, which in this case is String::from("string"). Because otherValue is simply borrowing value, we are free to continue referencing value further along in our code.

Avoid This Common React Hook Antipattern

David — Mon, 01 May 2023 16:04:45 +0000

When displaying synchronous data in React components, useState and useEffect are antipatterns that should be avoided. Using useState and useEffect to compute synchronous values will lead to a sub-optimal user experience and subtle bugs that can be hard to debug.

The Problem

Consider the following component:

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

interface Props {
  firstName: string;
  lastName: string;
}

function MyComponent(props: Props) {
  const { firstName, lastName } = props;
  const [fullName, setFullName] = useState('');

  useEffect(() => {
    setFullName(`${firstName} ${lastName}`);
  }, [firstName, lastName]);

  return (
    <span>{fullName}</span>
  );
}

In this example we are computing fullName from two props: firstName and lastName. Even though firstName and lastName are both available at render time, we are passing them both into a useEffect hook. Inside the useEffect hook, we are then concatenating the values and then calling setFullName with the concatenated value.

This is problematic for several reasons:

useEffect runs after the component renders and displays a value to the user. This means that the user will always see a stale value before the updated value is shown to the user.
To see our computed value, we have to always render our component twice. On the first render, we display a stale value. When the useEffect runs, it calls setFullName which will trigger another render.
From a developer perspective, the logic is hard to read and hard to follow.

The fix

The fix for this pattern is simple. Instead of computing the values in a useEffect, we can simply compute the values as part of the "natural" rendering process:

import React from 'react';

interface Props {
  firstName: string;
  lastName: string;
}

function MyComponent(props: Props) {
  const { firstName, lastName } = props;
  const fullName = `${firstName} ${lastName}`;

  return (
    <span>{fullName}</span>
  );
}

Computing the value during render has the following advantages:

Our component is much simpler. We were able to completely eliminate any hook usage in our component.
The user will never see a stale value. Everytime one of our props changes, it will be immediately reflected in the DOM.
We've eliminated an extra render cycle.

The takeaway

When you need to display computed value from synchronous data in React, it is almost always easier and safer to just compute the value in the component's body without useEffect or useState. This will lead to simpler components and a better user experience!

How to Create and Run Your First Docker Image

David — Tue, 23 Aug 2022 04:49:00 +0000

I've spent the last few weeks diving into the world of Docker containers to understand how they work and how they can be improve our deployment process. While it was clear to me that Docker can provide a huge amount of value to our deployment and ops processes, it took me a while to understand exactly how to use it.

Images and Containers

Docker has two main concepts that we need to understand: Images and Containers. Images define the environment you application needs in order to run. For node apps, this probably includes things like your source code, node_modules directory, and package.json and package-lock.json files. For static apps, it may just include static HTML. For ruby apps, it may be your source plus your bundle file. It all depends on your app.

Images are built from your source and pushed into repository, much like an NPM package or a Ruby gem. Once an image is built and published to a repository, anyone else on your team can pull that image down and use it to to create a container, which is effectively just an instance of our image.

The important takeaway is that Images define the application environment while Containers actually run that environment.

Building a Docker Image

All Docker images are build from a Dockerfile. A Dockerfile is a file that just has a set of commands{:target="_blank"} telling Docker how to "wrap" the application environment into a reusable Image that can be used to create containers. The contents of a Dockerfile looks more or less just like a series of bash commands. These commands are executed when we run $ docker build and the output of those commands makes up our image.

Dockerfile

Your application's Dockerfile should live in your app's repo alongside the source code. It doesn't make a ton of sense for your Dockerfile to live outside of your application's repo since your Dockerfile will be responsible for creating an image that will be used to eventually run the application. Ultimately, the application developer is responsible for writing their own Dockerfile to create their image.

Your first Dockerfile

Let's create a simple Dockerfile that only contains Nginx. Create a Dockerfile and add the following:

FROM nginx

The FROM command is almost always the first command in every Dockerfile. It tells Docker that we are basing our image from an already existing image. In this case, we are pulling down the nginx image and using it as the basis for our image.

To build this image, run the following command. (Make sure that you are in the same directory as our new Dockerfile.)

$ docker build .

That's all we need to create our first image! If you run $ docker images in your teminal, you should see something like this:

Having our first image is great, but it's only the first step. Now, we need to use that image to create and run a container. Run $ docker images again. Take note of the IMAGE ID (c431399b6d03 in the image above, we'll call it <<HASHED_ID>>). Copy that ID from your terminal and then run the following command:

$ docker run -p 8000:80 <<HASHED_ID>>

This command tells docker to create and run a container from our image with the ID <<HASHED_ID>>. Now, open your browser and navigate to http://localhost:8000. You should see the standard nginx splash screen:

Viola! We are now running an Nginx container from an image we created!

Tagging your Docker image

You may be wondering about the <<HASHED_ID>> part from the step above. When we run docker build, Docker automatically assigns our image a generated ID so it can be referenced laster. While we can continue to use that ID, it isn't the best developer experience and it's not that easy to remember! When we build our image, we can create a Docker image with a human-readable tag. Docker will still create our image with it's generated ID, but it will also tag that ID with whatever name we provide it. Let's rebuild our image and give it the tag my-first-docker-image:

$ docker build -t my-first-docker-image .

If you run $ docker images again, you will see that the Repository field is now populated with my-first-docker-image:

Our run command from above can now be changed to:

$ docker run -p 8000:80 my-first-docker-image

Much better!

In Summary

Creating Images and running them in Containers is only scratching the surface for what Docker can do. Docker does have a bit of a learning curve, but once you get the hang of it, you won't be able to work without it!

Enjoy this article? Subscribe to EasyWebDev!

Fetching Data in Svelte

David — Wed, 17 Feb 2021 18:11:41 +0000

I always find it frustrating when I'm learning a new framework and I get to the point where I have to depart from my existing knowledge and principles in order to learn the framework's way of thinking. Frameworks should exist for developers and so it was refreshing to discover that Svelte is mostly unopinionated when it comes to fetching server data. This means that developers can focus on creating high-quality applications instead of learning “the Svelte way” of fetching data.

The Tech

Because Svelte doesn't have an out of the box solution for fetching data, it is possible to use almost any existing library to fetch data in your Svelte component. Even though almost everything is possible, fetch and XMLHTTPRequest are the easiest ways to fetch data in your Svelte component. In this article, I will examine specifically how we can use fetch to load data from the The Star Wars API, a publicly accessible API for Star Wars data.

Code Along

You can find working examples of all the code in this article on github: https://github.com/davidturissini/svelte-data-demo

Clone the repo and then run npm install && npm run dev. The app will be running at http://localhost:5000.

After reading this article you will be able to:

Load server data in your Svelte component
Load server data inside Svelte's onMount lifecycle hook
Display a loading screen while data is being loaded
Load data on-demand from a user interaction

This article only covers fetching data for your Svelte components. If you are interested to learn more about Svelte and state management, be sure to follow me to get notified when that article gets published!

Using Fetch with Svelte

Code on Github

The easiest way to use fetch in your Svelte component is to simply invoke fetch directly in your component's <script> tag. You'll recall that Svelte's reactivity model works by referencing a let variable directly in your component's HTML. Whenever the variable gets a new value, Svelte will automatically re-render that new value.

With a modified approach, we can use this same functionality to render the contents of a fetch response. Instead of immediately assigning a value to our let variable, we instead dispatch a fetch request. We then populate our variable with values from our response once it settles. Our new values will then automatically be rendered into our HTML and become visible to the user.

For example, to display Luke Skywalker's name in a Svelte component, we can create the variable characterName and then make a fetch call to https://swapi.dev/api/people/1. After our response is settled, we can then assign character.name to characterName. Since characterName is referenced in our HTML, Svelte will render the value for us. Fairly simple!

<script>
    let characterName;

    fetch('https://swapi.dev/api/people/1')
        .then((response) => response.json())
        .then((character) => {
            characterName = character.name;
        })
</script>
<main>
    {characterName}
</main>

This approach is not limited to just fetch. If we wanted to, we could create a Redux subscription and update characterName whenever we are passed a new value. We could also create a GraphQL subscription and follow the same pattern. As long as we can update variables that are in our HTML, Svelte will continue rendering the latest data no matter how we received those values.

Component onMount

Code on Github

Executing fetch in your <script> tag works well if you know that your component will always run in the browser. If it is even remotely possible that your component will be server rendered, we need to find a different approach. The biggest drawback with invoking fetch directly in your <script> that fetch will also be invoked when your component is rendered on the server. This could lead to some noticeable performance problems, both for your users and your servers.

We can improve our approach above by invoking our fetch call inside of Svelte's onMount lifecycle hook. With the exception of onDelete, Svelte lifecycle hooks are never invoked on the server, so putting our fetch call inside of an onDelte hook guarantees that we will only call our APIs when the component is rendered in the browser. This will reduce your server load because we are only making our fetch call once the component is rendered in the browser. It also reduces time to serve because our server code does not have to wait for our data to settle before sending something back to the user.

<script>
    import { onMount } from 'svelte';
    let characterName;

    onMount(async () => {
        const response = await fetch('https://swapi.dev/api/people/1');
        const character = await response.json();
        characterName = character.name;
    })
</script>
<main>
    {characterName}
</main>

Handle Loading States

Code on Github

Even if we use onMount to fetch server data, we aren't quite giving our users the best possible experience. Because characterName is not initialized with a default value, Svelte will render text "undefined" while our app fetches our data. Not ideal! We could avoid this by giving characterName some default value that is displayed while we fetch our data. That approach would work, and it would definitely be a better experience, but I think using an if-else conditional in our HTML to add a spinner would be an even better user experience. This approach is pretty powerful because there is no limit to what you can display while data is being fetched. It can be some simple text or it can be a complex Svelte component.

<script>
    import { onMount } from 'svelte';
    let characterName;

    onMount(async () => {
        const response = await fetch('https://swapi.dev/api/people/1');
        const character = await response.json();
        characterName = character.name;
    });
</script>

<main>
    {#if characterName === undefined}
        Loading Character Name...
    {:else}
        {characterName}
    {/if}
</main>

Lazy HTTP Requests

Code on Github

Invoking our fetch call inside of onMount means that every time our component mounts, we are going to make a server request. This is not always the correct behavior. Sometimes, we might want to wait for our users to give us a signal that they are ready for some data to be loaded. In this case, we can give our users some sort of UI, like a button, to control when our fetch call is invoked.

Instead of invoking our fetch call directly in onMount, we can make our fetch request lazy by moving it inside of a function that can be used as an event handler.

Making our fetch request lazy is a nice performance win. It reduces our server load and perceived user performance because we are not consuming memory or server resources with data that our user may never use. It also exposes an assumption that we made in our code. Up until now, all of our code samples have assumed that we are either making an HTTP request or the HTTP request has settled. Making our fetch lazy means that it is possible for our code to be idle. In our case, our idle state is just a period of time before the initial fetch request is triggered. In this state, we don't need to show a loading indicator and we don't yet have data to show the user so we need to update our code to handle this new behavior. There are many approaches that we could use, but the easiest way is to simply move characterName and loading into a tuple. We can then update our HTML conditional to not show our loading screen if loadig is false AND characterName is not present.

<script>
    let data = {
        characterName: undefined,
        loading: false,
    };

    async function loadData() {
        data.loading = true;
        const response = await fetch('https://swapi.dev/api/people/1')
        const character = await response.json();
        data = {
            characterName: character.name,
            loading: false,
        };
    }
</script>

<main>
    <button on:click={loadData}>Load Data</button>
    {#if data.loading === true}
        Loading Character Name...
    {:else if data.characterName !== undefined}
        {data.characterName}
    {/if}
</main>

Now our component waits for our user to click on our <button> before making an HTTP request. This is also a good pattern for making create, update, or delete server calls. We certainly wouldn't want our component to be mutating data every time it loads!

Conclusion

Svelte is very flexible when it comes to fetching data for your application. By and large, you bring whichever tools you are comfortable with and you don't need to reinvent the wheel to render your data. The easiest approach to loading data is by using fetch in our <script> tag but the most robust way to fetch data is to use onMount. Svelte also makes it easy to render a loading screen while our data is being fetched and to make our fetch requests lazy which improves our application’s overall performance. If there are any other tips or suggestions, feel free to leave them in the comments below!

Don't forget to FOLLOW if you want to get more Svelte tutorials and deep dives as soon as they are published!

My First Impressions of Svelte

David — Mon, 01 Feb 2021 16:04:53 +0000

After hearing a lot about Svelte over the last few months, I've finally decided to take the plunge and give it a try. Since this is my first time playing with Svelte, I wanted to publish my initial thoughts to hopefully help anyone curious about what Svelte has to offer.

This isn't meant to be a tutorial on Svelte, it is simply my reaction to looking at Svelte for the first time. If you haven't already, be sure to check it out. It is a simple way to get started working with Svelte. Most (if not all) of the code examples are lifted straight from the Svelte tutorial.

What is Svelte?

In its own words, Svelte "is a radical new approach to building user interfaces." In my words, Svelte is a component-based framework for building websites and web apps.

Conceptually, Svelte appears to share a lot of concepts with React and Vue, however, those are only surface level appearances. Svelte introduces a new way of thinking about components, and a unique set of features that allow you to create high quality components.

Absolute First Impression

After spending about half an hour on Svelte's playground, I can say that I very much enjoy the framework's ergonomics, how it approaches building components, and its general philosophy. I also like that accessibility is a first class citizen. For example, if you create an <img> without an alt attribute, the Svelte compiler will give you a clear, actionable warning. This is a great feature that hopefully will go a long way towards better application accessibility.

The code that the Svelte compiler outputs is surprisingly clean. When a compiler is involved, it usually means that the output code is not entirely human readable. Not so with Svelte. Most of the outputted code looks as if it could have been written by a human, which means that the run time code should be very debuggable.

Architecture

I haven't taken a deep dive into Svelte's architecture, but at a high level Svelte components are written with HTML, CSS and Javascript. Those templates are then compiled into code that can be executed in your browser. Svelte templates really, really want to be fully declarative. They want to let the developer forget all about rendering and render cycles. This is really good news for developers because it allows us to focus on our business problem and not on the details of rendering our components. We can simply declare the data we need and delegate the work to Svelte.

Writing a Svelte Component

Svelte component files behave just like a plain HTML document. Just like any HTML document, you use <style> and <script> tags to add styles and interactivity. I think the plain HTML, CSS and Javascript model is one of Svelte's most powerful features. Writing scalable and performant apps using familiar HTML, CSS, and Javascript is pretty compelling. In fact, if your application does not require any component level css or javascript, it is entirely feasible that your Svelte app could just be HTML. That's pretty neat!

Declaring Javascript Variables

Adding Javascript to your component is as easy as adding a <script> tag to your template file. Everything inside your <script> tag is scoped to your component so you don't have to worry about naming or state collisions outside of your component.

Any variable declared in your template file can be referenced in your HTML using bracket notation:

<script>
  let buttonText = 'text';
</script>

<button title={buttonText}>{buttonText}</button>

<script> tags in your Svelte components are a superset of standard <script> tags. You are able to use any standard Javascript in your <script> tag including ternarys, function calls, and even import statements. In addition to standard Javascript, Svelte introduces some domain-specific concepts like declarations and statements that you can use to enhance your component.

I find <script> usage intuitive because it is already a concept that I am familiar with. It also more or less aligns with how I think about Javascript in template files in general. This approach also becomes very interesting in terms of how Svelte handles reactivity and component state.

Event Handling

I find Svelte's approach to event handling intuitive as well. Adding an event listener is fairly simple. You can create an event handler in your <script> tag and then reference that function in your HTML using an attribute prefixed with on:. For example, in the code below, handleClick will be executed every time our button is clicked:

<script>
  let buttonText = 'text';

  function handleClick() {
      // handle click event
  }
</script>

<button on:click={handleClick}>{buttonText}</button>

Reactivity

Reactivity is essentially how your components and app respond to changes over time. Svelte handles reactivity bindings during compilation, not during runtime. Because Svelte understands where your Javascript variables are referenced in your HTML, it can generate efficient bindings ahead of time. This means you don't need to waste run time CPU to understand what is reactive and what isn't. Svelte takes care of this well before you execute any code.

Svelte attempts to add reactivity as transparently as possible. There is no special syntax to make a value reactive. All you have to do is reference the value in your HTML. This makes adding reactivity in Svelte fairly straightforward. It does mean that we are adding side effects to what would otherwise be a simple variable declaration. I might be overthinking things a bit, but foot-guns here are not inconceivable.

Because Svelte's compiler handles generating reactivity bindings for you, making a variable reactive is straightforward. You only have to reference the value in your HTML.

<script>
  let buttonCount = 0;

  function handleClick() {
      buttonCount += 1;
  }
</script>

<button on:click={handleClick}>{buttonCount}</button>

Every time our button is clicked, our buttonCount variable is incremented and our new value is rendered. You simply declare that you want to display the value for buttonCount and Svelte generates code that handles the binding for you. Svelte makes it easy to bind values to HTML, but its reactivity model extends to Javascript values as well.

Declarations

Declarations are the first feature that truly feels like something only Svelte offers. I think declarations are the most interesting feature of Svelte. Declarations allow you to create composable data streams that can be reflected into your HTML.

You can create a declaration inside your <script> tag with new grammer introduced by : $: NAME = VALUE. The $: NAME creates a reactivity binding that listens to changes to VALUE. Every time VALUE changes, NAME will be updated. All references to NAME in HTML will then be updated as expected.

Composing declarations is as easy as using a + operator. $: NAME = VALUE + OTHER will cause NAME to be updated if VALUE or OTHER ever changes.

I love this feature because it allows you to declaratively create really complex datastreams without much effort. Aside from the new syntax, creating a declaration is almost exactly the same as creating a plain variable. Really neat!

Statements

Svelts statements are like declarations except they add reactivity to entire Javascript statements, not just variables. For example, this means that we can make an if-conditional recompute every time a value within its block changes.

This is another feature that I absolutely love. In effect, it allows you to declaratively create reactive routines which can then be piped to other declarations or statements. Really good stuff!

Conclusion

I will definitely be exploring using more of Svelte in the future. I think the intuitive component model plus the innovative declaration + statement features create a compelling case for using Svelte for some of my projects going forward. If you're curious about Svelte, head on over to their website to get an even more detailed look about how Svelte works.

Happy coding! 🗿

Enjoyed this article? Head on over to Easy Web Dev and SUBSCRIBE to get access to in-depth web development tutorials and walk-throughs.

How Typescript Generics Work

David — Tue, 19 Jan 2021 06:31:00 +0000

The following article is a free sample from EasyWebDev mailing list. Subscribe to get simple web development guides, tutorials, and explanations.

If you've been using Typescript, there is a good chance that you've come across Generics. Generics are a handy Typescript feature that allows you to declare variable types for your interfaces, types, and declarations.

interface GenericInterface<T> {
    prop: T;
}

T is a Generic that allows the consumer to specify the type for our property prop. This is handy in situations where all the possible types are not known ahead of time or where there are a wide variety of types that we don't need to constrain on the interface level.

Using Generics

Using generics in your application code is conceptually very similar to passing arguments to to your functions. However, instead of passing run time values, we are passing Typescript type definitions.

const myObject: GenericInterface<string> = {
    prop: 'string'
}

Generics make our code more flexible but they still also guarantee type safety.

const myObject: GenericInterface<string> = {
    prop: 1, // Error! string is passed to the generic, but a number is specified.
}

Non-Trivial Types

Complex Types

The values passed to a Generic do not need to be simple types. Any valid Typescript expression is allowed. The important take-away is that the concrete value must adhere to the Generics' type, whatever it is.

const unionObject: GenericInterface<string | number> = {
    prop: 1; // this can be either a string or a number
}

const typeofObject: GenericInterface<typeof window.document> = {
    prop: window.document; // this can only be an object that matches the type from window.document
}

Multiple Generics

There is no limit to the number of generics that you can define for a given interface, type, or declaration.

interface GenericInterface<A, B, B> {
    prop: A;
    next: B;
    another: C;
}

Default Types

When a generic is defined, the caller always has to specify a type for the generic. To get around this requirement, Generics can be assigned default types. When a default type is used and a type has not been specified, Typescript will use the default Generic type.

interface GenericInterface<A = string> {
    prop: A;
}

const myObject: GenericInterface = {
    prop: 'string'
}

Default types allow you to do some very complex and interesting inference. Here is a silly example:

interface GenericInterface<A extends { prop: string | number }, B = A['foo']> {
    a: A;
    b: B
}

const obj: GenericInterface<{ prop: string }> = {
    a: {
        prop: 'string',
    },
    b: 1 // Error! b MUST match the type from a.prop.
}

Constraining Generics

By default there are no constraints on the types that can be passed to a Generic. Sometimes, however, we want to constrain a Generic's type. One way we can do this is aliasing the constraint to a new type. This applies a localized constraint and does not globally constraint the Generic's type.

type Constrained = GenericInterface<string>;
function myfunction(arg: Constrained) {

}

Another way to constraing Generics is on the Generic's definition itself. This constraint will apply to any usage of the Generic, so all callers will need to adhere to the constraint when using extends directly in the Generic's definition.

interface GenericInterface<T extends string> {
    prop: T
}

Naming Generics

This is a somewhat controversial topic, but there is a long-standing convention to use single letter names for your Generics. I would encourage you to use whatever approach works best for your team and application.

Happy coding!

Enjoy this article? Subscribe to EasyWebDev!

Aha! Understanding Typescript's Type Predicates

David — Mon, 05 Aug 2019 16:47:48 +0000

This article will cover Type Predicates at a high level. To understand Type Predicates, we must first understand how they are used in relation to union types.

Union Types

In Typescript, a variable isn't always restricted to a single type. Union Types are a way to declare multiple types onto a single value.

// value can now be set to a `string`, `boolean`, or `null` value. 
let value: string | boolean | null = ...

interface Cat {
  numberOfLives: number;
}
interface Dog {
  isAGoodBoy: boolean;
}

let animal: Cat | Dog = ...

When we use union types, we have to do work to narrow the possible types down to the current value's actual type. Type Guards are what allow us to do this narrowing.

Type Guards

According to the official docs,

A type guard is some expression that performs a runtime check that guarantees the type in some scope.

Put another way, type guards guarantee that a string is a string when it could also be a number.

Type guards are not entirely different than doing feature detection. The big idea is to try to detect properties, methods or prototypes to figure out how to handle a value. There are four main ways to use type guards:

in keyword
typeof keyword
instanceof keyword
type predicates with custom type guard

Type Predicate

While you are probably familiar with "in", "typeof", and "instanceof", you might be wondering what "type predicates" are. Type predicates are a special return type that signals to the Typescript compiler what type a particular value is. Type predicates are always attached to a function that takes a single argument and returns a boolean. Type predicates are expressed as argumentName is Type.

interface Cat {
  numberOfLives: number;
}
interface Dog {
  isAGoodBoy: boolean;
}

function isCat(animal: Cat | Dog): animal is Cat {
  return typeof animal.numberOfLives === 'number';
}

For sample function, isCat, is executed at run time just like all other type guards. Since this function returns a boolean and includes the type predicate animal is Cat, the Typescript compiler will correctly cast the animal as Cat if isCat evaluates as true. It will also cast animal as Dog if isCat evaluates as false.


let animal: Cat | Dog = ...

if (isCat(animal)) {
  // animal successfully cast as a Cat
} else {
  // animal successfully cast as a Dog
}

Pretty neat! Perhaps the best thing about custom type guards and type predicates is not only we can use in, instanceof, and typeof in our type guards but we can also custom type checks. As long as our function returns a boolean, Typescript will do the right thing.

What do you work on when you are on a plane? ✈️✈️

David — Tue, 30 Jul 2019 22:41:17 +0000

I’m about to spend a few hours on a plane as I head to our quarterly planning.

I’ll probably spend the time working on a blog post and maybe a side project.

What do you work on when your flying?

Code Golf Challenge: Palindrome Detector

David — Thu, 25 Jul 2019 18:25:42 +0000

Challenge: Using Javascript, implement a method that detects if a string is a palindrome in as few characters as possible!

The goal of this exercise is to write as little code as possible. Readability and maintainability are not a concern!

Solutions in comments 👇👇

DEV Community: David

Build Your Own AI Code Review Workflow in 5 Minutes with Github Actions

Prerequisites

The Idea

Step 1: Get an API Token for your LLM

Step 2: Create a Github Action

Conclusion

Why Dead Code Is Hurting Your Team — and How to Fix It

What Is Dead Code?

The Hidden Costs of Dead Code

The Bigger Picture: Dead Code Across Your Codebase

1. Manual Auditing

2. Automated Tools

Why Dead Code Shouldn’t Be Ignored

What's with the Weird Elixir Function Names

Rust vs Typescript Variables

A Simple Log Statement

Ownership

Borrowing

Avoid This Common React Hook Antipattern

The Problem

The fix

The takeaway

More Reading

How to Create and Run Your First Docker Image

Images and Containers

Building a Docker Image

Dockerfile

Your first Dockerfile

Tagging your Docker image

In Summary

Fetching Data in Svelte

The Tech

Code Along

Using Fetch with Svelte

Component onMount

Handle Loading States

Lazy HTTP Requests

Conclusion

My First Impressions of Svelte

What is Svelte?

Absolute First Impression

Architecture

Writing a Svelte Component

Declaring Javascript Variables

Event Handling

Reactivity

Declarations

Statements

Conclusion

How Typescript Generics Work

Using Generics

Non-Trivial Types

Complex Types

Multiple Generics

Default Types

Constraining Generics

Naming Generics

Aha! Understanding Typescript's Type Predicates

Union Types

Type Guards

Type Predicate

What do you work on when you are on a plane? ✈️✈️

Code Golf Challenge: Palindrome Detector