Unit 6 - Practice Quiz

TypeScript's core feature is its static type system, which helps developers catch errors during development (e.g., passing a string to a function that expects a number) before the code is ever run.

The interface keyword is a fundamental part of TypeScript used to define a 'contract' or a shape that an object must adhere to, ensuring type safety for complex data structures.

The [] syntax following a type name is used to denote an array of that type. Therefore, string[] represents an array of strings.

The question mark (?) is used to mark a property in an interface or type as optional, meaning an object of that type does not need to have that property defined.

The | symbol creates a 'union type', which means the value can be one of the specified types. User | null correctly indicates that the value can be a User object or it can be null.

Standard TypeScript files use the .ts extension. The TypeScript compiler then transpiles these files into standard JavaScript (.js) files.

The tsconfig.json file is placed in the root of a TypeScript project and specifies compiler options and files that should be included in the compilation process.

When using JSX syntax within a TypeScript file, the .tsx extension is required so the compiler knows to process both the TypeScript and JSX syntax correctly.

Linters are static analysis tools that scan code to identify programmatic errors, bugs, stylistic errors, and suspicious constructs, helping to maintain code quality and consistency.

The 'static' part means the code is analyzed in a non-running state. This is different from dynamic analysis, which involves testing the code during its execution.

Prettier is an opinionated code formatter. It enforces a consistent code style by parsing your code and re-printing it with its own rules, taking the manual effort out of formatting.

Modern browsers come with a built-in set of web developer tools that allow developers to inspect the DOM, check network requests, and debug JavaScript code using features like the console and breakpoints.

A breakpoint is a tool that allows a developer to pause the execution of their code at a specific line, enabling them to inspect the state of variables and the call stack at that moment.

Unit testing is a testing method where individual units or components of a software are tested. The purpose is to validate that each unit of the software code performs as expected.

Jest is a widely-used, full-featured testing framework that is particularly popular in the React and TypeScript ecosystems for its simplicity and powerful features like mocking and code coverage.

An assertion is a check that verifies if a condition is true. If the condition is true, the test passes; if it's false, the test fails. It is the core of any test case.

The 'Don't Repeat Yourself' (DRY) principle is aimed at reducing the repetition of code. Instead of duplicating logic, it should be abstracted into a reusable function or component to improve maintainability.

Refactoring focuses on improving non-functional aspects of the code, such as readability, complexity, and maintainability. The key is that the code's functionality from an external perspective remains unchanged.

Using descriptive names for variables (e.g., userAge instead of x) makes the code's purpose easier to understand for other developers (and your future self), reducing the need for excessive comments.

By defining the shape of the expected API data, TypeScript can provide valuable developer assistance like autocompletion and will raise an error if you try to access a property that doesn't exist on the type, preventing runtime bugs.

Interfaces in TypeScript support 'declaration merging', which allows you to extend an interface by declaring it again with the new properties. This is ideal for creating extensible base models. type aliases, on the other hand, do not support declaration merging and cannot be augmented after they are created.

Both utility types can correctly create the UserPreview type. Pick<User, 'id' | 'name'> directly selects the specified properties. Omit<User, 'email' | 'createdAt'> achieves the same result by removing the other properties. In this scenario, both are valid and effective solutions.

A discriminated union works because there is a common property (the 'discriminant'), in this case, status, which has a distinct literal type for each variant in the union. This allows TypeScript's control flow analysis to narrow down the exact type within a conditional block (like if or switch), providing type safety for accessing other properties like data or error.

Using React.ComponentProps<'button'> is the standard and most maintainable way to get all the valid props for a native <button> element. By intersecting it (&) with a custom type containing the variant prop, you create a new type that includes both your custom props and all the native HTML attributes, without having to list them manually.

This signature correctly uses a generic type parameter <T>. The caller specifies the expected data type, e.g., fetchData<User>('/api/user'). The function then returns a Promise<T>, ensuring that when the promise resolves, the resulting data is correctly typed as User. The other options are incorrect: Promise<any> loses type safety, passing a type as an argument is not valid syntax, and returning T directly is wrong for an async function which always returns a Promise.

