Building an Enterprise Corporate Catalog with React, TypeScript, Fluent UI, and Vite

Introduction

As React applications evolve from simple demonstrations into enterprise-grade systems, one recurring requirement appears across almost every organization: a centralized catalog.

A corporate catalog can represent many different business concepts:

  • Products
  • Services
  • Software licenses
  • Hardware assets
  • Corporate subscriptions
  • Consulting offerings
  • Internal service requests
  • Procurement inventories

In large organizations, employees need a single place to discover, search, and review available resources. This is why enterprise platforms such as Microsoft 365, SharePoint portals, ERP systems, procurement platforms, and service management applications frequently include catalog-style interfaces.

App 94 — Corporate Catalog represents an important milestone in the ReactLab journey because it combines many concepts introduced throughout the previous applications into a realistic business scenario.

This application demonstrates how modern React architecture can be used to create a scalable, maintainable, and professional catalog management experience using:

  • React
  • TypeScript
  • Fluent UI
  • Vite
  • Component composition
  • Service layers
  • Derived state
  • Search functionality
  • Dashboard summaries
  • Enterprise UI patterns

The application follows the React philosophy that the user interface should be derived from state and data rather than manually manipulating the DOM.


Business Scenario

Imagine a company that offers dozens or hundreds of internal services.

Examples include:

ServiceDepartment
Microsoft 365 LicenseIT
Laptop RequestInfrastructure
SharePoint ConsultingConsulting
Power BI Dashboard DevelopmentBusiness Intelligence
Security AssessmentCybersecurity
Cloud MigrationCloud Services

Instead of managing these offerings through spreadsheets, the organization wants a searchable corporate catalog.

Users should be able to:

  • Browse catalog items
  • Search by name
  • View categories
  • Review ownership information
  • Verify availability
  • See summary statistics

This is the problem solved by App 94.


Architecture Overview

The application follows a layered architecture:

App
├── Dashboard
├── Filters
├── Catalog Grid
Service Layer
Mock Data
TypeScript Models

Each layer has a specific responsibility.

This separation makes the application easier to maintain and expand.

Future enhancements might include:

  • REST APIs
  • Authentication
  • Pagination
  • DataGrid integration
  • Reservation workflows
  • CRUD operations
  • SharePoint integration

The architecture is already prepared for that evolution.


Why TypeScript Matters

The catalog uses a strongly typed model.

export interface CatalogItem {
id: number;
name: string;
category: string;
owner: string;
price: number;
status: "Available" | "Retired";
}

This interface defines the shape of every catalog item.

Benefits include:

  • Compile-time validation
  • Better IntelliSense
  • Safer refactoring
  • Self-documenting code
  • Reduced runtime errors

Without TypeScript, it would be easy to accidentally introduce invalid properties or inconsistent structures.

In enterprise systems, strong typing becomes increasingly important as applications grow.


Data-Driven UI

One of the most important React principles demonstrated in this application is:

UI = Function(Data)

The catalog interface is generated from data rather than hardcoded markup.

Instead of creating individual cards manually, the application loops through catalog items and renders them dynamically.

This approach provides:

  • Scalability
  • Maintainability
  • Reusability
  • Consistency

If tomorrow the catalog grows from 3 items to 3,000 items, the rendering approach remains exactly the same.

Only the data changes.


Service Layer Pattern

The application introduces a simple service layer:

export function getCatalogItems() {
return catalogData;
}

At first glance this may appear unnecessary because the data is local.

However, architecturally it is extremely valuable.

Why?

Because future changes become easier.

Today:

Service
→ Local Mock Data

Tomorrow:

Service
→ REST API

Or:

Service
→ Microsoft Graph

Or:

Service
→ SharePoint List

The UI components remain unchanged because they communicate only with the service layer.

This is a common enterprise architecture pattern.


Search Functionality

The search experience is implemented through React state.

const [search, setSearch] = useState("");

This state stores the current search text.

Whenever the user types into the Fluent UI Input component:

<Input
value={search}
onChange={(_, data) =>
setSearch(data.value)
}
/>

React automatically updates the state.

The interface then re-renders using the new value.

No DOM manipulation is required.


Derived State

One of the most important React concepts demonstrated in App 94 is derived state.

Instead of storing filtered results separately, the application calculates them:

const filteredCatalog = useMemo(() => {
return catalog.filter((item) =>
item.name
.toLowerCase()
.includes(search.toLowerCase())
);
}, [catalog, search]);

This follows React’s recommendation:

Do not store redundant state.

The filtered list can always be derived from:

  • Original catalog
  • Search text

Therefore it does not need its own state.

Benefits:

  • Less complexity
  • Fewer bugs
  • Easier maintenance
  • Better React architecture

Why useMemo Is Important

The application uses:

useMemo()

This hook allows React to cache calculated values.

In a small catalog the difference is minimal.

However, imagine:

5,000 catalog items
10,000 catalog items
50,000 catalog items

Filtering could become expensive.

useMemo ensures React only recalculates when necessary.

This introduces an important performance optimization pattern used in enterprise applications.


Dashboard Cards

The dashboard component displays summary information:

  • Total catalog items
  • Available items

These metrics are examples of derived business information.

The dashboard transforms raw data into useful insights.

This pattern appears everywhere in enterprise software:

  • Executive dashboards
  • Power BI reports
  • SharePoint portals
  • Management systems

Users often care more about summarized information than raw records.

The dashboard provides immediate visibility into catalog status.


Fluent UI Integration

The application uses Fluent UI as the visual framework.

Why Fluent UI?

Because it provides:

  • Accessibility
  • Microsoft styling
  • Consistent design language
  • Keyboard navigation
  • Enterprise appearance
  • Professional component library

Instead of manually building every control, Fluent UI provides production-ready components.

Examples used in this application include:

  • Card
  • Input
  • Badge
  • Text
  • Title

These components automatically follow Microsoft design guidelines.


Component Composition

The application is intentionally divided into multiple components:

CatalogDashboard
CatalogFilters
CatalogGrid

Each component has one responsibility.

This follows React’s philosophy of composition.

Rather than creating a giant App.tsx file, the interface is broken into reusable building blocks.

Benefits include:

  • Easier maintenance
  • Better readability
  • Improved testing
  • Reusability
  • Scalability

This becomes increasingly important in larger applications.


Enterprise Design Considerations

Several enterprise design principles are demonstrated:

Clear Separation of Concerns

UI components do not fetch data directly.

They receive data through props.

Predictable Data Flow

Data flows downward:

App
→ Components

This makes debugging easier.

Reusable Components

The dashboard, filters, and grid could be reused elsewhere.

Future Expandability

The architecture can evolve toward:

  • CRUD systems
  • Reservation systems
  • ERP modules
  • SharePoint integrations
  • Microsoft Graph APIs

without major restructuring.


React Mental Model Reinforced

App 94 reinforces one of the most important React concepts:

State changes
→ React re-renders
→ UI updates

There is no direct DOM manipulation.

Instead:

User types
→ State updates
→ Filter recalculates
→ Grid re-renders

This declarative approach is what makes React applications predictable and maintainable.


Technical Summary

ConceptPurpose
ReactComponent-based UI
TypeScriptStrong typing
Fluent UIMicrosoft design system
ViteDevelopment tooling
Service LayerData abstraction
useStateSearch state
useMemoPerformance optimization
Derived StateFiltered catalog
Component CompositionReusable architecture
Dashboard CardsBusiness metrics
Search FilteringUser interaction
Catalog GridData presentation

What We Learned

By completing App 94, we learned how to:

  • Build a realistic enterprise catalog
  • Separate data, services, and UI
  • Implement search functionality
  • Use derived state correctly
  • Apply useMemo for optimization
  • Structure React applications professionally
  • Use Fluent UI enterprise components
  • Follow React architectural best practices

Most importantly, we reinforced the React principle that interfaces should be derived from data and state rather than manipulated manually.

This same pattern will be reused in reservation systems, CRM applications, ERP modules, administrative portals, analytics dashboards, and the final enterprise applications that conclude the ReactLab journey.

The Corporate Catalog serves as an excellent example of how modern React architecture scales from simple examples into real business solutions.

Technical References

Current Progress

BlockAppNameStatus
Block 591Report GeneratorCompleted
Block 592Audit SystemCompleted
Block 593SharePoint Inspired PortalCompleted
Block 594Corporate CatalogCompleted
Block 595Reservation SystemNext

Current App: 94 — Corporate Catalog
Next App: 95 — Reservation System
Progress: 94 / 100 Apps Completed 🚀

Edvaldo Guimrães Filho Avatar

Published by