I can’t quite believe it’s Friday again already. I mean, it’s nice and all because of the weekend, but I never feel like I’ve achieved quite as much as I had planned.
This week I saw a really interesting ‘thread’ (is that the right word?) on Twitter from the Laravel community showcasing interesting projects being worked on:
#Laravel people. I want to see what you’re working on. Send me all the links.
— Ian Landsman (@ianlandsman) January 17, 2017
(credit where it’s due, I found this via @davedevelopment, a really talented and knowledgeable dev who I would highly recommend you follow, if you don’t already)
Anyway, I think we should share our own projects in the same way. You already know mine – CodeReviewVideos – but I’d love for you to share yours. If you want to get in touch, reply here, or any of the other numerous ways to get in touch, and I will share any I do get in next weeks mail out, plus you will get a backlink from the blog. I can’t promise heaps of traffic, but as Tesco say, every little helps.
There have been three new videos added to the site this week:
I was recently on a piece of client work whereby an API had been created, and somewhere along the lines the business requirements had dictated a change in JSON output from camelCase to snake_case.
Now, there’s a couple of points that need to be addressed here – firstly you’ve got your output (GET requests) which is the obvious one. But if you’re accepting input (POST, PUT, PATCH) then you need to ensure you update the associated form fields, and that’s a breaking change for API consumers.
Anyway, in this particular case the externally visible change had already been made. But to make the change, the devs had decided to fudge all the class properties from camelCase to snake_case, which in turn, caused some additional, seemingly unrelated problems. Most of the time when you circumvent the way Symfony expects you to work, you’re going to open an entire pallet of cans of worms that should make you sit up and think – hey, we cannot be the first people who want to do this. What’s the right way to do it?
In this video we cover the simple way to do this that ensures your view concerns don’t need to affect your model concerns. And if you’re in a similar position and need to handle the GET / read side of things, one easy way is to use JMS Serializer’s SerializedName annotation.
If you aren’t using PHPStorm then I would strongly advise you to give it a try. For Symfony there is an excellent plugin – the Symfony plugin being the most essential.
However, regardless of whether you “do” Symfony, Laravel, one of Zend’s offerings, vanilla PHP, WordPress, Magento… (the list goes on), then your code quality stands to be improved by using the PHP Inspections EA Extended plugin.
Honestly, this plugin is fantastic. Unless you have the cold, artificial heart of a PHP codebot, I am confident this plugin will find at least one ‘problem’ in your code that could be improved. My favourite feature is how it finds code that may throw exceptions somewhere down your stack, which you may very well not be handling – or at the very least, not documenting.
This one is well worth the 30 seconds it takes to install, and I cannot recommend it enough.
Lastly this week we covered testing the “unhappy path” through the AuthSaga in our React / Redux / Redux Saga > Symfony 3 API project.
In this video we look at how we can quickly test a couple of problem areas:
1. Ensuring our saga throws when a call to api.login fails, and;
2. Ensuring our saga throws if the api.login response doesn’t contain a token in the response body.
As a side note this week I’ve been playing with JavaScript’s MobX as an alternative approach to Redux. Whilst I like it, I still think Redux Saga is the easiest way to write code that is extremely testable, which means you gain that much higher level of confidence that it will work now, and in the future even when you inevitably change stuff.
Until next week, take care, and happy coding.
Chris
