[Question] How to handle "complex" types extending primitives? about wsdl-tsclient HOT 4 OPEN

Flagging @esivkov to this one!

from wsdl-tsclient.

Hi,

wsdl-tsclient only inherits parsed types from node-soap and then generates client.... Some complex types are too "complex" :/ . Right now, there's no easy solution for this. I think it should be handled first by node-soap and then I can implement it in wsdl-tsclient

from wsdl-tsclient.

You can pass a customDeserializer into node-soap's createClientAsync method, maybe wsdl-tsclient could use this?

We do this for example to generate Date-Objects from a WSDL object containing custom Date & DateTime types, but those types are currently detected as simple strings by wsdl-tsclient.

On the reverse-direction you can pass custom-types as arguments into WSDL methods generated by node-soap as long as they provide a string $value property. There is currently no way to handle this mapping with wsdl-tsclient as well.

Example File: OrgUnitService.wsdl.txt

With example customDeserializer:

const client = soap.createClientAsync('example.wsdl', {
  customDeserializer:  {
    date: (text: string, xmlContext: XMLContext): SoapDate | string | undefined => {
      if (xmlContext.nil) { return undefined; }
      if (text.length > 0) { return new SoapDate(text); }
      return text;
    },
  }
});

And example custom type:

import moment from 'moment';

class SoapDate {
  protected $value: string;
  protected data: moment.Moment;

  public constructor(input: string | moment.Moment) {
    if (moment.isMoment(input)) {
      this.data = moment.utc(input, 'YYYY-MM-DD');
    } else {
     this.data = input;
    }
    this.$value = this.data.format('YYYY-MM-DD');
  }

This custom-type can be used as any string-type argument of a Soap-Method due to its $value property and with the customDeserializer it is returned by any Soap-Method that returns an argument of type date.

In my customized type-definitions I can ensure that Date-Type input and output values are pinned to the corresponding SoapDate-type, reducing any ambiguity when reading results or piping in arguments.

from wsdl-tsclient.

Addendum: This not only affects complex-types but (understandably) any customDeserializer type.

An option to pass in a custom type mapping from WSDL TypeDefinition to TypeScript type would be nice or as an alternative
an option to preserve the WSDL TypeDefinition name here instead of pinning it to string:

For example replace "string" with the type value.
This would preserve this information and allow for text-level post-processing and would be an easy workaround.

from wsdl-tsclient.