One of the best things to happen to developers in the 21st Century is open source, at least for me. The power to look under the hood of some of the key software out there is mega. Not only do you better understand the software, you become a better developer by learning as well.
Getting Started with Laravel.
Prior to 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 its hyped for a reason.It had some interesting concepts that I wanted to understand.
Learning beyond the Docs
The default place to look up possible 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 code base. Documents are prepared based on what is present in code and the code is more accessible to me than the docs. So why not look up that instead :) . You might be thinking this is hard to do . Its very easy . Example
lets say you want to work with Laravel’s collection, which is a nice way to work
with arrays. To make a collection out of an array you first collect it eg
collect(["name"=>"joe"]) now depending on the editor or IDE you use you should
be able to locate where the collect method lives by placing your cursor on it.
With most IDEs pointing your cursor on the keyword and pressing down on CTRL or Command will show you where this keyword is implemented and sometimes places you have used it. With this you are able to see how this is implemented as well as discover other callable methods.
For me this is gold as at a glance I can experiment and know what more I can do
as well as understanding how these things are implemented. This saved me one
time where I had code for counting my collection
collect()->count() . Count
is just a wrapper around the 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 default REPL which allows one to try out Laravels components without having to deal with views. Its similar to the rails and Django console.
It also has some cool features which I won’t get into, but as mentioned its one of the quickest way for me to try out stuff I discover within the framework.
From the above you will notice it also gives the namespace which collect belongs to. From there I can also go ahead and look it up some more.
Alright so we’ve looked at how to discover some of the things packed in Laravel for developers. One other important piece is understanding how Laravel deals with the request/response 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 this. 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 even better we can replace
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
Routing package. Ow by the way the laravel framework it self is based of a
bunch of packages together known as illuminate which you can find on
Github. There use to be lots of symfony parts 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 pages. This is also true for things within the framework.
One of the best ways to pick up some of these things is to read the source of Laravel projects by other developers. One of the ways I decide which project to look at is through the Github PHP trending pages This way am more likely to find young Laravel projects that have smaller footprints. I can now follow the progress of this projects and learn while its grows. Also the few contributions I have made has been through this process.
People Behind the Framework
One other important step that I take is to lookup those involved with the
development of Laravel. This not only allow me 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 stumbled on Calculus. Also with something like PHP following the story
allowed me understand why we have
str_replace which is
because the implementation is by two different people :). Anyways.
These are some of the techniques that came to mind that I use. There might be more that escaped me but hopefully you find some of these techniques useful, And apply them as you try and understand the inner parts of Laravel.