-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[VarDumper] Add support for options in dump()
/dd()
#48667
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
base: 7.4
Are you sure you want to change the base?
[VarDumper] Add support for options in dump()
/dd()
#48667
Conversation
b90f2fc
to
1a3ab94
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for tackling this, that's a complex feature because the matrix of possibilities is huge.
Here are some random thoughts:
- I like the style proposed in the issue:
dump()->trace()->maxDepth(4)->values($var);
. I'm just wondering ifvalues()
shouldn't be nameddump()
orvar()
or ? - I also like the
dump($var, _trace: true)
style, which could work well with autocompletion if we describe the options as virtual arguments on the function?array{_trace: bool, ...}
- instead of trace_limit, what about
trace: bool|int
? - have a look at
FrameStub
/TraceStub
for dumping traces - we might want to provide a way to define the default options on the VarDumper class?
As states by @derrabus, this cannot work I don't really like the current object API: $options = (new VarDumperOptions())
->trace()
->stringLength()
; it's too long to type. We should not forgot we are a in debug context. So we want to be able to get a result ASAP. that's why we have the function That's why I prefer the second bullet point of @nicolas-grekas comment: dd($this, _trace: true, _maxDepth: 4); |
yes it can, see #48474 (comment) ;) |
This is ugly :) I really don't like it. And it's too slow to type. |
@ro0NL I mixed my thought :/ I was talking about: $options = (new VarDumperOptions())
->trace()
->stringLength()
;
dump($this, _options: $options); |
I agree the current object API is a bit much to type. I am 👍 to find a better solution. Should I try to implement both @GromNaN solution ( Also, I really like the solution proposed by @ro0NL. If I may find a drawback, I'm afraid this syntax could be difficult to be "discovered" by yourself without reading the documentation. |
The syntax that don't work is the one that rely on __destruct. |
1a3ab94
to
90438de
Compare
I updated the feature. The new version allows you to do both ways: // Passing options as named parameters
dump('Values', _trace: 5, _flags: AbstractDumper::DUMP_STRING_LENGTH);
// Use the options builder syntax
dump()
->trace(5)
->stringLength()
->dd('Values') // or ->dump('Values')
; Still investigating on how to use Also, I made the choice to only have the options builder syntax on |
90438de
to
0b25f56
Compare
1b933a2
to
c8f0cd9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
About the default options, I'd suggest configuring them via a VAR_DUMPER_OPTIONS env var. I'd go with a url-encoded string so that it's easy to turn into an options array
} | ||
|
||
if (self::requiresRegister($options)) { | ||
self::register($options); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this will change the options of the default handler when any options changes?
this would be unexpected to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
requiresRegister
helps on taking care of registering again the handler if dump/dd
is not called with the exact same set of options as the previous call (this should work great with options defined in an env var!). So if you call the default dumper (I assume what you called "default dumper" is the one called without any special option? I may be wrong 😄), it should be registered again with its default options.
I struggled a bit on this part, only a few options need a full and new registration. I may be missing something?
When dumping large objects, it could be nice to be able to have the possibility to dump only one or several properties instead of the full object. Something like: |
@nicolas-grekas thank you for the review, I'll check this out! The env var is also a great idea too, in my opinion. @dunglas I really like your proposition! Giving the size of this PR, I think it would deserve a separate one. Definitely keeping your idea this in mind 👍 |
d3ccb34
to
1916b04
Compare
1916b04
to
a596b1c
Compare
229123d
to
9be6dea
Compare
Hey @alexandre-daubois! We're currently working on Buggregator, and it can be used as a server for displaying dumps for the var-dumper component. I really like your PR with options. However, it would be great if you also provided the ability to add custom context as an array to a $options = (new VarDumperOptions())
->withContext(['language' => 'php'])
;
dump($this, _options: $options); This feature can be used in various scenarios, such as providing information about syntax highlighting for string dumps or offering details about the project to which a dump should be linked. Would you kindly consider adding support for custom context in the Thanks for PR! |
74b5287
to
59db402
Compare
Hey @butschster! Thank you for your interest in this PR! I kinda forgot about it, but I still think it is worth it to have this in the framework. About the context feature you're talking about: while I understand it would help in your case, I find it weird to add some context here that won't be used apart from super precise use cases. Two solutions here:
Anyway, I'll try finalize this PR. Thanks for digging it up! |
59db402
to
32f4839
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Coming back after a few months here, I'm wondering if this is worth the extra complexity...
We have an unresolved concern, which is that dump-handlers don't have to react to options, and we don't have an internal API to communicate those options to them. If we do want options, we need that API.
I'm wondering if we need this options class. We could instead document options using @param
on the dump() function, so that using them would look like: dump($var, _max_depth: 3)
. That might be good enough in terms of DX.
src/Symfony/Component/VarDumper/Tests/Dumper/functions/dump_without_args.phpt
Outdated
Show resolved
Hide resolved
a94b07a
to
df524cb
Compare
I pushed a rebased, cleaner version. I removed the Options class and replaced it with an array, which seems enough. Tests are fixed.
I wasn't exactly sure what you meant here. I updated |
b3bd92a
to
e1a90f4
Compare
|
||
if ($cursor->attr || '' !== $label) { | ||
$dumper->dumpScalar($cursor, 'label', $label); | ||
} | ||
$cursor->hashType = 0; | ||
$this->dumpItem($dumper, $cursor, $refs, $this->data[$this->position][$this->key]); | ||
|
||
if (false !== ($options['_trace'] ?? false) && $cursor->attr = $this->context[BacktraceContextProvider::class] ?? []) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
comparisons to boolean... you missed testing this is === true
:P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, _trace
can be either a bool or a integer. false
disables the trace. If it's an integer, we limit the trace size. Also, the limit is disabled if _trace
is <= 0. That's why we can't use === true
here 😄 But maybe limiting the stack trace isn't that useful and we may only accept a boolean for _trace
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, makes sense then, let's keep as is :)
e1a90f4
to
b700997
Compare
PR title and header needs to be updated to reflect the content of this PR, thanks |
dump()
/dd()
b700997
to
b477b6a
Compare
b477b6a
to
9077e4e
Compare
Should be better now @OskarStark |
Following up #48432, this PR brings an options builder to configure VarDumper's behavior thanks to a special
_options
named argument. Here is a snippet of it in action and a screenshot of the result. Feedbacks on UI are really welcomed, especially about the debug backtrace!