DEV Community: Nathan B Hankes

Getting Started With C#: Interfaces

Nathan B Hankes — Wed, 19 Jul 2023 15:23:16 +0000

This article is part of a series. For part one, visit the link below:
Part 1: Getting Started with C#: Classes, Objects, and Namespaces

In C#, an interface specifies a set of methods, properties, events, or indexers (collectively referred to as class members) that a class must define. This programmatic obligation is referred to as a contract. The interface contract functionally serves as a blueprint that classes must adhere to, ensuring consistent behavior, enabling polymorphism (we'll get more into this later), and providing a host of other benefits.

To apply an interface, a class must use the :InterfaceName syntax after the class name. In the example below, you'll see the Truck and Car class names followed by :IVehicle. This means that both of these classes are bound to the IVehicle interface contract. By implementing :IVehicle on these classes, the class enters into a contract that promises to define the members stipulated by the IVehicle interface.

Continuing with our example from Part 1 here's an interface and its implementation:

namespace VehicleInventory
{
    public interface IVehicle
    {
        string Make {get; set;}
        string Model {get; set;}
        int Year {get; set;}

        void StartEngine();
        void CheckOil();
    }

    public class Car: IVehicle
    {
      private string make;
      private string model;
      private int year;

      public string Make { get; set; }
      public string Model { get; set; }
      public int Year { get; set; }

      public Car(string make, string model, int year)
      {
        this.make = make;
        this.model = model;
        this.year = year;
      }

      public void StartEngine()
      {
        Console.WriteLine("Car engine is started.");
      }

      public void CheckOil()
      {
        Console.WriteLine("Car oil checked.");
      }
    }

    public class Truck: IVehicle
    {
      private string make;
      private string model;
      private int year;

      public string Make {get; set;}
      public string Model {get; set;}
      public int Year {get; set;}

      public Truck(string make, string model, int year)
      {
        this.make = make;
        this.model = model;
        this.year = year;
      }

      public void StartEngine()
      {
        Console.WriteLine("Truck engine is started.");
      }

      public void CheckOil()
      {
        Console.WriteLine("Truck oil checked.");
      }
    }
}

You'll notice that the IVehicle interface is implemented with the interface keyword. The interface does not provide any implementation details. It only defines members. The classes that implement this interface must provide implementations for all the members defined in the interface (in our case, methods and properties). This is why the Car class and the Truck class both have StartEngine() and CheckOil() method implementations. And this is why they both have the Make, Model, and Year properties defined.

By separating the interface from the class implementation, we create a clear distinction between the contract and the actual implementation. While it may require writing additional code in each class that implements an interface, the benefits of code organization, reusability, flexibility, and testability outweigh the initial effort. Let's take a look at some of these benefits below.

Benefits of Using Interfaces

Implementing methods individually in each class may seem like more work initially, but it serves an important purpose and offers several advantages:

Contract Enforcement

As already discussed, interfaces provide a way to enforce a contract or agreement between classes. By implementing an interface, a class commits to providing specific methods or functionality defined by the interface. This ensures that all implementing classes adhere to the same set of behaviors.

Polymorphism

Interfaces enable polymorphism, allowing objects of different classes to be treated interchangeably. This flexibility is valuable when writing code that works with multiple types of objects based on a shared set of methods. For example, you can create a collection of vehicles (objects implementing the IVehicle interface) and perform common actions on them without worrying about the specific class. Let's look at an example:

using System;

namespace VehicleInventory
{
    class Program
    {
        static void Main(string[] args)
        {
            IVehicle car = new Car("Honda", "Civic", 2022);
            IVehicle truck = new Truck("Ford", "F-150", 2021);

            PerformVehicleActions(car);
            PerformVehicleActions(truck);
        }

        static void PerformVehicleActions(IVehicle vehicle)
        {
            Console.WriteLine($"Make: {vehicle.Make}");
            Console.WriteLine($"Model: {vehicle.Model}");
            Console.WriteLine($"Year: {vehicle.Year}");

            vehicle.StartEngine();
            vehicle.CheckOil();

            Console.WriteLine();
        }
    }
}

In the Main method above, we create instances of Car and Truck and assign them to variables of type IVehicle. This allows us to treat both objects polymorphically.

The PerformVehicleActions method takes an IVehicle parameter and prints the vehicle details, starts the engine, checks the oil, and adds a line break for separation.

Because the IVehicle interface guarantees the Make, Model, Year, StartEngine(), and CheckOil(), the PerformVehicleActions method can treat the Truck and Car classes the same.

Loose Coupling and Flexibility

Using interfaces reduces tight coupling between classes. Instead of depending on specific class implementations, you can depend on the interface. This promotes better separation of concerns and improves the flexibility of your code. You can easily introduce new classes that implement the interface or modify existing classes without affecting the rest of the codebase.

Let's say we want to add a new class to identify a new vehicle type. In the example below, we'll create a new Motorcycle class:

public class Motorcycle : IVehicle
{
    private string make;
    private string model;
    private int year;

    public string Make { get; set; }
    public string Model { get; set; }
    public int Year { get; set; }

    public Motorcycle(string make, string model, int year)
    {
        this.make = make;
        this.model = model;
        this.year = year;
    }

    public void StartEngine()
    {
        Console.WriteLine("Motorcycle engine is started.");
    }

    public void CheckOil()
    {
        Console.WriteLine("Motorcycle oil checked.");
    }
}

With the addition of the Motorcycle class, we can now create instances of Motorcycle and pass them to the PerformVehicleActions method defined in our polymorphism example above -- without modifying the PerformVehicleActions method itself. This showcases the flexibility provided by the interface, as the existing code can seamlessly work with the new Motorcycle class without any breaking changes.

Testing and Mocking

Interfaces help facilitate unit testing and mocking. You can create mock implementations of interfaces during testing to isolate and verify the behavior of specific components without relying on actual implementations. This helps in writing robust and maintainable tests.

The interface implementation in the provided example facilitates testing and mocking by allowing the creation of test doubles or mock objects that implement the IVehicle interface. This enables isolated unit testing and the ability to simulate different scenarios without relying on the actual concrete implementations of Car and Truck. Here's an example:

using System;
using Moq;
using Xunit;

namespace VehicleInventory.Tests
{
    public class VehicleTests
    {
        [Fact]
        public void PerformVehicleActions_Car_StartEngineAndCheckOilCalled()
        {
            // Arrange
            var carMock = new Mock<IVehicle>();
            carMock.Setup(c => c.Make).Returns("Honda");
            carMock.Setup(c => c.Model).Returns("Civic");
            carMock.Setup(c => c.Year).Returns(2022);

            var vehicleActions = new VehicleActions();

            // Act
            vehicleActions.PerformVehicleActions(carMock.Object);

            // Assert
            carMock.Verify(c => c.StartEngine(), Times.Once);
            carMock.Verify(c => c.CheckOil(), Times.Once);
        }

        [Fact]
        public void PerformVehicleActions_Truck_StartEngineAndCheckOilCalled()
        {
            // Arrange
            var truckMock = new Mock<IVehicle>();
            truckMock.Setup(t => t.Make).Returns("Ford");
            truckMock.Setup(t => t.Model).Returns("F-150");
            truckMock.Setup(t => t.Year).Returns(2021);

            var vehicleActions = new VehicleActions();

            // Act
            vehicleActions.PerformVehicleActions(truckMock.Object);

            // Assert
            truckMock.Verify(t => t.StartEngine(), Times.Once);
            truckMock.Verify(t => t.CheckOil(), Times.Once);
        }
    }
}

In this example, we use the Moq mocking framework and the xUnit testing framework to demonstrate testing and mocking with the interface implementation. We create two test methods: PerformVehicleActions_Car_StartEngineAndCheckOilCalled and PerformVehicleActions_Truck_StartEngineAndCheckOilCalled.

In each test method, we create a mock object of the IVehicle interface using Mock. We set up the necessary properties (Make, Model, and Year) for the mock objects to return specific values during the test.

Next, we instantiate the VehicleActions class, which contains the PerformVehicleActions method that we want to test. We pass the mock object (carMock.Object or truckMock.Object) to the PerformVehicleActions method.

Finally, we use the Verify method provided by the mock objects to assert that the StartEngine and CheckOil methods are called exactly once during the execution of the PerformVehicleActions method.

By creating mock objects that implement the IVehicle interface, we can isolate the behavior being tested and verify that the expected methods are called, without relying on the actual implementations of Car and Truck. This enables effective unit testing and helps identify issues in the VehicleActions class while maintaining test independence.

Adding Interfaces to Your Codebase

Interfaces are typically organized into namespaces alongside classes and other related interfaces. Remember from part one, a namespace is a container for organizing related types, such as classes and interfaces. It helps prevent naming conflicts and provides a logical structure to your code.

When it comes to storing interfaces in your codebase, there is no universally prescribed folder structure or naming convention. However, it's generally recommended to follow a structure that reflects the logical organization of your codebase and promotes maintainability. Here are some suggestions:

Create a separate folder or directory for interfaces: You can have a dedicated folder specifically for interfaces, which can make it easier to locate and manage them.

Use meaningful and descriptive names: Name your interfaces based on the functionality they represent. Make sure the names are clear and indicative of their purpose.

Group related interfaces together: If you have interfaces that are closely related, you can place them in the same folder or subfolder. This makes it easier for developers to find related interfaces when working on a specific feature or module.

Follow a consistent naming convention: It's good practice to follow a consistent naming convention for interfaces, such as prefixing them with "I" (e.g., IExampleInterface). This convention helps distinguish interfaces from classes and makes your code more readable.

Below is an example from the open source nopCommerce repository. You'll notice the interface files (staring with capital I) are in the same folder as the class files. In the External folder, all classes and interfaces are built inside of the namespace Nop.Services.Authentication.External:

Ultimately, the specific folder structure and naming conventions will depend on your project's requirements and the preferences of your development team. The key is to ensure consistency and maintainability throughout your codebase.

Getting Started with C#: Classes, Objects, and Namespaces

Nathan B Hankes — Sun, 18 Jun 2023 01:40:54 +0000

Together, classes, objects, and namespaces form the fundamental building blocks of C# programs. This article offers a brief orientation to each of these.

Introduction to Classes and Objects

Classes are the building blocks of Object-Oriented Programming, serving as blueprints or templates for creating objects. Objects, on the other hand, are instances of classes that represent real-world entities or concepts.

For example, a Car class will define the blueprint for creating car objects. The Car class may have properties like make, model, and year, as well as methods such as StartEngine() and Drive().

This is what the Car class would look like in your codebase:

public class Car
{
    //Fields
    private string make;
    private string model;
    private int year;

    //A field is a variable declared within a class.



    //Properties
    public string Make { get; set; }
    public string Model { get; set; }
    public int Year { get; set; }

    //A property is a class member that offers a convenient way to
    //access, modify, or calculate the value of a private field.
    //The get and set keywords are used to define the accessors
    //for the property. The get accessor returns the property
    //value, and the set accessor assigns a new value to the 
    //property



    // Class Constructor
    public Car(string make, string model, int year)
    {
        this.make = make;
        this.model = model;
        this.year = year;
    }

     //A Class Constructor is a special member method responsible
     //for initializing the object of that class.



    // Method 1
    public void StartEngine()
    {
        Console.WriteLine("The engine is started.");
    }

    // Method 2
    public void Drive()
    {
        Console.WriteLine("The vehicle is driving.");
    }

    //A method is a block of code within a class that performs a
    //specific task or action. Methods are declared within a class
    //and are accessed by and invoked on objects created from that
    //class. 
}

Now, let's say you create two car objects: car1 and car2. These objects are instances of the Car class and represent real-world cars. Each car object will have its own set of property values.

For example, car1 may have the make "Toyota," model "Camry," and year "2012," while car2 may have the make "Honda," model "Accord," and year "2020."

This is what instantiating those two Car objects would look like in your codebase:

Car car1 = new Car("Toyota", "Camry", 2012);
Car car2 = new Car("Honda", "Accord", 2020);

By instantiating car objects from the Car class, you can work with each car individually, accessing their properties and invoking their methods. You can start the engine of car1 by calling the StartEngine() method on the car1 object, and similarly, you can drive car2 by invoking the Drive() method on the car2 object. Calling the Car class methods on your Car objects looks like this:

car1.StartEngine();
car2.Drive();

Each car object maintains its own state and behavior, allowing you to perform different operations on different cars. Meaning you can modify the properties of car1 without affecting the properties of car2, and vice versa.

Introduction to Namespaces

Classes are held within namespaces. By organizing classes within a namespace, developers create a clear and logical grouping of related code elements.

This is what that a namespace would look like in your codebase:

namespace VehicleInventory
{
    public class Car
    {
        // Car class code from above
    }

    public class Truck
    {
       // Truck class
    }

    public class Motorcycle
    {
       // Motorcycle class
    }
}

Namespaces must be imported into your file with a using statement, like this:

using VehicleInventory;

// Now the Car class can be used directly
Car car3 = new Car("Toyota", "Prius", 2018);

car3.StartEngine();

This has been a brief orientation to the structure of a C# program. In my next article, I will provide an orientation to Interfaces:

Part 2: Getting Started With C#: Interfaces

Financial App Design: CSS Considerations

Nathan B Hankes — Sun, 08 Aug 2021 05:11:17 +0000

When your app involves handling a user's money, any minor issue with user experience or design will shake their confidence in your product. If you can't get design right, how do you expect your customers to trust the security of their money?

Let's consider the use case where you're brought into a contract position for a financial app that already exists. The functionality is already in place, so you don't have much control on high level user experience (onboarding flow, navigation, etc.) Your role isn't to design the pages from scratch or anything like that. You're strictly there to make them look nice with some CSS and minor changes to the HTML here and there.

I'll assume you already have a grasp of the UX fundamentals, but I will touch on these as they relate specifically to a financial app.

Here is a brief list of considerations before you go digging into the stylesheets.

1. ) Show Users What They Want

There is a reason your user is on a specific page. They're looking for certain information or want to perform an action. If it's account balances they're after, make sure the numbers displayed are prominent enough that it's the first thing the user's eye naturally gravitates to. And if it's an action they need to take, make sure the button or call to action pops off the screen. Bold colors and drop shadows can help here.

In the example by HIX below, notice where your eyes go first. Do they go to the numbers or colors?

2.) Less is More

Minimalism is in, but bland is not. So if you're only authorized to use bland (AKA safe) colors, there should be some other interesting elements to keep the user's attention. Depending on the brand personality, this can range from subtle animations that reassure your user that some process just completed successfully to modern dashboard design that includes design like layering, drop shadows, rounded edges, transparent backdrops, etc. When you're designing for mobile, it's important not to go too wild here since these design choices can impact performance in lower bandwidth use cases.

In the example below, the designer Mira creates a beautiful dashboard in grayscale.

3. ) Get Your Input Mode Right

The HTML input tag attribute of inputmode is supported by all mobile browsers. Do you know exactly what your user will input? Why distract them with any unnecessary keyboard elements?

Take a look at the below infographic by @stefanjudis. If the input was for the amount stated on a check, for instance, what inputmode could you use?

Conclusion

While coming into a project that's already designed can feel limiting, there's plenty of value you can add working with CSS alone. Just stay laser focused on why your user is on a page, and your knowledge of the UX fundamentals can take you far.

If you have a financial app design project coming up, visit these for some inspiration:

Top 10 Banking Apps UI/UX Design Case Studies

Banking on Dribble

Investing on Dribble

Go to your phone and computer to study the financial apps and websites you use. What works well? Why does it work?

The API Series - Part 4: Updating Your GitHub Status With a GraphQL Mutation

Nathan B Hankes — Thu, 13 May 2021 12:36:16 +0000

Introduction

In this tutorial, you'll learn about GraphQL mutations, authorization, and get a step-by-step demonstration of how to change you GitHub status sending a mutation request to the GitHub GraphQL API.

If you missed the other parts to this API series, you can find the rest at:

Part 1 - An Intro to APIs
Part 2 - The REST API, fetch(), and AXIOS
Part 3 - GraphQL and Sending Queries With fetch()

Prerequisites

Some familiarity with HTML, Git, and Javascript.

What Is A GraphQL Mutation

A GraphQL mutation changes data in an API database. Mutations encompass the REST API POST, PUT, PATCH, and DELETE methods. These GraphQL mutations are defined by the API and will often require some form of authorization to complete.

Getting Started With Your First Mutation

APIs can change over time, so please take the time to study the GitHub GraphQL API documentation should you encounter any
issues if you are reading this tutorial far out from its
publication date.

In this tutorial, you'll be learning about mutations in the context of the GitHub GraphQL API. In order to gain insight into what types of data the API allows us to change, we'll have to reference the API documentation for a list of mutations. By navigating to the Mutation Reference page, we encounter a list of all the mutations allowed by the API.
In this tutorial, we're going to use the fetch() method to update our user status. The mutation allowing this behavior is called changeUserStatus and is described by the Mutation Reference documentation like so:

We see two clearly defined fields listed: The Input fields and the Return fields.

Input fields

Input fields are the inputs the API will accept for this particular mutation. We will include these input fields and values in our mutation request so that the API knows what fields to update and what values to update them to. The ChangeUserStatusInput! object provides the fields we can change, as seen below:

In the above photo, we see a list of all the inputs the changeUserStatus mutation will accept. These include:

clientMutationId
emoji
expiresAt
limitedAvailability
message
organizationId

The input name column also includes the type of data the input field expects to receive: String, DateTime, Boolean, ID, etc. And the description columns provides further details, such as whether the input is required for a successful mutation.

Return fields

Return fields represent the data that the changeUserStatus mutation returns after completion. In this way, every GraphQL mutation is also a query. This is ideal because we can immediately verify that our fields updated to match our input fields or update them on the user's screen in real time. This mutation returns the following data:

clientMutationId
status {
    UserStatus {
        createdAt
        emoji
        emojiHTML
        expiresAt
        id
        indicatesLimitedAvailability
        message
        organization
        updatedAt
        user {
            User {
                A list of all the User fields...
                }
            }
        }
    }

While the changeUserStatus Return field documentation lists two rows, the status row accepts the UserStatus object, which has several of its own fields. And the user field points toward another object, and so on. To keep your project load times as fast as possible, it's good practice to only return what is needed. In this example, we'll be returning the following fields:

clientMutationId
status {
     message
     emoji
     updatedAt
        }

Writing Your First GraphQL Mutation

The GitHub GraphQL API documentation tells us exactly what is required to make a successful mutation. The GraphQL Foundation website provides additional documentation regarding the GraphQL syntax and conventions. From GitHub's guide "Forming Calls with GraphQL," the following components are required to complete a successful GraphQL mutation:

Mutation name. The type of modification you want to perform.
Input object. The data you want to send to the server, composed of input fields. Pass it as an argument to the mutation name.
Payload object. The data you want to return from the server, composed of return fields. Pass it as the body of the mutation name.

So here's how our changeUserStatus mutation will look:

    mutation {
        changeUserStatus(input: {clientMutationId: "YOUR_USERNAME", emoji: ":rocket:", expiresAt: "2021-05-09T00:00:00", limitedAvailability: true,  message:"Working on an API tutorial"}) {
                    clientMutationId
                    status {
                        message
                        emoji
                        updatedAt
                    }
            }

In the above code we have the mutation name of changeUserStatus, we have the Input object and the values we want to pass to it, and we also have the payload object, which consists of the return fields we previously decided on. This satisfies the three numbered components listed in GitHub's "Forming Calls with GraphQL" guide. In order to ensure that the above mutation is drafted correctly, we'll go into GitHub's GraphQL API Explorer interface. This is a powerful tool that helps us ensure we're structuring our queries and mutations correctly. I added this mutation into the Explorer, inserting my username in the clientMutationId input filed value, and here's what I saw:

The leftmost column contains the mutation, input fields and values, and the return fields. The center column displays what API response after clicking on the circular Play button in the top left corner. And the rightmost column provides the API documentation, which helps when drafting the mutation or query. And since the GitHub API Explorer requires user login, this mutation actually executes. The return fields are displaying the status listed on my profile. Success!

Setting Up The Project

Before we can insert our mutation into a fetch() request, we'll need to generate a personal access token that creates scoped permissions and allows us to make changes to the GitHub API. Below is a step-by-step list of how to do this:

Login into your GitHub account
Click on your avatar in the top right corner
Navigate to the "Settings" item and click through
Navigate to the "Developer Settings" item and click through
Navigate to the "Personal access tokens" item and click through
Click the "Generate new token" button. You'll be prompted to enter your password. Do it.
Check the boxes setting the following permissions recommended by GitHub:

user
public_repo
repo
repo_deployment
repo:status
read:repo_hook
read:org
read:public_key
read:gpg_key

Click the "Generate token" button. GitHub will generate the token, which will look like a string of random characters. Keep the window open for later use.

So now we have our mutation formed and our authorization token available. We'll also need the GitHub GraphQL API URL, which is found in the GitHub GraphQL API documentation: https://api.github.com/graphql

Okay, so now we're ready to dive into our editor of choice to make this mutation. In this example, we'll be creating an HTML and JS project and run the fetch request on our local system.

The code used in this tutorial can be reviewed here

Create two files inside of a new project folder:

index.html
script.js

Copy and paste the following code into the HTML file:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <script src="script.js"></script>
    <title>JS-GraphQL-Mutation-Demo</title>
  </head>
  <body>
    <button type="text/javascript" onclick="myAlert()">
      Check Script Connection
    </button>
  </body>
</html>

In the above code, we've set up a standard HTML document, linked our script.js file, and created a button that will execute a function called myAlert().

Now in our script.js file, insert our myAlert() function:

function myAlert() {
    alert("Documents Successfuly Connected!");
}

The above code is designed to verify that our index.html and script.js are in fact connected. It's not required, but gives us confidence and ensures we don't waste time troubleshooting this later on.

To execute the function, run the project using an extension like Live Server. Click the "Check Script Connection" button on the browser. If the files are connected, you'll see an alert pop up that reads "Documents Successfully Connected!"

So our project foundation is set, and we can begin crafting our fetch statement. We'll pass the mutation, the API URL, and the fetch options to our fetch as variables. So let's create the variables like so:

const mutation = `
    mutation {
        changeUserStatus(input: {clientMutationId: "YOUR_USERNAME", emoji: ":rocket:", expiresAt: "2021-05-09T00:00:00", limitedAvailability: true,  message:"Working on API tutorial"}) {
                    clientMutationId
                    status {
                        message
                        emoji
                        updatedAt
                    }
            }    
        }
                `;


const url = "https://api.github.com/graphql";


let opts = {
    method: "POST",
    headers: { "Content-Type": "application/json", "Authorization": "Bearer PERSONAL_ACCESS_TOKEN" },
    body: JSON.stringify({query: mutation })
    };

At this phase, you'll want to replace "YOUR_USERNAME" and "PERSONAL_ACCESS_TOKEN" with the actual values you want to use. We already generated the personal access token in GitHub, so copy that value and replace the PERSONAL_ACCESS_TOKEN string with the token. Your USER_NAME is your GitHub user name. You'll also want to adjust the expiresAt input variable to some time in the future.

Next, we'll pass the variables to our fetch, which will look like this:

fetch(url, opts)
  .then(res => res.json())
  .then(console.log)
  .catch(console.error);

Now save your project and check the console in developer tools. The input values should be returned in the return fields. If you login to you GitHub account and navigate your profile, you'll see that the mutation worked:

The API Series - Part 3: GraphQL and Sending Queries with fetch()

Nathan B Hankes — Thu, 06 May 2021 12:57:56 +0000

Introduction

In this tutorial you'll learn how to query data from a GraphQL API. In the process, you'll be exposed to some common tools used to work with GraphQL APIs, GraphQL syntax and structure, and you'll receive a VanillaJS GraphQL repository to study and get running on your local system.

If you missed the previous parts, you can find them here:
Part 1 - An Intro to APIs
Part 2 - The REST API, fetch(), and AXIOS

Prerequisites

Some familiarity with HTML, Git, and JavaScript.

What is GraphQL

In the same way that the RESTful APIs conform to a REST architectural style, GraphQL APIs follow a strict GraphQL architecture. GraphQL is a query language for APIs organized with this GraphQL architecture. But unlike RESTful APIs, GraphQL has a single URL endpoint, offering an advantage over working with REST APIs that require different URL endpoints for different data. Additionally, GraphQL APIs only returns the data you need, unlike REST APIs which often deliver all the data associated with an object. For example, if you want to fetch the user name, the REST API would return the User object along with all of its properties. This is known as overfetching and can slow down your applications. With GraphQL, as you'll see, you can return the user name only.

As a frontend developer, you'll be interacting with an API that is already built, but understanding how they're built is useful. The GraphQL schema architecture is defined by a series of schema based on type, like the below example from the GraphQL Foundation website:

type Query {
  hero: Character
}

type Character {
  name: String
  friends: [Character]
  homeWorld: Planet
  species: Species
}

type Planet {
  name: String
  climate: String
}

type Species {
  name: String
  lifespan: Int
  origin: Planet
}

In the above example, there are several types: Query, Character, Planet, and Species. Some types are built into the query language. Examples of these are the types Query and Mutation, which we'll dive into deeper later on. The custom types of Character, Planet, and Species are referred to as object types. Each type will have one or more properties, which are often referred to as fields. From the example above, the Query type has a field of hero, which returns an array of the Character object type. Within the API, fields are assigned a type, such as the built-in String, Int, Float, Boolean, or ID, or fields are assigned type objects, such as, in the example above, Character, Planet, or Species. Like the syntax of JavaScript, object types enclosed in brackets return an array of that object type.

Queries and Mutations

Whereas the REST API has several methods, such as POST, GET, PATCH, PUT, and DELETE, GraphQL has only two methods: Query and Mutation.

Queries are like the REST API GET method. They return data stored by the API.

Mutations change data, and encompass the REST API POST, PUT, PATCH, and DELETE methods.

Getting Started With GraphQL API Query

In order to avoid getting bogged down in setting up a development environment to get started, we're going to first learn about consuming a GraphQL API using the OneGraph's GraphiQL explorer located at https://www.onegraph.com/graphiql
The home page will look like this:

OneGraph is a company that integrates all the most commonly used APIs in business into a single GraphQL API, so developers can query Twitter, Salesforce, Slack, and UPS in a single query. GraphiQL is not owned by OneGraph. It is a tool that you can use independently.

To learn more about GraphiQL, visit https://github.com/graphql/graphiql

In the leftmost column, we see all the APIs that OneGraph has integrated into their offering. The center columns is where we will write our query. The rightmost column is where our query output will be displayed.

In the below example, we'll query the DEV blogging API to get some article information from user nbhankes:

The GraphiQL explorer shows us the GraphQL API schema structure of the DEV API and allows us to select the data we'd like to retrieve from the API. As we make this selection, the explorer creates a query, which we see being built in the middle column. Once our query is built, we run the query by hitting the play button on the bar. The query is then sent to the DEV API and the results are displayed on the right.

Below is the actual code for you to study. Notice the terms edges and node in the section labeled GraphQL Query. nodes define objects and edges define relationships between objects and are optional (except in the Relay GraphQL client). Adding these to a query can be useful when working with complex APIs schemas. For the sake of this introduction, it's just important to be aware of them. If you'd like to dive deeper into edges and nodes, visit https://www.apollographql.com/blog/explaining-graphql-connections-c48b7c3d6976/

Let's dive into the code below:

//GraphQL Query

query MyQuery {
  devTo {
    articles(username: "nbhankes") {
      edges {
        node {
          title
        }
      }
    }
  }
}


//API Response

{
  "data": {
    "devTo": {
      "articles": {
        "edges": [
          {
            "node": {
              "title": "The API Series - Part 2: The REST API, fetch(), and AXIOS"
            }
          },
          {
            "node": {
              "title": "The API Series - Part 1: An Intro to APIs"
            }
          },
          {
            "node": {
              "title": "Classless CSS Isn't Trashy"
            }
          },
          {
            "node": {
              "title": "Upgrade Your CSS: The Syntax.fm Typography Sizing Strategy"
            }
          }
        ]
      }
    }
  }
}




//GraphQL Query without edges or node

query MyQuery {
  devTo {
    articles(username: "nbhankes") {
      title
    }
  }
}


//API Response without edges or node

{
  "data": {
    "devTo": {
      "articles": [
          {
              "title": "The API Series - Part 2: The REST API, fetch(), and AXIOS"
          },
          {
              "title": "The API Series - Part 1: An Intro to APIs"
          },
          {
              "title": "Classless CSS Isn't Trashy"
          },
          {
              "title": "Upgrade Your CSS: The Syntax.fm Typography Sizing Strategy"
          }
        ]
      }
    }
  }

In the above code, you can see that the shape of the query defines the shape of the API response. The response is shaped like a nested JavaScript object and can be handled similarly.

Using GraphQL in Your Project: A Demo

While the GraphiQL explorer is extremely useful, you can't just add the GraphQL query into your code and expect it to work. Below you'll find a link to a GitHub repo that makes a GraphQL query using plain JavaScript and the Fetch() API. This demonstration repository contains code for a website that queries the SpaceX GraphQL API and renders the response data to the browser. The demo built this:

And the great thing about working with APIs is that if the CEO of SpaceX changes, our website will automatically reflect the changes as soon as the API is updated.

Visit the Live Demo

Link To Repo: https://github.com/nbhankes/vanillaJS-GraphQL-demo

Study the comments and the code in the repository, follow the directions on the README.md file to get the project running on your local environment. Customize the query and template literal for practice.

Conclusion

In this tutorial you learned how to query data from a GraphQL API. You were exposed to some common tools used to work with GraphQL APIs, the GraphQL syntax and structure, and you received a VanillaJS GraphQL repository to study and get running on your local system.

The API Series - Part 2: The REST API, fetch(), and AXIOS

Nathan B Hankes — Thu, 29 Apr 2021 13:41:05 +0000

Introduction

In this tutorial, you'll learn of different tooling options that allow you to make requests from APIs, you'll learn how to retrieve data from a REST API, how to submit data to a REST API, and you'll learn how to use a developer key in the case that the API requires it.

Prerequisites

Some familiarity with JavaScript.

Getting Started With the REST API

RESTful APIs communicate using HTTP/HTTPS. So part of your request will include what looks to be a website URL. These URLs are found in the API documentation, and they are the access points for the data or functionality you need. As an example, the following URL is part of a Dev.to API request to get the blog articles for a user named "vwc-user1": https://dev.to/api/articles?username=vwc-user1

The API may also display the format of all the data associated within this URL. It looks like this:

This list and data is stored as JSON. JSON stands for JavaScript Object Notation. It is a lightweight format for storing and transporting data. But without formatting and parsing, it's not very useful to us. If you submit the URL to the browser using your username instead of "vwc-user1," you'll only see a jumble of data.

To get our data in a way that's useful to use, we'll need to add in some tooling designed just for this purpose.

Fetch()

Per the MDN Documentation:

"The Fetch API provides a JavaScript interface for accessing and manipulating parts of the HTTP pipeline, such as requests and responses. It also provides a global fetch() method that provides an easy, logical way to fetch resources asynchronously across the network."

The Fetch API is something that is already available to you. That's because the Fetch API is part of the browser software and certain Fetch objects are part of the Javascript language. It will just work.

Before going further, you'll need to know the HTTP verbs. Below is a list of these verbs and what function they do when they are declared as your request method:

POST: Creates and inserts new data to API
GET: Receive something from the API
DELETE: Delete data
PUT*: Updates/replaces existing data
PATCH*: Updates/modifies existing data

*To understand the differences between PUT and PATCH, visit PATCH - HTTP | Mozilla Developer Network

In the sections below, we'll use the fetch() method to make a GET and POST request.

GET

Let's say that we found our API endpoint already. This is the part that looks like a website URL:

http://some-site.com//some.json

Here is an example of a Fetch request to that same endpoint:

fetch('http://some-site.com//some.json', {
    method: 'get'
})
  .then(function(response) {
    return response.text();
  })
  .then(function(text) {
    console.log('Request successful', text);
  })
  .catch(function(error) {
    log('Request failed', error)
  });

First we invoke the fetch() method, passing it the URL shared above. Within the Fetch() method is also included the method type of "get" as an option within the Fetch() request. This is wrapped in curly brackets. The GET method retrieves data from the API. Other methods, which you'll see shortly, can send data to a database associated with the API.
Second, we see a .then() chained to the fetch() method. then() is part of JavaScript's Promises object. So once our Fetch() method delivers the desired resource, the promise is officially met and the Then() method executes a function. In this case, the function takes the response from API request, which Fetch() handles by returning as an object called "response," and turns this raw data into text using the Text() method.

Oftentimes the json() method is used in place of the Text() >method, and that's to convert the raw data within the response >object into a json object.

Once the request is turned to text, the next promise in our chain is met and the second Then() method executes a function. In this case, the Text() method returns a "text" object (an object created by this particular method) and logs the string "Request successful" and the text object to the console.

The Catch() method is designed specifically for error handling and will execute a function that logs an error message when the previous promises are not met.

POST

There are times when we want to send data to a database using an API. For example, the Twitter API allows developers to post tweets through API requests. When you send new data, this is considered the POST method. When you update existing data, this is what's known as a PUT method.

In the example below, we are going to POST the user object to the API endpoint of:

https://example-api.com/post-user

// this is our user object that we're passing to the API via POST request
let user = {
  email: "example@email.com",
  firstName: "John", 
  lastName: "Doe"
}

// this is our POST request

fetch('https://example-api.com/post-user', {
  method: "POST",
  headers: {
    'X-API-KEY': 'my-apikey-string',
    'Accept': 'application/json',
    'Content-Type': 'application/json'
  body: JSON.stringify(user),
})
.then(response => response.json()) 
.then(json => console.log(json));
.catch(err => console.log(err));

In the above example, we set the fetch method as POST to let the API know that we are passing it new data. The headers section allows us to include more instructions and information with our request. You'll notice an API X-API-Key included in the header. This allows the API to authenticate our request. In this case, we would have registered with www.example-api.com to receive an API key. When they see a request from our unique API key, they'll know it's coming from the registered user with that key.

Within the header section, you'll also notice "Accept" and "Content-Type." In this example, we're letting the API know to accept and expect to receive data in the "application/json" format. The application documentation should let you know how the API expects to receive data.

The body section includes the data we are passing to the API. In this example, we're sending the user object defined in the first part of the above code block. But for the API to understand the data passed to it, we must first turn our user object into a string using the JSON.stringify() method. We must convert the object to a JSON string because Fetch() does not recognize JavaScript objects as a valid body response. This is a quirk of the Fetch API that developers must know when using Fetch()

After the body is defined, we then go into the chain of promises. Starting with:

.then(response => response.json())

The above code waits for a response. And when it receives a response as JSON, it uses the json() method to parse the response back to the JavaScript object format.

The second link in our promise chain looks like this:

.then(json => console.log(json));

The above code takes the JavaScript object return in the previous promise link and logs this value to the console. This should send you the data you sent, and it may include an id and time stamp that was generated by the API as the data was posted to the database.
The final link in the promise chain alerts us of any errors in the process by logging errors to the console:

.catch(err => console.log(err));

This break down of the Fetch API has covered some of the basics. As you grow as a developer, you'll find use cases for more of its functionality. As always, the Mozilla Development Network is the best starting place to read the documentation.

AXIOS

Axios is a popular library used to make HTTP requests to RESTful APIs. The library replaces the functionality of the Fetch API, and adds some improvements. For instance, the Axios library will handle some of the data type conversions for you, so you're not always using JSON.stringify or relying on the text() method.

Consider the similarities and differences of the Axios HTTP requests below:

// Send a POST request

axios({
  method: 'post',
  url: '/user/12345',
  data: {
    firstName: 'Blue',
    lastName: 'Falcon'
  }
})
  .then(response => {
    console.log(response);
  })
  .catch(err => {
    console.log(err);
})

// Send a GET request

axios.get('/user', {
    params: {
      USER_ID: XYZ543
    }
  })
  .then(response => {
    console.log(response);
  })
  .catch(err => {
    console.log(err);
})

In the above code, you'll see that Axios differs from Fetch in that we don't have to change the format of the response. This reduces some complexity for us as developers, and makes the code easier to read.

Axios can be installed via your package manager of choice or accessed through a CDN, which is when you gain access to Axios by linking your HTML document with a script tag provided by Axios.

To learn more about Axios, visit their GitHub page at: https://github.com/axios/axios

The API Series - Part 1: An Intro to APIs

Nathan B Hankes — Thu, 22 Apr 2021 14:14:54 +0000

APIs are the workhorse of modern web development. They put the "A" in JAMstack. And knowing how to work with them is a requirement for a career in frontend web development.

What Is An API

API stands for Application Programming Interface. An API's function is to relay information, requests, and responses between two or more programs or machines.

An example of an API you might need to use one day is Stripe. Stripe is a software company that creates software that processes online payments. They have developed the Stripe API, which allows any developer on the planet to interact with Stripe's payment processing software.

By using the Stripe API, you can add payment processing functionality to a website without possessing that specific area of software and banking expertise.

Sometimes an API simply provides access to a third-party database. An example of this would be the Open EAN/GTIN Database API, which allows you to access product information based on barcode details.

Some APIs allow you to add to a database. An example of this is the Twitter API, which allows you to add Twitter posts to your feed via the API.

The core similarity is that an API allows you to interact with software that you did not write and machines and data that you do not own.

Types of APIs

In this tutorial we are focusing on web service APIs. These are APIs that are designed to pass information between machines over networks like the internet, but there can also be local APIs. can be structured differently, which affects how you interact with, or consume, the API. So it's important to know about the common types.

REST

By far the most common since 2000, the REST, or RESTful, API is one that conforms to the constraints of the REST architectural style and allows for interaction with RESTful web services. REST stands for representational state transfer. By working within a set of architectural constraints, the RESTful APIs provide consistency to all developers. The reason RESTful APIs are so common is that they offer a standardized methodology for making requests to an API. So once a developer works with one REST API, other REST APIs are going to function in a similar way. If you want a career in frontend web development, learn to master consuming RESTful APIs.

GraphQL

An emerging API type, GraphQL API data is presented as a schema, which can be viewed by developers within the GraphiQL development environment. Frontend developers use the GraphQL query language to consume the data, providing the frontend, or client, with only the necessary data. Since this is an emerging technology, it is important to learn to consume GraphQL APIs.

SOAP

SOAP APIs are an older format, and you might encounter them when working on a legacy project. This tutorial will not cover SOAP APIs, though there are plenty of resources available online should you run into a SOAP API in your career.

XML-RPC / JSON RPC

These API types are older. Both follow a strict format that developers can rely on. One uses XML, and the other uses JSON data.

API Access

Some APIs are public. Some APIs require a developer key, which functions as an authorization protocol allowing access. These keys are acquired when registering with the API provider.
For example, Stripe requires a developer key so they know who is transferring money! Also, since some APIs charge for use, this is a way of tracking usage.

As a rule, it's highly recommended to keep your keys private. If someone else uses your key, you could get charged for their activity! Here is a good article on keeping your API keys secure: Best Practices For Securely Storing API Keys

Follow for future posts on how to consume RESTful and GraphQL APIs.

Classless CSS Isn't Trashy

Nathan B Hankes — Tue, 02 Feb 2021 16:22:58 +0000

Can you write a nice-looking website without adding classes or IDs to your HTML? That's exactly what classless CSS promises, though in practice you'll find you'll likely need to add some customization to get it just the way you want.

What is Classless CSS

Classless CSS is a design philosophy that adds properties and property values to type selectors only. A type selector is an HTML tag, so something like h1, p, form, div, etc.

Since every HTML element has a predefined style, a plain HTML doc will look good once the classless CSS stylesheet is linked.

How to Get Started

There are several classless CSS stylesheets available for use, and these are often times linked to your HTML document via a Content Delivery Network. Basically, there's a stylesheet stored on a server that you can link your HTML to. Below are a few options, and their websites are demos for what the stylesheet will do to plain HTML:

Water.css
New CSS
AWSM CSS
Style CSS
Writ CSS

There are many others out there, which can be found by searching for classless CSS stylesheets.

Create Your Own Style

Another option is to build your own classless stylesheet for reuse in your future projects. We all have our own style, and it's often easier and more satisfying to work with something you've crafted.

One way to go about this, is that you can download an existing classless stylesheet and tweak it to your liking.

Scott Tolinski of Syntax.fm podcast fame also teaches a course on building your own classless CSS stylesheet from scratch. His Level Up Tutorials course, Modern CSS Design Systems, covers this topic in much more detail.

Have you ever made a project using classless CSS? If so, leave a comment so other readers can hear about your experience!

Upgrade Your CSS: The Syntax.fm Typography Sizing Strategy

Nathan B Hankes — Tue, 26 Jan 2021 14:20:19 +0000

In a recent episode of the Syntax.fm podcast, Wes Bos and Scott Tolinski discuss how they handle typography sizing in their applications. I decided to try it out in Codepen and share my results here.

In short, here's the approach:

1.) A range of font sizes are declared as custom properties
2.) Sizing is declared as rem units
3.) The root font size is changed via @media queries to shrink and grow the rem sizes as needed

