❔ Advice on Blazor+TypeScript debugging in Visual Studio
Hey there, I'm working on a Blazor Server app in Visual Studio. I've followed some guides on adding TypeScript, and got the compiler integration working with code isolation. That is to say, my Index.razor.ts gets processed into a Index.razor.js + source map. I can import the code into my component and call it just fine.
My question is about debugging this TS/JS. I read and tried to follow the MS guide here https://learn.microsoft.com/en-us/visualstudio/javascript/debug-nodejs?view=vs-2022, but the only breakpoints that are being hit are when I go into my browser dev tools, then set a breakpoint on the JS from within the browser. Visual Studio will notice that, and I can inspect objects at the breakpoint from either the browser or a temporal tab that shows up in VS. Breakpoints that I set in the TS or JS within Visual Studio directly are not being hit.
I feel like / imagined that I could set a breakpoint on the TS in Visual Studio, and deal with it from there -- is that just not how it works? I understand that the browser will be running JS, not TS, but from what I'd read I was under the impression the TS could be debugged directly. Am I just wrong on that point? Is it working as it should and my assumptions are incorrect?
Thanks for taking the time to answer!
Debug a JavaScript or TypeScript app - Visual Studio (Windows)
Visual Studio provides support for debugging JavaScript and TypeScript apps in Visual Studio.
5 Replies
yoy definitely can debug TS code 100% within Visyal Studio, for a "normal" setup
no idea how/if this works in conjunction with Blazor Server, cause Blazor Server is trash
the basic way this is supposed to work is that VS attaches to the browser process
when the browser kicks a breakpoint out to VS, VS pulls up the JS file and location specified by the browser
if that JS file has an adjacent source map, it uses that to pull up TS instead
when you set a breakpoint in TS inside Visual Studio, VS has to be able to tell the browser to set a breakpoint there
it sounds like VS does not recognize files being loaded in the browser, because the pathibg doesn't match up, or some other reason
ultimately, probably because of Blazor Server
okay, thanks for the response, i might spend a bit more time getting it to work with careful attention to the path mappings. your description of how it should work definitely makes sense
what do you consider to be a non-"trash" alternative framework?
i get where people are coming from in calling it webforms 2.0, but i'm not sure i understand where the hate comes from. is signalR really so awful?
it's got nothing to do with SignalR
Blazor Server manages to take the WORST aspects of all the different web UI paradigms, to achieve the one advantage of only having to write your own code in C#
for server-side-rendering frameworks, every user action that the UI needs to respond to requires a round trip to the server, and a subsequent full reload of the browser
for client-side-rendering frameworks, communication with the server is minimal, occurring only when server-maintained data is being retrieved or saved, and then the traffic consists only of that data, and nothing else
this sounds obviously better, and the tradeoff is in the compexity of the code to be maintained, and the fact that the only real way to make a client-side app is in JS
Blazor Server tries to take options from both, and ends up with the worst aspects of both
server-side-rendering ends up being simpler because state is maintained client-side, and then just passed around from one action to the next
Blazor Server takes the same approach as server-side-rendering, in that every user action requires a round trip to the server
but it actually swaps the rendering and state management
rendering takes place in the client, with a big pre-made JS library
and state is maintained on the server
this reduces the size of traffic for the round trips, since the server isn't re-sending a whole rendered HTML page in each action, but it ends up being pretty objectively worse
the client has to maintain a constant connection with the server to make the whole thing work
any intermittent interruption that SignalR can't accommodate results in corruption of the server-side state, and the whole thing falls apart
client-side apps can tolerate stuff like this because at least when errors inevitably occur, it doesn't mean the entire app has to be rebooted.
nearly anything else, honestly
if you want server-side rendering, Razor Pages or the Razor-based MVC are both good
if you want client-side rendering, bite the bullet on JS/TS or use Blazor WASM
Blazor WASM is not ideal, as there's still a LOT of improvement to be made to bundling and load times, but beyond the initial load, it works quite well, and is really fun to use
to me it feels like using WPF, but actually better
Thanks for the thorough responses, you’ve given me some things to consider. Have peace in all your dealings
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.