RxJS 6中自定义Single/Maybe/Completable类是否为最佳实践？

Great question—let’s break this down clearly, especially since your use case with reflect-metadata adds a specific constraint that makes type aliases useless here.

First, let’s cut to the chase: Creating concrete Single/Completable subclasses of Observable isn’t a universal "best practice" in RxJS, but it’s absolutely justified and necessary for your specific needs. RxJS typically favors operators and type aliases to express stream semantics, but your reliance on reflect-metadata’s design:returntype requires actual class constructors to be detectable at runtime.

Why Type Aliases Fail for You #

Type aliases like type Single<T> = Observable<T> are just compile-time sugar—they vanish at runtime. When you use Reflect.getMetadata, you’ll only get Observable (or Object) as the return type, not a distinct Single identifier. Concrete classes solve this because they leave a runtime footprint the reflection system can pick up.

Implementation Approach & Key Considerations #

1. Properly Extend Observable #

Your idea to use the single operator to enforce Single’s behavior is spot-on. Just make sure your subclass maintains compatibility with RxJS’s core mechanics, especially the lift method (to preserve your subclass type through operator chains).

Example code:

import { Observable, Subscriber, Operator } from 'rxjs';
import { single, map, takeLast } from 'rxjs/operators';

// Single: Emits exactly 1 value (or errors if 0/more)
export class Single<T> extends Observable<T> {
  constructor(source: Observable<T>) {
    super((subscriber: Subscriber<T>) => {
      // Enforce Single semantics: error if no value or multiple values
      return source.pipe(single()).subscribe(subscriber);
    });
  }

  // Override lift to keep operator returns as Single instead of Observable
  lift<R>(operator: Operator<T, R>): Single<R> {
    const observable = new Single<R>(this as any);
    observable.operator = operator;
    return observable;
  }
}

// Completable: Emits only completion or error (no values)
export class Completable extends Observable<void> {
  constructor(source: Observable<any>) {
    super((subscriber: Subscriber<void>) => {
      return source.pipe(
        map(() => undefined), // Discard any emitted values
        takeLast(1) // Ensure we only pass completion after source finishes
      ).subscribe(subscriber);
    });
  }

  lift<R>(operator: Operator<void, R>): Observable<R> {
    // Adjust based on whether you want to retain Completable semantics post-operator
    const observable = new Completable(this as any);
    observable.operator = operator;
    return observable;
  }
}

2. Integrate with reflect-metadata #

Now your decorators can reliably detect the return type. Here’s how that might look:

import 'reflect-metadata';

function ApiEndpoint() {
  return function(target: any, propertyKey: string) {
    const returnType = Reflect.getMetadata('design:returntype', target, propertyKey);
    
    if (returnType === Single) {
      console.log(`Endpoint ${propertyKey}: Returns exactly one value`);
    } else if (returnType === Completable) {
      console.log(`Endpoint ${propertyKey}: Returns no data, only completion status`);
    } else if (returnType === Observable) {
      console.log(`Endpoint ${propertyKey}: Returns a stream of multiple values`);
    }
  };
}

class UserService {
  @ApiEndpoint()
  fetchUserById(id: number): Single<User> {
    return new Single(of({ id, name: 'Diego' }));
  }

  @ApiEndpoint()
  deleteUser(id: number): Completable {
    return new Completable(of(null));
  }
}

3. Watch for Potential Pitfalls #

• Operator Chain Consistency: If you skip overriding lift, some operators will return plain Observables instead of your subclass, breaking type semantics. The example above fixes this, but test edge cases.
• RxJS Version Compatibility: RxJS 6+’s architecture supports subclassing, but future updates might introduce changes—keep your tests aligned with your RxJS version.
• Semantic Clarity: Make sure your subclasses behave as expected (e.g., Single errors on 0 or multiple values, Completable never emits values). Align with common conventions (like RxJava’s Single/Completable) to avoid confusing your team.

Final Takeaway #

For your use case—where runtime type detection via reflect-metadata is non-negotiable—creating custom Observable subclasses is the right approach. It’s not the standard RxJS pattern, but it solves your specific problem effectively. Just ensure your implementations are robust and maintain consistent semantics.

内容的提问来源于stack exchange，提问作者Diego Fernando Murillo Valenci