Category: Laravel

It’s the wrong way round, don’t do it. Your models need access to data without any N+1 issues from using Lazy load. So if you need to merge some data streams and return a collection, rather than use a repo call to access each stream object; Create a view table which `Union ALL`’s the data various models. Then the model can have lazy load access to all the things you need, and the laravel commands, `->with()` or `->load()` can work without slowing it all down

2. Laravel Collective “Custom Components”

Laravel Collective packages have been staple Laravel components for a while now, however I’ve never quite got to down all the docs (just whizzed on with the bits I need).

I’ve found the Custom Components part method. Before I’ve been creating a new “HTML Components” service class and linking up blade template files with that, however, now I can just keep it within the HTML Facade without any trouble. Much cleaner!

This morning was spent fixing something, which frankly, I should have known better! However, when you’re coding and project managing on your own, it’s not easy to keep everything rolling.

When I write new Repository methods, I leave a comment note @totest to remind me to come back and write some tests!

However, I’ve missed writing 2 simple types of tests which would have taken 20 mins and then saved me an hour this morning. So I thought I’d share with you lot.

In My Laravel Middleware I have a method which checks the UserId provided is one of our students.

$user = $this->userRepo->findByUidOrFail($this->fetchUser());

However, because I haven’t filled in any tests on that Repo yet, I’ve been going around the houses trying to fix a problem which some simple unit tests would have flagged 2 days ago. The return wasn’t erroring if the user isn’t there AND was returning a Collection when it should have been giving me a Model…

So along with unit testing positive results from a successful method call, we should be writing two other types of tests.

The Exception Test.

Clearly this method name says, find…OR FAIL!!!! However, it wasn’t throwing a ModelNotFoundException on failing, it was just returning a Collection!

The returned type Test.

It seems weird to test you’re getting the write variable type back, however, it’s crucially important. Because what if you expect an integer, 2, and you’re returned a string of “2”. Any triple if’s === would fail and probably throw something else off.

So we test for cast types. In this example, I assert the Model by looking for a certain method’s availability or not.

Since using it in one of our major projects I have found it not all that great. So, yes it’s nice having it split from the Repo which I see as a way of searching on data, however, it’s a pain in the wotsit to test. Also, in Laravel it seems to add a lot of extra un-necessary time to my workflow.

The real problem however appears to be a mis-interpretation of what Commands are used for. Since Laravel 5.1 was released it has re-named Commands to Jobs. Highlighting that they should be used more so for delayed tasks rather than, inserting new models NOW!

So, it’ll take time to un-do I imagine and move them into the repository, however I’m glad I tried it as I’ve learnt a lot about testing!