[typescript-rxjs] runtime and api cleanup

[denyo]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

Description of the PR

This PR simplifies models RequestArgs and ResponseArgs and makes them an alias for { AjaxRequest, AjaxResponse } from 'rxjs/ajax';. Also parameter names make more sense now and unneeded checks are removed.
For people that have previously applied any middlewares this is breaking due to the model changes but it is quite easy to fix. Docs where also extended.

Middleware Before

export class AuthInterceptor extends Configuration {
  private static config: AuthInterceptor;

  private constructor() {
    const middleware: Middleware[] = [
      {
        pre: (context: RequestContext): RequestArgs => ({
          ...context,
          options: {
            ...context.options,
            headers: {
              ...context.options.headers,
              Authorization: `Bearer ${getAuthToken()}`
            }
          }
        })
      }
    ];

    super({ middleware });
  }

  public static get Instance() {
    return AuthInterceptor.config || (AuthInterceptor.config = new this());
  }
}

Middleware After

export class AuthInterceptor extends Configuration {
  private static config: AuthInterceptor;

  private constructor() {
    const middleware: Middleware[] = [
      {
        pre: (request: RequestArgs): RequestArgs => ({
          ...request,
          headers: {
            ...request.headers,
            Authorization: `Bearer ${getAuthToken()}`,
          },
        }),
      },
    ];

    super({ middleware });
  }

  public static get Instance() {
    return AuthInterceptor.config || (AuthInterceptor.config = new this());
  }
}

@TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @nicokoenig (2018/09) @topce (2018/10)

[auto-labeler]

👍 Thanks for opening this issue!
🏷 I have applied any labels matching special text in your issue.

The team will review the labels and make any necessary changes.

[macjohnny]

the changes are not backwards-compatible. so this should go to the 5.x branch or we should prefer the current interfaces. what do you think?

[macjohnny]

this isnt backwards compatible, so I would not delete ResponseContext

[macjohnny]

this isn't backwards-compatible so I would revert it

[macjohnny]

cc @akehir

[macjohnny]

according to https://github.com/OpenAPITools/openapi-generator/wiki/Git-Branches it should be ok to merge this into 4.1.x, as the breaking-change is easy to fix

[macjohnny]

@denyo can you cherry-pick into 4.1.x?
4.0.3 is the last patch release before 4.1.0, so it is fine to merge this into master

[akehir]

@denyo can you cherry-pick into 4.1.x?
4.0.3 is the last patch release before 4.1.0, so it is fine to merge this into master

@macjohnny, during the release, the 4.1.0 branch would be merged into master, and future 4.1.x patch releases would be branched of master (unexpectedly containing the breaking change). Merging to master seems to violate the merge direction description of the git branches wiki entry.

How are breaking changes documented in order to help people experiencing the breakage to be able to fix this easily?

I understand that simplifying the template is a good idea, however, I would be reluctant to introduce unexpected breaking changes (especially since whoever doesn't like the template can easily override it in the local project), if it cannot be communicated properly.

[denyo]

I kind of had the same thoughts as @akehir.
On the one hand I am all for simplification and performance, on the other I am not a fan of breaking changes either in patch or minor version bumps.
In general until recently with 1 or 2 bug reports about this particular generator I had the feeling it wasn't really used by anyone so I wasn't too worried. Are there any usage stats about this?
Since it is initially based on typescript-fetch some of their technical debt was obvisouly dragged over. So this PR is mainly towards cleaning this up since rxjs is providing the ideal interfaces already.

[macjohnny]

now that 4.0.3 has been released, the next release (i.e. 4.1.0) will be taken from master, as the 4.1.x branch should be merged into master now.
in the next minor release (4.1.0), breaking changes with fallback are permitted. I labelled this PR with Breaking changes with fallback, so it can be found in the release notes (see e.g. https://github.com/OpenAPITools/openapi-generator/releases/tag/v4.0.0), so the migration steps should be documented here in this PR. @denyo can you do that?

[denyo]

@macjohnny migration steps are in the description with before and after? Or what do you mean?

[macjohnny]

migration steps are in the description with before and after? Or what do you mean?

I think the description in the PR should be enough, but maybe it might be worth adding an additional line explaining explicitly which signature changed.