ReactJS

Composing React Components with TypeScript

Published Mar 29, 2021

Updated Feb 14, 2023

6 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

TypeScript is a language that supercharges your JavaScript by giving your application's source codes type-checking. Combining the compiler tool and the IDE plug-ins gives a beautiful development experience when building JavaScript applications.

What I love most about using TypeScript is that when I use it, I know exactly the structure of data to give to components and when I give a different structure, the IntelliSense immediately notifies me.

Also, as a friend said:

If you use TypeScript in your application (without doing "illegal" kinds of stuff like passing any everywhere), you'll never have an uncaught error of "x as undefined"

This view is opinionated, but I quite agree with it.

Using TypeScript with React makes building React components faster with little to no uncaught errors. It allows you to specify the exact structure of expected props for any component.

In this article, we'll learn how to use TypeScript to compose React components. To continue with this article, a fair knowledge of TypeScript is required. This is a great starting guide to learn TypeScript.

At the end, we'll also look at the difference between prop-types and TypeScript.

Let's start building components

In this article, we'll build four components: an Input, a Button, a Header, and a BlogCard component. These components will show how TypeScript can be used with React.

Setting up TypeScript for React

Some React frameworks (like NextJS and GatsbyJS) already have support for TypeScript out of the box, but for Create React App, you have a few things you'll need to do.

If it's a new project, you can create the project like so:

create-react-app project-name --template typescript

The --template typescript installs dependencies that add support for TypeScript in your React application.

If it's an existing project, then you would need to install the Typescript dependencies:

npm install --save typescript @types/node @types/react @types/react-dom

With these, you can rename .js files to .tsx to allow TypeScript codes.

Now, let's build our components.

An `Input` component

For our Input component, we need the following props: defaultValue, onChange, placeholder and name. Each of them is a string value except onChange, which is a function.

Using TypeScript, here's how we define the component:

// Input.tsx
import React from "react";

type Props = {
  onChange: (str: string) => void;
  placeholder: string;
  name: string;
  value?: string;
};
function Input({ onChange, name, placeholder, value = "" }: Props) {
  return (
    <input
      onChange={event => onChange(event.target.value)}
      name={name}
      placeholder={placeholder}
      value={value}
    />
  );
}

export default Input;

This way, our component is well defined. The expected onChange method must accept only one argument which must be a string. placeholder, name and value (if provided) must be a string. If a different data type is passed, the IntelliSense immediately yells, or the compile command on the terminal breaks.

And here's how this component is used:

// Form.tsx
import React, { useState } from "react";

import Input from "./Input";

function Form() {
  const [nameInput, setNameInput] = useState("");
  const onChange = (str: string) => {
    setNameInput(str);
  };

  return (
    <form>
      <Input
        onChange={onChange}
        name="name"
        placeholder="Enter your name"
        value={nameInput}
      />
    </form>
  );
}

export default Form;

Let's change the data type of the placeholder property to see the warning we get:

...
<form>
    <Input
        ...
        name={10}
    />
</form>
...

Here's the warning:

A `Button` component

Our Button component will have the following props: value and processing like so:

// Button.tsx
type Props = {
    value: "Submit" | "Continue" | "Update";
    processing: boolean;
};
function Button({ value, processing }: Props) {
    return <button>{processing ? "Processing" : value}</button>;
}

For the value prop, we're expecting either of three strings: "Submit", "Continue", or "Update", and the processing expects a true or false value.

Let's see the component in use:

// Form.tsx
import React, { useState } from "react";

import Input from "./Input";
import Button from "./Button";

function Form() {
  const [nameInput, setNameInput] = useState("");
  const onChange = (str: string) => {
    setNameInput(str);
  };

  return (
    <form>
      <Input
        onChange={onChange}
        name="name"
        placeholder="Enter your name"
        value={nameInput}
      />
      <Button value='Submit' processing={false} />
      <Button value='Submit' processing={true} />
    </form>
  );
}

export default Form;

As you'd notice, "Next" is not included in the expected strings for value. Therefore, we get an error from IntelliSense. Here are two things you'd notice on your IDE:

As seen above, on entering quotes, the IDE already gives you the acceptable values. But if you pass "Next", you'll get this:

A `Header` component

So our Header component would be a bit complex. For an authenticated user, the header would have the user's name, but if otherwise, we have the "Sign in" text. Here's how we'll define it:

// Header.tsx
import React from "react";

type User = {
  name: string;
};
type Props =
  | {
      authenticated: false;
      profile: null;
    }
  | {
      authenticated: true;
      profile: User;
    };
function Header(props: Props) {
  return (
    <header>
      <a href="/">Home</a>
      <a href="/about">About</a>
      {props.authenticated ? props.profile.name : <a href="/signin">Sign in</a>}
    </header>
  );
}

export default Header;

The Header component accepts two props: authenticated and profile. The props are conditional such that when props.authenticated is false, props.profile is null and when props.authenticated is true, props.profile is the User type.

This means, if a user is authenticated, a profile object must also be provided.

Here's how the component is used:

import Header from "./Header";

function Layout() {
    return (
        <div>
            <Header authenticated={true} profile={null} />
        </div>
    );
}

For the above, we do something unacceptable. authenticated is true, but a different data type for profile is provided. Here's what the IntelliSense gives:

A `BlogCard` component

In this component, we expect a post prop which is an object with the following properties: title, author, date and timeToRead. Here's how we define it with TypeScript:

// BlogCard.tsx
import React from "react";

type Props = {
  post: {
    title: string;
    author: {
      name: string;
    };
    date: Date;
    timeToRead: number;
  };
};
function BlogCard({ post }: Props) {
  return (
    <div className="blog-card">
      <span className="title">{post.title}</span>
      <span className="date">
        on {new Intl.DateTimeFormat().format(post.date)}
      </span>
      <span className="time-to-read">{post.timeToRead}mins</span>
      <span className="author-name">By {post.author.name}</span>
    </div>
  );
}

export default BlogCard;

And here's how it's used:

// BlogPosts.tsx
import React from "react";
import BlogCard from "./BlogCard";

type Post = {
  title: string;
  author: {
    name: string;
  };
  date: Date;
  timeToRead: number;
};
function BlogPosts() {
  const posts: Post[] = [
    {
      title: "What is JavaScript",
      date: new Date(),
      timeToRead: 3,
      author: {
        name: "Dillion Megida"
      }
    }
  ];
  return (
    <div>
      {posts.map((p, i) => (
        <BlogCard key={`post-${i}`} post={p} />
      ))}
    </div>
  );
}

export default BlogPosts;

Note that the Post type does not have to be written multiple times in different files. It can be a shared type exported from its own file and used anywhere.

With the above, we do not get an error because every data type is as expected. Now let's say we added an extra property to the Post type in the blog posts like so:

type Post = {
    title: string;
    author: {
        name: string;
    };
    date: Date;
    timeToRead: number;
    excerpt: string; // new property
}
...

We get errors in the IDE like so:

In the components examples above, we've seen how to add typings to the component's properties such that a parent components using such components would know exactly what the component wants to receive. We've seen how the Intellisense provides error messages when types are not valid.

Having an IntelliSense makes the development faster as you can easily see the warnings and errors in your IDE. Without IntelliSense, you can also verify the data types when you try building (npm run build) your React application.

For example, using the Header component like so:

...
<Header
    authenticated={true}
    profile={null}
/>
...

Running npm run build for the above code gives the following error in the terminal:

The examples above are in this Stackblitz project. You can play with it, and violate expected types to see warnings.

Prop Types

TypeScript is not the only way to ensure expected data types in a React application. There are also prop-types. They are quite similar, but work in different ways. prop-types is more of an injected tool that inspects data received from an API to ensure it has the expected type. Also, it can be used in libraries that are compiled to JavaScript to be consumed by other applications. This means, even in Vanilla JavaScript, you'll still be able to catch type errors. However, prop-types is limited in the way you can specify data types compared to TypeScript. For example, prop-types cannot have interfaces, neither can they have the conditional props as we saw for the Header component.

This StackOverFlow answer shows a detailed difference between them.

Conclusion

While TypeScript has a lot of work (adding typings to almost everything) which can be strenuous, it makes developing React applications faster and with little fear of errors. You're not just limited to single types as with prop-types, but you can also specify objects of objects or literally any pattern as an expected type.

There's also more than you can do with TypeScript and React. You can further read the TypeScript Documentation to learn more.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Dillion Megida
Loves learning, building and teaching tech.
@iamdillion @dillionmegida

End-to-end type-safety with JSON Schema

End-to-end type-safety with JSON Schema I recently wrote an introduction to JSON Schema post. If you’re unfamiliar with it, check out the post, but TLDR: It’s a schema specification that can be used to define the input and output data for your JSON API. In my post, I highlight many fantastic benefits you can reap from defining schemas for your JSON API. One of the more interesting things you can achieve with your schemas is end-to-end type safety from your backend API to your client application(s). In this post, we will explore how this can be accomplished slightly deeper. Overview The basic idea of what we want to achieve is: * a JSON API server that validates input and output data using JSON Schema * The JSON Schema definitions that our API uses transformed into TypeScript types With those pieces in place, we can achieve type safety on our API server and the consuming client application. The server side is pretty straightforward if you’re using a server like Fastify with already enabled JSON Schema support. This post will focus on the concepts more than the actual implementation details though. Here’s a simple diagram illustrating the high-level concept: We can share the schema and type declaration between the client and server. In that case, we can make a request to an endpoint where we know its type and schema, and assuming the server validates the data against the schema before sending it back to the client, our client can be confident about the type of the response data. Marrying JSON Schema and TypeScript There are a couple of different ways to accomplish this: * Generating types from schema definitions using code generation tools * Creating TypeBox definitions that can infer TypeScript types and be compiled to JSON Schema I recommend considering both and figuring out which would better fit your application and workflows. Like anything else, each has its own set of trade-offs. In my experience, I’ve found TypeBox to be the most compelling if you want to go deep with this pattern. Code generation A couple of different packages are available for generating TS types from JSON Schema definitions. * https://github.com/bcherny/json-schema-to-typescript * https://github.com/vega/ts-json-schema-generator They are CLI tools that you can provide a glob path to where your schema files are located and will generate TS declaration files to a specified output path. You can set up an npm hook or a similar type of script that will generate types for your development environment. TypeBox TypeBox is a JSON Schema type builder. With this approach, instead of json files, we define schemas in code using the TypeBox API. The TypeBox definitions infer to TypeScript types directly, which eliminates the code generation step described above. Here’s a simple example from the documentation of a JSON Schema definition declared with TypeBox: ` This can then be inferred as a TypeScript type: ` Aside from schemas and types, TypeBox can do a lot more to help us on our type-safety journey. We will explore it a bit more in upcoming sections. Sharing schemas between client and server applications Sharing our JSON Schema between our server and client app is the main requirement for end-to-end type-safety. There are a couple of different ways to accomplish this, but the simplest would be to set up our codebase as a monorepo that contains both the server and client app. Some popular options for TypeScript monorepos are: PNPM, Turborepo, and NX. If a monorepo is not an option, you can publish your schema and types as a package that can be installed in both projects. However, this setup would require a lot more maintenance work. Ultimately, as long as you can import your schemas and types from the client and server app, you are in good shape. Server-to-client validation and type-safety For the sake of simplicity, let's focus on data flowing from the server to the client for now. Generally speaking, the concepts also apply in reverse, as long as your JSON API server validates your inputs and outputs. We’ll look at the most basic version of having strongly typed data on the client from a request to our server. Type-safe client requests In our server application, if we validate the /users endpoint with a shared schema - on the client side, when we make the request to the endpoint, we know that the response data is validated using the user schema. As long as we are confident of this fact, we can use the generated type from that schema as the return type on our client fetch call. Here’s some pseudocode: ` Our server endpoint would look something like this: ` You could get creative and build out a map that defines all of your endpoints, their metadata, and schemas, and use the map to define your server endpoints and create an API client. Transforming data over the wire Everything looks stellar, but we can still take our efforts a bit further. To this point, we are still limited to serialized JSON data. If we have a created_at field (number or ISO string) tied to our user, and we want it to be a Date object when we get a hold of it on the client side - additional work and consideration are required. There are some different strategies out there for deserializing JSON data. The great thing about having shared schemas between our client and server is that we can encode our type information in the schema without sending additional metadata from our server to the client. Using format to declare type data In my initial JSON Schema blog post, I touched on the format field of the specification. In our schema, if the actual type of our date is a string in ISO8601 format, we can declare our format to be "date-time". We can use this information on the client to transform the field into a proper Date object. ` Transforming serialized JSON Data This can be a little bit tricky; again, there are many ways to accomplish it. To demonstrate the concept, we’ll use TypeBox to define our schemas as discussed above. TypeBox provides a Transform type that you can use to declare, encode, and decode methods for your schema definition. ` It even provides helpers to statically generate the decoded and encoded types for your schema ` If you declare your decode and encode functions for your schemas, you can then use the TypeBox API to handle decoding the serialized values returned from your JSON API. Here’s what the concept looks like in practice fetching a user from our API: ` Nice. You could use a validation library like Zod to achieve a similar result but here we aren’t actually doing any validation on our client side. That happened on the server. We just know the types based on the schema since both ends share them. On the client, we are just transforming our serialized JSON into what we want it to be in our client application. Summary There are a lot of pieces in play to accomplish end-to-end type safety. With the help of JSON Schema and TypeBox though, it feels like light work for a semi-roll-your-own type of solution. Another great thing about it is that it’s flexible and based on pretty core concepts like a JSON API paired with a TypeScript-based client application. The number of benefits that you can reap from defining JSON Schemas for your APIs is really great. If you’re like me and wanna keep it simple by avoiding GraphQL or other similar tools, this is a great approach....