Setting "strict": true in tsconfig.json is a master switch that enables a collection of strict type-checking options. This includes noImplicitAny, strictNullChecks, strictFunctionTypes, strictBindCallApply, strictPropertyInitialization, and noImplicitThis. It is the recommended approach for starting new projects to ensure maximum type safety.

The TypeScript compiler (tsc) is primarily concerned with type correctness and transpilation. A linter like ESLint focuses on code quality and consistency. It catches issues like unused variables, inconsistent formatting, use of 'magic numbers', and enforces best practices that are not strictly type errors but can lead to bugs or unmaintainable code.

Source maps are a crucial debugging tool. They create a connection between the transpiled/minified code that the browser runs and the original source files you wrote. This allows the browser's developer tools to display and let you interact with your readable TypeScript code, greatly simplifying the debugging process.

The goal of a unit test is to test a single 'unit' (like a component) in isolation. By mocking the API call, you replace the actual network request with a predictable, fake implementation. This makes the test fast, reliable, and repeatable, as it won't fail due to network issues or changes in the real API data. It allows you to focus solely on how the component behaves with specific data (success, error, etc.).

The satisfies operator provides a way to check an object against a type without 'widening' its type. If you used : Theme, TypeScript would 'forget' about the spacing property. If you used as Theme, you'd lose type safety. satisfies confirms that myTheme meets the Theme contract (it has colors) but lets TypeScript remember the full, specific shape of the object, so you can still access myTheme.spacing without error.

The DefinitelyTyped project is a massive repository of high-quality type definitions for JavaScript libraries. The standard first step is to check if a types package exists by running npm install @types/some-js-library. If one exists, installing it will provide all the necessary types for TypeScript. Creating a custom declaration file is a fallback if no @types package is available.

ESLint's job is to analyze code structure (the Abstract Syntax Tree, or AST). Its default parser, Espree, is designed for JavaScript. TypeScript introduces new syntax that Espree doesn't recognize. @typescript-eslint/parser is a special parser that can create an ESLint-compatible AST from TypeScript code, allowing ESLint's rules to be applied to it.

This is the most accurate and comprehensive type. The ? makes the property optional (it might not exist in the object). The number | null union type specifies that if the property does exist, its value can be either a number or null. This covers all possible valid states for the discount field.

By applying your application's types to your mock data (const mockUser: User = { ... };), TypeScript will immediately flag any discrepancies at compile time. This prevents you from writing tests with mock data that is inconsistent with what the real application expects, making your tests more robust and reliable.

strictNullChecks makes null and undefined distinct types that are not assignable to other types like string or object by default. If a variable could be User | undefined, TypeScript will not let you access user.name until you've checked that user is not undefined (e.g., with an if (user) { ... }). This shifts the error from a runtime surprise to a compile-time check.

The Single Responsibility Principle states that a component or module should have only one reason to change. By creating a custom hook for data fetching (useUserData), you separate the concern of 'how' to get the data from the concern of 'what' to display. The component becomes a pure presentational component, and the hook becomes a reusable piece of logic, improving modularity and maintainability.

This scenario involves testing the interaction and data flow between multiple components (login form, modal, nav bar). A unit test would focus on just one of these components in isolation. An integration test is specifically designed to verify that different parts of the application work together as expected, which is exactly what is required here.

React.ChangeEvent is the specific type for onChange events in React. By providing HTMLInputElement as the generic argument, you are telling TypeScript that this event originates from an input element. This correctly types event.target as an HTMLInputElement, giving you safe access to its value property.

Vite prioritizes development speed. It leverages extremely fast transpilers like esbuild, which handle the syntax conversion from TS to JS almost instantly. Crucially, Vite's dev server delegates type-checking to your IDE and a separate build process (like tsc --noEmit), focusing only on transpilation to serve code to the browser as quickly as possible.

An index signature is the correct way to type an object with arbitrary keys. The Record<string, number> utility type is a clean way of writing { [key: string]: number; }. This tells TypeScript that any string can be used as a key for this object, and the corresponding value must be a number, which perfectly fits the requirement for a dictionary-like object.

This question tests understanding of advanced utility types, specifically conditional types (extends ? :), the infer keyword, and the built-in ReturnType<T> utility.

1. ReturnType<Func> evaluates to the return type of Func, which is Promise<{ user: string }>.
2. The UnpackPromise<T> type is then applied with T as Promise<{ user: string }>.
3. The conditional type T extends Promise<infer U> checks if T is a Promise. It is.
4. The infer U keyword captures the type wrapped by the Promise, so U becomes { user: string }.
5. The conditional type then resolves to U, which is { user: string }. Therefore, Result is { user: string }.

This question tests deep understanding of typing HOCs in React with TypeScript. The correct option is the most robust.

• Option A incorrectly types the returned component's props. It should return a component that accepts the original props, not props that already include the injected ones. It also requires the passed component to already expect the injected props, which is backward.
• Option B is close, but the generic constraint P is not constrained to include InjectedProps. This means the WrappedComponent isn't guaranteed to accept the data prop that the HOC will pass to it, leading to a type error inside the HOC.
• Option C is correct. It uses a generic P to represent the props of the WrappedComponent. The constraint P extends InjectedProps ensures that the WrappedComponent can accept the props the HOC will inject. The returned component's props are typed as Omit<P, keyof InjectedProps>, which correctly represents the original props of the WrappedComponent minus the ones that will be injected by the HOC. This is the standard, type-safe pattern for HOCs that inject props.
• Option D uses any and therefore loses all type safety for the props, defeating the purpose of using TypeScript.

This question assesses knowledge of advanced mapped types, including key remapping with the as clause and template literal types.

1. The mapped type iterates over E in keyof Events, where E will be 'login' and then 'logout'.
2. The as \on${Capitalize<E>}`clause remaps the key.Capitalize<E>` is a built-in utility type that capitalizes the first letter of the string.
   • For E = 'login', the new key is onLogin.
   • For E = 'logout', the new key is onLogout.
3. The value for each key is (payload: Events[E]) => void.
   • For the key onLogin, the value type is (payload: Events['login']) => void, which is (payload: { userId: string }) => void.
   • For the key onLogout, the value type is (payload: Events['logout']) => void, which is (payload: { reason: string }) => void.
     Combining these results gives the correct structure.

TypeScript's project references feature requires that any referenced project must have the "composite": true setting in its compilerOptions. This setting enforces certain other options (like declaration) and enables incremental builds, allowing TypeScript to quickly determine if a dependent project needs to be rebuilt. Without "composite": true in packages/shared-logic/tsconfig.json, the build system will not properly track its dependencies and updates, leading to the observed behavior where changes are not propagated.

A user-defined type guard has two responsibilities: 1) return a correct boolean value at runtime, and 2) correctly signal type narrowing to the TypeScript compiler. The correct option is the only one that tests both aspects.

• The runtime part is tested with expect(isUser(obj)).toBe(true).
• The compile-time part is tested implicitly. By placing obj.name.toUpperCase() (or a similar property access) inside the if block, you are leveraging the type guard. If the signature obj is User were incorrect (e.g., boolean), this line would cause a compilation error in your test file, effectively making your test suite a check on the type guard's definition itself. The other options only test the runtime behavior.

The Liskov Substitution Principle states that objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program. The key violation here is that the Square subclass strengthens the postconditions of the setWidth and setHeight methods. A user of a Rectangle object expects that calling setWidth(10) will not change the height. However, if that Rectangle object is actually a Square instance, setWidth(10) also changes the height to 10. This unexpected side-effect breaks the contract of the Rectangle class and violates the LSP. A function that works correctly with a Rectangle instance might fail with a Square instance, for example:

typescript
function g(rect: Rectangle) {
rect.setWidth(5);
rect.setHeight(4);
console.assert(rect.getArea() === 20); // This assertion fails for Square!
}

The void operator evaluates the given expression and then returns undefined. In the context of typescript-eslint, using void is the recommended, idiomatic way to explicitly mark a promise as intentionally not being awaited. It signals to both the linter and other developers that this is a deliberate "fire-and-forget" operation. While other options work, they are considered less ideal:

