ReactJS

Composing React Components with TypeScript

Mar 29, 2021

6 min read

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.

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

CSS Hooks: A new way to style your React apps

In the world of web development, the management of styles has always been a crucial aspect of building modern and responsive user interfaces. With the rise of CSS in JS libraries like Material UI and Chakra, developers have started creating dynamic and reusable styles using JavaScript; however, the performance implications of these libraries have led to the exploration of alternative solutions. One such solution is CSS Hooks, a library that offers a different approach to managing styles in web applications. The Problem with CSS in React and CSS in JS Libraries In React applications, you typically write styles directly with the style prop by applying classes with className, or if you’re using a framework like Material UI or Chakra then you may use the sx attribute, which is more powerful than the baseline attributes. There are some performance concerns in the case of the sx attribute specifically. The framework has to dynamically generate classes with your styles and apply them to the document whenever it is used. This can become an issue with large and complex applications as your styles will be regularly regenerated on the fly as the user navigates through the application. This has led developers to seek alternative solutions that offer similar flexibility but with better performance. Introduction to CSS Hooks CSS Hooks improve upon the aforementioned issues by pre-generating your CSS using configuration hooks. The styles that these hooks generate remain static during the lifetime of the application and are reused wherever possible. CSS variables are utilized under the hood whenever dynamic behavior is needed. By dynamic behavior, I’m referring to advanced CSS features such as pseudo-class selectors and media queries, which are both traditionally unavailable for use with inline styles. CSS Hooks utilize an interesting trick under the hood to accomplish this, which we will now explore. The Power of CSS Variables and the Fallback Trick As mentioned before, CSS variables are utilized in order to support using advanced dynamic behavior such as pseudo-selectors in our inline styles. CSS variables are core to something known as the “fallback trick”. The gist of how the fallback trick works is to have the pseudo-selector or media query toggle the state of a variable between initial and an empty invalid value, and then we put the value that we actually want to toggle as the “fallback” value in the reference to the CSS variable inside of the inline style itself. Changing this fallback value inside of an inline style essentially allows us to control the values used by the pseudo-selector without having to regenerate linked stylesheets as we only have to change the inline style attribute. This is best explained with an example: ` This plain HTML and CSS code effectively allows us to utilize the focus pseudo-selector on any element that we want using inline styles only. This is what CSS Hooks effectively does in the background when you use dynamic styles. No nasty re-renders and mucking with stylesheets needed! How to use CSS Hooks Now that we know how CSS Hooks fundamentally work, let’s try using them. The library itself is much easier to use than the aforementioned example. Installation and usage of CSS Hooks is easy. Firstly, we must install the @css-hooks/react package into a React project with the package manager of your choice (npm, pnpm yarn, etc). Once that’s done, all that’s left is a little bit of configuration. You have to first use a utility function called createHooks that is exported from the package we just installed. The result of that function returns a couple of variables in an array that can be deconstructed, the first being a stylesheet in the form of a string, and the second being a function. ` I recommend putting this in a separate file that can be imported from multiple other places in the project as this is where we will be configuring hooks across the project. We’re exporting both hooks and css, and both are important. We need to include hooks into the DOM as it contains the styles of the hooks that we’ll be referencing in our components. In your root component you need to add the following tag so that the generated CSS can be used. ` How this is done may vary based on the libraries that you are using. After that’s done, you can integrate CSS Hooks into your components while writing inline styles mostly just like you would do normally, with the only change being the addition of an additional call to the css function that we exported earlier: ` Now that the core boilerplate is set up, your components can now utilize CSS Hooks in theory; however we need to actually add some hooks to start with before we can use them, or else we’ll just be limited to basic styles in the same way that React inline styles are. Make your own hooks We can define our hooks inside of the css-hooks file that we created earlier, the same one that exports the css helper function that gets CSS Hooks working with our components. Hooks are defined in the options parameters that are currently empty. Defining a simple hook that allows us to define inline hover styles for a component is very easy and can be done as follows: ` Although both the key and the value in this example are the same, they both serve different purposes. The key is the name of the hook that we reference when we want to use it, while the value is the spec. The spec is the actual CSS selector that we’re writing. The name can be anything that you want it to be so long as it doesn’t clash with any existing style properties or hooks. Recommended hooks Although making your own hooks may be necessary at times, there is another repository provided by the CSS Hooks authors that adds a way to generate many useful hooks called @css-hooks/recommended. I highly recommend using this library to generate your hooks if at all possible, and the usage is pretty simple. Here’s an example showing how you can use it to generate media queries, color scheme specific styles and pseudo-selectors: ` Then with that done, these can be utilized as follows: ` We can also modify the hooks configuration to add our own hooks in addition to the recommended hooks by using the spread operator: ` Then that custom hook can be used by simply using its key name: ` Summary CSS Hooks offers a performant alternative to traditional CSS in JS libraries by leveraging CSS variables and providing a unique approach to managing styles in web applications. By pre-generating the stylesheet based on configured hooks and utilizing CSS Variables for dynamic behavior, developers can create reusable styles without the performance overhead associated with dynamic stylesheet generation. If you're interested in exploring CSS Hooks further, be sure to check out @CSSHooks for more information. You can also find some of the examples demonstrated here in a working app in our demos repository. Thank you for reading!...

Feb 28, 2024

5 mins

CSSReact

Getting Started with GatsbyJS

GatsbyJS is a React framework and a Static Site Generator (SSG) tool used in building web applications. It combines Server Side Rendering (SSR) features, and static site development for building SEO-powered, secured, and fast applications. In this article we’ll start with an introduction to Gatsby, we’ll learn the terms SSG, CSR, and SSR, how Gatsby improves SEO, and then we’ll build a simple website with Gatsby. Introduction GatsbyJS is built on React. React is a frontend UI library for frontend implementations. It supports the idea of small components that merges with other components to make bigger components. As a UI library, React is a tool that can be combined with other tools for building web applications. Therefore, React on its own may require other tools (like routing tools, webpack server, and so on) for building full-fledged frontend applications. With that being said, when you install React, you need to install other tools to make up your application. This results in an opinionated setup aided by Create React App (CRA). Despite this, more configurations and tools needed to be installed for a full application. Then, Gatsby! Gatsby is an opinionated framework that takes away the hassle of setting up the application and allows you to begin development immediately. Asides from this, Gatsby also solves the issue of Search Engine Optimisation (SEO) that using only React provides. react-helmet is not an effective SEO solution. This article explains that further. SSR, CSR, and SSG Client-Side Rendering (CSR) In CSR, all routings and renderings are handled by the browser with JavaScript. For this technique, different HTML files are not created for different pages, instead, one page referencing some JavaScript files that determine what to display depending on the URL. React is a CSR tool. This means all routings are handled by the browser. In React, you have an index.html file found in the public folder which codes similar to this: ` After the build process (npm run build), the index.html will look like this: ` The referenced .js files handles all routings and responds to the URL with contents to share. build/index.html is only fetched once, also with the JavaScript files. This may result in low page load speed due to fetching all resources. This method affects SEO in such a way that SEO crawlers only see React App and does not see every other meta changes because those changes only happen when libraries like react-helmet are executed (which is only on the browser). Server Side Rendering In contrast to CSR, SSR involves populating the browser with resources from the server. This means that for every route change, a request is made to the server to fetch new resources. SSR is perfect for SEO because SEO crawlers get the right meta information when any page is requested. SSR also has its cons, one of which is a delay when navigating between pages. CSR wins in this area because all JavaScript resources are fetched on the first request and every other navigation does not need a page refresh. Static Site Generator An SSG is a tool or set of tools that create static HTML pages from input files or content sources. Many SSG tools work in various ways but most of them take away the issues of security and slow fetching that database-driven platforms use. SSG takes content from different sources and builds them all into static pages which can be accessed faster when fetched by a browser. How Gatsby improves SEO Gatsby is an SSG tool that solves the issue of SEO that CSR brings and also makes routing faster compared to SSR. Gatsby does this by pre-building the web application before it is hosted. During the build process, all meta information provided within components is attached to the built pages. So when SEO crawlers or social sharing tools access any page of the application, they get access to the meta-information that has been provided to all pages during development. This does not involve any rendering in the browser. The built files are static pages which looks like each page was built separately like so: ` Building a simple website with Gatsby To show how Gatsby sites are built, we’ll be building a very simple website. No much complexities or dynamics, just simple. Install the CLI tool Firstly, install the gatsby CLI tool. Or you can use npx if that’s what you want. ` Create new site You can either create a new Gatsby site with a basic template ([gatsby-starter-default]9https://www.gatsbyjs.com/starters/gatsbyjs/gatsby-starter-default/)) provided by the team, or use a specify another template to customize. For the default template, a new site is created like so: ` Where new-site is the name of the project you’re creating. This gives the following project structure: The template provides SEO configurations using GraphQL which you can improve. To see the site in action, run: ` At localhost:8000, you’ll find your site displayed like so: Alternatively, you can specify a template you want to use. You can find different starter templates from their list of starter libraries. To use a template, say, gatsby-starter-blog, the following command will be used: ` This gives the following project structure: On starting the development server, localhost:8000 shows this: Improving the gatsby-starter-default template The template has three folders under src namely components, images and pages. The components and images page are optional, but pages is a required page for Gatsby. Unlike React, where you need a router library to show a set of components for a particular URL, in Gatsby, you create pages by having React JavaScript files under the pages folder. Let’s add an about page under pages like so: In about.js, you can create your React components or import components. For example: ` SEO is a component that dynamically updates meta information about each pages and Layout is a wrapper component that serves as the layout of all pages. This can be configured to fit your needs too. When you start your development server, go to localhost:8000/about and you’ll find this: Note that: whatever you can do in React (components structuring, prop-types, and so on), you can do the same in Gatsby. Gatsby makes things easier allow you to focus on the important parts of your application and pre-building your site to make SEO-fit. Also, Gatsby makes your site fast and since they are static pages, they can be served from anywhere (like CDNs). Conclusion Gatsby goes beyond the general understanding of “static pages”. Gatsby can source content from Content Management Systems and build static pages for them. An example is gatsby-source-instagram. It sources content from Gatsby at every building process, source the latest content from Instagram, and makes them available on your website. There a lot of other awesome applications that can be achieved by using Gatsby, such as e-commerce tools, portfolios, and so on. Here's a gallery of sites using Gatsby. Another beautiful thing about Gatsby is the community. You’ll find a ton of plugins that make development easier and more effective. This article gives introductory information on what makes Gatsby an awesome tool. There are still more to learn to make the best use of Gatsby such as Gatsby and GraphQL, SSR APIs, and many more. Their documentation gives a very great guide to learning more about the tool. I hope this article gives you reasons to try out Gatsby in your next project....

Dec 14, 2020

7 mins

JavaScriptReactGatsby

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

Shuchi Mittal, the Head of Cloud enablement at Honeywell, discusses how she as a leader in platform engineering has been able to transform internal platform engineering teams at other organizations by providing teams with value-added services, and how they effectively managed costs. She talks about how to treat these teams as customers, and delivering services that meet the customer needs, but also charging them for their usage. By providing policy-compliant infrastructure and unique services tailored to their requirements, platform engineering teams can showcase their commitment to supporting the success of other teams within an organization. This approach not only fosters trust but also positions platform engineering as a strategic partner rather than just a service provider. By going beyond the basic infrastructure provisioning, the platform engineering team can offer services that help development and product teams streamline their processes and improve efficiency. Shuchi shares her work at Fiserv where she implemented a chargeback system to track usage and costs effectively, incentivizing better development practices. This not only helped in managing costs but also encouraged teams to optimize their resource utilization, leading to improved overall efficiency and more easily scalable systems. Her platform engineering team recognized the importance of effectively managing financial aspects to secure upfront investment for product development. By implementing a billing system based on gigabyte hours, they aligned costs with usage, enabling teams to have a clear understanding of their resource consumption. This approach not only provided transparency but also incentivized teams to adopt cost-effective practices. By strategically managing financial aspects, the platform engineering team gained the trust of stakeholders and secured the necessary resources to drive innovation and deliver value to the organization. Shuchi’s journey of platform engineering serves as a valuable example of how a team can transition from being a basic service provider to becoming an innovation partner within an organization. By building trust, offering value-added services, and strategically managing financial aspects, the platform engineering team successfully elevated their role and became a strategic enabler of innovation. Download this episode here....

Apr 16, 2024

2 mins

Engineering LeadershipSoftware Engineering

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

CSS Hooks: A new way to style your React apps

Getting Started with GatsbyJS

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

You might also like

End-to-end type-safety with JSON Schema

CSS Hooks: A new way to style your React apps

Getting Started with GatsbyJS

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

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

CSS Hooks: A new way to style your React apps

Getting Started with GatsbyJS

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

End-to-end type-safety with JSON Schema

CSS Hooks: A new way to style your React apps

Getting Started with GatsbyJS

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

An `Input` component

A `Button` component

A `Header` component

A `BlogCard` component