惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Spread Privacy
Spread Privacy
K
Kaspersky official blog
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Forbes - Security
Forbes - Security
Hacker News - Newest:
Hacker News - Newest: "LLM"
The Last Watchdog
The Last Watchdog
SecWiki News
SecWiki News
Attack and Defense Labs
Attack and Defense Labs
Google DeepMind News
Google DeepMind News
Security Archives - TechRepublic
Security Archives - TechRepublic
S
Secure Thoughts
WordPress大学
WordPress大学
Microsoft Security Blog
Microsoft Security Blog
P
Proofpoint News Feed
云风的 BLOG
云风的 BLOG
V
Visual Studio Blog
Security Latest
Security Latest
TaoSecurity Blog
TaoSecurity Blog
Cyberwarzone
Cyberwarzone
S
SegmentFault 最新的问题
Cloudbric
Cloudbric
aimingoo的专栏
aimingoo的专栏
S
Schneier on Security
N
Netflix TechBlog - Medium
MyScale Blog
MyScale Blog
T
The Blog of Author Tim Ferriss
H
Hacker News: Front Page
C
Cybersecurity and Infrastructure Security Agency CISA
小众软件
小众软件
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
AWS News Blog
AWS News Blog
AI
AI
G
GRAHAM CLULEY
IT之家
IT之家
P
Privacy & Cybersecurity Law Blog
L
Lohrmann on Cybersecurity
Last Week in AI
Last Week in AI
D
Docker
Recent Announcements
Recent Announcements
O
OpenAI News
T
Threat Research - Cisco Blogs
GbyAI
GbyAI
S
Security @ Cisco Blogs
T
Troy Hunt's Blog
C
Check Point Blog
博客园 - 三生石上(FineUI控件)
A
About on SuperTechFans
The Cloudflare Blog
阮一峰的网络日志
阮一峰的网络日志
N
News and Events Feed by Topic

Kent C. Dodds Blog

Implementing Hybrid Semantic + Lexical Search Simplifying Containers with Cloudflare Sandboxes Migrating to Workspaces and Nx Offloading FFmpeg with Cloudflare Building Semantic Search on my Content Helping YOU ask ME questions with AI How I used Cursor to Migrate Frameworks The Dow's Start on the Covenant Path 2025 in Review The next chapter: EpicAI.pro AI is taking your job How I increased my visibility Launching Epic Web 2023 in Review Stop Being a Junior RSC with Dan Abramov and Joe Savona Live Stream Fixing a Memory Leak in a Production Node.js App 2022 in Review My Car Accident I Migrated from a Postgres Cluster to Distributed SQLite with LiteFS I'm building EpicWeb.dev A review of my time at Remix Remix: The Yang to React's Yin How I help you build better websites Why I Love Remix The State Initializer Pattern How to React ⚛️ Get a catch block error message with TypeScript Building an awesome image loading experience How Remix makes CSS clashes predictable Introducing the new kentcdodds.com How I built a modern website in 2021 How to use React Context effectively Static vs Unit vs Integration vs E2E Testing for Frontend Apps The Testing Trophy and Testing Classifications Array reduce vs chaining vs for loop Don't Solve Problems, Eliminate Them Super Simple Start to Remix Super Simple Start to ESModules in Node.js JavaScript Pass By Value Function Parameters How to write a Constrained Identity Function (CIF) in TypeScript How to optimize your context value TypeScript Function Syntaxes Listify a JavaScript Array Build vs Buy: Component Libraries edition Using fetch with TypeScript Wrapping React.useState with TypeScript Define function overload types with TypeScript 2020 in Review Business and Engineering alignment Hi, thanks for reaching out to me 👋 useEffect vs useLayoutEffect Super simple start to Firebase functions Super simple start to Netlify functions Super Simple Start to css variables Favor Progress Over Pride in Open Source Testing Implementation Details How getting into Open Source has been awesome for me useState lazy initialization and function updates Use ternaries rather than && in JSX Application State Management with React Use react-error-boundary to handle errors in React JavaScript to Know for React How I structure Express apps What open source project should I contribute to? When I follow TDD AHA Programming 💡 How I Record Educational Videos Should I write a test or fix a bug? Stop mocking fetch Intentional Career Building Improve test error messages of your abstractions Tracing user interactions with React Eliminate an entire category of bugs with a few simple tools Common mistakes with React Testing Library Super Simple Start to React Stop using client-side route redirects The State Reducer Pattern with React Hooks Function forms Replace axios with a simple custom fetch wrapper How to test custom React hooks React Production Performance Monitoring Should I useState or useReducer? Stop using isLoading booleans Make Your Test Fail Make your own DevTools An Argument for Automation Fix the "not wrapped in act(...)" warning Super Simple Start to ESModules in the Browser Implementing a simple state machine library in JavaScript 2010s Decade in Review Why users care about how you write code Why I avoid nesting closures Don't call a React function component Why your team needs TestingJavaScript.com Inversion of Control Understanding React's key prop How to Enable React Concurrent Mode How to add testing to an existing project Profile a React App for Performance
How to write a React Component in TypeScript
2021-03-04 · via Kent C. Dodds Blog

