TypeScript with React: Props and State Typing Quiz Quiz

Explore essential concepts of props and state typing in TypeScript for React development. Enhance your understanding of type safety, functional components, and type annotations relevant to modern React applications.

1. Props Typing Basics

   Which of the following is the correct way to type a prop object for a functional React component that expects a 'name' string and an optional 'age' number?

   1. type Props = { string: name; number?: age }
   2. type Props = (name: string, age: number) =u003E void
   3. type Props = { name: string; age?: number }
   4. type Props = { name?: string; age: number }

   Explanation: The first option correctly defines a typed object with 'name' as a required string and 'age' as an optional number, following TypeScript standards for props. Option two mistakenly makes 'name' optional, which does not match the requirement. Option three incorrectly swaps the syntax, using type names as keys, which is invalid in TypeScript. Option four uses a function signature, not an object shape, so it is not suitable for component props typing.

2. State Typing in useState

   When initializing a useState hook for a boolean state variable called 'isActive' in TypeScript, which is the correct way to type the state?

   1. const [isActive, setIsActive] = useState(false: boolean)
   2. const isActive: boolean = useState(false)
   3. const [isActive, setIsActive]: boolean = useState(false)
   4. const [isActive, setIsActive] = useStateu003Cbooleanu003E(false)

   Explanation: The first option uses the correct syntax for typing the state with useState, where the generic parameter 'u003Cbooleanu003E' specifies the state's type. The second option places the type after the value, which is invalid syntax. The third does not destructure the state and provides an incorrect assignment. The fourth incorrectly adds a type annotation to array destructuring, which is not standard in this context.

3. Props Type Reusability

   If you want to reuse the same prop type definition across multiple components, which TypeScript feature should you use?

   1. statement
   2. interface
   3. tuple
   4. enum

   Explanation: The interface construct in TypeScript is designed to define the shape of objects and can be reused by multiple components for consistent props typing. Option 'enum' is used for defining named constants, not object shapes. A tuple is used for fixed-length arrays with defined types, which does not suit prop objects. 'Statement' is not a relevant TypeScript feature for reusable type definitions.

4. Default Props with TypeScript

   In TypeScript, how should you specify default values for props in a functional React component while maintaining strong typing?

   1. By declaring the prop as required in the type
   2. By omitting the prop from the type definition
   3. By using the State generic instead of Props
   4. By setting default values in the function parameter destructuring

   Explanation: Providing default values during parameter destructuring allows props to remain strongly typed and ensures missing values fall back to defaults. Declaring a prop as required means the caller must supply it, so defaults would be ignored. Omitting the prop excludes it from the API, not supporting a default. Using the State generic is unrelated to how props and their defaults are handled in TypeScript.

5. Type Inference with useState

   What happens if you call useState([]) in TypeScript without an explicit type argument, and why might this be a problem when storing user objects?

   1. The state is always implicitly any[], so there is no type safety.
   2. The state will be typed as object[], allowing any value.
   3. The state will be typed as never[], so pushing user objects will fail.
   4. The state will only accept numbers by default.

   Explanation: If useState is initialized with an empty array and no type is specified, TypeScript infers its type as never[], which means you cannot add items to the array as it does not accept any type. Option two suggests object[], but TypeScript does not infer this without a value. The third option incorrectly claims the array will be any[], which reduces type safety. The fourth option falsely suggests default acceptance of numbers, which is not the case in this context.