[5.6] Yet another blade helper @dump

[vinterskogen]

Why don't we also have a @dump helper along with @dd in our blade views? ;)

Example:

// welcome.blade.php
...

<div class="title m-b-md">
    Laravel
</div>

@dump(42, 'foobar', new \App\User)

It simply passes all given arguments to dump function and then prints the output.

No more old school dumping like so {{ dump() }}.

[GrahamCampbell]

Thanks, but 👎. I don't see the need for this, the original code you posted there looks fine.

[vinterskogen]

Well, currently both 'dd' and 'dump' methods (that are related to output debug data), as I remember, are fine:

• by their own
• on collection objects (\Illuminate\Support\Collection::dump())
• on test response objects (while testing) (\Illuminate\Foundation\Testing\TestResponse::dump())

By are they really not okay at views? I do feel dissonance about this.

[sisve]

Those methods aren't supported by everyone either. I dislike them and would like them removed. You cannot argue that since there's some weird part of the framework in once place, you can add more weird parts to another area.

[vinterskogen]

I can definitely argue that if someone prefer another way, they are free not to use them at all, due they all are optional. Think of them as kind of weird on not is the all about personal tastes. Also, I can notice that Laravel in fact is tightly integrated with Symfony's var-dumper component for a very long time by now. :)

[taylorotwell]

Going to hold off on this for now. :)

[vinterskogen]

Okay. But pretty sure someone will attempt to pull in a thing like this again sooner or later. :)

[jordyvandomselaar]

@dd should never have been merged either.

[sisve]

You mean #22293, and I agree that it shouldn't have been merged. This only shows to the randomness of the selection process. And the main argument seem to be "Eh, it's fine I guess [...]"

[byCedric]

Can't we create a simple library where you have all these "extra" blade helpers. Or even can list all the ones you want... I feel like there is a road in between, one where everyone can add stuff like @form and one where it isn't included by default. Also if built correctly, it should be fairly easy to include composer require laravel-blade-helpers --save. I really don't like all these helpers being merged into the core. And the lack of proper reasoning why one is merged and the other isn't is disturbing...

[jordyvandomselaar]

I find it effing annoying how {{ dd() }} apparently has to be shortened into @dd(). Now there's even more people using different syntax, and the quality of the helpers added is in decline. People seem to be adding random crap for the heck of it.

[Miguel-Serejo]

@dd() is a whole 5 characters shorter than {{ dd() }}. That's 50% less code. @dump() is also 5 characters shorter than {{ dump() }}, but it's only roughly 41% less code, so I guess it doesn't quite make the cut.

Code size is often ignored, but for some people running their production code on old hardware or embedded systems, these seemingly minute changes can be a big help.

[byCedric]

@36864 Please don't tell me you are either using {{ dd() }} or {{ dump() }} in production... Those are development methods and should never be used in production.

I'm also really doubting if removing characters would drastically improve the performance. If you are really interested in performance gains, try experimenting with object references and loop optimisations. Of course Laravel should definitely be runnable on older or "lesser fortunate" hardware, but I don't think we are gaining any performance by adding these blade directives.

[Dylan-DPC-zz]

@36864 so you want to save 5 chars but add 2 functions to support this?

[Miguel-Serejo]

In retrospect, I should not have attempted sarcasm before having my morning coffee.

I was trying to find a logical reason for adding @dd() but not @dump(), but the only reason I could find was immediately defeated by the fact that these are test functions that should never make it to production, coupled with the fact that it would only be a valid argument if the helper was being used quite a lot.

Sorry.

[byCedric]

Don't be sorry, healthy discussions are actually great! And maybe if somebody feels inspired by this he or she can come up with another point.

[jordyvandomselaar]

It's just that stuff like this makes the core overly bloated. There's already too many helpers no one would need if they knew plain PHP, how strange it may be.

[freekmurze]

In recent versions of Symfony the dump will return what was passed into it.

So doing this in a view {{ dump($var) }} will be a bit problematic. After the dump function has displayed the contents of the passed var, Blade will try to display the return value. And because {{ is used it will output gibberish.

So it might make sense to have a @dump Blade directive that discards the return value of the dump function.

[Miguel-Serejo]

Or just <?php dump($var) ?>

Or just ignore the gibberish since it's just a debugging tool and you can easily identify what you dumped vs what gets echoed afterwards.

[byCedric]

Yeah, or even use the Blade version of <?php => @php 😉

[vinterskogen]

Heh, it was pulled in, but in different PR - #23364.

[jordyvandomselaar]

Are you kidding me -.-