Table of contents
- Getting Started with Laravel
- Learning beyond the Docs
- Using Tinker
- Using `dd(debug_backtrace());`
- Learning from other Laravel Projects
- People Behind the Framework
One of the best things to happen to developers in the 21st Century is open source, at least for me. The ability to look under the hood of some of the key software applications out there is very powerful. Not only do you better understand the software, but you become a better developer as well.
Getting Started with Laravel
Before Laravel I did most of my PHP projects in either Yii [↗], CakePHP [↗], and Slim [↗] for my APIs. Then the Laravel hype got to me, So on my next project I decided to try it out and it turns out it lives up to the hype. It had some interesting concepts that I wanted to understand.
Learning beyond the Docs
The default place to look up things you can do with any piece of software is its documentation. I must mention that Laravel has very good documentation. But then again the single source of truth is the Laravel codebase. Documents are prepared based on what is present in the code and the code is literally on my local machine compared to the hosted documentation. So why not look up that instead :). You might be thinking this is hard to do. It's very easy.
For example, let's say you want to work with Laravel’s collection, which provides an intuitive way to work with arrays. To make a collection out of an array, you need to pass it through the
collect(["name"=>"joe"]) now depending on the editor or IDE you use you should be able to locate where the collect method is defined within the Laravel codebase.
With most IDEs pointing your cursor at the keyword and pressing down on CTRL or Command will show you where this keyword is defined and sometimes places you have used it. With this, you see exactly how the function does what it does and even discover other callable methods.
For me, this is gold as at a glance I can see what is possible.
This saved me one time when I had code for counting my collection
collect()->count(). The Count method is just a wrapper around the internal PHP
count function and so I knew if the
collection ever ended up being a string I will silently get back
0 so I
handled that nicely as the collection count method won’t do that for me.
Well once I get to see all the options I have for a given concept, class, or function I immediately try out these methods using tinker. Tinker is the built-in REPL for Laravel. You have access to all Laravel classes and connected DB within this REPL.
It also has some cool features which I won’t get into, but as mentioned it's one of the quickest ways for me to try out stuff I discover within the framework.
From the above, you will notice it also shows you the namespace which
collect belongs. I can keep going down the rabbit hole by following the namespace.
Alright, so we’ve looked at how to discover Laravel's built-in features. Another interesting thing to look at is how Laravel handles the request/response cycle and flow.
For me whenever I need to understand the flow of any PHP project I pull out
die(var_dump(debug_backtrace()));. I drop this at any part of the code I
understand and run the app once again, view this in my browser and I end up with
a complete execution stack up to where I dropped the debug method. I can then follow through and understand how each class/method/file processes the request and hands over
execution to the next. This gives me an understanding of how the app works as a whole. With Laravel it gets even better as we can replace
dd so we end up with
dd(debug_backtrace()); which gives us something much more pleasant to the eye.
So above I have the complete execution path till it gets to
You can see that the request came through the
Controller.php file from within the
Routing package. Oh by the way the laravel framework itself is based on a bunch of packages together known as illuminate which you can find on
GitHub [↗]. There used to be lots of Symfony packages in there as well. With every new release of Laravel, I run
to see if there are any changes in the request/response flow. You get to learn a lot by doing this. Also, it might take you a while to understand exactly what happens at every point.
Learning from other Laravel Projects
One interesting thing about code is that not even the authors of the tools can completely predict how developers will be using some of the things they created.
For example, some developers use blade for scripting and others as a stand-alone tool for creating static sites [↗]. This is also true for other components within the framework.
One of the best ways to pick up some of these things is to read the source of Laravel-based projects. One of the ways I decide which project to look at is through the GitHub PHP trending list [↗]. This shows you a list of new interesting Laravel projects with fewer commits. I can now follow the progress of these projects and learn as they grow. Also, the few contributions I have made have been because of this process.
People Behind the Framework
One other important step that I take is to look up those involved with the
development of Laravel. This not only allows me to keep up with the state of development of the framework. It also gives me a sense of why something exists or was added. I picked this approach up from school, where the only way I could understand something like calculus was to follow the life story of Newton and how he uncovered calculus. Also, for something like PHP following the story allowed me to understand why we have
str_replace which is
because the implementations are by two different people :).
Anyways, these are some of the techniques that I use to learn new things in tech.
There might be more that escaped me but hopefully, you find some of these techniques useful and apply them as you uncover the inner parts of Laravel.
Here is another article you might like 😊 "I love the internet habitat f**k MARS"