Implementation frontend part similar to Swagger UI

[TerraVenil]

Hi! Are you going to implement frontend part with SigSpec similar to Swagger UI? As I understand from source you already have dynamic proxy generation(TS) + Spec, so the last step would be integrate all that staff with a pretty UI :)

[RicoSuter]

Don't wait for it, I already have too much to do with NJsonSchema and NSwag - and SigSpec was essentially for free with these projects :-) The next step would be to add a C# generator + CLI. But feel free to contribute an UI based on the spec - that would be awesome...

[RicoSuter]

I currently don't use SignalR in any of my job projects and I don't receive any money etc. so it's really hard to justify building a UI - I already spend too much time for free OSS work...

[RicoSuter]

I will probably add a sigspec ui to apiverse.io (site is far from ready)

[RicoSuter]

If there is demand ill add this as an endpoint type to https://apiverse.io/ and also a Swagger UI like experience via this page (but read-only).

[TomSmith27]

I know this is an old issue but i have started working on making a UI similar to SwaggersUI for SignalR.

The idea is you will be able to send messages in, and listen for callbacks and get a list of all the callbacks that have fired so you should be able to use this Like SwaggerUI.

[RicoSuter]

@TomSmith27 very nice, is this a completely new implementation or are you somehow using Swagger UI?

I'd really like to have this as part of this repo and maybe directly generate a bundle with the UI and expose it via a UseSigSpecUI() extension method from the SigSpec.AspNetCore nuget package so that the final experience is the same as with NSwag

Ref: #33

[TomSmith27]

I agree it would be great to include it as part of this Repo. I will move the code from where i am working on it into a WIP: PR so you can see what i have.

is this a completely new implementation or are you somehow using Swagger UI?

This is a new implementation but i have used the CSS from the swaggerUI project so it should have the same look and feel but applicable to this project,

[RicoSuter]

As you can see here:
https://github.com/RicoSuter/NSwag/tree/master/src/NSwag.AspNetCore/SwaggerUi3
we bundle the js/html for Swagger UI in the nuget package.

We could have your UI either in an own repo or even in this repo and then in the CI build we rebuild it and update the js/html in this folder so that it is automatically distributed and easily "hostable"...

[RicoSuter]

Another question: Is your UI reading the SigSpec specification from UseSigSpec() and building a dynamic UI based on that?

[RicoSuter]

/cc @bradygaster this might interest you

[RicoSuter]

BTW, before you couple your UI too much on the current SigSpec specification we should discuss whether we should keep it as is or improve it so that we dont have to break it later.

e.g. it's currently using JSON Schema style and not OpenAPI style for nullability and other things.

[TomSmith27]

As you can see here:
https://github.com/RicoSuter/NSwag/tree/master/src/NSwag.AspNetCore/SwaggerUi3
we bundle the js/html for Swagger UI in the nuget package.

We could have your UI either in an own repo or even in this repo and then in the CI build we rebuild it and update the js/html in this folder so that it is automatically distributed and easily "hostable"...

Ah thanks I have been using NSwag as a basis for some of the work I have been doing. I think an extension method called UseSigSpecUI would be the way to go.

In terms of where the code should live I think it would be good to put it in this repo like you said so that its all contained here and will give people everything they need to start working on this project. We can still have a build step that publishes it to NPM like swagger-ui

Another question: Is your UI reading the SigSpec specification from UseSigSpec() and building a dynamic UI based on that?

Yes the UI is reading from the SigSpec json and building the UI based on that.

BTW, before you couple your UI too much on the current SigSpec specification we should discuss whether we should keep it as is or improve it so that we dont have to break it later.

e.g. it's currently using JSON Schema style and not OpenAPI style for nullability and other things.

Ye that is a good point i think it will be fairly easy to adjust the UI if the spec gets changed anyways.

I am not sure of the difference between the styles of code generation.