@deringer I like the idea of documenting things more. I am not a good writer though :( Maybe it would be nice to write something about how magic methods works inside eloquent. But I am not sure.

Happy to have a read over any thoughts you might have @halaei, but as I mentioned, the magic methods in this context (query scopes) are documented. Perhaps if they're not clear, we could work on clarifying? :)

I don't think I have ever explicitly called the query method unless I had to conditionally build up the query.

I try write code in ways that is most intuitive to me so for me, it's written the way I would speak it.

"Get all flights that are active." => Flight::where('active', 1)->get();

Explicitly calling the query method is just more verbose and unnecessary. Flight::query()->where('active', '=', 1)->first(); is like saying "Query the database to get all flights that are active". Do you really need to say that, or should that just be understood? We all know that we're fetching data from the database by the way the code reads.

If I tell my coworker to send me some report, I don't have to explicitly tell him to go on outlook, attach the file, and then click send. It's already understood, and he'll handle that behind the scenes. Maybe if he's new to the company, then I will teach him what systems we use internally and how things work. After that initial process though, everything should just be understood.

Laravel works in a similar way. You can do things explicitly. You can avoid facades. You can avoid magic methods, but a lot of times, these things are there to help you and save you the hassle.

@thomaskim I use facades with ide_helper. ide_helper makes it more practical to me, because I don't memorize the list of functions and I am afraid of mis-spelling that is common to me, since English is not my first language. I don't know what fraction of laravel programmers use ide_helper as well.

There is an old saying "each to their own". I don't understand the logic, but if it works for you and you're happy go with it.

I admit, I was the same until I watched tonnes of Laracasts videos and I can honestly say that I am a thousand times better coder simply because I inherited @JeffreyWay 's way of coding. Although I got so much more to learn, I've only just learned about Traits.

Outside of the technicalities - there is a lot to be said for following conventions. In the laravel world Model::where('active', true)->first() is almost the universal style where-as Model::query()->where... would make people do a double-take (it did for me anyway).

You missed such a golden opportunity there, @miiikkeyyyy!

Did I, @deringer? lol

Let's have another aspect, how exacly are you binding variables for your views? Let's consider this example:

public function index(Request $request)
{
    $search = false;
    $stats = $this->statistical->getStats($request->get('timespan'));
    $data = $this->repository->getRecords($request->get('timespan'));
    // search was made, so we need to tell the template
    // and also because I want a third variable
    if ($request->has('timestamp') {
        $search = true;
    }

    // here we need to return the view
}

You can send them magically:

return view('site.section.index')->withData($data)->withStats($stats)->withSearch($search)

You can send them non magically:

return view('site.section.index')->with('data', $data)->with('stats', $stats)->with('search', $search)

You can use session (I think, never did this, but it should be working):

Session::flash('data', $data);
Session::flash('stats', $stats);
Session::flash('search', $search);
return view('site.section.index');

You can use compact:

return view('site.section.index', compact('data', 'search', 'stats'));

Or, you can send them with one with but as an array:

return view('site.section.index')->with([
     'data' => $data,
     'search' => $search,
     'stats' => $stats,
]);

I personally have always used the compact approach, but I am more and more finding myself using the last array-one-with approach, because for me it is the most readable version.

@LucasFecko I normally use the forth one, but the third one is also good, as long as I don't need to change variable names, and those $data and $search and $stats are defined. I think that view part is all magic. No option to escape from that! So I remain as compact as possible. Also instead of using general Request class, I define specific class with its own validations and phpdocs, then I do this:

public function index(StatsRequest $request)
{
    return view('site.section.index')->with([
         'data' => $this->statistical->getStats($request->timespan),
         'search' => $request->has('timestamp'),
         'stats' => $this->repository->getRecords($request->timespan),
    ]);
}

Or maybe not this much compact. I also consider injecting statistical and repository into inbox funtion rather than into class construction. I have a bad feeling about that 'search' key in your array. Why not giving timestamp into view instead of just its presence?

@halaei thank you for response. It's much better written than mine, that's true. The code was my recollection of a work I did on Monday I think, and when I am nervous and in a hurry I just write logical nonsense, I will fix it, thanks!

I am starting to not trust the compact method, that's just too magical for me now.

I had a weird PHP related issue with compact, so never got into the habit of using it. I like the array approach best.

@halaei out of curiosity, why don't you use the Request class? You appear to be reinventing the wheel.

@puzbie I am using request class. StatsRequest extends from Request with rules() method being overridden. In that I can validate timespan. If no validation is required, then I use Request directly.

Ah gotcha.

I use compact only if I'm passing through one or two variables. Otherwise, I manually create the array.

@miiikkeyyyy "Jeffrey's Way" haha

Ayeeee I didn't see that, haha!