-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
$inspect(...).with(...)
#9737
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
Comments
I don't think the way this feature is currently planned is great from a developer point-of-view. As a user of Svelte, I understand that these are macros and so can do whatever the hell they want, but they still look and feel like they should abide by how JavaScript works. As such, having the functionality of |
Can you clarify with these two cases. Is the expectation that they would actually be identical, or would the first one omit the type that's included in the $inspect('>>> HERE', foo, bar, baz); // Output: '>>> HERE foo bar baz'
$inspect('>>> HERE', foo, bar, baz).with(console.log); // Output: 'init >>> HERE foo bar baz' That would be my expected/preferred behaviour, but maybe that could be considered confusing. |
Perhaps e.g. $inspect('>>> HERE', foo, bar, baz).with(console.log, true); // Output: 'init >>> HERE foo bar baz'
$inspect('>>> HERE', foo, bar, baz).with(console.log, false); // Output: '>>> HERE foo bar baz' Whether it should default to true or false I'm not too sure, though I'd probably lean towards false to make the example mentioned actually identical. Also questionable if it should be a config object rather than a simple boolean for easier extensibility in the future 🤷♂️ |
`$inspect` now takes 1-n arguments, and inspections modification happens through `.with(..)` closes #9737
Describe the problem
Some feedback we've had on
$inspect
is that this......is a common pattern that doesn't work with
$inspect
, as it only takes a single value argument (in order to prevent ambiguity when providing a callback function).Describe the proposed solution
@dummdidumm had a great idea — allow an arbitrary number of arguments, and put the callback in a
.with
method:Alternatives considered
n/a
Importance
nice to have
The text was updated successfully, but these errors were encountered: