TypeScript Decorator Composition

This challenge focuses on a powerful feature in TypeScript: decorator composition. You'll learn how to combine multiple decorators to apply a sequence of behaviors to classes and class members. Understanding decorator composition is crucial for building reusable and modular code, especially in frameworks and libraries.

Problem Description

Your task is to implement a system that allows for the composition of TypeScript decorators. Decorators are special kinds of declarations that can be attached to classes, methods, accessors, properties, or parameters. Decorator composition means applying multiple decorators to a single target, where their execution order can be controlled.

You will need to:

1. Define a base DecoratorFactory type that represents a function that returns a decorator.
2. Implement a composeDecorators function that takes an arbitrary number of DecoratorFactory functions and returns a single DecoratorFactory that, when applied, executes the provided decorators in a specified order (typically reverse order of application).
3. Demonstrate the functionality by creating a few simple decorators and composing them, showing how their effects are combined.

The composeDecorators function should handle the fact that decorators are applied in reverse order of their declaration in code. For example, if you have @decoratorA @decoratorB class MyClass {}, decoratorB will be applied first, and then decoratorA will be applied to the result of decoratorB. Your composition function should mimic this behavior.

Examples

Example 1: Method Decorator Composition

// Assume these are defined elsewhere and provided for demonstration
type MethodDecoratorFactory = (target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) => PropertyDescriptor | void;
function createMethodDecoratorFactory(decorator: MethodDecoratorFactory): () => MethodDecoratorFactory {
    return () => decorator;
}

// Example Decorator 1: Logs method calls
const logCall = createMethodDecoratorFactory((target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) => {
    const originalMethod = descriptor.value;
    descriptor.value = function(...args: any[]) {
        console.log(`Calling ${String(propertyKey)} with arguments:`, args);
        const result = originalMethod.apply(this, args);
        console.log(`${String(propertyKey)} returned:`, result);
        return result;
    };
    return descriptor;
});

// Example Decorator 2: Adds a delay to method execution
const delayExecution = (ms: number) => createMethodDecoratorFactory((target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) => {
    const originalMethod = descriptor.value;
    descriptor.value = function(...args: any[]) {
        return new Promise(resolve => {
            setTimeout(async () => {
                console.log(`Executing ${String(propertyKey)} after ${ms}ms delay...`);
                const result = await originalMethod.apply(this, args);
                resolve(result);
            }, ms);
        });
    };
    return descriptor;
});

// --- Your implementation of composeDecorators would be used here ---

// Imagine composeDecorators exists and works like this:
// const composedMethodDecorator = composeDecorators(logCall(), delayExecution(100));
// @composedMethodDecorator
// class MyService {
//     async greet(name: string) {
//         console.log(`Greeting ${name}...`);
//         return `Hello, ${name}!`;
//     }
// }

// When MyService().greet("World") is called, the output would be:
// Calling greet with arguments: [ 'World' ]
// Executing greet after 100ms delay...
// Greeting World...
// greet returned: Hello, World!
// (with a 100ms pause before "Executing...")

// For this example, we'll manually apply the composed decorator to show behavior
class MyServiceManual {
    @logCall()
    @delayExecution(100)
    async greet(name: string) {
        console.log(`Greeting ${name}...`);
        return `Hello, ${name}!`;
    }
}

// To verify:
// const service = new MyServiceManual();
// service.greet("World");

Example 2: Class Decorator Composition

// Assume these are defined elsewhere and provided for demonstration
type ClassDecoratorFactory = (target: any) => any | void;
function createClassDecoratorFactory(decorator: ClassDecoratorFactory): () => ClassDecoratorFactory {
    return () => decorator;
}

// Example Decorator 1: Adds a static property
const addVersion = (version: string) => createClassDecoratorFactory((target: any) => {
    Object.defineProperty(target, 'version', {
        value: version,
        writable: false,
        enumerable: true,
    });
});

// Example Decorator 2: Adds a static method
const addInfo = createClassDecoratorFactory((target: any) => {
    target.getInfo = () => "This is an info decorator";
});

// --- Your implementation of composeDecorators would be used here ---

// Imagine composeDecorators exists and works like this:
// const composedClassDecorator = composeDecorators(addVersion("1.0.0"), addInfo());
// @composedClassDecorator
// class MyComponent {}

// For this example, we'll manually apply the composed decorator to show behavior
class MyComponentManual {
    // The order of decorators matters for composition.
    // If composeDecorators applies them in reverse, then addInfo would be applied first,
    // then addVersion to the result of addInfo.
    // For manual application, the execution order is from top to bottom when applying.
    // However, composition logic should handle the reverse execution.
    @addVersion("1.0.0")
    @addInfo()
    constructor() {} // This is a common pattern to apply class decorators
}

// To verify:
// console.log(MyComponentManual.version); // Expected: "1.0.0"
// console.log(MyComponentManual.getInfo()); // Expected: "This is an info decorator"

// Note: The constructor decorator is a common way to apply class decorators
// in practice, even though class decorators can be applied directly.
// When using @Component @AnotherComponent class MyClass, @AnotherComponent is applied first.
// Therefore, your composeDecorators should process them in reverse.

Constraints

• The composeDecorators function must accept a variable number of decorator factories (using rest parameters).
• The returned decorator factory must correctly apply the decorators in the order that mimics TypeScript's default decorator application (reverse order of declaration).
• Your solution should be written in TypeScript and leverage its type system.
• You can assume that the input decorator factories are valid decorators for their intended targets (class, method, etc.).

Notes

• Consider how decorators are applied in TypeScript: @decoratorA @decoratorB class MyClass {} means decoratorB is applied first, and then decoratorA is applied to the result of decoratorB. Your composeDecorators function needs to achieve this sequential application.
• You'll need to define appropriate types for different kinds of decorator factories (e.g., ClassDecoratorFactory, MethodDecoratorFactory). You can start with a generic DecoratorFactory and potentially refine it.
• Think about how to handle the target, propertyKey, and descriptor arguments that decorators receive.
• The provided examples use helper functions (createMethodDecoratorFactory, createClassDecoratorFactory) to simulate how you might create and wrap decorators. You can use these or adapt them as needed for your solution.
• The core challenge is the composeDecorators function itself and ensuring the correct execution order.