Apr 17, 2024

6 mins

JSONTypeScript

Improving INP in React and Next.js

Improving INP in React and Next.js In one of my previous articles, I've explained what INP is, how it works, and how it may affect your website. I also promised you to follow up with more concrete advice on how to improve your INP in your favorite framework. This is the follow-up article, where I'll focus on how to improve your INP score in React and Next.js. How to prepare for INP in React and Next.js? The first thing to do is to ensure you're using the latest version of React. The React team has been working on making React more INP-friendly and has already made some improvements in the latest versions. To enhance your INP score, consider fully taking advantage of new features introduced in React 18, such as Concurrent Rendering, Automatic Batching, and Selective Hydration. However, there are also some general areas to focus on, such as SSR and SSG in Next.js, Web Workers, or optimizing your hooks and state management. Concurrent Rendering The Concurrent Mode in React uses an algorithm that breaks rendering down into so-called "fiber nodes" and schedules the renders based on their expiration and priority. This effectively allows the user to interact with the page while the rendering is still in progress. In previous React versions, all updates, such as setState calls were treated as "urgent" and once the re-render had started, there was no way to interrupt it. Concurrent Mode changes this by being able to prioritize the updates and interrupt a non-blocking state update started with startTransition. For a simple explanation of concurrency in React, you can check out Dan Abramov's explanation. As part of the Concurrent Mode, React introduced several lifecycle methods that allow you to prioritize the rendering of certain parts of your UI, such as: - useTransition hook that allows you to update the state without blocking the UI, - useDeferredValue hook that allows you to defer the rendering of certain parts of your UI, - startTransition API that, similarly to the useTransition hook lets you mark a state update as non-blocking. It lacks, however, an indication of whether it's still pending. Automatic Batching Introduced in React 18, Automatic Batching reduces the number of re-renders that happen on state changes even when they happen outside of event handlers, e.g. in a setTimeout or Promise callback. This feature comes out of the box and you don't have to do anything to enable it, and it makes a great argument for upgrading to React 18. Selective Hydration Selective Hydration allows you to take hydration off the main thread by wrapping your components in a Suspense boundary. This way, components can become interactive faster as the browser can do other work on the main thread while the hydration is happening. To fully take advantage of selective hydration, consider the following: - Prioritizing Above-the-Fold Content: Use Suspense boundaries strategically around any parts of your application that may take the server longer to deliver to ensure they don’t block critical content from becoming interactive as soon as possible. - Hydration on Interaction: Implementing hydration upon user interaction for non-critical components can drastically reduce the main thread's workload, enhancing INP. Vercel even has a small case study showing how using selective hydration improved the performance of a Next.js site. Server-Side Rendering (SSR) and Static Site Generation (SSG) in Next.js Not everything has to run client-side. Next.js excels in SSR and SSG capabilities, which can significantly impact INP by delivering content to users faster. Optimizing SSR with techniques like incremental static regeneration (ISR) or leveraging SSG for static pages ensures that users can interact with content faster, improving the perceived performance. Workers Offloading heavy computations to Web Workers can free up the main thread, enhancing the responsiveness of React and Next.js applications. This strategy is especially useful when dealing with third-party scripts. Offloading such scripts in Next.js can be easily done by specifying the "worker" strategy on your Script component. Be aware that this feature is not yet stable and does not work with the app directory, though. If you want to take things one step further, you could use Partytown, which helps you offload any resource-intensive scripts to Web Workers. It comes with a React component that you can use to wrap your third-party scripts and offload them to a Web Worker, and it's compatible with Next.js as well. Hooks and State Management State management in React applications can easily get out of hand, leading to unnecessary re-renders and effectively an increased INP. Sometimes, using a state management library like Redux or MobX can help you consolidate your state and reduce the number of re-renders. However, they are not silver bullets and can also introduce performance issues if not used properly. If you are dealing with a lot of re-renders due to prop changes, make sure you are leveraging memoization. As of now, you may need to work with useMemo and useCallback hooks to memoize your values and functions, respectively. The upcoming React 19’s Forget Compiler, however, will apparently memoize everything under the hood, making these hooks obsolete. Using memoization properly can help you reduce the number of re-renders and improve your INP. To investigate your hook dependencies and re-renders, you can leverage React Developer Tools or use this handy helper hook I found on the internet to trace your re-renders: ` Conclusion Improving INP in React and Next.js is not easy and can require much investigation and fine-tuning. Still, it's worth doing to avoid being penalized by Google in its search results and provide a better experience for your users. Adopting React 18's new features, leveraging SSR and SSG in Next.js, utilizing Web Workers, and optimizing hooks and state management can significantly boost your INP score and deliver a faster application to your users. Remember, INP is just one among many performance metrics emphasizing the need for a comprehensive approach to performance optimization...

Apr 19, 2024

5 mins

Web PerformanceReactNextJSJavaScript

Building SEO-Powered Websites With Gatsby

Gatsby is a framework that leverages React for building SEO-powered websites. Many websites are created to be discovered, hence, SEO support is an important factor in such websites. Many factors influence SEO such as accessibility, correct meta-information (at the head tag) and some other external tools. Gatsby supports using appropriate meta information for individual pages to improve their presence online. In this article, we'll look at the limitations of Create React App in respect to SEO, and how Gatsby solves this with SSR. Furthermore in the article, we'll go through a tutorial on building a basic website with good SEO. Why CRA is not a good tool for SEO CRA is an opinionated tool used for building React applications but cannot be used for SEO. Here's why: When using React, you'll most probably be using a library like react-helmet (a document head manager for React) for updating meta-information about the site. The limitations of such libraries is that they contain JavaScript, which means they can only be executed on the browser (so JavaScript can run). SEO crawlers or social media tools that inspect head tags of websites (to display a card, perhaps) would not execute that JavaScript. Instead, they make use of the default meta information they can find. In CRA, the default title in public/index.html is "React App". This means, for every page you create (based on routes), they will all have the same title. They only show different titles when they are executed on the client's browser because the react-helmet library gets the chance to be executed, thereby updating the head tags. This article contains more information. How Gatsby solves React SEO problems with SSR Gatsby is a Static Site Generator (SSG) which uses Server Side Rendering (SSR) to generate static pages during the build process. What this means is that you provide dynamic meta information in every page, and during the process of static site generation, pages are server-side rendered with the specified meta information, thereby making static pages with their own details. With this technique, every page contains its own meta title, meta description and basically every meta information. The following tutorial shows how Gatsby improves SEO in web applications. Building an SEO powered site with Gatsby We'll be building a basic website with two pages: / - Home and /about - About Us. These two pages would have their own meta information attached to them during the build process. To get started, let's created our Gatsby project. Run the following in your terminal: ` This pulls the default template, and installs all necessary dependencies. In the src directory, you'll find three directories: components, images and pages. As you may observe, the template already comes with some configurations for seo and optimizing images. To build our project afresh, delete the following files/directories: ` This will leave us with components/seo.js and images. In a future series, we'll explore the gatsby-image plugin used in components/images.js. But for now, understand that it performs optimizations on images. Let's briefly explore the content of components/seo.js ` _Note that_ this component can look a bit different in another template, or you may do it differently. The SEO component receives four props: title, description, lang and meta with title as required. You can specify more props if you want or take out those you don't need. This allows different pages to specify their titles, descriptions and other meta information specific to them. Helmet is from react-helmet but is used a bit different from how it is used in CRA. It works with gatsby-plugin-react-helmet which provides server rendering support. components/seo.js also contains some GraphQL which we will cover in a future series. The Helmet plugin during the build process populates all pages with their respective meta information depending on the inputs provided during development. Now let's add our pages. With Gatsby, you do not need any routing packages for determining components to show based on specific URLs. To create a page, all you need to do is add the component's file directly under the pages directory. To create the two pages for our project, add two files: index.js for / and about.js for /about. Before proceeding with our pages, let's add a layout. Create components/layout.js and components/header.js. Add the following in components/header.js: ` Same React. The only thing new here is a different Link component from Gatsby is used. In the components/layout.js, add the following: ` For the pages, add the following to index.js: ` I added an unsplash image to images and required it require('../images/laptop.jpg') as seen above. We'll look at the usage of the SEO component soon. For pages/about.js, add the following: ` Create a new directory called styles under src and create a new file: global.css. Copy the following css styles to that file: ` For the global stylesheet to be used for the whole site, the gatsby-browser.js API file would be used. gatsby-browser.js is a reserved API file that gives access to actions within the browser. In gatsby-browser.js (at the root of your project), add the following: ` When you run the gatsby server for your project (gatsby develop), you'll get the following on localhost:8000: For /: For /about: The SEO component makes all the pages unique and SEO-ready. For index.js, we have: ` Just as we have configured the SEO component using react-helmet, this updates the meta information for the homepage during the build process. This way, the first thing crawlers will see is the unique meta details for the page, as they do not require any JavaScript to be updated. To test this, do the following: - build for project for production (gatsby run build) - serve the production build (gatsby run serve) This will run the built content on localhost:9000. You can use curl on your terminal to inspect the source code (or run inspect on the browser). ` The result: The reason it came out as "Homepage | Gatsby Default Starter" is because of the prop titleTemplate provided by Helmet which was configured like so in the SEO template: ` This appends a default title to every title provided by the pages. Conclusion In this article, we looked at how Gatsby solves the problem of SEO using server side rendering for generating static pages. The basic example used in the tutorial shows how each page contain their own meta information that can easily be crawled by SEO bots or social media tools....

