Spring Parser. Allow custom "Unwrapping"

[Antibrumm]

Hi

It would be nice to be able to have the possibility to unwrap a class type before giving it into the TypeProcessor handling.

I saw, for example, that you already handle ResponseEntity in the SpringApplicationParser explicitly and would need this feature to be available from outside so we can inject our own unwrapping.

A concrete use case would be my jackson filter library where the returnType is a generic class with the concrete result defined in the generic part:
(https://github.com/Antibrumm/jackson-antpathfilter)

    @RequestMapping
    @ResponseBody
    public AntPathFilterMappingJacksonValue<SomeClass> getSomeObject() {
        return new AntPathFilterMappingJacksonValue<>(someObject, "*", "*.*", "!not.that.path");
    }

Similar to ResponseEntity I would need to give the class SomeClass into the modelReturnType.

            final Class<?> returnType = method.getReturnType();
            final Type genericReturnType = method.getGenericReturnType();
            final Type modelReturnType = unwrapReturnType(genericReturnType);

[vojtechhabarta]

Hi,
I think you can achieve "return type unwrapping" with current typescript-generator version by using customTypeMappings which is general mechanism and not just for Spring return types.

You can add custom mapping from your.package.AntPathFilterMappingJacksonValue to some Unwrap type alias. Then you need to create for example unwrap.d.ts file with following alias:

export type Unwrap<T> = T;

and import it from this file using importDeclarations parameter.

In d85cf01 commit I added unit test demonstrating this solution.

Currently this solution requires extra file but maybe I could add possibility to add custom type aliases to generated output.

[vojtechhabarta]

I forgot to mention that this example assumes that you are using modules (outputKind parameter set to module).

[Antibrumm]

Thanks for the hint.
I gave it a try and it seems to be okay. I would still say that it's preferable to avoid having that type declaration in the client as that could avoid some confusion for the developers using a type which is only a support class for spring and has no added value, like the ResponseEntity.

As a test I was able to use the customTypeProcessor in my fork build which looks something like this:

public interface UnwrappingTypeProcessor extends TypeProcessor {
    Type unwrapType(Type type);
}

public class DefaultSpringUnwrappingTypeProcessor implements UnwrappingTypeProcessor {
    public Type unwrapType(Type genericReturnType) {
        if (genericReturnType instanceof ParameterizedType && ResponseEntity.class == ((ParameterizedType)genericReturnType).getRawType()) {
            ParameterizedType parameterizedReturnType = (ParameterizedType)genericReturnType;
            return parameterizedReturnType.getActualTypeArguments()[0];
        } else {
            return genericReturnType;
        }
    }
    ...
}

public class SpringApplicationParser extends RestApplicationParser {

    private void parseControllerMethod(JaxrsApplicationParser.Result result, JaxrsApplicationParser.ResourceContext context, Class<?> controllerClass, Method method) {
        ....
        final Type genericReturnType = method.getGenericReturnType();
        final Type modelReturnType = unwrapReturnType(genericReturnType);
        foundType(result, modelReturnType, controllerClass, method.getName());
        ....
    }
    
    
    private Type unwrapReturnType(Type genericReturnType) {
        if (this.settings.customTypeProcessor != null && this.settings.customTypeProcessor instanceof UnwrappingTypeProcessor) {
            return ((UnwrappingTypeProcessor) this.settings.customTypeProcessor).unwrapType(genericReturnType);
        } else {
            return defaultSpringUnwrappingTypeProcessor.unwrapType(genericReturnType);
        }
    }
}

As this is only a SpringApplicationParser thing I did not try to adapt the Settings object and I misused the <customTypeProcessor> feature for it so I don't have to change the plugin definition. I think it would deserve it's own config setting.
But I would also understand if you say: "It's already achievable, so no need for something like that" :)

[vojtechhabarta]

I agree that the Unwrap type is not meaningful for clients, it would be there just for technical reason.

Another solution with current typescript-generator version:
I think you can create custom TypeProcessor and do unwrapping in processType method. You can then assign it using customTypeProcessor parameter. Little downside is that you need to add this compiled class to typescript-generator dependencies.

What about this solution?

[vojtechhabarta]

In version 2.15 I added customTypeAliases parameter which simplifies solution using Unwrap type alias. Now there is no need for extra file and import.

Maven example:

<configuration>
    <customTypeMappings>
        <mapping>your.package.AntPathFilterMappingJacksonValue:Unwrap</mapping>
    </customTypeMappings>
    <customTypeAliases>
        <alias>Unwrap&lt;T>:T</alias>
    </customTypeAliases>
</configuration>

Please note that < character must be escaped using < in XML.

[vojtechhabarta]

In 2.16.538 release I changed customTypeMappings parameter format (#384) so now it should be possible to "unwrap" types directly, for example like this:

<configuration>
    <customTypeMappings>
        <mapping>your.package.AntPathFilterMappingJacksonValue[T]:T</mapping>
    </customTypeMappings>
</configuration>

[Antibrumm]

Hi

Thank you. I was just playing around with the generator and can confirm that this works as expected :)