16

And today in Laravel-land, how to take fluent APIs to the utmost consequences.

Better...? Seriously? All your lines got longer and you know have closures to run.

Comments
  • 2
    Um. Pass?
  • 1
    Did they have any explanation? Seems like utter bullcrap
  • 1
    Yeah, although it's awesome to have these methods available on the eloquent models, this looks like overkill.
  • 1
    i've used this just because Laravel people said its right way, they say the only advantage is passing the parameters... which was not the problem in the first place...
  • 1
    what makes me furious about laravel is how they assumed all php devs uses this format of braces

    public function foo()

    {

    //bar

    }

    i'm so furious!.
  • 3
    As a laravel dev, I can disagree that it makes it less readable. It is a specific tool that you might apply only as needed, for example when filtering a lot of data. I've built the shop metadata filters with these and it worked perfectly, especially when I had to allow one to be selected if the other is preset.

    Of course, as with everything in Laravel - it's up to you to decide if you need it. Suggestions are good as they might show something that you've missed :)
  • 0
    @potata would you clarify how bulkier code makes for more readability?

    I mean, you're plainly replacing standard control structures (if/else) by convoluted closures. This is much worse if you ever need an extra variable inside the query you're making - i.e. you must set your closure to "use" extra things. ugh.

    It MAY make sense when arrow functions arrive on PHP, but we're a bit far from that, yet. And this is not even a new concept on Laravel, to say they're "anticipating" something.
  • 0
    @elitedawn sorry, but not sorry. This ain't Laravel fault, this was decided by a body of decision-making PHP "elite", including a bunch of standard frameworks (www.php-fig.org). If you're new to PHP or have been living in a cave for the past years, it's called PSR-2, check an example of its styling rules here: http:///www.php-fig.org/psr/...
  • 1
    @igorsantos07 You see, it really depends. For me, a bulky code is symfony doctrine ORM but for them - our Laravel Eloquent is bulky as hell.

    So, keep that perspective in mind.

    Now, how does the logic extend? Well, if you are writing everything on a single file and single method - yes, if's are great, and might not be too bulky but I personally love to add each condition as a Scope in the model itself, so my query looks like this:
    Model::includeDiscounts(request('discounts')->hasImage(request('has_image')->....->get()

    Which in the model translates to a simple scoped $q->when($condition, function() {} );

    And that is how I create readable code.

    On the other hand, having whens - alow you to follow a DATABASE logic, rather than being separated by if's/elses, so that's personal preference what you want :)
  • 0
    @potata hmmmmmm got it. So what I posted was pretty much a dirty example, with a bad use-case, I guess.

    Nonetheless, when() is going to be quite better with arrow functions from PHP 7.4!
Add Comment