Here's our component without types:

const operations = {
	'+': (left, right) => left + right,
	'-': (left, right) => left - right,
	'*': (left, right) => left * right,
	'/': (left, right) => left / right,
}

function Calculator({ left, operator, right }) {
	const result = operations[operator](left, right)
	return (
		<div>
			<code>
				{left} {operator} {right} = <output>{result}</output>
			</code>
		</div>
	)
}

const examples = (
	<>
		<Calculator left={1} operator="+" right={2} />
		<Calculator left={1} operator="-" right={2} />
		<Calculator left={1} operator="*" right={2} />
		<Calculator left={1} operator="/" right={2} />
	</>
)

Right there you may notice we do things a little differently. Maybe you prefer this instead:

const Calculator = ({ left, operator, right }) => (
	<div>
		<code>
			{left} {operator} {right} ={' '}
			<output>{operations[operator](left, right)}</output>
		</code>
	</div>
)

I don't like the implicit return there. It means you can't reasonably declare variables or use hooks. So even for simple components, I never go with this approach.

Ok, so maybe you do this:

const Calculator = ({ left, operator, right }) => {
	const result = operations[operator](left, right)
	return (
		<div>
			<code>
				{left} {operator} {right} = <output>{result}</output>
			</code>
		</div>
	)
}

Honestly, that's fine most of the time. I personally like the hoisting characteristics of function declarations rather than function expressions like that (learn more).

Alright, let's add some types to this. For functions, you need to consider the types coming in and the types going out. Let's start with the input: props. To start, let's go with a simple type for the props (we'll improve it later):

type CalculatorProps = {
	left: number
	operator: string
	right: number
}

With that, let's try some options for applying that type to the props object in our React Component.

