React.js and Angular Architecture

Introduction

Modern frontend applications are not merely collections of HTML pages. They are software systems that manage state, user interaction, navigation, data access, rendering, testing, and deployment. A frontend architecture defines how these responsibilities are divided and how the resulting parts communicate.

React.js and Angular are two influential approaches to frontend development. React is primarily a user-interface library whose surrounding ecosystem is selected and assembled by the development team. Angular is an integrated framework that provides an opinionated structure and a broad set of official tools. Both support component-based development, but they differ in syntax, application organization, dependency management, rendering models, and development philosophy.

Understanding these differences is important because framework choice affects team skills, maintainability, testing, performance, onboarding, and long-term technical governance. This chapter compares the two architectures while explaining the fundamental concepts needed to design applications with either technology.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Explain the architectural relationship between React and its ecosystem and Angular as an integrated framework.
2. Describe components, JSX, Angular templates, modules, metadata, and dependency injection.
3. Compare React rendering and change-management mechanisms with Angular change detection.
4. Organize a small application using professional structural principles.
5. Select an appropriate architectural approach for a practical project.
6. Identify maintainability, performance, security, accessibility, and governance concerns.

1. Architectural Foundations

1.1 What frontend architecture means

Frontend architecture is the set of structural decisions that determine:

• how the user interface is divided into components;
• where application state is stored;
• how data moves between parts of the application;
• how services communicate with APIs and other external systems;
• how navigation and security are handled;
• how the application is tested, built, deployed, and maintained.

A useful architecture separates concerns without creating unnecessary complexity. Presentation code should render information and collect user interaction. Domain logic should represent business rules. Infrastructure code should manage HTTP requests, persistence, authentication, and external services. These concerns may be implemented differently in React and Angular, but the architectural goal is similar: make change predictable and defects easier to isolate.

1.2 React as a library-based ecosystem

React is a JavaScript library focused principally on describing user interfaces through components. It does not prescribe one official solution for routing, global state, forms, HTTP communication, or application-wide dependency injection. Teams commonly combine React with tools such as React Router, a state-management library, a data-fetching library, a testing framework, and a build tool.

This flexibility is a strength when a team can evaluate alternatives carefully. It allows gradual adoption and can support small, highly focused applications. However, it also creates architectural decisions that Angular makes centrally. Two React applications can use very different patterns, which may increase onboarding and maintenance costs.

React applications commonly use:

• functional components;
• JSX for describing the interface;
• props for input data;
• state and hooks for local behavior;
• context or external stores for shared state;
• explicit imports and JavaScript or TypeScript modules;
• a separately selected router and data-access strategy.

1.3 Angular as an integrated framework

Angular is a TypeScript-based framework that provides an extensive application platform. It includes a component model, templates, routing, forms, HTTP services, dependency injection, testing conventions, command-line tooling, and build integration. Angular therefore supplies stronger defaults for application structure.

Angular is opinionated: it guides developers toward particular patterns. This can reduce architectural variation in large teams and make an application easier to navigate. The trade-off is that developers must learn more framework concepts and follow more formal conventions.

Modern Angular supports standalone components, which can reduce reliance on traditional NgModules. Nevertheless, modules remain important historically and conceptually because many existing Angular applications use them, and module-based design still appears in professional codebases.

1.4 High-level comparison

Neither approach is universally superior. The correct choice depends on application size, team experience, existing systems, delivery constraints, and the need for standardized tooling.

2. Components: The Primary Architectural Unit

A component combines a view with the behavior and data needed to operate that view. A well-designed component has a clear responsibility, a small public interface, and limited knowledge of unrelated application details.

A component can be understood through four elements:

1. Inputs: data supplied by a parent or another application boundary.
2. Internal state: information that changes during the component's lifetime.
3. Outputs or events: notifications that allow other parts of the application to respond.
4. Rendering description: JSX or a template that expresses the visible result.

2.1 React components

A React functional component is a function that receives a props object and returns a description of the interface.

function Greeting({ name }) {
  return <h2>Hello, {name}</h2>;
}

The expression <h2>Hello, {name}</h2> is JSX. It resembles HTML, but it is JavaScript syntax transformed by a compiler or build tool into calls that create React elements. JSX is not a string of HTML and should not be confused with a server-side template language.

State is commonly managed with hooks:

import { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

The useState hook supplies a state value and a function that requests an update. Calling the setter does not directly modify the displayed DOM node. Instead, React schedules another rendering process and updates the necessary parts of the interface.

React's rules of hooks are architectural constraints: hooks must be called at the top level of a component or custom hook, not conditionally or inside loops. These constraints allow React to associate hook state consistently with a component's execution order.

2.2 Angular components

An Angular component is commonly a TypeScript class associated with a template through the @Component decorator.

import { Component } from '@angular/core';

@Component({
  selector: 'app-greeting',
  template: `<h2>Hello, {{ name }}</h2>`
})
export class GreetingComponent {
  name = 'Amina';
}

The decorator is metadata. It tells Angular how the class participates in the framework: its selector, template, styles, and other configuration. The class contains state and behavior, while the template describes the view.

Angular input and output APIs allow parent-child communication. The exact APIs have evolved across Angular versions, so a project should follow the conventions of its installed version. Conceptually, an input receives data and an output emits an event. This is similar to React props and callback functions, although the syntax and framework mechanisms differ.

2.3 Component boundaries

Good component boundaries are based on responsibility rather than visual size alone. A ProductCard may display product information and emit a selection event. A ProductPage may coordinate data loading, filtering, and child components. A reusable Button should not know how a particular business process works.

Components should avoid excessive coupling. Passing a value from a parent to a direct child is usually clear. Passing data through many unrelated layers may indicate a need for context, a shared service, or an application store. However, global state should not be used merely to avoid designing clear component interfaces.

3. JSX and Angular Templates

3.1 JSX

JSX allows markup-like syntax to coexist with JavaScript expressions. JavaScript expressions are placed inside braces.

const title = <h1>{product.name}</h1>;

JSX supports conditional and repeated rendering through JavaScript constructs:

{items.length === 0 ? <p>No items found.</p> : (
  <ul>
    {items.map(item => <li key={item.id}>{item.name}</li>)}
  </ul>
)}

A stable key helps React identify items when a list changes. A key should represent the identity of the item, not merely its current array position when items can be inserted, removed, or reordered.

JSX also encourages explicit event handling and property assignment. For example, onClick receives a function, whereas ordinary HTML uses an attribute-like string. JSX is expressive, but placing large amounts of business logic directly inside markup can reduce readability. Complex decisions should be moved into named functions or derived values.

3.2 Angular templates

Angular templates use HTML-like syntax enriched with framework features. Interpolation displays a value:

<h1>{{ product.name }}</h1>

Property binding assigns a value to a DOM property or directive input:

<button [disabled]="isSaving">Save</button>

Event binding responds to an event:

<button (click)="save()">Save</button>

Two-way binding combines property and event behavior, commonly in forms:

<input [(ngModel)]="username">

Angular also provides structural control-flow mechanisms for conditional and repeated content. The syntax differs across Angular generations, so developers should use the syntax supported by the project version. The underlying principle remains the same: the template declares how data and control state determine the rendered view.

Angular templates are not unrestricted JavaScript documents. The framework template compiler applies rules intended to improve analysis, security, and performance. Business logic should generally remain in the component class or an injected service rather than being embedded in complicated template expressions.

3.3 Comparison of view declarations

React places markup expressions inside a programming language. This makes composition and conditional logic familiar to JavaScript developers, but it can allow presentation and computation to become tightly mixed.

Angular separates the template from the component class more visibly. This supports a clear division between view declaration and TypeScript behavior, but developers must learn Angular-specific binding and control-flow syntax.

Both approaches support reusable views, conditional rendering, list rendering, event handling, and component composition. In both, accessibility attributes, semantic HTML, keyboard operation, and appropriate focus behavior remain the developer's responsibility.

4. Modules, Metadata, and Dependency Injection

4.1 JavaScript and TypeScript modules in React

React applications use the module system of JavaScript or TypeScript. A file can export a component, function, type, or constant, and another file can import it.

export function formatCurrency(value) {
  return `$${value.toFixed(2)}`;
}

This module system organizes source code but does not itself define a complete dependency-injection container. Dependencies are normally imported directly, passed as props, provided through context, or managed by a third-party library.

Direct imports are simple and explicit. They can also make substitution difficult in testing when a module performs side effects or creates a concrete infrastructure object internally. A useful professional practice is to place API access behind small service functions or interfaces and inject configurable behavior through props, context, or a testing seam when needed.

4.2 Angular modules and standalone components

Traditional Angular applications use NgModules to group declarations, imports, providers, and exports. A module may define a feature boundary such as OrdersModule or ReportsModule.

A conceptual module configuration may contain:

• declarations: components, directives, and pipes belonging to the module;
• imports: other modules whose exported capabilities are needed;
• providers: services available through the injector;
• exports: declarations made available to importing modules.

Angular's standalone components allow a component to declare its own imports without being declared in an NgModule. This can make dependency relationships more local and reduce ceremonial configuration. Existing applications may combine standalone and module-based patterns during migration.

4.3 Metadata

Metadata is descriptive information that tells a framework how to interpret a class or configuration. In Angular, decorators such as @Component, @Injectable, and @Directive provide metadata. The Angular compiler uses this information to generate and connect framework behavior.

React does not normally require component decorators or equivalent metadata. A function becomes a React component primarily by being used in a component tree and returning a valid React element structure. Build tools still process imports, JSX, and TypeScript, but the programming model is less dependent on framework decorators.

4.4 Dependency injection

Dependency injection (DI) is a technique in which an object receives the services it needs from an external provider rather than constructing those services internally. DI improves substitutability, testability, and separation of concerns.

Angular has a built-in hierarchical injector. A service may be registered at an application-wide level or at a narrower component level. A simplified example is:

@Injectable({ providedIn: 'root' })
export class ProductService {
  constructor(private http: HttpClient) {}
}

A component can request the service through its constructor or through the injection APIs supported by the Angular version. Angular resolves the dependency and supplies an instance according to provider configuration.

The hierarchy matters. A service provided at the root is generally shared application-wide, whereas a service provided at a component boundary may have a separate lifetime and state for each relevant component instance.

React commonly achieves a similar result using composition:

function ProductPage({ productService }) {
  // productService is supplied by the parent or test harness
}

Context can make a dependency available to descendants, but context is not automatically a complete DI system. The team must define conventions for scopes, defaults, replacement, and lifecycle. Libraries can provide more formal solutions.

5. Rendering and Change Detection

5.1 Rendering as a process

Rendering converts application state into a user-visible interface. A simplified model is:

application state → component evaluation → view representation → DOM updates

The browser then performs layout and painting. Efficient frameworks avoid unnecessary DOM work, but application performance also depends on network requests, JavaScript execution, CSS, images, accessibility features, and device limitations.

5.2 React rendering and reconciliation

When React renders a component, it evaluates the component and produces a tree of elements. React compares the new result with the previous result using its reconciliation process and commits the required changes to the host environment, commonly the browser DOM.

React's comparison is not a general mathematical proof of visual equality. It uses implementation rules, element types, keys, component identity, and other internal mechanisms. Developers should therefore avoid assuming that every render causes every DOM node to be recreated or that every render is free.

State updates may be batched, and rendering may be scheduled according to the version and execution context. A component should be written as a predictable function of its inputs and state. Side effects such as subscriptions, timers, and network operations should be managed with appropriate lifecycle mechanisms rather than executed unconditionally during rendering.

Memoization tools such as memo, useMemo, and useCallback can reduce selected work, but they introduce comparison and maintenance costs. They should be applied after identifying a genuine performance problem rather than used mechanically.

5.3 Angular change detection

Angular checks whether values used by a view have changed and updates the view when necessary. The traditional default strategy can check a broad component tree after relevant asynchronous activity. The OnPush strategy narrows when a component is checked, commonly relying on changed input references, events, explicit requests, or observable and signal mechanisms supported by the framework version.

Angular's change detection is not identical to React reconciliation. React evaluates components to produce a new element description and reconciles it. Angular evaluates bindings within its view system and updates the relevant rendered output. Both systems seek to keep the interface synchronized with state, but their scheduling and optimization rules differ.

Angular applications may use RxJS observables, signals, or other state patterns. Regardless of the mechanism, mutable shared state can make updates difficult to reason about. Immutable updates or carefully controlled state transitions generally improve predictability.

5.4 Performance principles

Performance decisions should be evidence-based. Useful practices include:

• keep component responsibilities focused;
• avoid unnecessary network requests;
• use stable identities for repeated lists;
• load large features lazily when appropriate;
• minimize expensive work during rendering or template evaluation;
• use production builds and appropriate code splitting;
• measure with browser and framework profiling tools;
• optimize images, fonts, and critical rendering paths;
• preserve accessibility while optimizing.

Server-side rendering and hybrid rendering can improve initial delivery and search-engine discoverability, but they add requirements for hydration, browser-only APIs, data consistency, and deployment configuration. They should be selected according to application needs rather than fashion.

6. Application Structure

A small application can begin with a feature-oriented structure:

src/
  app/
    app-shell/
    shared-ui/
    products/
      components/
      product-page/
      product.service.ts      or productApi.ts
      product.types.ts
    orders/
    core/
      authentication/
      error-handling/
      configuration/

The exact names differ between ecosystems. The architectural principle is to organize around features and stable responsibilities rather than placing every component in one large folder.

6.1 Presentation, application, and infrastructure

A useful separation has three conceptual levels:

• Presentation: components, templates, JSX, visual formatting, and user events.
• Application coordination: workflows such as loading a product, submitting an order, or changing a filter.
• Infrastructure and domain services: API clients, authentication adapters, validation rules, persistence, and business concepts.

This is not a rigid requirement that every feature contain three layers. Over-layering a small application creates needless indirection. The appropriate structure should match complexity and expected change.

6.2 Routing and feature boundaries

Routing maps a URL or navigation action to a view. Routes should be treated as application boundaries, not merely as a list of component names. A route may define authorization requirements, data loading, lazy loading, error handling, and page-level layout.

Angular provides an official router. React teams generally select a router library. In either ecosystem, route configuration should be readable and security-sensitive authorization must be enforced by the server as well as represented in the client. Hiding a button is not an authorization mechanism.

6.3 State ownership

State should be owned by the narrowest component or feature that needs to control it. Local form input state need not be global. Shared authenticated-user information may belong in an application-level service, context, or store. Server state, such as cached product data, has different requirements from transient UI state such as whether a dialog is open.

A common error is to place all data in a global store. This increases coupling, makes updates harder to trace, and may retain data longer than necessary. Another error is to duplicate the same state in several components, causing synchronization defects. State ownership should be explicit and documented.

7. Worked Application: Product Catalogue

Background

The following is an illustrative case. A training company wants a product catalogue that displays categories, supports search, shows loading and error states, and permits users to open a product detail page. The catalogue must be maintainable by several developers.

Problem

A first prototype places API requests, filtering logic, navigation, and display markup in one large component. As features are added, developers encounter duplicated requests, inconsistent loading indicators, and difficult tests.

Analysis

The system contains at least four responsibilities:

1. obtaining product data;
2. representing loading, success, and failure states;
3. applying search and category filters;
4. rendering cards and handling navigation.

The API client should not manipulate the DOM. The product card should not decide how authentication or HTTP retries work. The page-level feature should coordinate the workflow.

React approach

A React design might contain ProductPage, SearchControls, ProductGrid, and ProductCard. A productApi module performs HTTP operations. ProductPage owns query state and server-state coordination, while ProductGrid receives products and emits selection behavior through props.

function ProductGrid({ products, onSelect }) {
  return (
    <section aria-label="Products">
      {products.map(product => (
        <ProductCard
          key={product.id}
          product={product}
          onSelect={() => onSelect(product.id)}
        />
      ))}
    </section>
  );
}

A production implementation should also handle empty results, request cancellation or stale responses, accessible loading announcements, and errors that do not expose confidential server details.

Angular approach

An Angular design could contain ProductPageComponent, SearchControlsComponent, ProductGridComponent, and ProductCardComponent, supported by an injectable ProductService. The page component subscribes to or otherwise consumes product data according to the project's chosen Angular state pattern. Templates use bindings for values, events, and conditional states.

The service provides a testable boundary for HTTP operations. A route can lazy-load the catalogue feature, and an interceptor can apply authentication or standardized error handling where appropriate. Angular's DI system makes it straightforward to replace the service with a test double in unit tests.

Outcome

Both designs can produce the same user experience. The React version offers freedom in selecting data-fetching and routing tools. The Angular version supplies stronger official structure and DI conventions. In both cases, the important outcome is separation of responsibilities, clear state ownership, accessible interface behavior, and tests at the appropriate levels.

Learning points

• Component decomposition is useful only when boundaries reflect responsibilities.
• API access belongs behind a service or module boundary.
• Loading, empty, success, and error states are part of the design, not afterthoughts.
• Framework features do not replace architectural judgment.
• The server must enforce authorization even when the client hides controls.

8. Testing, Security, Accessibility, and Governance

Testing

Component tests should verify observable behavior: rendered content, user interaction, emitted events, and error states. They should avoid asserting framework internals or fragile implementation details. Service tests should verify request construction, response handling, and failure behavior. End-to-end tests should cover critical journeys such as sign-in, checkout, or submission.

React teams select testing tools and conventions. Angular provides strong testing integration and dependency replacement patterns, but developers must still decide which behaviors deserve tests. Excessive snapshot testing can produce large, low-value outputs; carefully selected behavioral assertions are often more useful.

Security

Frontend code is delivered to users and must be treated as observable and potentially modifiable. Never place secrets such as private API keys in client bundles. Validate and authorize actions on the server. Protect authentication tokens according to the security model, use secure transport, and understand cross-site scripting, cross-site request forgery, and content-security policies.

Both JSX and Angular templates provide mechanisms that reduce some classes of unsafe HTML insertion, but deliberately rendering untrusted HTML remains dangerous. Sanitization must be appropriate to the content and threat model; simply removing a few characters is not a complete security strategy.

Accessibility

Components should use semantic elements, labels, keyboard-accessible controls, visible focus indicators, suitable color contrast, and meaningful status announcements. Custom widgets require careful keyboard and assistive-technology behavior. Framework abstractions do not automatically make an interface accessible.

Governance and maintainability

In a professional team, architecture includes standards for dependency selection, version upgrades, code review, linting, security scanning, documentation, and deprecation. React's ecosystem requires explicit governance because many choices are external. Angular's integrated conventions reduce some variation but do not eliminate the need for review and dependency management.

9. Contemporary Developments and Limitations

Both ecosystems continue to evolve toward improved compilation, server rendering, partial hydration or hydration, fine-grained state updates, and better developer tooling. Angular's standalone APIs and signals represent a move toward more direct composition and targeted reactivity. React continues to develop scheduling, server-oriented capabilities, and ecosystem patterns for data loading and rendering.

Terminology and recommended APIs change. Developers should consult the documentation for the exact framework version used by a project, especially for routing, forms, lifecycle APIs, server rendering, and state management. A sound architectural principle should survive a version change even when a particular API does not.

React's principal limitations include ecosystem fragmentation, inconsistent conventions between projects, and the need to assemble a complete platform. Angular's limitations include a larger conceptual surface, more framework-specific rules, and possible overhead for very small interfaces. Both can produce poorly structured applications if developers create oversized components, duplicate state, ignore accessibility, or treat framework defaults as substitutes for design.

Best-Practice Checklist

Before approving a React or Angular feature, ask:

1. Does each component have a clear responsibility?
2. Are inputs, outputs, and state ownership explicit?
3. Is API and infrastructure code separated from presentation?
4. Are loading, empty, error, and success states designed?
5. Are list identities stable and rendering work reasonable?
6. Are authentication and authorization handled securely?
7. Can important behavior be tested without fragile implementation assertions?
8. Does the interface support keyboard and assistive-technology users?
9. Are dependencies and framework versions governed by the team?
10. Is the chosen architecture appropriate to the application's size and expected change?

Chapter Summary

React is a UI library that offers component composition and JSX while leaving many platform decisions to the development team. Angular is an integrated TypeScript framework with official solutions for templates, routing, forms, HTTP communication, dependency injection, and application tooling. React commonly uses explicit imports, props, hooks, context, and selected ecosystem libraries. Angular uses components, templates, metadata, services, injectors, and—historically—NgModules, while modern Angular also supports standalone components.

Both frameworks represent interfaces as the result of application state and user interaction. React uses rendering and reconciliation to determine host updates. Angular uses change detection and a view system to evaluate bindings and update rendered output. Performance depends on more than framework choice: state design, network behavior, list identity, code splitting, rendering work, and measurement all matter.

Professional architecture requires clear component boundaries, disciplined state ownership, service boundaries, testable code, secure server enforcement, accessible interfaces, and governance of dependencies. The most important comparison is therefore not simply library versus framework; it is the balance between flexibility and convention for a particular team and application.

Key Terms

Component: A cohesive unit combining interface rendering, state, and behavior.

React: A JavaScript library primarily concerned with building user interfaces.

Angular: An integrated TypeScript framework for building web applications.

JSX: JavaScript syntax that allows markup-like expressions in component code.

Template: A declarative view description associated with an Angular component.

Props: Input values supplied to a React component.

State: Data whose changes can affect rendered output or application behavior.

Hook: A React function-based API for using state and lifecycle-related capabilities.

Metadata: Configuration that tells Angular how to interpret a class or declaration.

Decorator: A syntax used in Angular to attach framework metadata to classes or members.

Module: A JavaScript or TypeScript file boundary; in Angular, also historically an NgModule grouping declarations and providers.

Dependency injection: Supplying an object's dependencies through an external mechanism.

Injector: Angular's mechanism for resolving and providing dependencies.

Change detection: The process of determining whether a view should reflect changed data.

Reconciliation: React's process for comparing rendered element descriptions and applying necessary host updates.

Routing: Mapping navigation state or URLs to application views and behavior.

Lazy loading: Loading a feature or resource only when it is needed.

Server state: Data obtained from and synchronized with a backend system.

Component boundary: A defined interface separating one component's responsibilities from another's.

Hydration: Connecting client-side behavior to markup that was initially rendered elsewhere, commonly on a server.

Review Questions

Short Answer Questions

1. Why is React described as a library-based ecosystem rather than an integrated framework?
2. What roles do JSX and Angular templates play in interface development?
3. Define dependency injection and state one benefit it provides.
4. What is the purpose of a stable key when rendering a list in React?
5. Why should authorization not be implemented only by hiding a client-side button?

Long Answer Questions

1. Compare React components and Angular components, including their inputs, state, event communication, and view declarations.
2. Explain how React reconciliation differs conceptually from Angular change detection.
3. Discuss the advantages and disadvantages of Angular's integrated framework model compared with React's ecosystem model.
4. Design a feature-oriented folder and responsibility structure for a medium-sized catalogue application.
5. Explain how accessibility, security, testing, and dependency governance influence frontend architecture.

Analytical / Application Questions

1. A team has five independent React applications with different routing, form, and state libraries. Analyze the maintenance risks and propose a governance strategy without eliminating all flexibility.
2. An Angular page checks a large component tree whenever a user types into a search field and becomes slow on low-powered devices. Identify possible causes and propose an evidence-based optimization plan.
3. For a product catalogue with authenticated users, server-side filtering, offline-friendly cached data, and a large development team, compare React and Angular and justify a recommendation using explicit criteria.

Multiple Choice Questions with Answers

Question 1

Which statement best characterizes React?

A. It is an integrated framework that mandates routing and forms

B. It is primarily a UI library supported by an ecosystem of additional tools

C. It is a database access framework

D. It is a browser replacement runtime

Correct Answer: B. It is primarily a UI library supported by an ecosystem of additional tools

Question 2

What does JSX provide in a React application?

A. A database schema language

B. A replacement for JavaScript modules

C. Markup-like syntax embedded in JavaScript or TypeScript

D. A server-side authorization protocol

Correct Answer: C. Markup-like syntax embedded in JavaScript or TypeScript

Question 3

In Angular, what is the primary purpose of component metadata?

A. To describe how Angular should interpret and configure a class

B. To encrypt component properties

C. To replace all TypeScript types

D. To create database indexes

Correct Answer: A. To describe how Angular should interpret and configure a class

Question 4

Which practice is an example of dependency injection?

A. A service constructs every dependency internally

B. A component receives a service from an injector or external provider

C. A template duplicates a service's source code

D. A browser downloads an image

Correct Answer: B. A component receives a service from an injector or external provider

Question 5

What is a principal purpose of a stable React list key?

A. To identify the user's password

B. To force every DOM node to be recreated

C. To help React associate rendered items with their identities across updates

D. To make an API request secure

Correct Answer: C. To help React associate rendered items with their identities across updates

Question 6

Which Angular feature historically groups declarations, imports, providers, and exports?

A. NgModule

B. JSX fragment

C. React hook

D. Browser cookie

Correct Answer: A. NgModule

Question 7

Which statement about frontend authorization is correct?

A. Hiding a button is sufficient authorization

B. Authorization should be enforced by the server as well as represented in the client

C. Authorization is unnecessary for internal applications

D. A component key enforces authorization

Correct Answer: B. Authorization should be enforced by the server as well as represented in the client

Question 8

What is generally the best reason to avoid putting all application state in a global store?

A. Global stores cannot contain strings

B. It can increase coupling and make state changes harder to trace

C. Global stores prevent any component from rendering

D. It disables browser networking

Correct Answer: B. It can increase coupling and make state changes harder to trace

Question 9

Which approach best supports maintainable feature architecture?

A. Place all logic in one page component

B. Separate responsibilities such as presentation, coordination, and infrastructure

C. Duplicate API calls in every visual component

D. Store secrets in client-side source files

Correct Answer: B. Separate responsibilities such as presentation, coordination, and infrastructure

Question 10

What is hydration generally concerned with?

A. Connecting client-side behavior to markup rendered initially elsewhere

B. Compressing database records

C. Changing a CSS color into a font

D. Deleting unused routes from a server

Correct Answer: A. Connecting client-side behavior to markup rendered initially elsewhere