I dont know why travis fails for php 5.6 && 7 and Its fine for 5.5 && hhvm. my code is 80% js

I understand the need but the current interface (method) is really tailored to one single use case.
What if now I want to expand key foo.bar.baz? Then should we add a new method for each way of collapsing/expanding we can think of? Is there a more generic solution?

I think it is the best generic solution.
If u want replace foo.bar.baz the steps are

• add in array jsPropertiesDefault default Value like 'fooBarBaz' => 'hi'
• in js where used replace hardcode value to var fooVar = options.fooBarBaz
• To override default values call setJsProperties(['fooBarBaz' => 'bye!'])

ping @nicolas-grekas

I think its worth it. Here are a few suggestions:

I'd rename setJsProperties() to setDisplayOptions().
I'd add a third argument to dump(), called $displayOptions, that overwrites the default options when provided (and thus keep only one $this->displayOptions property, that holds the default config).
I'd then allow more display options. Dump limiting is controlled by a few more options, amongst them:

1. maxItems: max total number of items to dump
2. maxDepth: well, max depth
3. maxItemsPerDepth: max number of items per depth level
4. maxStringLength: max sumber of chars for strings
5. maxStringWidth: max number of characters per line for strings

1. and 5. are not applicable, but 2., 3. and 4. could also exist to control default collapsing of elements in the browser. I'd keep the same wording (maxDepth instead of collapsedByDefaultNodesHigherThan, etc.).

WDYT?

Ey Nicolas thx for your reply!.

• I think displayOptions var instead of (propertiesJs && propertiesJsDefault ) its perfect
• Add displayOptions to HtmlDumper->dump() its ok and we can also add to VarDumper::dump() because it can be used for CliDumper (in the future?), isn't it?
• maxItemsPerDepth and maxStringLength its ok, but maxDepth I think is ambiguos. It would be maxDepthByDefault or something like that.

I have a another question. Sorry if its a dumb question (is my 1º pullrequest here ...)
If I break a test like my pullrequest 62c6ab5 (build: https://travis-ci.org/symfony/symfony/builds/115623557 deps=high)
I think this test is looking for a bc breaks, because its executing in branch 3.0, and in my local machine all test are passed.

What is the process to correct or warn of this problem?
Thanks!

add to VarDumper::dump() because it can be used for CliDumper (in the future?)

This doesn't apply to CliDumper, because we are talking about collapsing options, which doesn't exist on the cli. We already handle these kind of limits (max depth) at the state extraction level, they are not exposed by the dump functions but could be one day (see #17290).

but maxDepth I think is ambiguos

that's the way it is now and changing it would be a bc break, no way to change :)

If I break a test

We'll look at them once the feature is ready, but the fix usually is to raise the lowest required versions in the composer.json file of the failing components (at least for the deps=low matrix line).

Status: needs work

What's the status of this PR?

currently working, I was on vacation

Hi,

If I use a single var to displayOptions, I break a some test like TwigDumpExtension.
What should we do to fix this problem?

I think it would be good, add a parameter in TwigDumpExtension to change displayOptions, but it can have a random number of arguments.

I am stuck :/

The option maxItemsPerDepth require modify all samp elements to ul because each row must be delimited by a element like li. WDYT?

Let's do maxItemsPerDepth later in an other PR then. I can't look at this right now but will definitely try it soon!

Continued in #18948
Thank you @MGDSoft !