Skip to content

Extension points to generated Service classes (supporting angular) #936

@kutlugsahin

Description

@kutlugsahin

Hey Ferdi!

I hope you are doing well!

First I'm very glad to see that this super handy library keeps growing and improving 🚀 Keep up the awesome work!
I'm willing to use this in my new project but it needs a little bit tuning though. So what's not enough already? Well for angular I need to have these generated service classes a little bit different. Btw it works as is also with angular but you need to compromise on angular's http service and dependency injection mechanism which makes angular devs unhappy 😭 . I also appreciate the framework agnostic structure of the library so I have added few extension points to the exportService template where the user can inject additional code and finally an injectable angular service using http client is possible. (for a complete angular solution user should also use the --request option but it's already there!)

TLDR; I've already created a PR for that here --> #935

To illustrate the need here is an example of a generated service

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';


@Injectable()
export class AssetsService {
    constructor(private http: HttpClient) {}

    /**
     * Download Images for products as a .zip file
     * @param assetIds
     * @returns any successful operation
     * @throws ApiError
     */
    public downloadAssets(
        assetIds: Array<number>,
    ) {
        return __request<any>({
            method: 'GET',
            path: `/v1/assets/download`,
            query: {
                'assetIds': assetIds,
            },
            context: this.http,
        });
    }
}

As you can see this very close to already generated classes but there are few updates

  • additional imports
  • class decorator
  • constructor with parameter property
  • non static methods
  • an optional payload (named "context") to be passed to request function which can be used later on if --request is used

I also removed explicit return type of CancellablePromise and let it to be inferred from the return type of _request function which is by default CancellablePromise but the user can redefine it by --request option. (For instance my request function for angular will return Observable)

So in order to accomplish that I've added an cli option as --serviceOptions which is a path to a file which exports a javascript object in the shape of

export interface ServiceOptions {
    serviceImports?: string;
    serviceConstructor?: string;
    serviceDecorator?: string;
    staticMethods?: boolean;
    serviceRequestContext?: string;
}

The values provided by the serviceOptions are injected to the generated service classes only if they are provided of course.

So please take a look and let me know what you think 😉

Cheers!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions