Ask HN: How do you relate rendered HTML to the TypeScript file it came from? | Hacker News Reader

Ask HN: How do you relate rendered HTML to the TypeScript file it came from?

7 pointsjztan4 comments

Let's say we have a any web app (React, Next, whatevr framework. It has a App.tsx file and Button.tsx file. We start the local development server and use puppeteer to extract the content. You can use whatever frameworks, source maps, tools, etc. How would you take that string input and figure out the line number where the typescript actually occurred?

View on HN

You don’t.

This is where framework nonsense gets you in trouble. If you are troubleshooting in that way you are basically stuck doing a shift+ctrl+f through the entirety of a project string searching for something the resembles the HTML output of the code hoping the result you find is actually the result you need. Nonsense.

The reason why it works that way is because you are trying to find where certain content is generated from code, but that isn’t how the framework works. The framework is a generic solution for how to write code, an architecture in a box, so it solves basic functional concerns with content as an input. It then compiles your content input from something friendly to you, something that pretends to look like HTML into DOM instructions with events attached.

If instead the code is just a collection of functions that generate the DOM artifacts directly, without compiling from something unrelated, then it’s just a matter of organizing your functions into files by content type. Then you simply go to the correct file and look through the functions associated with DOM output. In a large project you can find what you need the first time without guessing and without string searches through the code about 80% of the time and another 10-15% of the time that place you first looked suggests the next place you should look.

There is a nifty SvelteKit plugin called Svelte Inspector[1] that lets you select an element in the browser and open the source file in you IDE. It doesn't always get the line number perfectly, but it's pretty good.

I think it is based on https://github.com/webfansplz/vite-plugin-vue-inspector

And this seems to be a similar tool for React: https://chrome.google.com/webstore/detail/react-inspector/gk...

There is also React Dev Tools: https://chrome.google.com/webstore/detail/react-developer-to...

If none of those suit your needs, I think most of them are open-source. So modify as needed~

[1]: https://joyofcode.xyz/svelte-inspector

This is where the debugger comes in. You can use the one built in to Chrome if you have your source maps set up, but it's often easier to use the IDE one (VScode and Webstorm both have it built in). You might have to set up ignored files (like the generic Next stuff and the node modules and whatnot), then set breakpoints either in the files you're working with (if you know) or at some sane entry point to your app in general (if you don't know exactly), then carefully step through the lines of code.

It's a bit of a learning curve but really powerful once you learn it.

Is that what you mean, or did I misunderstand? Like if you were thinking about it in terms of scraping someone else's code that you can't as easily debug, that's harder (you can still do it to some degree in Chrome, but it may be minified etc). Probably a lot of regex, assuming the string isn't obfuscated in code.

If you have source mapping you can do basically what C compilers perform which is symbol mapping. If you are trying to map the HTML content to source you have to "tag" each of the steps in the process so you can figure out where the content came from.

Reply on news.ycombinator.com