This approach solves several problems:

1.) Standardizes sizing
2.) Simplifies your CSS
3.) Responsive to changes in browser size

How To Start

First, set up your custom properties with a range of font sizes in rem units

:root {
  --text-1: 0.5rem;
  --text-2: 1rem;
  --text-3: 1.5rem;
  --text-4: 2rem;
  --text-5: 2.5rem;
  --text-6: 3rem;
}

You can name your custom properties however you like, but I found using a number at the end helped me keep it straight in my head. Some might prefer their names to be --smallest-font, --extra-large-font, etc. Whatever works for you is best.

You can also use whatever rem values you like. I found the 0.5rem to 3rem range useful for this short example. Out in the wild, there might be uses for more text size options and a larger range.

I then went through some common elements and assigned them these custom variables:

h1 {
  font-size: var(--text-6);
}

h2 {
  font-size: var(--text-5);
}

h3 {
  font-size: var(--text-3);
  margin-bottom: var(--text-2);
}

p {
  font-size: var(--text-2);
  margin-bottom: var(--text-1);
}

You'll notice I used the font sizing custom properties to set margin sizing. I don't see the downside, but in the future, perhaps I'll define a margin sizing custom property, as well.

Scott Tolinski's Level Up Tutorials course, Modern CSS Design Systems, covers this topic in much more detail, if you're looking to Level Up your CSS.

Take a look at the Codepen example to see this strategy implemented. I use JavaScript to cycle the root font size between 16px and 20px, so you can easily visualize how a change to the root font size proportionally changes any sizes declared as rem units.

Why is standardization important?

When you define your unit sizes in custom properties, you can change the font sizes throughout the entire document by changing a single value in the custom properties, versus combing through the entire stylesheet to adjust the font sizes for individual classes and html type selectors.

How does this simplify design?

Coming up with a strategy like this simplifies design. Sizing decisions are pre-made for you (and by you), so your task is to find the best fit from your limited options. When compared to selecting the perfect size from infinite options, you'll find that this approach is faster.

How is this responsive?

rem units are sized relative to the root font size, meaning 1 rem is equal to the font size set in the :root or html property. So if the root font size is decreased via a @media query as the screen size gets smaller, then all values with property values declared in rem units will resize proportionally.

The CSS Series: Part 13 - CSS Frameworks, CSS-in-JS, Architecture, and Accessibility

Nathan B Hankes — Tue, 19 Jan 2021 15:46:08 +0000

While this series hasn't covered every detail of CSS, I hope it leaves you with a solid foundation in CSS. But before you depart, there are some CSS topics beyond the fundamentals that you will want to be aware of. This page is simply a list of such topics with brief descriptions. If something interests you, you'll now have the resources to get started on your path of self-directed learning.

You can catch up on the rest of the series at the links below:
Part 1: An Intro to CSS
Part 2: How to Link a Stylesheet to Your index.html File
Part 3: Selectors
Part 4: Properties
Part 5: The Box Model
Part 6: CSS Units
Part 7: Flexbox
Part 8: CSS Grid
Part 9: Display Property
Part 10: Specificity
Part 11: Custom Properties
Part 12: Mobile and Responsive Design

Prerequisites

A basic understanding of CSS

CSS Documentation and Resources

There are several websites that strive to document everything about CSS. Others show how to harness the fundamentals to create exciting functionality. Below is a list of some of these resources.

Mozilla Development Network: https://developer.mozilla.org/en-US/docs/Web/CSS
Dev Docs: https://devdocs.io/css/
CSS Tricks: https://css-tricks.com/

CSS Frameworks

There are several popular CSS frameworks you can use that supply completed CSS stylesheets to you. These styles render when you add the framework's pre-defined class names into your HTML. Some popular frameworks include:

Bootstrap: https://getbootstrap.com/
Tailwind CSS: https://tailwindcss.com/
Bulma: https://bulma.io/

CSS-in-JS

There are libraries and tooling that allow developers to define all their CSS designs directly from within JavaScript. This is especially useful when developing within JS-centric frameworks and libraries like React.

If you're just learning CSS, these won't make much sense now. But as you progress into developing with something like React, you may encounter some issues that can best be solved using some of the links below.

Atomic CSS-in-JS: https://sebastienlorber.com/atomic-css-in-js…
Tailwind-in-JS: https://github.com/ben-rogerson/twin.macro…
styled-components: https://styled-components.com
theme-ui: https://theme-ui.com
styled-system: https://styled-system.com

CSS Architecture

Often times large code bases can become so large and compartmentalized, that it's hard to locate your design elements and your styling. Making changes suddenly requires more time navigating around folders than actually writing code. Due to this common problem, developers have shared some of their strategies on how to think about your CSS.

SMACSS: http://smacss.com/
Atomic CSS: https://acss.io/

There's no right way to write CSS. So if you discover something that works for you, consider sharing it with the developer community a blog post.

Web Accessibility

Web designers have a responsibility to make their websites accessible to visitors with disabilities. For example, people with poor eyesight will be able to read better if there is a lot of contrast between the background color and the font color. These are things most of us wouldn't consider naturally, so it's important to read up on accessibility.

A11y: https://www.a11yproject.com/
7 Things Designers Need To Know: https://medium.com/salesforce-ux/7-things-every-designer-needs-to-know-about-accessibility-64f105f0881b

Conclusion

Learning web design is a journey that never ends. There's always more to learn and it's not humanly possible to learn it all. Persistence will take you far. Curiosity will make the process enjoyable.

The CSS Series: Part 12 - Mobile First and Responsive Design

Nathan B Hankes — Tue, 12 Jan 2021 17:19:30 +0000

Because your web designs will be viewed on screens ranging from an old iPhone to a 27" iMac and beyond, you'll often encounter design situations where the website will require two or more designs in order to look nice and remain functional across multiple screen widths. Responsive design is web design that renders well at any browser size.

When developing a website or app from the ground up, you'll find that beginning by designing for mobile has many advantages.

Understanding the Mobile First Philosophy

Mobile first design simply means that developers begin their project by designing for mobile. This isn't simply an opinion, but there's logic behind it. Here are some key reasons this approach makes sense:

1) Mobile applications have bandwidth constraints, meaning that only core functionality should be included in mobile design.
It's most often easier to add to a design than to take away. So starting with a no frills, basic functionality design forces you to streamline and avoid the type of complexity that makes life harder for developers and users, alike.

Due to bandwidth constraints, you'll want to avoid animations, excessive pictures, and gradients, giving you more time to focus on things like functionality, user experience, and accessibility.
The focus on core functionality increases your chances of not bogging down on functionality and designs that aren't necessary to launch your project. This makes you more likely to finally complete side project!

2) HTML tags most often default to a display property value of block.

A mobile phone design is essentially a narrow column with HTML design elements stacked on top of each other. The default block property value automatically stacks HTML elements on top of one another, meaning that, by default, the HTML will be (mostly) optimized for mobile viewing. It's when screens become wider that developers begin placing items side by side in order to fill the space. Let's look at an example from Airbnb:

If we look at the layout of the above mobile Airbnb page, almost all containers are stacked on top of one another. This is often the default behavior for HTML elements, so before you even apply CSS to your html, the layout is close to your mobile design needs.

Oppose this to the desktop layout below:

It's the exact same content, but now we see the design splitting into two major columns. This is not the default behavior for html and requires additional CSS to achieve.

3) Google search algorithms place added value on websites optimized for mobile viewing.
By starting with mobile design first, you ensure you'll have better odds of being found by the world's most popular search engine.

4) Mobile browsing is becoming the new normal.

5) When you finish your mobile design, your site will work on a desktop.

It may not look pretty, but it will be functional.

Responsive Design

Responsive design is design that optimizes for whatever browser width it displays in. The flexbox display property is valuable for this as are the following CSS functions.

@media Queries

As a developer, you have several tools to help you display the website differently depending on the browser width. @media queries are, as of 2020, the best CSS solution to this problem:

"The @media CSS at-rule can be used to apply part of a style sheet based on the result of one or more media queries. With it, you specify a media query and a block of CSS to apply to the document if and only if the media query matches the device on which the content is being used."

In terms of mobile development, you can have different sections of code apply to different browser widths by setting up @media queries. Let's look at an example to so you understand the concept:

body {
    background-color: white; 
}

@media only screen and (max-width: 500px) { 

body { 
    background-color: blue; 
} 

}

In the example above, when the browser is less than 500 pixels in width, the @media rule takes over and the body background color will render as blue. When the browser width is greater than 55 pixels, the body background renders as white.

clamp()

A newer approach that's gaining popularity is the clamp() CSS function. The clamp() function takes in three values that allow developers to set a minimum, preferred, and maximum value to any property. The order is as follows clamp(minimum value, preferred value, maximum value).

Let's takes a look at an example:

font-size: clamp(1rem, 2.5vw, 2rem);

In the above example, the font size render at a maximum of 2 rems and a minimum of 2.5vw. This approach allows to you create responsive sizing that doesn't get too large or small at the far edges of any range. This is the type of CSS function you'll want to play around with to understand more.

Here's a demo from the MDN documentation worth looking at: clamp() demo

The CSS Series: Part 11 - Custom Properties

Nathan B Hankes — Tue, 05 Jan 2021 15:58:01 +0000

Once you pick a color palette for your website, you can imagine how often you'll write those color values in your stylesheet. You could have the same color listed as a property value in thirty or more places! Now imagine if your client or team suddenly needs to change your site's color palette? You'd have to go through the entire document and change each of those 30+ values!

One way to avoid this is to use CSS custom properties, also known as CSS variables. CSS custom properties are variables defined by CSS authors that contain specific values to be reused throughout a document. This tutorial will show you how to create and use CSS variable.

Understanding CSS Custom Properties

Let's say our client thinks they'd like their website background to be gray. And all borders are black. Font colors should be white, they say. But you've worked with enough people to know that this will change a few times before finishing your project, so you decide to set up custom properties. You would create custom properties for each of these colors like so:

/ stylesheet.css

:root {
    --background: gray;
    --border: black;
    --font: white;
    }

By declaring the CSS custom properties inside of the root pseudo-class, these custom properties are globally available throughout your entire project. Assigning a custom value to a div declaration means that the custom variable would only be available to div types. This is due to a process referred to as scoping, which you'll learn more about as you dive into a language like JavaScript. But for now, let's carry on with our website design stylesheet, inserting these custom properties into your project like so:

/ stylesheet.css

:root {
    --background: gray;
    --border: black;
    --font: white;
    }

div .header {
    background-color: var(--background);
    border: 5px solid var(--border);
    color: var(--font);
    }

h1,
h2,
h3,
h4 {
    color: var(--font);
    }

body {
    background-color: var(--background);
    color: var(--font);
    }

Now your html is styled with the property values assigned to your custom properties of --background, --border, and --font. As you can see, if you needed to change the color palette of the entire website, all you would need to do is change the property value assigned to your custom property declarations inside of the root pseudo-class.

The benefits of CSS custom properties are not limited to colors and you're really only limited by your imagination.