feat: custom devtools formatters #13070
Conversation
|
| 'div', | ||
| {}, | ||
| ['span', { style: 'font-weight: bold' }, '$state'], | ||
| ['object', { object: snapshot(object), config }] |
There was a problem hiding this comment.
I think this line is why it's not working in FF. The "object" type isn't supported it seems, so we'd have to manually do it with own own styled divs/spans?
There was a problem hiding this comment.
Ah. Surprising that I learned about "object" from firefox-source-docs.mozilla.org of all places. I guess this is why Chrome has 174% market share and Firefox has -42%.
We could construct our own representation but it might be a challenge to make it look consistent with normal object logging across browsers and light/dark modes. We might have to settle for unstyled text if we attempt this.
|
There's another downside to this – the console.log doesn't actually produce the object until you click the arrow. So it's a bit pointless if you want to know the value of something at a given time? Surely there's a way around this though. |
|
I think that's fine somewhat - it certainly is in line with how it works for console logging POJOs as well. If you need a snapshot, well, use |
Ah it appears to be fine actually. I was messing with some other setting and forgot to remove it. |
|
Yeah, I called that out upthread ('you always have to expand it to see the properties') but if we were to generate string representations that worked across browsers then maybe it would be okay. It's not the same as POJOs — they get a preview before you expand them |
|
"String representation" as in like JSON.stringify? Because that could amount to walls of text, where I would prefer the "not expanded by default" nature of POJOs. Maybe there's a sensible default here (under 100 characters, just raw text, over that, do more elaborate stuff). Or "string representation" as in "construct our own div soup which browsers will render fine"? |
|
We can look at how the Chrome dev tools handles it and copy that, as I assume they use the same API :P |
More like how devtools print the first
Do you know where the code lives? Even if we could, it's subject to change at Chrome's whim and it would look out of place in Firefox — plain text might end up being simpler |
|
I think it's somewhere here - from a quick looks it's not that straightforward. So it would different in Firefox anyway, which I think would be fine. I certainly don't want my potentially giant objects always be printed in full. |
|
Yeah, let's do plain text |
|
I meant this as in "I don't want plain text in the sense of JSON.stringify(...)", because I don't want to clutter my console. I want this... ...not this... ... but I would be in favor of concatenating a poor man's preview ourselves, if that helps firefox. |
Wrap console.log/warn/error statements in DEV mode with a check whether or not they contain state objects. Closes #13123 This is an alternative or enhancement to #13070. Alternative if we deem it the better solution. Enhancement because it's not as robust as a custom formatter: We only check the top level of each entry (though we could maybe traverse a few levels), and if you're logging class instances, snapshot currently stops at the boundaries there and so you don't get snapshotted values for these (arguably this is a more general problem of $inspect and $state.snapshot), whereas with custom formatter it doesn't matter at which level you come across it.
|
Opened #13142 as an alternative/enhancement to this |
|
I'm going to close this, because #13142 is a far more consistent and reliable experience that will nudge the community towards better patterns. Having to click the collapsed object to see the snapshotted value sucks, and the alternative (attempting to format it ourselves) is just a recipe for sadness and regret |
…ts (#13142) * feat: provide guidance in browser console when logging `$state` objects Wrap console.log/warn/error statements in DEV mode with a check whether or not they contain state objects. Closes #13123 This is an alternative or enhancement to #13070. Alternative if we deem it the better solution. Enhancement because it's not as robust as a custom formatter: We only check the top level of each entry (though we could maybe traverse a few levels), and if you're logging class instances, snapshot currently stops at the boundaries there and so you don't get snapshotted values for these (arguably this is a more general problem of $inspect and $state.snapshot), whereas with custom formatter it doesn't matter at which level you come across it. * lint * use normal warning mechanism, so we can link to docs etc * add a few more methods --------- Co-authored-by: Rich Harris <rich.harris@vercel.com>
A few people have been tripped up by the extremely useless way in which
Proxyobjects are logged to the console — rather than logging what the proxy itself reports about its shape, they print the original target object (albeit behind several clicks), along with (for reasons I cannot fathom) the handler. Since Svelte doesn't mutate the original object (for good reason) this makes the logs unhelpful.The proper fix is to snapshot the object (
console.log($state.snapshot(object))) or, better yet, use$inspect. But for people as-yet-unfamiliar with those tools, it would be nice ifconsole.loggave a better experience.I tried monkey-patching console methods so that we could at least print a warning ('use
$state.snapshot, it's better') but that means you no longer get a clickable link to the place where the log happened, which sucks.It turns out, via @trueadm, that custom formatters are a thing. This PR does two things — if you haven't enabled custom formatters, it prints a warning suggesting that you do so...
...and if you have, it prints this when you log state:
Annoyingly, there's no straightforward way to generate a preview (i.e.
$state ▸ Object { count: 1 }), you always have to expand it to see the properties.More annoyingly, this only really works in Chrome. Firefox 'supports' custom formatters, but it's so broken (it seems to just log a non-expandable
Object { }, ignoring what the formatter returned and hiding the object contents) that once again I find myself wondering why they bother at all. Safari doesn't support it at all AFAICT.Is this worth it? I can't tell.
Before submitting the PR, please make sure you do the following
feat:,fix:,chore:, ordocs:.Tests and linting
pnpm testand lint the project withpnpm lint