Explained: 'React' refers to a UMD global
Find out why this error occurs and learn how to fix it.
Developers love a good folder structure. It helps application code feel organized. JavaScript developers generally have a good idea about where to put their implementation code - but what about types?
In this guide, I'll give you my opinionated take on where to put your types in application code. For most of you, it'll hopefully confirm your existing intuitions. For others, it'll give you some new ideas to try out.
Rule 1: When a type is used in only one place, put it in the same file where it's used.
Most applications are built from functions and classes. And when you're working on them, you'll often need to make changes to their types to keep moving.
The classic example in applications is component props. If you have a component MyComponent
that takes props foo
and bar
, I recommend putting its types in the same file.
typescript
// MyComponent.tsxinterface Props {foo: stringbar: number}export const MyComponent = (props: Props) => {// ...}
Other approaches would see you moving the types to a separate module:
|- src|- components|- MyComponent.tsx|- MyComponent.types.ts
But I find this approach pretty unintuitive to work with. When I'm working on MyComponent
, I'll often need to be editing both its implementation and its types. Having them in separate files just makes that harder.
When types are truly single-use, don't be afraid to inline them:
typescript
// MyComponent.tsxexport const MyComponent = (props: {foo: string; bar: number}) => {// ...}
A lot of teams are reluctant to inline types because it feels too "messy". But don't feel that you always need to extract out a type into a separate type
or interface
- inlining is absolutely fine, and it's very low-cost to refactor it into a separate type later if you need to.
Rule 2: Types that are used in more than one place should be moved to a shared location.
You should think of types in your application as functions. If you've got a function that's used in multiple modules, you'll probably want to move it to a shared location. Same goes for types.
For me, this usually means creating a *.types.ts
file in an appropriate spot in my app. If they're shared across the whole app, I'll put them in the src
folder.
|- src|- components|- MyComponent.tsx|- shared.types.ts
If they're only used in the components
folder, I'll put them there:
|- src|- components-|- MyComponent.tsx|- components.types.ts
In other words, I share the type across the smallest number of modules that need it.
Rule 3: Types that are used in more than one package in a monorepo should be moved to a shared package.
So far, we've talked about types in the context of a single application. But what if you're working on a monorepo with multiple packages?
In that case, you should move shared types to a shared package.
|- apps|- app|- website|- docs|- packages|- types|- src|- shared.types.ts
In the example above, we've got a monorepo with three apps: app
, website
, and docs
. We've also got a types
package that contains types shared across the whole monorepo.
Depending on how your monorepo is structured, how this package is implemented may vary. When I was at Vercel, I wrote a guide on internal packages for the Turborepo docs which might help you get started.
So, keep these three rules in mind:
And you'll be well on your way to a well-structured codebase.
Share this article with your friends
Find out why this error occurs and learn how to fix it.
Learn the differences between React.ReactNode
and JSX.Element
in TypeScript when working with React.
Since I first got into advanced TypeScript, I've been in love with a particular pattern. It formed the basis for one of my first-ever TypeScript tips, and it's been extraordinarily useful to me ever since. I call it the IIMT (rhymes with 'limped'): the Immediately Indexed Mapped Type.
Discover the power of ComponentProps in React and TypeScript. Learn how to extract and utilize props from native HTML elements, existing components, and elements with associated refs. Enhance your development workflow with this essential type helper.
Testing types is a crucial aspect of developing libraries in TypeScript. In this article, we explore three different ways to test your types: using the vitest test runner, rolling your own solution with type helpers, and leveraging the tsd library.
The TypeScript 5.1 beta is out - here's everything you need to know.
There’s a difference between using TypeScript and knowing TypeScript.
The docs give you a good grasp of the pieces like generic functions, conditional types, and type helpers.
But out in the wild, developers are combining these pieces together into patterns.
Four of the most important patterns to know and use are:
Testing code doesn't need to be typed so strictly, and sometimes tests need to pass the wrong type. I made a library called shoehorn that eases the pain of working with tests in TypeScript by providing a first-class way to pass the wrong type to a function.
The article discusses why TypeScript does not throw an error when a function that is assigned to a variable doesn't match its type. It explains that a function with fewer parameters than its type can still be passed, and this behavior is not restricted to TypeScript but exists in JavaScript as well.
TypeScript 5.0 introduces const type parameters which are useful in preserving the literal types of objects passed to functions.
Updates to TypeScript 5.0 have made their way into Total TypeScript!
Exclude
is a very powerful utility type that can be used in a variety of ways. In this article, I'll show you 9 ways to use it along with code examples.
As a frontend developer, your job isn't just pixel-pushing. Most of the complexity in frontend comes from handling all the various states your app can be in.
It might be loading data, waiting for a form to be filled in, or sending a telemetry event - or all three at the same time.
If you aren't handling your states properly, you're likely to come unstuck. And handling states starts with how th
Using the satisfies keyword is one of four ways to make type assignments in TypeScript. In this article we'll look at examples of when each method should be used.
Understand why TypeScript throws complicated errors by learning how to read them. Errors mirror the structure of the code being compared and can be simplified by changing the way types are assigned.
Learn how to use TypeScript generics on the type level and with functions to improve code readability, type safety, and reduce repetitive code. Use "type helpers" to create new types and generic functions to pass in and return specific types.
Use Zod to validate unknown inputs in your app, whether it's a CLI or a public API, to ensure that data entering your app is safe. Zod can also be used for 'sort of' trusted inputs, like third-party services, to ensure that the data returned is what you expect.
TypeScript's template literal syntax allows developers to manipulate and transform strings in a powerful way. This can be extended using unions, infer, and recursion to handle more complex tasks.
Donny (kdy1 on GitHub) is rewriting TypeScript in Rust hoping to speed up tsc which is slow due to its TypeScript base. In this interview, he explains some of the financial and technical challenges they face with this open-source project.
Let's imagine you're creating a function which sums up an array of objects. Here's one, taken from the Excalidraw codebase:
const sum = <T>(array: readonly T[], mapper: (item: T) => number): number => array.reduce((acc, item) => acc + mapper(item), 0)
Let's look at the type definition. This function takes in:
readonly T[]