joffrey-bion / livedoc

A not-so-annotation-based documentation generator for REST and websocket services
MIT License
4 stars 2 forks source link

@RequestMapping using regex not working in UI #122

Closed Shinigami92 closed 6 years ago

Shinigami92 commented 6 years ago

Describe the bug If you have a @Controller/@RestController with a method that contains a @RequestMapping that uses Regex, you can not unfold this method in the UI

example: @RequestMapping("/{id:[0-9]+}")

Expected behavior Expandable UI element for the method

Screenshots If you can wait until tomorrow, I can take a screenshot at work

Environment/Context

Shinigami92 commented 6 years ago

Two errors are shown in the DEV-Console when clicking on the element

livedoc - google chrome_078

The jsondoc part looks like this:

{
    "jsondocErrors": [],
    "jsondocWarnings": [],
    "jsondocHints": [
        "Add description to ApiOperation",
        "Add description to ApiPathParam"
    ],
    "name": "update",
    "summary": null,
    "description": null,
    "paths": [
        "***/update/{id:[0-9]+}"
    ],
    "verbs": [
        "PUT"
    ],
    "pathParameters": [{
        "jsondocErrors": [],
        "jsondocWarnings": [],
        "jsondocHints": [],
        "type": {
            "typeElements": [{
                "text": "long",
                "livedocId": null
            }],
            "composingTypes": [
                "long"
            ],
            "oneLineText": "long"
        },
        "name": "id",
        "description": null,
        "required": "true",
        "allowedValues": [],
        "format": null,
        "defaultValue": null
    }],
    "queryParameters": [],
    "headers": [],
    "requestBody": {
        "type": {
            "typeElements": [{
                    "text": "Map",
                    "livedocId": null
                },
                {
                    "text": "<",
                    "livedocId": null
                },
                {
                    "text": "String",
                    "livedocId": null
                },
                {
                    "text": ", ",
                    "livedocId": null
                },
                {
                    "text": "Object",
                    "livedocId": null
                },
                {
                    "text": ">",
                    "livedocId": null
                }
            ],
            "composingTypes": [
                "java.util.Map",
                "java.lang.String",
                "java.lang.Object"
            ],
            "oneLineText": "Map<String, Object>"
        },
        "template": {}
    },
    "responseBodyType": {
        "name": "DTO",
        "oneLineText": "DTO",
        "typeElements": [{
            "text": "DTO",
            "livedocId": null
        }],
        "composingTypes": []
    },
    "consumes": [
        "application/json"
    ],
    "produces": [
        "application/json"
    ],
    "responseStatusCode": "200 - OK",
    "apiErrors": [],
    "auth": null,
    "supportedVersions": null,
    "stage": null,
    "livedocId": "put-***-update-id%3A%5B0-9%5D%2B"
}

i have masked some parts with ***

joffrey-bion commented 6 years ago

Thanks again for opening issues, it really helps me improve Livedoc.

Regarding the part hidden with stars, is it properly URL-encoded? It is just plain ascii, isn't it?

joffrey-bion commented 6 years ago

I managed to reproduce using the same regex as you. It looks like the square brackets are the culprits. WIthout them, even with a regex, it seems to work. Strangely enough the brackets are encoded properly in the JSON output of livedoc, however they seem to be decoded when storing the ID on client side.

I'm at work right now, but I'll try to get this fixed tonight and release a patch tomorrow.

joffrey-bion commented 6 years ago

The problem seems due to the fact that react-router decodes the path I gave it, despite the fact that I took care of properly URL-encode this stuff to avoid this kind of problems!

This router issue comes from this history issue

I'll look for a simple solution to work around that, but I believe it is annoying and unexpected from the router to do this sort things.