@hichchi/nest-connector
v0.0.9
Published
Comprehensive NestJS connector library providing standardized HTTP responses, authentication interfaces, CRUD operations, and shared utilities for the Hichchi ecosystem
Readme
🔗 @hichchi/nest-connector
Description
Comprehensive NestJS connector library providing standardized HTTP responses, authentication interfaces, CRUD operations, and shared utilities for the Hichchi ecosystem
Part of the Hichchi ecosystem - A powerful, scalable application built with Nx workspace
📋 Table of Contents
📦 Installation
npm install @hichchi/nest-connector⚡ Quick Start
Get up and running with standardized API responses in just a few minutes:
// 1. Install the package
npm install @hichchi/nest-connector
// 2. Import response interfaces and builders
import {
HttpResponse,
SuccessResponse,
ErrorResponse,
SuccessResponseDto
} from '@hichchi/nest-connector';
// 3. Use in your NestJS controllers
@Controller('users')
export class UsersController {
@Get()
async getUsers(): Promise<SuccessResponse> {
const users = await this.usersService.findAll();
return new SuccessResponseDto(users, 'Users retrieved successfully');
}
}📋 Prerequisites
Before installing @hichchi/nest-connector, ensure you have:
Required Dependencies
- Node.js: ^20.0.0
- NestJS: ^11.0.0
- TypeScript: ~5.9.3
Peer Dependencies
npm install @nestjs/common @nestjs/core
npm install rxjs reflect-metadataInternal Dependencies
This package depends on:
npm install @hichchi/utilsOptional Dependencies
For enhanced features:
# For validation decorators
npm install class-validator class-transformer🌟 Overview
🎯 Your standardized response toolkit for NestJS applications. Ensure consistent API responses across your entire application with pre-defined interfaces, builders, and response structures that follow industry best practices.
✨ Features
🏗️ Ready-to-Use Response Structures
- 📋 HttpResponse Interface - Base interface for all API responses
- ✅ SuccessResponse Interface - Standardized success response structure
- ❌ ErrorResponse Interface - Consistent error response format
- 🔢 HTTP Status Enums - Pre-defined status code enumerations
🛠️ Response Builders & DTOs
- 🏭 SuccessResponseDto - Builder for success responses with data
- 🎯 Response Code Types - Application-specific response codes
- 📊 Status Code Management - Organized HTTP status code handling
- 🔧 Type-Safe Responses - Full TypeScript support for response structures
🔐 Authentication Interfaces
- 👤 Typed Auth User Interface - Generic
User<Role, Permission, Tenant>typing for role/permission/tenant-aware authentication flows - 🏢 Tenant Interface Support - Dedicated tenant interfaces with owner/member user relationships for multi-tenant domains
- 🧩 Composed Auth Models - Consistent
Role,User, andTenantinterface exports for shared contracts across services
🎨 Developer Experience
- 📝 Comprehensive Documentation - Detailed JSDoc comments for all interfaces
- 🔍 IntelliSense Support - Full IDE autocomplete and type checking
- 🎯 Consistent API Design - Standardized response patterns across applications
- 🚀 Easy Integration - Drop-in replacement for custom response handling
🔧 Advanced Features
- 🏷️ User Info Interfaces - Standardized user information structures
- 🔀 Clear Context Separation - Base
UserInfofor identity data, authUserinterface for tenant-aware authentication context - 📦 Modular Design - Import only what you need
- 🔄 Extensible Architecture - Easy to extend with custom response types
- 🎪 Framework Agnostic Types - Core interfaces can be used beyond NestJS
🔧 Development
Building the Library
nx build nest-connectorRunning Tests
nx test nest-connectorLinting
nx lint nest-connectorMade with ❤️ by Hichchi Dev
Standardizing API responses and connecting NestJS applications with consistent interfaces and shared utilities
📖 API Documentation
Complete technical reference for all classes, interfaces, methods, and types in this library.
Auto-generated by TypeDoc - Browse through detailed API references, code examples, and implementation guides below.
📋 API Table of Contents
Classes
SuccessResponseDto
Defined in: builders/success-response.dto.ts:55
Data Transfer Object for standardized success responses
This class provides a standardized way to create success response objects for API endpoints. It implements the SuccessResponse interface and ensures that all required properties are properly set with appropriate default values.
Key features:
- Flexible constructor that accepts either individual parameters or a complete response object
- Default values for all properties if not explicitly provided
- Type-safe response code handling with autocomplete support
- Consistent structure for all success responses across the application
The class is designed to be used in controllers and services to return standardized success responses to API clients.
Examples
// Creating a success response with custom message
@Post()
createUser(@Body() createUserDto: CreateUserDto): SuccessResponseDto {
this.userService.create(createUserDto);
return new SuccessResponseDto("User created successfully");
}// Creating a success response from an existing response object
@Get()
getUsers(): SuccessResponseDto {
const users = this.userService.findAll();
const response = {
statusCode: HttpSuccessStatus.OK,
code: "USERS_RETRIEVED",
message: "Users retrieved successfully",
data: users
};
return new SuccessResponseDto(response);
}See
- SuccessResponse The interface this class implements
- HttpSuccessStatus Enum of HTTP success status codes
- SuccessResponses Predefined success response templates
Implements
Constructors
Constructor
new SuccessResponseDto(
message?,
code?,
status?,
description?): SuccessResponseDto;Defined in: builders/success-response.dto.ts:118
Creates a new success response with individual parameters
This constructor overload allows creating a success response by specifying individual properties. Any properties not provided will use default values from SuccessResponses.SUCCESS.
Parameters
message?
string
Human-readable success message
code?
string
Unique code identifying the success type
status?
HTTP status code for the response
description?
string
Optional detailed description
Returns
Example
// Basic success response with just a message
const response = new SuccessResponseDto("Operation completed successfully");
// Success response with custom code and status
const response = new SuccessResponseDto(
"User created successfully",
"USER_CREATED",
HttpSuccessStatus.CREATED,
);Constructor
new SuccessResponseDto(response): SuccessResponseDto;Defined in: builders/success-response.dto.ts:140
Creates a new success response from an existing response object
This constructor overload allows creating a success response by providing an existing SuccessResponse object. Any properties not provided in the input object will use default values from SuccessResponses.SUCCESS.
Parameters
response
Existing success response object
Returns
Example
// Creating from an existing response object
const existingResponse = {
statusCode: HttpSuccessStatus.OK,
code: "DATA_RETRIEVED",
message: "Data retrieved successfully",
};
const response = new SuccessResponseDto(existingResponse);Properties
code
LooseAutocomplete<AuthSuccessResponseCode>
Unique code identifying the success response type
This property holds a string code that identifies the specific type of success. It uses LooseAutocomplete to provide type suggestions from AuthSuccessResponseCode while still allowing custom string values.
See
AuthSuccessResponseCode For predefined success codes
builders/success-response.dto.ts:75
description?
string
Optional detailed description of the success result
This property can contain additional information about the success result that might be useful for debugging or providing more context to developers.
builders/success-response.dto.ts:91
message
string
Human-readable success message
This property contains a user-friendly message describing the success result. It should be clear, concise, and suitable for displaying to end users.
builders/success-response.dto.ts:83
statusCode
HTTP status code for the success response
This property holds the HTTP status code that should be returned to the client. It uses the HttpSuccessStatus enum to ensure only valid success status codes are used.
See
HttpSuccessStatus For available status codes
builders/success-response.dto.ts:64
Enumerations
CommonErrorResponseCode
Defined in: enums/common-error-response-code.enum.ts:16
Common Error Response Codes Enum
This enum defines general-purpose error response codes that can be used across different services and modules in the application. Each code represents a specific error condition related to common operations such as data validation, resource access, and file operations.
The naming convention includes HTTP status codes (e.g., 400, 404, 500) for clarity, with the prefix "ERROR_" to distinguish them as error codes.
Enum Values are organized by HTTP status categories:
400series: Client errors (Bad Request, Unauthorized, Forbidden, Not Found)500series: Server errors (Internal Server Error)- Generic errors without specific status codes
Enumeration Members
ERROR
"ERROR"
Generic unspecified error
Most general error code for cases where the specific error type cannot be determined or doesn't fit into any other category.
enums/common-error-response-code.enum.ts:129
ERROR_400
"ERROR_400"
Generic bad request error (400 Bad Request)
Generic error for bad requests when a more specific error code is not applicable.
enums/common-error-response-code.enum.ts:93
ERROR_400_EMPTY_ID
"ERROR_400_EMPTY_ID"
Empty ID error (400 Bad Request)
Occurs when an ID field is required but not provided or is empty.
enums/common-error-response-code.enum.ts:22
ERROR_400_EMPTY_IDS
"ERROR_400_EMPTY_IDS"
Empty IDs array error (400 Bad Request)
Occurs when an array of IDs is required but not provided or is empty.
enums/common-error-response-code.enum.ts:29
ERROR_400_INVALID_ID
"ERROR_400_INVALID_ID"
Invalid ID format or value (400 Bad Request)
Occurs when an ID is provided but has an invalid format or value.
enums/common-error-response-code.enum.ts:36
ERROR_400_INVALID_IDS
"ERROR_400_INVALID_IDS"
Invalid IDs array (400 Bad Request)
Occurs when an array of IDs contains one or more invalid entries.
enums/common-error-response-code.enum.ts:43
ERROR_400_INVALID_UUID
"ERROR_400_INVALID_UUID"
Invalid UUID format (400 Bad Request)
Occurs when a provided UUID doesn't conform to the required format.
enums/common-error-response-code.enum.ts:50
ERROR_400_NOT_ID_ARRAY
"ERROR_400_NOT_ID_ARRAY"
Not an array of IDs (400 Bad Request)
Occurs when a parameter expected to be an array of IDs is of the wrong type.
enums/common-error-response-code.enum.ts:57
ERROR_401
"ERROR_401"
Generic unauthorized error (401 Unauthorized)
Generic error for unauthorized access when a more specific error code is not applicable.
enums/common-error-response-code.enum.ts:100
ERROR_403
"ERROR_403"
Generic forbidden error (403 Forbidden)
Generic error for forbidden access when a more specific error code is not applicable.
enums/common-error-response-code.enum.ts:107
ERROR_404
"ERROR_404"
Generic not found error (404 Not Found)
Generic error for resource not found when a more specific error code is not applicable.
enums/common-error-response-code.enum.ts:114
ERROR_404_FILE_NOT_EXIST
"ERROR_404_FILE_NOT_EXIST"
File not found (404 Not Found)
Occurs when attempting to access a file that doesn't exist.
enums/common-error-response-code.enum.ts:64
ERROR_404_NOT_IMPLEMENTED
"ERROR_404_NOT_IMPLEMENTED"
Feature not implemented (404 Not Found)
Occurs when attempting to use a feature or endpoint that is not yet implemented. Note: While HTTP 501 is traditionally used for this, this uses 404 for specific cases.
enums/common-error-response-code.enum.ts:72
ERROR_500
"ERROR_500"
Generic server error (500 Internal Server Error)
Generic error for server-side issues when a more specific error code is not applicable.
enums/common-error-response-code.enum.ts:121
ERROR_500_FILE_DELETE
"ERROR_500_FILE_DELETE"
File deletion error (500 Internal Server Error)
Occurs when there is a server-side error during file deletion.
enums/common-error-response-code.enum.ts:86
ERROR_500_FILE_UPLOAD
"ERROR_500_FILE_UPLOAD"
File upload error (500 Internal Server Error)
Occurs when there is a server-side error during file upload processing.
enums/common-error-response-code.enum.ts:79
CommonSuccessResponseCode
Defined in: enums/common-success-response-code.enum.ts:16
Common Success Response Codes Enum
This enum defines general-purpose success response codes that can be used across different services and modules in the application. Each code represents a specific success condition for operations and requests.
While HTTP status codes in the 2xx range (like 200 OK, 201 Created) provide a standardized way to indicate success at the protocol level, these application-specific success codes offer more granular information about the exact nature of the successful operation.
Currently, this enum contains a single generic success code, but it can be extended with more specific success codes as the application grows and more detailed success states need to be communicated.
Enumeration Members
SUCCESS
"SUCCESS"
Generic success response
Indicates that the requested operation completed successfully without any issues. This is the most general success code and can be used when a more specific success code is not necessary or has not been defined.
enums/common-success-response-code.enum.ts:24
Endpoint
Defined in: enums/endpoint.enum.ts:16
Base API Endpoints Enum
This enum defines the root-level API endpoints used throughout the application. Each value represents a top-level API route segment that serves as a namespace for more specific endpoints within that domain.
These root endpoints are typically combined with more specific sub-endpoints (defined in domain-specific endpoint enums) to form complete API paths. For example, the AUTH endpoint combined with an AuthEndpoint value would create a full authentication API route.
This approach allows for organized, hierarchical API routing and helps maintain consistency across the application's API structure.
Enumeration Members
AUTH
"auth"
Authentication API endpoint root
Base path segment for all authentication-related operations. This serves as the namespace for endpoints defined in AuthEndpoint enum.
Complete authentication endpoints are formed by combining this root with specific authentication operations, e.g., "/auth/sign-in" or "/auth/verify-email".
See
AuthEndpoint For specific authentication operation endpoints
Gateway
Defined in: enums/gateways.enum.ts:17
Application Gateways Enum
This enum defines the different communication gateways used in the application for real-time or streaming data exchange. Each value represents a specific gateway technology or implementation that enables bidirectional communication between clients and the server.
Gateways provide alternatives to traditional HTTP request/response patterns, allowing for push notifications, live updates, and interactive features.
The values in this enum can be used to identify and configure the appropriate gateway implementation for different parts of the application.
Enumeration Members
SOCKET
"socket"
WebSocket gateway
Represents the WebSocket-based communication gateway, which provides full-duplex communication channels over a single, long-lived TCP connection.
This gateway enables real-time data exchange between clients and the server without the overhead of repeatedly establishing new connections. It's particularly useful for applications requiring low-latency updates, notifications, or interactive features.
The implementation may use libraries like Socket.IO or native WebSockets.
HttpClientErrorStatus
Defined in: enums/http-status.enums.ts:83
HTTP Client Error Status Codes (4xx)
This enum defines the standard HTTP status codes in the 4xx range (Client Error). These status codes indicate that the client seems to have made an error in the request.
The 4xx class of status codes is intended for situations in which the client appears to have erred, such as sending invalid authentication credentials, requesting a resource that doesn't exist, or submitting malformed data.
See
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#client_error_responses
Enumeration Members
BAD_REQUEST
400
CONFLICT
409
EXPECTATION_FAILED
417
enums/http-status.enums.ts:101
FAILED_DEPENDENCY
424
enums/http-status.enums.ts:106
FORBIDDEN
403
GONE
410
IM_A_TEAPOT
418
enums/http-status.enums.ts:102
LENGTH_REQUIRED
411
LOCKED
423
enums/http-status.enums.ts:105
METHOD_NOT_ALLOWED
405
MISDIRECTED_REQUEST
421
enums/http-status.enums.ts:103
NOT_ACCEPTABLE
406
NOT_FOUND
404
PAYLOAD_TOO_LARGE
413
PAYMENT_REQUIRED
402
PRECONDITION_FAILED
412
PRECONDITION_REQUIRED
428
enums/http-status.enums.ts:109
PROXY_AUTHENTICATION_REQUIRED
407
RANGE_NOT_SATISFIABLE
416
enums/http-status.enums.ts:100
REQUEST_HEADER_FIELDS_TOO_LARGE
431
enums/http-status.enums.ts:111
REQUEST_TIMEOUT
408
TOO_EARLY
425
enums/http-status.enums.ts:107
TOO_MANY_REQUESTS
429
enums/http-status.enums.ts:110
UNAUTHORIZED
401
UNAVAILABLE_FOR_LEGAL_REASONS
451
enums/http-status.enums.ts:112
UNPROCESSABLE_ENTITY
422
enums/http-status.enums.ts:104
UNSUPPORTED_MEDIA_TYPE
415
UPGRADE_REQUIRED
426
enums/http-status.enums.ts:108
URI_TOO_LONG
414
HttpInfoStatus
Defined in: enums/http-status.enums.ts:15
HTTP Informational Status Codes (1xx)
This enum defines the standard HTTP status codes in the 1xx range (Informational). These status codes indicate a provisional response and require the client to continue with the request or ignore the response if the request is already finished.
The 1xx class of status codes represents preliminary information, indicating that the request was received and is continuing to be processed.
See
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#information_responses
Enumeration Members
CONTINUE
100
EARLYHINTS
103
PROCESSING
102
SWITCHING_PROTOCOLS
101
HttpRedirectionStatus
Defined in: enums/http-status.enums.ts:60
HTTP Redirection Status Codes (3xx)
This enum defines the standard HTTP status codes in the 3xx range (Redirection). These status codes indicate that further action needs to be taken by the client in order to complete the request, typically involving following a redirect.
The 3xx class of status codes indicates the client must take additional action to complete the request, such as following a new URL or using a cached version.
See
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#redirection_messages
Enumeration Members
FOUND
302
MOVED_PERMANENTLY
301
MULTIPLE_CHOICES
300
NOT_MODIFIED
304
PERMANENT_REDIRECT
308
SEE_OTHER
303
TEMPORARY_REDIRECT
307
USE_PROXY
305
HttpServerErrorStatus
Defined in: enums/http-status.enums.ts:128
HTTP Server Error Status Codes (5xx)
This enum defines the standard HTTP status codes in the 5xx range (Server Error). These status codes indicate that the server failed to fulfill a valid request.
The 5xx class of status codes is intended for cases in which the server is aware that it has encountered an error or is otherwise incapable of performing the request. These errors are typically related to server configuration issues, unexpected conditions, or temporary overloading.
See
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#server_error_responses
Enumeration Members
BAD_GATEWAY
502
enums/http-status.enums.ts:131
GATEWAY_TIMEOUT
504
enums/http-status.enums.ts:133
HTTP_VERSION_NOT_SUPPORTED
505
enums/http-status.enums.ts:134
INSUFFICIENT_STORAGE
507
enums/http-status.enums.ts:136
INTERNAL_SERVER_ERROR
500
enums/http-status.enums.ts:129
LOOP_DETECTED
508
enums/http-status.enums.ts:137
NETWORK_AUTHENTICATION_REQUIRED
511
enums/http-status.enums.ts:139
NOT_EXTENDED
510
enums/http-status.enums.ts:138
NOT_IMPLEMENTED
501
enums/http-status.enums.ts:130
SERVICE_UNAVAILABLE
503
enums/http-status.enums.ts:132
VARIANT_ALSO_NEGOTIATES
506
enums/http-status.enums.ts:135
HttpSuccessStatus
Defined in: enums/http-status.enums.ts:35
HTTP Success Status Codes (2xx)
This enum defines the standard HTTP status codes in the 2xx range (Success). These status codes indicate that the client's request was successfully received, understood, and accepted.
The 2xx class of status codes represents successful completion of the HTTP request, with different codes indicating specific types of success such as resource creation, accepted but not yet processed requests, or successful responses with no content.
See
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#successful_responses
Enumeration Members
ACCEPTED
202
ALREADY_REPORTED
208
CONTENT_DIFFERENT
210
CREATED
201
MULTI_STATUS
207
NO_CONTENT
204
NON_AUTHORITATIVE_INFORMATION
203
OK
200
PARTIAL_CONTENT
206
RESET_CONTENT
205
Interfaces
ErrorResponse
Defined in: interfaces/response.interfaces.ts:126
Interface for error API responses that include error details.
The ErrorResponse interface extends the base HttpResponse interface to standardize
error responses across the application. It includes properties for error identification,
detailed error information, and optionally the original error object for debugging.
This structured approach to error responses makes it easier for clients to handle errors in a consistent way and for developers to debug issues in the system.
ErrorResponse
See
- HttpResponse Base interface for all responses
- HttpClientErrorStatus Client error HTTP status codes
- HttpServerErrorStatus Server error HTTP status codes
- ErrorResponseCode Application-specific error codes
Extends
Properties
code
Application-specific error code.
This provides more granular information about the specific error case, allowing clients to handle different error scenarios distinctly.
See
ErrorResponseCode Type for error response codes
‐
interfaces/response.interfaces.ts:147
description?
string
Optional detailed description of the response.
When provided, this field contains additional information about the response that might be useful for debugging or logging purposes. Unlike the message field, this can contain technical details and is primarily intended for developers rather than end users.
‐
interfaces/response.interfaces.ts:66
message
string
Human-readable message describing the response.
This short message explains the result of the operation and is suitable for displaying to end users. It should be clear, concise, and avoid technical details that aren't relevant to users.
‐
interfaces/response.interfaces.ts:56
statusCode
| HttpClientErrorStatus | HttpServerErrorStatus
The HTTP status code, which will be an error code (4xx or 5xx).
For error responses, this will typically be:
- 4xx range for client errors (e.g., 400 Bad Request, 404 Not Found)
- 5xx range for server errors (e.g., 500 Internal Server Error)
See
- HttpClientErrorStatus Enum of client error status codes
- HttpServerErrorStatus Enum of server error status codes
‐
interfaces/response.interfaces.ts:137
HttpResponse
Defined in: interfaces/response.interfaces.ts:21
Base interface for all HTTP responses in the application.
The HttpResponse interface defines the standard structure for API responses
throughout the application. It ensures a consistent response format that includes
status information, a specific response code, and descriptive messages.
This standardized format makes it easier for clients to process responses and handle different scenarios (success, error, etc.) in a consistent manner.
HttpResponse
See
- SuccessResponse For successful operation responses
- ErrorResponse For error operation responses
- ResponseCode Type for response status codes
- HttpStatus HTTP status codes enumeration
Extended by
Properties
code
Application-specific response code.
This code provides more detailed information about the specific result of the operation beyond what the HTTP status code indicates. It allows for fine-grained categorization of responses within each HTTP status category.
See
- ResponseCode Union type for all response codes
- SuccessResponseCode Type for success response codes
- ErrorResponseCode Type for error response codes
interfaces/response.interfaces.ts:47
description?
string
Optional detailed description of the response.
When provided, this field contains additional information about the response that might be useful for debugging or logging purposes. Unlike the message field, this can contain technical details and is primarily intended for developers rather than end users.
interfaces/response.interfaces.ts:66
message
string
Human-readable message describing the response.
This short message explains the result of the operation and is suitable for displaying to end users. It should be clear, concise, and avoid technical details that aren't relevant to users.
interfaces/response.interfaces.ts:56
statusCode
The HTTP status code for the response.
This corresponds to standard HTTP status codes (200, 400, 500, etc.) and provides a quick way for clients to determine the general category of the response (success, client error, server error).
See
- HttpStatus Type for HTTP status codes
- HttpSuccessStatus Enum for success status codes
- HttpClientErrorStatus Enum for client error status codes
- HttpServerErrorStatus Enum for server error status codes
interfaces/response.interfaces.ts:34
SuccessResponse
Defined in: interfaces/response.interfaces.ts:84
Interface for successful API responses that include data payload.
The SuccessResponse interface extends the base HttpResponse interface to include
a data property containing the operation's result. This interface is used for all
successful API responses that need to return data to the client.
The generic type parameter T allows for type-safe specification of the data structure
being returned, ensuring consistency between backend definitions and frontend expectations.
SuccessResponse
See
HttpResponse Base interface for all responses
Extends
Properties
code
Application-specific success code.
This provides more granular information about the specific success case, allowing clients to handle different success scenarios distinctly if needed.
See
SuccessResponseCode Type for success response codes
‐
interfaces/response.interfaces.ts:105
description?
string
Optional detailed description of the response.
When provided, this field contains additional information about the response that might be useful for debugging or logging purposes. Unlike the message field, this can contain technical details and is primarily intended for developers rather than end users.
‐
interfaces/response.interfaces.ts:66
message
string
Human-readable message describing the response.
This short message explains the result of the operation and is suitable for displaying to end users. It should be clear, concise, and avoid technical details that aren't relevant to users.
‐
interfaces/response.interfaces.ts:56
statusCode
The HTTP status code, which will be a success code (2xx).
For successful responses, this will typically be:
- 200 (OK) for general success
- 201 (Created) when a resource was successfully created
- 204 (No Content) when an operation succeeded but returns no data
See
HttpSuccessStatus Enum of available success status codes
‐
interfaces/response.interfaces.ts:95
UserInfo
Defined in: interfaces/user-info.interface.ts:38
Interface representing essential user information.
The UserInfo interface defines the core identifying information for a user
that is commonly needed throughout the application. It contains only the essential
properties needed to identify and display basic user information, without including
sensitive or authentication-related data.
This interface is designed to be embedded within other entities for tracking user associations, such as who created or modified a record. It's a lightweight alternative to embedding or referencing the complete user entity.
Common use cases:
- Audit trails for entity creation and modification
- Activity logs showing which user performed an action
- User attribution in collaborative features
- Display of user information in UI components
See
- Model Uses this interface for tracking entity ownership and changes
- EntityId Type used for the user identifier
Example
// Example of a blog post entity using UserInfo
interface BlogPost {
id: EntityId;
title: string;
content: string;
author: UserInfo; // The user who wrote the post
lastEditedBy?: UserInfo; // The user who last edited the post
}Properties
firstName
string
The user's