-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[LoAF] Use sourceLine
and sourceColumn
instead of sourceCharPosition
for attribution
#16
Comments
I agree that this would be a lot more convenient for developers to see line/column instead of char position. In an earlier prototype that is actually how it worked. However-- Noam noticed that this was a perf regression, because it requires parsing the text (in order to find all the newline characters). This isn't something that happens typically and so it is expensive to do automatically. I wonder if it could be possible to request this type of parsing explicitly, after the LoAF fires, only once we know there is a client that is interested? |
Thanks for the reply! For more context, I'm sending the LoAF to an observability tool for later use and I'm trying to link the sourceCharPosition to the matching development file. I tried to replicate this in user space by using However it would be even better with the opt-in API you're suggesting. |
Oh that's a neat strategy to just polyfill on client. Neat! I might use
that!
I suspect that many scripts are dynamically rendered per request, and/or
minified, and require source mapping (not just to the UN minified file but
also to original source templates) and this seems best done server side,
anyway.
If the script is static, then char position should be sufficient to do the
line mapping on server as well.
It's neat to do on client, but I suspect there aren't many cases where it's
actually better, except for local debugging use cases.
Not sure though-- is there a use case where doing it on client is
specifically enabling? Ignoring just developer ergonomics?
…On Fri, Jun 28, 2024, 08:24 Nazim Saouli ***@***.***> wrote:
Thanks for the reply!
For more context, I'm sending the LoAF to an observability tool for later
use and I'm trying to link the sourceCharPosition to the matching
development file.
Agreed that natively paying that cost for every LoAF is probably not
great. A way to opt-in to it would be a good alternative.
I tried to replicate this in user space by using fetch and only-if-cached
request in order to retrieve the source file content if it exists in the
browser cache. I then compute the sourceLine and sourceColumn from the
sourceCharPosition provided by the LoAF and it seems to work well.
However it would be even better with the opt-in API you're suggesting.
—
Reply to this email directly, view it on GitHub
<#16 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADTZKQ4FVJIVZVHCGQDXC3ZJVIX3AVCNFSM6AAAAABJ53I4OSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJWG44TENJYGI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
yes you're absolutely right! However I'm working on an observability tool and I want to collect LoAFs for our users and link to their source code automatically. So my constraints are:
This is why I did that way. However it's good enough for a POC but I'm probably gonna hit CORS issues. If the opt-in API you were suggesting existed, I could let our users opt-in to that computation and accept the performance hit as a trade off to being able to monitor LoAFs. |
@mmocny Coming back to your idea about performing the parsing only once we know there is a client that is interested. What would be a good way to advocate for that and see if it could actually get included down the line? |
I think you just did :P @noamr for thoughts. |
I think this is better done in a service-worker than in the browser... Put the service worker between the document and the server that gives you the script, and tee the response stream to some processor that returns an array of line breaks. It should be trivial to create a |
Hey @noamr, thank you so much for your reply! Alright, sounds like a good path forward I'm going to give it a shot. |
Hi again! I found a way around this in the end but I do have a question on what So my question on this would be, is the sourceCharPosition pointing to beginning of a task that is executed by the browser? Meaning that in order to understand the performance issue we would need to also know the rest of the code executed in that task. |
It points to the "entry point" function, see key point in https://developer.chrome.com/docs/web-platform/long-animation-frames#better-attribution Also see issue #3 which we're currently working on. |
Source maps use line and column in order to map generated code to the matching line and column in the original file. It would make it a lot easier to link from the code attribution in a LoAF to the original source code if the LoAF could include
sourceLine
andsourceColumn
.Otherwise if you have some thoughts about how to achieve this using the
sourceCharPosition
I would be very interested. Or even more information about what that position refers to e.g. do line breaks count as 1 char?The text was updated successfully, but these errors were encountered: