Effect CommunityEC
Effect Community•2y ago
BinaryArtifex

Exploring Design Choices in RequestResolver Requirements Propagation

is it by design that RequestResolver requirements don't propagate to the implementation function (makeService) or the the Context itself?

Return type of the below resolver is Effect.Effect<RequestResolver.RequestResolver<LoginRequest, never>, never, EnvService | StorageService>

// auth-service.resolvers.ts
export function buildLoginResolver(api: AuthenticationApi) {
  return RequestResolver.fromEffect((request: LoginRequest) => {
    return Effect.gen(function* ($) {
      const [storage, env] = yield* $(Effect.all([StorageService, EnvService]));

      // .....rest of implementation

  }).pipe(RequestResolver.contextFromServices(StorageService, EnvService));
}


Here, the return type of makeService is Effect.Effect<Session, never, never> but as you can see the login has error and requirement types that don't propagate up to the makeService itself. Is there some inference considerations here im not seeing or understanding?

// auth-service.live.ts
export const makeService = Effect.gen(function* ($) {
  const api = new AuthenticationApi();
  const loginResolver = buildLoginResolver(api);

  // .... rest of implementation

  return AuthService.of({
    // Effect.Effect<Session, AuthServiceError, EnvService | StorageService>
    login: (args: LoginArgs) => Effect.request(new LoginRequest(args), loginResolver),
  });
});
Was this page helpful?