• Disabling the rule is heavy-handed for a single case.
• An async IIFE adds unnecessary complexity and overhead.
• Assigning to _ can be confusing and might be flagged by no-unused-vars rules if not configured properly.

While all options could potentially cause issues, the most common and difficult-to-diagnose reason for source map misalignment in highly optimized builds is the optimization process itself. Minifiers and bundlers perform complex transformations like function inlining, dead code elimination, and code hoisting. These can sometimes break the linear mapping between the original source and the generated code, causing the source map to be slightly inaccurate. This is a known trade-off between performance optimization and debuggability. A common solution is to use less aggressive optimization settings (e.g., devtool: 'source-map' instead of 'eval-source-map') for staging or debugging builds.

This is a subtle but important aspect of TypeScript's control flow analysis. Inside the first if (state.status === 'success') block, the type of state is correctly narrowed to { status: 'success', data: T }. However, once that block is exited, TypeScript's analysis 'resets' the type of state back to the full union ApiState<T>. It does not carry the narrowed type information into the second, separate if block. To fix this, the logic must be nested or combined. For example, by returning from within the first if block, or by using an if/else if/else structure, the compiler can correctly trace the control flow and maintain the narrowed type.

Express's type definitions are structured within a global Express namespace. To extend interfaces within a global namespace, you must re-open that same namespace in a declaration file (.d.ts) that is included in your project's compilation (e.g., via tsconfig.json's include array). The correct syntax is to declare the namespace and then export the interface with the additional properties. This merges your declaration with the original one from @types/express. Using declare module 'express-serve-static-core' is another modern approach, but augmenting the global Express namespace is the classic and still widely supported method specifically for Express.

This question addresses the core concept of type erasure in TypeScript. Generic type parameters like T exist only at compile time for static analysis. They are completely erased when the code is transpiled to JavaScript. Therefore, at runtime, the expression instance instanceof T is invalid because T doesn't exist as a value. The idiomatic solution is to pass the actual constructor function (which does exist at runtime) as an argument and use that for the check.

Corrected implementation:
typescript
function createAndValidate<T>(
ctor: new (...args: any[]) => T,
data: any
): T | null {
const instance = new ctor(data);
if (instance instanceof ctor) {
return instance;
}
return null;
}

This question tests recursive mapped types and conditional types. The DeepReadonly<T> type does the following:

1. It maps over each property P of T and makes it readonly.
2. It uses a conditional type to check the property's type T[P].
3. If T[P] is a Function, it leaves it as is. This is a common pattern as making a function 'readonly' doesn't change its callable nature, just its reassignability, which is already handled by the top-level readonly on the property.
4. If T[P] is an object (but not a function, due to the first check), it recursively calls DeepReadonly<T[P]>. This is what makes the readonly property cascade down into user and address.
5. If it's neither a function nor an object (i.e., a primitive), it just returns the type.
   Therefore, id, user, user.name, user.address, user.address.street, and the getData property itself all become readonly.

When jest.mock('./service') is used, Jest replaces the ApiService class with a mock constructor. Instances created from this mock constructor will have all their methods replaced with mock functions (jest.fn()). To correctly type this, we need Jest's utility type jest.Mocked<T>. However, ApiService refers to the instance type, not the class (constructor) itself. We need to mock the constructor and its static methods, so we use typeof ApiService. jest.Mocked<typeof ApiService> recursively traverses the properties of the class constructor and its prototype, converting any function properties into jest.Mock types. This allows type-safe access to mock-specific properties like .mockResolvedValue() on (new MockedApiService()).fetchData.

This is a classic problem when applying generics to union types. The constraint K extends keyof T means that K must be a key that exists on type T. When T is a union type like User | Product, keyof T resolves to the intersection of the keys of its members, which is never in this case (since User and Product share no common keys). The compiler errors because if model is a User, trying to access a key of 'price' would be a runtime error. Even though the key is asserted as keyof Model, the generic function getProperty(obj: T, key: K) can't resolve a safe return type because model[key] is an unsafe operation on a union type. The correct solution would involve a type guard to narrow model before access, or to redesign the function to handle this specific disjoint union case.

Rules that require type information (like most of the typescript-eslint "unsafe" rules) rely on the ESLint parser being able to find and parse your tsconfig.json to build the full program's type context. A common pitfall is this configuration mismatch. For example, your .eslintrc.js might be missing or have an incorrect parserOptions.project path:
javascript
module.exports = {
// ...
parserOptions: {
project: './tsconfig.json', // This line is crucial!
},
};

If this is missing, ESLint may not find the type information and will either fail or silently ignore type-aware rules. If it points to a different tsconfig.json (e.g., one with different include or compilerOptions), it will analyze the code with a different type context than tsc, leading to the observed discrepancy.

This is a complex recursive conditional type that requires precise handling of variadic tuple features. Let's break down the correct option:

1. F extends (arg: infer A, ...rest: infer R) => infer RT: This is the main check. It destructures the function F into its first argument A, the rest of its arguments R (as a tuple), and its return type RT.
2. ? R extends []: If the rest of the arguments R is an empty array, it means this was the last argument.
3. ? (arg: A) => RT: In the base case (last argument), it returns a simple function from that argument to the final return type.
4. : (arg: A) => Curry<(...args: R) => RT>: If there are more arguments, it returns a function that takes the first argument A and returns the result of recursively calling Curry on a new function type constructed from the remaining arguments R and the original return type RT.
5. The other options are incorrect: B is not valid syntax/logic for this problem, C is a close but slightly less robust variation, and D is too simplistic, only handling the very first argument and ignoring the rest.

This advanced pattern relies heavily on TypeScript generics and React's built-in utility types. The key is React.ComponentPropsWithoutRef<C>.

• C extends React.ElementType makes C a generic that can represent any valid component type (like a function component, a class component, or a string tag name like 'div').
• When you render <Box as="a" ...>, C is inferred to be the literal type 'a'.
• React.ComponentPropsWithoutRef<'a'> then resolves to the type of all valid HTML attributes for an anchor tag (<a>), including href, target, etc.
• By intersecting this (&) with the Box's own props ({ as, children }), the component's final props type correctly includes the attributes of the element it's meant to render as. This provides powerful, type-safe autocompletion and error checking for polymorphic components.

This question gets at a subtle but powerful distinction between enums and string literal unions derived from objects. TypeScript's type system is primarily structural, but enum is one of the few features that provides nominal typing. When you define enum UserRole, you create a new type named UserRole. A variable of this type is not assignable from a primitive string, even if the string's value matches an enum member. This prevents accidental misuse. In contrast, UserRoleObjType resolves to 'ADMIN' | 'EDITOR'. A function expecting this type would happily accept the raw string 'ADMIN', providing less type safety and making the code more brittle to refactoring. This nominal characteristic of enums is a key reason for their use in scenarios demanding strict type identity.

This is a significant and often surprising limitation when using JSDoc for JS type-checking. TypeScript interfaces do not have a runtime presence and are purely a compile-time construct. The JSDoc comment system, which is analyzed by TypeScript, cannot resolve a reference to a construct that doesn't exist in the generated JavaScript. Therefore, import('./types').User fails to resolve because User is an interface. To fix this, you would need to change User in types.ts to something that has a more concrete definition, like a type alias or a class.

typescript
// types.ts (Corrected)
export type User = { name: string; };
// OR
// export class User { name: string; constructor() { /.../ } }

For a generic utility function, its primary value is not just its runtime behavior but also its type-level transformations. While runtime tests are essential (Option B), they only verify the logic for the specific inputs you provide; they don't prove that the generic types are correctly inferred for all possible inputs. Tools like tsd or in-test utilities like expect-type allow you to write assertions that are checked by the TypeScript compiler itself.

For example:
typescript
import { expectTypeOf } from 'expect-type';

const users = [{ name: 'Alice', age: 30 }];
expectTypeOf(pluck(users, 'name')).toEqualTypeOf<string[]>();
expectTypeOf(pluck(users, 'age')).toEqualTypeOf<number[]>();

This approach directly tests the type signature's correctness, which is the hardest part to get right in a generic function. A test suite that combines this with traditional runtime assertions is the most robust.