Dec 16, 2020

6 mins

GatsbyReact

The Quirks And Gotchas of PHP

The Quirks And Gotchas of PHP If you come from a JavaScript background, you'll likely be familiar with some of its famous quirks, such as 1 + "1" equaling "11". Well, PHP has its own set of quirks and gotchas, too. Some are oddly similar to JavaScript's, while others can surprise a JavaScript developer. Let's start with the more familiar ones. 1. Type Juggling and Loose Comparisons Like JavaScript, PHP has two types of comparison operators: strict and loose. The loose comparison operator in PHP uses ==, while the strict comparison operator uses ===. Here's an example of a loose vs. strict comparison in PHP: ` PHP is a loosely typed language, meaning it will automatically convert variables from one type to another when necessary, just like JavaScript. This is not only when doing comparisons but also, for example, when doing numeric operations. Such conversions can lead to some unexpected results if you're not careful: ` As you can see, the type system has gotten a bit stricter in PHP 8, so it won't let you commit some of the "atrocities" that were possible in earlier versions, throwing a TypeError instead. PHP 8 introduced many changes that aim to eliminate some of the unpredictable behavior; we will cover some of them throughout this article. 1.1. Truthiness of Strings This is such a common gotcha in PHP that it deserves its own heading. By default, PHP considers an empty string as false and a non-empty string as true: ` But wait, there's more! PHP also considers the string "0" as false: ` You might think we're done here, but no! Try comparing a string such as "php" to 0: ` Until PHP7, any non-numeric string was converted to 0 when cast to an integer to compare it to the other integer. That's why this example will be evaluated as true. This quirk has been fixed in PHP 8. For a comprehensive comparison table of PHP's truthiness, check out the PHP documentation. 1.2. Switch Statements Switch statements in PHP use loose comparisons, so don't be surprised if you see some unexpected behavior when using them: ` The New Match Expression in PHP 8 PHP 8 introduced the match expression, which is similar to switch but uses strict comparisons (i.e., === under the hood) and returns a value: ` Unlike switch, there is no "fall-through" behavior in match, and each branch must return a value, making match a great alternative when you need a more precise or concise form of branching—especially if you want to avoid the loose comparisons of a traditional switch. 1.3 String to Number Conversion In earlier versions of PHP, string-to-number conversions were often done silently, even if the string wasn’t strictly numeric (like '123abc'). In PHP 7, this would typically result in 123 plus a Notice: ` In PHP 8, you’ll still get int(123), but now with a Warning, and in other scenarios (like extremely malformed strings), you might see a TypeError. This stricter behavior can reveal hidden bugs in code that relied on implicit type juggling. Stricter Type Checks & Warnings in PHP 8 - Performing arithmetic on non-numeric strings: As noted, in older versions, something like "123abc" + 0 would silently drop the non-numeric part, often producing 123 plus a PHP Notice. In PHP 8, such operations throw a more visible Warning or TypeError, depending on the exact scenario. - Null to Non-Nullable Internal Arguments: Passing null to a function parameter that’s internally declared as non-nullable will trigger a TypeError in PHP 8. Previously, this might have been silently accepted or triggered only a warning. - Internal Function Parameter Names: PHP 8 introduced named arguments but also made internal parameter names part of the public API. If you use named arguments with built-in functions, be aware that renaming or reordering parameters in future releases might break your code. Always match official parameter names as documented in the PHP manual. Union Types & Mixed Since PHP 8.0, we can declare union types, which allows you to specify that a parameter or return value can be one of multiple types. For example: ` Specifying the union of types your function accepts can help clarify your code’s intent and reveal incompatibilities if your existing code relies on looser type checking, preventing some of the conversion quirks we’ve discussed. 2. Operator Precedence and Associativity Operator precedence can lead to confusing situations if you’re not careful with parentheses. For instance, the . operator (string concatenation similar to + in JavaScript) has left-to-right associativity, but certain logical operators have lower precedence than assignment or concatenation, leading to puzzling results in PHP 7 and earlier: ` PHP 8 has fixed this issue by making the + and - operators take a higher precedence. 3. Variable Variables and Variable Functions Now, we're getting into unfamiliar territory as JavaScript Developers. PHP allows you to define variable variables and variable functions. This can be a powerful feature, but it can also lead to some confusing code: ` In this example, the variable $varName contains the string 'hello'. By using $$varName, we're creating a new variable with the name 'hello' and assigning it the value 'world'. Similarly, you can create variable functions: ` 4. Passing Variables by Reference You can pass variables by reference using the & operator in PHP. This means that any changes made to the variable inside the function will be reflected outside the function: ` While this example is straightforward, not knowing the pass-by-reference feature can lead to some confusion, and bugs can arise when you inadvertently pass variables by reference. 5. Array Handling PHP arrays are a bit different from JavaScript arrays. They can be used as both arrays and dictionaries, and they have some quirks that can catch you off guard. For example, if you try to access an element that doesn't exist in an array, PHP will return null instead of throwing an error: ` Furthermore, PHP arrays can contain both numerical and string keys at the same time, but numeric string keys can sometimes convert to integers, depending on the context> ` In this example: - "1" (string) and 1 (integer) collide, resulting in the array effectively having only one key: 1. - true is also cast to 1 as an integer, so it overwrites the same key. And last, but not least, let's go back to the topic of passing variables by reference. You can assign an array element by reference, which can feel quite unintuitive: ` 6 Checking for Variable Truthiness (isset, empty, and nullsafe operator) In PHP, you can use the empty() function to check if a variable is empty. But what does "empty" mean in PHP? The mental model of what's considered "empty" in PHP might differ from what you're used to in JavaScript. Let's clarify this: The following values are considered empty by the empty() function: - "" (an empty string) - 0 (0 as an integer) - 0.0 (0 as a float) - "0" (0 as a string) - null - false - [] (an empty array) This means that the following values are not considered empty: - "0" (a string containing "0") - " " (a string containing a space) - 0.0 (0 as a float) - new stdClass() (an empty object) Keep this in mind when using empty() in your code, otherwise, you might end up debugging some unexpected behavior. Undefined Variables and isset() Another little gotcha is that you might expect empty() to return true for undefined variables too - they contain nothing after all, right? Unfortunately, empty() will throw a notice in such case. To account for undefined variables, you may want to use the isset() function, which checks if a variable is set and not null: ` The Nullsafe Operator If you have a chain of properties or methods that you want to access, you may tend to check each step with isset() to avoid errors: ` In fact, because isset() is a special language construct and it doesn't fully evaluate an undefined part of the chain, it can be used to evaluate the whole chain at once: ` That's much nicer! However, it could be even more elegant with the nullsafe operator (?->) introduced in PHP 8: ` If you’ve used optional chaining in JavaScript or other languages, this should look familiar. It returns null if any part of the chain is null, which is handy but can also hide potential logic mistakes — if your application logic expects objects to exist, silently returning null may lead to subtle bugs. Conclusion While PHP shares a few loose typing quirks with JavaScript, it also has its own distinctive behaviors around type juggling, operator precedence, passing by reference, and array handling. Becoming familiar with these nuances — and with the newer, more predictable features in PHP 8 — will help you avoid subtle bugs and write clearer, more robust code. PHP continues to evolve, so always consult the official documentation to stay current on best practices and language changes....

Jun 20, 2025

6 mins

PHPDevelopment

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Composing React Components with TypeScript

Let's start building components

Setting up TypeScript for React

An `Input` component

A `Button` component

A `Header` component

A `BlogCard` component

Prop Types

Conclusion

Dillion Megida

You might also like

End-to-end type-safety with JSON Schema

Improving INP in React and Next.js

Building SEO-Powered Websites With Gatsby

The Quirks And Gotchas of PHP

Let's innovate together!

You might also like

End-to-end type-safety with JSON Schema

Improving INP in React and Next.js

Building SEO-Powered Websites With Gatsby

The Quirks And Gotchas of PHP

Let's start building components

Setting up TypeScript for React

An Input component

A Button component

A Header component

A BlogCard component

Prop Types

Conclusion

Dillion Megida

End-to-end type-safety with JSON Schema

Improving INP in React and Next.js

Building SEO-Powered Websites With Gatsby

The Quirks And Gotchas of PHP

Let's innovate together!

End-to-end type-safety with JSON Schema

Improving INP in React and Next.js

Building SEO-Powered Websites With Gatsby

The Quirks And Gotchas of PHP

An `Input` component

A `Button` component

A `Header` component

A `BlogCard` component