A common method to typing a React component is to use one of the generics that are built-into @types/react (I mean, it's built-in right? So what could go wrong?). Interestingly, you cannot type a function declaration this way, so we'll have to use a function expression:

const Calculator: React.FC<CalculatorProps> = ({ left, right, operator }) => {
	// implementation clipped for brevity
}

This works pretty well, but there are three major problems with this:

  1. Our Calculator function now accepts a children prop, even though we don't do anything with it 🙃 (So, this compiles: <Calculator left={1} operator="+" right={2}>What?</Calculator>).
  2. You can't use generics. Not super common, but definitely a downside.
  3. We have to use a function expression and can't use a function declaration.

Ok ok, so maybe #3 isn't a major problem, but #1 is pretty significant. There are a few other smaller issues laid out in this excellent GitHub issue if you want to dive deeper (also check the React TypeScript Cheatsheet). Suffice it to say, don't use React.FC (or its longer alias React.FunctionComponent).

One of the things I love about React components is that they aren't all that special. Here's the definition of a React component:

A React component is a function that returns something React can render.

Now, according to @types/react, we're limited to null and React.ReactNodes, but React can actually render strings, numbers, and booleans as well. In any case, because a React component is simply a function that returns something React can render, typing it can be just as straightforward as typing functions. You don't have to do anything special just because it's React.

So here's how I'd type the props for this component:

function Calculator({ left, operator, right }: CalculatorProps) {
	// implementation clipped for brevity
}

This doesn't have any of the shortcomings of React.FC and it's no more complicated than typing the arguments to a regular function.

Ok, so what about the return value? Well, we could type it as React.ReactElement or even wider as a React.ReactNode. But honestly, I side with my friend Nick McCurdy when he says that mistakes can easily be made causing the return type to be too wide. So even outside a react context, I default to not specifying the return type (rely on inference) unless necessary. And that's the case here.

Improving the CalculatorProps type

Ok, now this next bit doesn't have a lot to do with typing React components, but I thought you'd find it interesting anyway, so skip ahead if you don't. Let's improve the CalculatorProps type. As a reminder, here's what we have so far:

// I took the liberty of typing each of these functions as well:
const operations = {
	'+': (left: number, right: number): number => left + right,
	'-': (left: number, right: number): number => left - right,
	'*': (left: number, right: number): number => left * right,
	'/': (left: number, right: number): number => left / right,
}

type CalculatorProps = {
	left: number
	operator: string
	right: number
}
function Calculator({ left, operator, right }: CalculatorProps) {
	const result = operations[operator](left, right)
	return (
		<div>
			<code>
				{left} {operator} {right} = <output>{result}</output>
			</code>
		</div>
	)
}

I think the left and right types are fine. It's the operator that I'm unhappy with. Using string is too wide. There are specific operations that are allowed. For example, what would happen if we tried:

const element = <Calculator left={1} operator="wut" right={2} />

That right there is what we call a runtime exception my friends. That is... unless you have strict mode on, in which case you'd have a compilation error on operations[operator]. In strict mode, TypeScript will correctly know that accessing any string from the operations object will not necessarily return a callable function.

There are plenty of ways to solve this problem. Basically, we want to limit the operator to only the supported operators. We can do that with a simple union type:

type CalculatorProps = {
	left: number
	operator: '+' | '-' | '*' | '/'
	right: number
}

But if we decided to add the Exponentiation Operator (**), then we'd have to update not only the operations object, but also the operator type which would be annoying. Maybe there's a way we can derive the type for the operator based on the operations object? Why, yes there is!

type CalculatorProps = {
	left: number
	operator: keyof typeof operations
	right: number
}

typeof operations is going to get us a type that describes the operations object, which is roughly equal to:

type operations = {
	'+': (left: number, right: number) => number
	'-': (left: number, right: number) => number
	'*': (left: number, right: number) => number
	'/': (left: number, right: number) => number
}

The keyof part will take all the keys of that type, resulting in '+' | '-' | '*' | '/' 🎉

Conclusion

Here's the finished version (I typed the operations functions as well):

const operations = {
	'+': (left: number, right: number): number => left + right,
	'-': (left: number, right: number): number => left - right,
	'*': (left: number, right: number): number => left * right,
	'/': (left: number, right: number): number => left / right,
}

type CalculatorProps = {
	left: number
	operator: keyof typeof operations
	right: number
}

function Calculator({ left, operator, right }: CalculatorProps) {
	const result = operations[operator](left, right)
	return (
		<div>
			<code>
				{left} {operator} {right} = <output>{result}</output>
			</code>
		</div>
	)
}

const examples = (
	<>
		<Calculator left={1} operator="+" right={2} />
		<Calculator left={1} operator="-" right={2} />
		<Calculator left={1} operator="*" right={2} />
		<Calculator left={1} operator="/" right={2} />
	</>
)

I hope that gives you an idea of a good way to type your React components. Good luck and take care!

P.S. One thing I don't like at all about our solution is we have to type each of the operations functions. Interestingly, this is a bit of a rabbit hole, but at the other end of it, the types are definitely better and you learn a few tricks along the way. Originally that was part of this blog post, but I decided to move it to its own post. Read all about it here: How to write a Constrained Identity Function (CIF) in TypeScript.