You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, thanks for all your fine work on NSwag. Just lately my team has made the journey from handrolling clients to generating TypeScript and C# clients for our platform using your marvellous tooling.
We bumped on one issue related to how the baseUrl for TypeScript clients is set. It's slightly related to this issue:
But subtly different. It goes like this: when we're developing our application locally we're serving up the front end of our app at http://localhost:8080 - webpack dev server. However, our API is being served up by ASP.NET Core at http://localhost:5000
The generated clients contain this line in the generated client code:
This code is problematic for one of our use cases. We have two potential baseUrls that we new up clients with.
When developing locally we pass "http://localhost:5000".
When deployed, our complete app: API, HTML, CSS and JavaScript generated from TypeScript all get served from the same location. So in that case we pass an empty string: "".
The first use case is fine. The second is problematic because of the behaviour of this.baseUrl = baseUrl ? baseUrl : "http://localhost:5000";. Namely that this is a falsey check. If baseUrl is null or undefined then we fall back to use "http://localhost:5000". That's desired behaviour. However, we also do the same for other falsey values including empty strings.
You can probably see where I'm going with this 😄
Would you be open to a PR that changed the constructor generated code in this case to something like this:
If you're open to the change I've suggested here I'd be happy to try pick this up. At present we're doing some string.Replace on our generated TypeScript client code to get to this place.
I'd expect that others have similar needs.
What do you think?
The text was updated successfully, but these errors were encountered:
Hello!
First of all, thanks for all your fine work on NSwag. Just lately my team has made the journey from handrolling clients to generating TypeScript and C# clients for our platform using your marvellous tooling.
We bumped on one issue related to how the baseUrl for TypeScript clients is set. It's slightly related to this issue:
#1198
But subtly different. It goes like this: when we're developing our application locally we're serving up the front end of our app at http://localhost:8080 - webpack dev server. However, our API is being served up by ASP.NET Core at http://localhost:5000
The generated clients contain this line in the generated client code:
This code is problematic for one of our use cases. We have two potential
baseUrl
s that wenew
up clients with.When developing locally we pass
"http://localhost:5000"
.When deployed, our complete app: API, HTML, CSS and JavaScript generated from TypeScript all get served from the same location. So in that case we pass an empty string:
""
.The first use case is fine. The second is problematic because of the behaviour of
this.baseUrl = baseUrl ? baseUrl : "http://localhost:5000";
. Namely that this is a falsey check. IfbaseUrl
isnull
orundefined
then we fall back to use"http://localhost:5000"
. That's desired behaviour. However, we also do the same for other falsey values including empty strings.You can probably see where I'm going with this 😄
Would you be open to a PR that changed the constructor generated code in this case to something like this:
This is code that I believe covers the intent of the current generated code but does it in a more specific way.
The behaviour is similar to the nullish coalescing operator which will be working it's way into JS / TS in future: microsoft/TypeScript#26578 / https://github.com/tc39/proposal-nullish-coalescing
If you're open to the change I've suggested here I'd be happy to try pick this up. At present we're doing some
string.Replace
on our generated TypeScript client code to get to this place.I'd expect that others have similar needs.
What do you think?
The text was updated successfully, but these errors were encountered: