Forem: Richard Bagshaw

Mocking Dependencies with PHPUnit and Prophecy

Richard Bagshaw — Sun, 04 Aug 2019 12:40:12 +0000

Unit testing is an essential part of development and programming these days, and within the PHP community, the most widely adopted is PHPUnit.

I've seen various unit testing libraries and frameworks come and go over the years but PHPUnit seems to be the one that resonates most with me and is now pretty much my unit testing framework of choice.

During that time I have also tried a bunch of mocking frameworks, everything from the standard PHPUnit Mocking Library to Mockery, but my favourite is Prophecy, not only because of its simplicity to use but also because it ships as part of PHPUnit itself.

Before we jump into testing we need to make sure that we are on the same page, we need to mention dependency injection which will enable us to test our code in isolation.

What is Dependency Injection?

When running our tests, we will often be testing units of code that are dependent on other units of code within a project, these dependencies are usually injected into our classes using dependency injection which enables us to test in isolation.

Without dependency injection, our code would be tightly coupled, which would make testing very hard and in some cases impossible. Let's take a quick look at what dependency injection looks like in PHP.

// PizzaMaker.php

namespace App;

use App\Repositories\PizzaRepository;

class PizzaMaker
{
    protected $repository;

    public function __construct(PizzaRepository $repository)
    {
        $this->repository = $repository;
    }

    public function makePizza(array $toppings) : Pizza
    {
        $pizza = new Pizza($toppings);

        $this->repository->save($pizza);

        return $pizza;
    }
}

In this example we have a PizzaMaker class which is responsible for making Pizza, however you will see that when we call makePizza() we are creating the new Pizza and then passing what we have created into the save() method of a PizzaRepository()

The PizzaRepository class deals with persisting the Pizza to the database, and for this reason, it has to send a request to a database to store this information.

When we are running our tests, in most cases we want to avoid hitting the database, if we don't then our test suite will becoming reliant on our database connection and will slow down our tests.

This isn't so much of a problem when you have one or two tests, but when you have thousands you could be waiting 20 minutes for your entire test suite to run.

Hitting the database and services means slower tests

You may be sat there wondering why waiting this long for slow tests is a problem? Well, it's because we want very fast unit tests so that we can have a fast feedback loop in the red, green, refactor cycle.

If you're waiting a long time for tests to pass then you simply won't run them, and you certainly won't adopt TDD to drive out the design of your code.

Let's have a look at the PizzaRepository in our example, this is usually the class that is making calls to the database, however, in this case, we are using sleep(3) to simulate a slow call to a database.

Also, just to note, I know the database wouldn't usually take 3 seconds to save a record, I am just using this as an extreme example of slowing down our test suite so we can see the difference clearly with just one test.

// PizzaRepository.php

namespace App\Repositories;

use App\Pizza;

class PizzaRepository
{
    public function save(Pizza $pizza)
    {
        // Simulate a long running database action for 3 seconds.
        sleep(3);

        $pizza->save();

        return $pizza;
    }
}

Next, let's create the best type of pizza in the world and create a simple test to make sure that we can create a Pizza using the makePizza() method on the PizzaMaker class.

// PizzaMakerTest.php

use App\PizzaMaker;
use App\Repositories\PizzaRepository;
use PHPUnit\Framework\TestCase;

class PizzaMakerTest extends TestCase
{
    public function test_it_can_create_an_hawaiian_pizza()
    {
        $pizzaMaker = new PizzaMaker(new PizzaRepository);

        $pizza = $pizzaMaker->makePizza([
            'Ham',
            'Pineapple'
        ]);

        $this->assertContains('Ham', $pizza->getToppings());
        $this->assertContains('Pineapple', $pizza->getToppings());
        $this->assertNotContains('Fish', $pizza->getToppings());
    }
}

Next, we need to use this fast feedback loop, let's run our test suite and make sure everything is working correctly and that our test is green.

Victory! it passed! - however, let's not get the champagne out just yet, there is a big problem with this test, take a look at the time it took to run this one single test alone.

Time: 3.02 seconds, Memory: 4.00 MB

Ouch!, that one test took a whole 3.02 seconds to run, that's not good.

It should be pretty obvious at this point that by running our test we are also calling the save() method on the PizzaRepository class which is very slow.

What is a mock and why do we need it?

A mock is used when we want to replace a dependency of a class that we are testing, in our example above the test is running so slow because we are indirectly calling the save() method on the PizzaRepository class which contains a sleep(3)

We simply need to replace this dependency with a mock, that looks and probably acts the same, but doesn't save anything to the database or have that horrible sleep(3) call inside it.

Creating a mock with Prophecy

All we need to do is create a mock of the PizzaRepository dependency and then pass that into our PizzaMaker class when we are testing, let's refactor our test a little bit to show how this would look.

// PizzaMakerTest.php

use App\Pizza;
use App\PizzaMaker;
use Prophecy\Argument;
use PHPUnit\Framework\TestCase;
use App\Repositories\PizzaRepository;

class PizzaMakerTest extends TestCase
{
    public function test_it_can_create_a_hawaiian_pizza()
    {
        $repository = $this->prophesize(PizzaRepository::class);

        $repository->save(Argument::type(Pizza::class))
                   ->shouldBeCalledOnce();

        $pizzaMaker = new PizzaMaker($repository->reveal());

        $pizza = $pizzaMaker->makePizza([
            'Ham',
            'Pineapple'
        ]);

        $this->assertContains('Ham', $pizza->getToppings());
        $this->assertContains('Pineapple', $pizza->getToppings());
        $this->assertNotContains('Fish', $pizza->getToppings());
    }
}

Before we run the test again to see the results, we have a few things to talk about here since we have added two extra lines of code and modified a third.

On the first line of the test, we added:-

$repository = $this->prophesize(PizzaRepository::class);

This will create a new mocked instance of PizzaRepository, it will look the same, however, all the methods on this mocked class will do nothing when called, this includes the slow running save() method which will just return null in this case.

On the next line, we are setting some expectations, we don't care if the PizzaRepository actually saves the data, all we care about is that it is asked to save the data correctly.

$repository->save(Argument::type(Pizza::class))
           ->shouldBeCalledOnce();

Here we are setting some expected behaviour on our mock, something that we expect will happen to it when we run our tests, if these expectations are not met, then the test will fail.

In this example, we are setting the following expectations on the mocked PizzaRepository object.

The save() method will be called on PizzaRepository
The save() method will be called with an argument which is of the type Pizza. (if we tried to pass in an object of type Taco for example, it would fail the test)
The save() method will be called once and only once

The final modification to the test we make and the most important one is to change how we construct our PizzaMaker within the test. Since we have been clever programmers in our code and used dependency injection, this is easy.

Previously, we were constructing the PizzaMaker as follows:-

$pizzaMaker = new PizzaMaker(new PizzaRepository);

We were injecting the real PizzaRepository class, perfect for production, but not so good for testing.

Again, one thing to note here, we are not concerned with testing the PizzaRepository dependency, that has it's own separate tests elsewhere, all we are concerned with is testing the PizzaMaker class.

Okay, so let's replace the PizzaRepository in our test with the mock one we created and set some expectations on earlier.

$pizzaMaker = new PizzaMaker($repository->reveal());

Simple! however, you might be wondering what that reveal() call is, we never created that did we? where does that come from?

If we dump out the class type of the $repository object without the reveal we see the following:-

var_dump(get_class($repository));
// string(32) "Prophecy\Prophecy\ObjectProphecy"

And let's take a look at what we get back when we do the same but adding the reveal() call.

var_dump(get_class($repository->reveal()));
// string(42) "Double\App\Repositories\PizzaRepository\P1"

Okay, this is interesting, we have a class of Double\App\Repositories\PizzaRepository\P1 but where does that fit into everything? what is it?

Let's use the PHP Reflection class and do some more digging to see if we can figure out what's happening here.

$repository = $this->prophesize(PizzaRepository::class);

$class = new ReflectionClass($repository->reveal());
$parent = $class->getParentClass()->getName();

var_dump($parent);
// string(32) "App\Repositories\PizzaRepository"

Aha! so the parent of the Double is string(32) "App\Repositories\PizzaRepository" which is why our PizzaMaker is happy to accept this through dependency injection.

Okay, enough of this digging around in the weeds, let's run our test.

See how much faster that is? 26 ms versus over 3s when we weren't mocking it.

We have created a mock instance of the PizzaRepository, set some expectations that should be called on the PizzaRepository and then used reveal() to get our mocked version of the PizzaRepository which is a child of PizzaRepository and then injected that into the PizzaMaker with dependency injection.

This is just a really simple example of a mock, we can also create different types of mock classes which I will go into in another post.

Should we mock everything then?

The simple answer here is no, and it's quite easy to feel the temptation to mock everything, but it's not a good idea.

For example, if you are testing a class which has a dependency which does some string manipulation, then I would generally just pass in that object if its simple and doesn't touch any 3rd party services or the database.

Just because you can mock it doesn't mean you should, sometimes just passing in an instance of a simple dependency is fine.

Also, be careful not to end up mocking the very class you are testing, this might sound obvious but you should only mock dependencies, I have seen developers who are new to testing attempting to mock the class they are trying to test, obviously there isn't much value in doing that.

Do what helps you sleep at night

As always, how much mocking and testing you do is largely up to you, don't try reaching for 100% coverage and don't mock every single dependency, just do what helps you sleep at night and use some common sense.

Javascript and the meaning of this

Richard Bagshaw — Mon, 29 Jul 2019 10:51:10 +0000

When it comes to the meaning of this in Javascript, it can be one of the most confusing things to learn and also the source of many bugs and issues. In this article, I want to talk about how to figure out what the this keyword refers to and under what conditions it might not be what you expect.

Figuring out what `this` means

There are four ways to figure out what the this keyword is referencing within your Javascript, these have some seemingly technical names but stick with me here as they are quite simple.

Implicit Binding
Explicit Binding
new Binding
Window Binding

What is binding?

Binding in Javascript refers to the idea that we can bind our function calls to particular contexts, we can do this implicitly and just let Javascript do its thing for us, or we can be very explicit and let Javascript know exactly what we want the this keyword to reference.

if that makes no sense, don't panic as I will be elaborating on each of these concepts with some examples, let's take a look at the most basic example first.

Implicit Binding

As you can see we have a Javascript object with three properties, a name, an age and a sayName() function.

const me = {
  name: "Richard",
  age: 42,
  sayName() {
    console.log(this.name)
  },
}

me.sayName()

Inside the sayName() function we are printing the name property out using console.log(), however, what does this refer to?

The key to understanding what the this keyword refers to, is to look at where the invocation occurs, in most cases, you can simply look to the left of the dot and see exactly what this will reference.

me.sayName()

Quite clearly, the this keyword in this particular case is referencing the me object, this is called implicit binding because at no point did we declare we wanted this, it just happened implicitly as part of Javascript.

In most cases this is what you will see in Javascript, however, there are some occurrences, especially in React components where we have to be explicit about our bindings.

Explicit Binding

Explicit binding is where you as a developer are explicitly defining what you want the this keyword to reference within your Javascript, this can be done using three separate functions which all provide us with the ability to bind to a context, but do it in slightly different ways.

call()
apply()
bind()

Call()

Let's jump in with a code example first, I will then explain exactly what we are looking at with the call() method.

const sayName = function() {
  console.log(this.name)
}

const author = {
  name: "Richard",
  age: 42,
}

sayName.call(author) // Outputs Richard

In this example we start off by declaring a simple Javascript function, this function is not part of any object and as you can see the this keyword is used within the function.

We also have an author object which contains a name and an age.

If we were to call the sayName() function on its own it would throw an error because within the function, the this keyword doesn't reference anything.

We can explicitly set what the this keyword points to by using the call() function. Using the call() function like this gives our sayName() function a context to work in and points this to author.

sayName.call(author) // Outputs Richard

We can also provide arguments with the call() function, let's look at another example of how that works

const sayName = function(food1, food2, food3) {
  console.log(this.name + ` likes ${food1}, ${food2}, and ${food3}`)
}

const author = {
  name: "Richard",
  age: 42,
}

const food = ["Pizza", "Tacos", "Lasagne"]

sayName.call(author, food[0], food[1], food[2])

As before, we are calling the sayName() function and using call() to provide the context in which we wish to call it, in this case author.

We are then passing through three arguments which we are pulling from an array of food, as you can see these arguments are then passed into the sayName() function like regular arguments which will allow us to console.log() them out.

Apply()

One thing you might not like is the idea of passing all these individual food items in with the context we wish to use, surely it would be better to just pass in the whole array?

const sayName = function(food1, food2, food3) {
  console.log(this.name + ` likes ${food1}, ${food2} and ${food3}`)
}

const author = {
  name: "Richard",
  age: 42,
}

const food = ["Pizza", "Tacos", "Lasagne"]

sayName.apply(author, food)

This is exactly what apply() does, it's the same as call() but instead of passing in the individual food items, we can just pass them in as a complete array and then call the function.

Bind()

The final way to explicitly bind is to use the bind() function, bind() is almost identical to call() but with one difference, instead of calling the function right away, it simply returns a new function with the required binding, let's take a look at an example.

const sayName = function(food1, food2, food3) {
  console.log(this.name + ` likes ${food1}, ${food2}, and ${food3}`)
}

const author = {
  name: "Richard",
  age: 42,
}

const food = ["Pizza", "Tacos", "Lasagne"]

const newFn = sayName.bind(author, food[0], food[1], food[2])

newFn() // "Richard likes Pizza, Tacos, and Lasagne"

As you can see, this works in exactly like call() except the function isn't called right away, in this case, the new function is assigned to a constant called newFn and we then invoke it on the line after (we could invoke this at anytime we like). This particular type of binding is often seen in React components, but I will go into that a little more later.

new Binding

The new binding is a very simple one to explain, anytime you use the new keyword in Javascript, you are binding this to the new object you're creating, a quick example of this might look as follows.

const Book = function(title, author, isbn) {
  this.title = title
  this.author = author
  this.isbn = isbn
}

const greatBook = new Book("Refactoring", "Martin Fowler", "0-201-48567-2")

console.log(greatBook)

The output of the above would be the new object we have created, which contains the title, author and ISBN which were set using the this keyword

[object Object] {
  author: "Martin Fowler",
  isbn: "0-201-48567-2",
  title: "Refactoring"
}

Window binding 🤮

The final binding I want to mention is window binding, I don't recommend using window binding as its essentially polluting the global scope, this can lead to bugs and all sorts of issues, but it's worth mentioning as it is still widely used sadly.

As always, let's look at an example.

const sayName = function() {
  console.log(this.name)
}

sayName() // undefined

In this context this is referring to the global scope on the window, we have nothing to the left of the invocation, no new binding, and no explicit binding. We could, in theory, fix this by specifying the missing name property on the window but please don't do this or <INSERT LIGHT-HEARTED THREAT HERE>

const sayName = function() {
  console.log(this.name)
}
window.name = "Richard"
sayName() // "Richard"

Why is knowledge about all `this` binding useful to know?

In our React components, we often have to be explicit about our bindings, this is because at the time of invocation from within our JSX we have no idea what the context is, and since components can be reused everywhere by nature, it may not always be the same.

Take a look at this example, at the end of the constructor() you can see that we are explicitly binding our switchOff() method to React component.

class App extends React.Component {
  constructor(props) {
    super(props)

    this.state = {
      mode: "on",
    }

    this.switchOff = this.switchOff.bind(this)
  }
  switchOff() {
    this.setState({
      mode: "off",
    })
  }
  render() {
    const { mode } = this.state

    return (
      <div>
        {mode === "on" && <button onClick={this.switchOff}>Switch Off</button>}
      </div>
    )
  }
}

ReactDOM.render(<App />, document.getElementById("app"))

In the above example we have a simple React component, the most important line is where we bind() the this keyword to this particular component at the end of the constructor() using the following

this.switchOff = this.switchOff.bind(this)

Without this line, the switchOff() function will not know what context to be called in since it was invoked from JSX.

Conclusion

As you can see, the this keyword is quite easy to understand when we look at each concept individually, I think the confusion arises around these little "Gotchas" which seem to be all over the place in Javascript.

Vue Scoped Slots - Screencast Tutorial

Richard Bagshaw — Wed, 24 Jul 2019 13:54:57 +0000

I put together a little video guide for scoped slots based on my blog post that I made earlier.

Enjoy

My Vim and Tmux Workflow for Web Development

Richard Bagshaw — Wed, 24 Jul 2019 10:31:06 +0000

In this video I show you my workflow that I am working on, Vim and Tmux

An Introduction to Gatsby.js

Richard Bagshaw — Wed, 24 Jul 2019 09:29:05 +0000

Modern web development is not something that can be picked up particularly quickly, in the current climate of web development there are just a tonne of things we need to learn as developers and this cycle of learning is a big part of every developers life.

We have front-end frameworks such as vue.js, react and angular, as well as webpack for creating our development and production builds, es6 and babel also need to be considered in most modern apps as well as CSS pre-processing with tools like PostCSS and tailwindcss.

On top of all this we also need to consider the back-end to support these applications such as Node.js, Laravel, APIs, database schema's, deployment strategies, development environments, CDNs ... whew! just an absolute tonne of stuff.

What is Gatsby?

At a very basic level Gatsby is a site / app generator which aims to solve all the above problems by having sensible defaults out of the box, however it is a little more than that.

Because what we are generating isn't exactly static as such, we are essentially generating a fully working react application that can be hosted anywhere where we can drop JavaScript and HTML, so hosting these applications on services like Netlify is a trivial task.

Gatsby can also pull in data from various sources at build time, so we will only need that API to be online and available whilst we are building our site, this will then result in a site build containing just HTML, CSS and JavaScript with all that API data then held in GraphQL which is almost like a static data-layer for your website build.

The two big advantages of doing it this way are speed and security, because we are hosting HTML and JavaScript there is no need for your website to be making HTTP requests to and from a server at run-time, this data is just held in GraphQL, for the same reason, there is no real vector for hackers to hurt you as such, sure they could "deface" your site, but all you need to do is create a new build with a single command and redeploy.

So I could write an entire blog post about why Gatsby is interesting, but I think we should get stuck into some coding, so let's get started with the installation procedure.

Installation

If you've installed any node / npm packages in the past then you'll be right at home here, installing Gatsby is a case of installing it globally on your development machine with a simple npm command. (you can also install with yarn)

npm install -g gatsby-cli

This will then give you a gatsby command right inside your shell prompt, you might need to logout of your shell and back in again to be able to see it, but you should be able to access it right away.

To create our first Gatsby site we just need to run the following command.

gatsby new my-blog

Running the above command will create a new directory called my-blog which will then contain your brand new Gatsby website, the next thing we need to do is spin up a local development environment, and luckily this has already been done for us as well!

We simply need to run these next commands and we are up and running ...

cd my-blog
gatsby develop

Gatsby will then start up a web development server with hot reloading included out of the box at http://localhost:8000 out of the box, another nice trick is that it will even reconfigure this for you to another port should 8000 already be taken, nice!

At this point you should be able to browse to your new development URL and see your shiny new Gatsby installation complete with hot reloading whenever you save a file.

Creating our first page with Gatsby

As with all site generators, the first task we need to take care of is creating our first page, in the app directory structure you will notice a src/pages folder, any .js files that you create in here will be translated into pages, the routing will be taken care of for you, so all you need to worry about is simply creating this file.

Let's have a look at the most basic hello world example for a new page, create a file in this pages directory and call it hello.js

import React from "react"

export default () => (
  <>
    <h1>Hello, World!</h1>
    <p>Welcome to your first Gatsby page</p>
  </>
)

At this point, as long as we still have our little development server running, you should see that adding this single file triggers a new build, you will then be able to navigate to http://localhost:8000/hello

With any luck you will then see our glorious new creation born into the world!

As you can see this process was very simple, if you don't know react then you may have some questions about the code that went into creating this page, so lets take a quick look at that.

import React from "react"

Since Gatsby is based on react we will be needing the react library, this is included into our project with this single import statement, at this point we don't really need any other dependencies, just react.

export default () => (
  <>
    <h1>Hello, World!</h1>
    <p>Welcome to your first Gatsby page</p>
  </>
)

There are a few things happening here, firstly we are exporting the following contents of this block of code so that other parts of our application can use it, think of this as a sort of component, and we are offering the following contents up to be used by Gatsby so it can then render it on the screen.

Next you can see these funny little empty brackets, these are react fragments, by default we are only allowed to return a single div or element from this function, which means that if we have sibling elements in our content (like we do with the h1 and the p tags) then we need to wrap these into a single div. A traditional way to do this in the past has been to actually use a div to wrap around the content, but the div then ends up in your HTML and provides no semantic purpose.

Using react fragments in this way allows us to wrap our h1 and p tags in this example, but no wrapping div element will be generated in the final HTML build, thus avoiding a "div soup" scenario where we have lots of useless wrapping elements in our code.

Linking between our pages

One final point I wanted to go over before we put the basics down is to talk about linking between pages, traditionally you may have linked between pages by creating a simple anchor tag on each of your pages, for example.

<a href="/">Home</a>

However, there is one problem with this approach we using something like Gatsby, and that is that the above will force a full page reload, so when you click on the link the entire page will reload before showing your content.

Instead, what we want to do is provide the ability for a user to click on the link, and only reloading the part of the app (in this case, the content) that has changed.

This means that our page will reload much faster has it never has to make the http request which would instantly add on a few hundred milliseconds, instead our application will fetch the page it wants to load as a component and swap it in the main content portion of the screen.

Lets take a look at an example of this in action.

import React from "react"
import { Link } from "gatsby"

export default () => (
  <>
    <h1>Hello, World!</h1>
    <p>Welcome to your first Gatsby page</p>
    <Link to="/">Home</Link>
  </>
)

As you can see we are simply importing the Link component from Gatsby which is given to us for free, and then we would use it in almost exactly the same way as we would a generic anchor tag except we use the property to instead of href

And that is literally all you need to do to link between pages, now when we click on these links, the pages will be reloaded into our app dynamically and we will not be fetching a new instance of our app from any back-end server, magic!

Conclusion

So let's take a look of what we have covered in this blog post :-

What is Gatsby
What problem is Gatsby trying to solve?
Installation with Node Package Manager (Yarn would be very similar)
Running our development environment with hot reloading
Creating our first page from scratch
React Fragments
Linking between pages and why it's better to not reload the full page

Of course there are way more parts to go over, but these are the basics, in later posts I will go over GraphQL, rendering, creating a list of posts, implementing tailwindcss and much more.

The Constant Learning Cycle of a Web Developer

Richard Bagshaw — Wed, 24 Jul 2019 09:25:09 +0000

I've been writing code since around 1987 and one thing that has stuck with me all this time is my passion for learning. I remember when I was around 10 years old, I was learning C on the Amiga 500 and had recently purchased a copy of "North C Compiler" from my local public domain library.

Public domain libraries were how we used to get software before the internet was a mainstream thing, These places were literally just middle aged guys distributing free software at a small fee to cover the cost of the floppy disks they were distributed on, this and DOS based bulletin board systems were the bread and butter of swapping and buying software in the 80s and 90s.

Learning new web development stacks and tools

As developers we are often tasked with learning a new stack or framework, I remember the first time I saw CodeIgniter after years of using generic PHP3, back then this was my first real exposure to a PHP framework and I was blown away by how much easier it made things.

Obviously, looking back it's easy to see just how simple and lacking these tools were, but at the time they were ahead of the pack and were the first exposure for many people in the PHP community to concepts such as MVC (model-view-controller).

Learning a new language or scripting language can be a daunting task, however I think it's always good to have a reason as to why you're learning a particular skill. Most of the time developers tend to find themselves in a situation where someone else has made the decision to use the latest and greatest JavaScript framework, and I think this is where we tend to most commonly learn.

This kind of approach for me is a more passive way of learning, yes you have a need to learn but you're only really learning it since your job or situation requires it, there is nothing wrong with this approach, I have done this hundreds of times, but personally I think about learning in a somewhat different way and therefore change my approach slightly.

Why we need to learn new skills as developers

The single most important part of being a web developer is your ability to learn new skills, I don't just mean frameworks and languages, but also general problem solving and communication skills, these are just as important and often overlooked.

The web development world moves ridiculously fast, and trying to keep up constantly will eventually lead to burn out, but since the ecosystem around us moves at such a fast pace it's important to learn new skills to stay relevant in today's job market, this includes full-time employment, freelance as well as contract work.

As a full time freelancer, one of the scariest situations to be in is to wake up knowing that your skills are outdated and not desired in the current market, this tends to happen when developers get stuck in jobs for years and take the comfort and security instead of stretching and forcing themselves to learn.

Many roles that I have worked in have promoted self development as part of the process, even providing budgets for conferences and learning materials, this is a fantastic start and if you have this available then you should 100% take advantage of it, however it's only the beginning, and this is where you need to build a company culture of learning.

A company culture of learning

This is a tricky beast, picture this situation, you work for a fantastic company, they provide you with a budget for learning and conferences, but nobody has the time. Everyone feels like they can't take two days off to go to that conference as it would put them behind in delivering that new feature, or worse still, their pull-request would go unmerged for another two days!

This situation in my experience is common, companies are so much better these days and want to do the right thing, but so often there is a culture within the company of "work hard, push to deliver" and very little time for learning and self development.

In a situation like this I think you have to lead by example and gently convince others to join you, I remember once working in a team of around twenty developers for a large mobile phone retailer, I managed to convince my manager to generate the budget to send us all to PHP North West, and out of those twenty or so developers there were literally two of us who took advantage.

This was crazy to me, the company were willing to pay for education of their employees, but nobody was interested, this was caused by the lack of learning and self development as part of the company culture, it was very much a case of push code, sling divs and work hard, in the minds of my peers there simply wasn't any time for learning even if it was free!

How I Learn Effectively

Different people learn in different ways, but I think my approach is the best of both worlds for my situation. Primarily I am a visual learner, I subscribe to a tonne of online learning resources both free and paid where I can watch a variety of different types of screencasts to learn a new topic.

I also like to read, I tend to read when I want to go into a topic in more depth, so as an example, if I were wanting to learn Vue then I would generally start with the documentation (which is excellent by the way) but quickly move onto picking up a course so I can see Vue in action.

Once I have gone through the very basics of something via the documentation and played around a little, I then add a little structure by taking an online course, this is not 100% necessary, but I feel it helps me arrive at the point quicker as the content is generally much more structured.

I also consume as much information as possible via other peoples blogs posts on the subject matter, as well as podcasts, books and even twitter.

One important aspect is to actually code, it's perfectly fine to watch an 8 hour course on something, but if you don't apply it then you simply won't retain any of the concepts.

Learn the concepts not the syntax

Learning syntax is something I see as secondary, it's something that just happens the more you use a language, using my memory to actively remember these different variations in syntax seems a little redundant to me, mostly because I can look them up easily on Google and within documentation.

Instead, I try to learn the concepts behind what I am learning, so as an example learning about scoped slots in Vue or dependency injection in PHP is a lot more about the concept of what the problem is and how we are solving it, and less about the task of remembering syntax.

A good point to remember is that I have been developing and programming for a very long time now, and every single day I use Google, Stack Overflow and look around for answers or more elegant solutions, instead focus on remembering the concepts of why something is built that way, and look the syntax up on Google or via a cheatsheet until its part of your muscle memory.

Don't try to learn everything

This will literally drive you to despair, trying to learn everything in the web development world is literally impossible by definition, you absolutely cannot learn everything, and I think this is why I have a problem with the term "full stack developer" or most recently "10x developer", it's just bullshit and it doesn't exist.

Instead of trying to learn everything, pick a stack that you're interested in and run with that as much as possible in your learning schedule, of course it's fine to learn other things less relevant along the way, but I would 100% recommend sticking to a particular stack.

For me that stack was PHP, Laravel, and Vue - I find the community a friendly one and it's where most of my day to day work currently resides, however that doesn't stop me dabbling with React and Gatsby from time to time.

My point here is this, just don't set yourself unrealistic expectations, and trying to learn everything is just setting yourself up for failure, instead focus or niche down a little more, learn something new every day and that can be as big or as small as you like.

It's a marathon not a sprint and consistency is king.

Don't Compare Yourself to Others

Looking around on the internet particularly on Twitter, it's easy to sit back and watch and assume everyone else has this all figured out, this is where impostor syndrome kicks in and all of a sudden you find yourself doubting your own abilities in comparison to others.

I have 100% done this, and we really shouldn't compare to others, what you see on the internet in most cases is the good parts, what you don't see is the pain that other developer went through to get his knowledge to where it is now.

The way I like to think of knowledge is as a journey rather than an amount, if someone knows more than you about a particular subject, it's not that they are smarter than you, they are just further down the road on this journey, you can easily be in the same spot by learning a little everyday to move forwards.

This also applies to people you might be ahead of, if I know something about a topic that you don't it just means I am further down the road at the moment, you could put in more learning time and easily surpass my knowledge.

So, don't compare yourself to others in the moment, instead focus on your own learning path and know that you can learn anything, it just takes time and practice.

Paying for education is a great investment

I know a lot of developers who are totally against paying for courses, whilst I know some of them can be very expensive it's possible to buy a course for as little as \$15 these days, however even for some developers they just have a hard time parting with cash this way.

As a freelancer and even before I was freelancing I would look at this concept in the same way that I would look at my business, I am essentially selling my expertise in return for some form of remuneration, so the more I know, the more I can offer my client, so if I spend \$15 on a 30 hour course to learn Vue, then I see that as a massive return on investment in the long term.

Of course not everyone is in a position to pay for education, and I understand that, but there are tonnes of free resources you can start with, online docs and blogs.

Paying for education is a bit like fast tracking knowledge in my experience, sure there are some excellent free resources out there to learn tonnes of things, but generally I find paid courses a little more structured in most cases and have a set of learning outcomes.

Get Plenty of Sleep

As the father of a 3 year old toddler I can 100% state that a lack of sleep will impact your ability to learn effectively in a huge way, if you've been up all night feeding the baby then honestly, just sleep, don't try to learn when you're exhausted, you won't be learning anything and you'll find yourself rewinding or rereading pages over and over again as you dose.

I tend to go to bed around 10 pm, any later and I just feel like death the next morning, I tend to read in the evenings or watch some screencasts in the very early evenings once my son is in bed.

There have been so many studies around the effects of sleep and performance in learning and in many other aspects of life, poor sleep will just hinder your progress, so try and get as much of it as you can.

Resources I use regularly

I am often asked what I use to learn PHP, Vue and Laravel, so asides from the obvious websites for various frameworks and their own documentation, here are a list of things I use to help me learn more effectively.

Conclusion

At the end of the day, you have to want to learn a subject matter to learn it effectively and efficiently, studying different forms of learning from videos, books, blogs and podcasts I find are the most valuable methods.

But also remember that it's perfectly OK to go at your own pace, don't compare yourself to others, get plenty of sleep and make learning a fun task that you enjoy and not dread.

Vue.js Scoped Slots

Richard Bagshaw — Wed, 24 Jul 2019 09:07:23 +0000

When scoped slots were first introduced to Vue.js I found them quite challenging to fully understand, not so much the syntax but mostly around when and why I would use them.

This is because with scoped slots it's more important to learn the concept over the syntax, so with this in mind lets dig deeper into scoped slots, we'll start with regular slots to make sure we are all on the same page, and then move onto the problems that scoped slots are trying to solve.

This article covers the new scoped slot syntax using v-slot which was introduced in version 2.6.0, the older syntax using the slot and slot-scope attributes is now deprecated but is currently still available in the framework at the time of posting.

I will cover the older syntax at the end of this article since it is still widely used by many developers and there are plenty of instances of it in the wild.

What are regular slots?

Let's quickly cover slots and how we use them in Vue, a regular slot is simply a way of passing data into a component, if you know how to use props already then the idea of passing data down into another component should seem pretty familiar, lets look at these two different approaches.

Using props to pass data into a component looks like this from the consumers point of view.

<Comment content="Im too old to play Mario Maker 2">

Props are great but when you need to pass data into a component that is something other than text or an object, then props tend to become less useful, mostly because passing in html through a prop would quickly turn into an awful sticky mess.

Instead, if we wanted to pass in some html for semantic and styling purposes, then we might use a regular slot in the following way.

<template>
  <div id="app">
    <Comment>
      <span class="text-center text-green-400">
        Making levels in Mario Maker 2 is Addictive!
      </span>
    </Comment>
  </div>
</template>

<script>
import Comment from './components/Comment'

export default {
  name: 'app',
  components: {
    Comment
  }
}
</script>

In this example above you can see that we are using the regular default slot to pass in not only the text, but we're also passing in an extra wrapping span tag with some tailwindcss styles applied.

The content between the opening and closing tags is what will be passed down into the child and will replace the <slot></slot> tags inside the component.

The biggest advantage of slots in this scenario is that the consumer of the component can choose how to style the text since they are also responsible for passing in the wrapping span.

Defining a component with a slot in Vue.js is really simple, let's take a quick look at how we would define this really simple example component now that we've seen how to use it.

<template>
  <div>
    <div>the following comment was left</div>
    <slot></slot>
  </div>
</template>

<script>
export default {
  name: 'Comment',
}
</script>

I know in this example that the output is largely redundant and pointless, but I am keeping things as simple as possible here just to try and explain the concept and not get bogged down with pages of html or components.

This works great, but we have a problem with the scoping, when we pass anything down into the child component from the parent it is evaluated in the parent, so if we wanted to access a value that was stored in the child component state, then we would be unable to since we would be evaluating all expressions in the parent component only.

I appreciate that may sound a little confusing, so let's look at another example to see this problem occurring.

What problems are scoped slots trying to solve?

Lets define the problem with a few examples that we can build on, firstly lets create a component for listing out some data that we may have fetched from an API, some kind of <product-listing> component.

<template>
  <div class="products">
    <h1>A List of Nintendo Games</h1>
    <div>
      <div v-for="product in products" :key="product.id">
        <span class="product_name">{{ product.name }}</span>
        <span class="product_price">{{ product.price }}</span>
      </div>
    </div>
  </div>
</template>

<script>
export default {
  data() {
    return {
      products: [
        { id: 1, name: "Mario Maker 2", rating: 4, price: 40000 },
        { id: 2, name: "Breath of the Wild", rating: 5, price: 60000 },
        { id: 3, name: "Tetris 99", rating: 4, price: 8000 }
      ]
    }
  }
}
</script>

Next, lets take a look at the code that would consume this component and how we might use it to display a basic list of Nintendo games.

<template>
  <div id="app">
    <product-listing></product-listing>
  </div>
</template>

<script>
import ProductListing from './components/ProductListing'

export default {
  name: 'app',
  components: {
    ProductListing
  }
}
</script>

This works okay (ish), however the main problem with this is that we have no way to change what information the child component displays or how it renders it in the browser.

For example, we might decide that as a consumer of this component we want to display the rating of the game, we don't want to change the actual component itself as this behaviour might not always be necessary.

This is where we might reach for a normal slot, lets refactor this example and pass in what we want to display and replace the current static layout with a <slot>

<template>
  <div class="products">
    <h1>A List of Nintendo Games</h1>
    <div>
      <div v-for="product in products" :key="product.id">
        <slot></slot>
      </div>
    </div>
  </div>
</template>

<script>
export default {
  data() {
    return {
      products: [
        { id: 1, name: "Mario Maker 2", rating: 4, price: 40000 },
        { id: 2, name: "Breath of the Wild", rating: 5, price: 60000 },
        { id: 3, name: "Tetris 99", rating: 4, price: 8000 }
      ]
    }
  }
}
</script>

Notice how we have removed the content for the product listing and replaced it with a slot that we want to just drop in, we then might try to consume this component like so.

<template>
  <div id="app">
    <product-listing>
      <span class="product_name">{{ product.name }}</span>
      <span class="product_rating">{{ product.rating }}</span>
      <span class="product_price">{{ product.price }}</span>
    </product-listing>
  </div>
</template>

<script>
import ProductListing from './components/ProductListing'

export default {
  name: 'app',
  components: {
    ProductListing
  }
}
</script>

When we then call this component from the parent you can see that we are passing in the span tags as well as the data we want to display, notice how we are passing in an extra piece of data we want to display here, the product rating.

As good as this looks, sadly it won't work, if we take a look inside the chrome development tools we will see an error which reads something like this.

Property or method "product" is not defined on the instance but referenced during render.

The problem here is that in the parent, we are trying to pass down the name, rating and price which are all stored on the product and the parent knows nothing about the data of product because this is scoped to the child component only.

What we need is a way to make the scope of our child component available to our parent component in-between the opening and closing <product-listing> tags, and that is exactly what scoped slots provide.

How to use scoped slots

Lets take a look at the refactored code to make use of scoped slots to get around the problem outlined above, firstly our component needs to make something in it's current scope available to it's parent, in our case this is a product.

<template>
  <div class="products">
    <h1>A List of Nintendo Games</h1>
    <div>
      <div v-for="product in products" :key="product.id">
        <slot :product="product"></slot>
      </div>
    </div>
  </div>
</template>

<script>
export default {
  data() {
    return {
      products: [
        { id: 1, name: "Mario Maker 2", rating: 4, price: 40000 },
        { id: 2, name: "Breath of the Wild", rating: 5, price: 60000 },
        { id: 3, name: "Tetris 99", rating: 4, price: 8000 }
      ]
    }
  }
}
</script>

The line of most significance here is where we define the actual slot, you'll notice that we have now bound the product to the actual slot tag making it available for our parent to use.

<slot :product="product"></slot>

This one simple line is essentially offering up something out of the child scope into the parent component if it wishes to use it.

If we want our parent to be able to take advantage of this offering from the child, then we can use the v-slot attribute, lets take a look at our refactored example of the parent.

<template>
  <div id="app">
    <product-listing>
      <template v-slot:default="slotProps">
        <span class="product_name">{{ slotProps.product.name }}</span>
        <span class="product_rating">{{ slotProps.product.rating }}</span>
        <span class="product_price">{{ slotProps.product.price }}</span>
      </template>
    </product-listing>
  </div>
</template>

<script>
  import ProductListing from './components/ProductListing'

  export default {
    name: 'app',
    components: {
      ProductListing
    }
  }
</script>

In the parent the most significant change is the content that we are passing down to the <product-listing> component, we are now using a template tag which will contain the content and the product on the slotScope

One point to note is that template tags are not rendered in the browser but the content will be, we are now accepting the scope that was offered to us from the child component.

<template v-slot:default="slotProps">
  <span class="product_name">{{ slotProps.product.name }}</span>
  <span class="product_rating">{{ slotProps.product.rating }}</span>
  <span class="product_price">{{ slotProps.product.price }}</span>
</template>

An interesting point to notice here is what the actual scoped content looks like that is offered back to the parent, if we take a look inside slotProps we will see the following :-

{
  "product": {
    "id": 1,
    "name": "Mario Maker 2",
    "rating": 4,
    "price": 40000
  }
}

Knowing this we can use JavaScript's destructuring to allow us to just use the product variable name directly and remove the need for showing slotProps everywhere, let's take a look at the final finished example.

<template>
  <div class="products">
    <h1>A List of Nintendo Games</h1>
    <div>
      <div v-for="product in products" :key="product.id">
        <slot :product="product"></slot>
      </div>
    </div>
  </div>
</template>

<script>
export default {
  data() {
    return {
      products: [
        { id: 1, name: "Mario Maker 2", rating: 4, price: 40000 },
        { id: 2, name: "Breath of the Wild", rating: 5, price: 60000 },
        { id: 3, name: "Tetris 99", rating: 4, price: 8000 }
      ]
    }
  }
}
</script>

<template>
  <div id="app">
    <product-listing>
      <template v-slot:default="{ product }">
        <span class="product_name">{{ product.name }}</span>
        <span class="product_rating">{{ product.rating }}</span>
        <span class="product_price">{{ product.price }}</span>
      </template>
    </product-listing>
  </div>
</template>

<script>
import ProductListing from './components/ProductListing'

export default {
  name: 'app',
  components: {
    ProductListing
  }
}
</script>

As you can see, in the parent we are now using destructuring to remove that unsightly slotProps naming we had previously.

This concludes the example and hopefully you can see exactly how we used scoped slots to pass the product up to the parent which we can then use to pass in via a slot.

Why are scoped slots a source of confusion?

On reflection, scope slots were definitely the most difficult concept for me to grasp at the time of learning, I think the difficulty comes from the fact that we are passing scopes up to the parent whilst passing content back down after that scope data has been evaluated in the parent.

The constant back and forth between parent and child just feels a bit odd and it definitely bends the mind a little when learning these concepts.

However, don't be deterred from learning these and getting them solidified in your brain, they are in my mind one of the most important concepts of Vue.js and make the entire framework much more powerful.

The deprecated syntax of scoped slots

As I mentioned at the top of this article, the syntax we have covered is the new 2.6.0 syntax, however the older syntax is used regularly, infact I am working on a freelance project at the moment which uses scoped slots heavily throughout, and at the moment they are using the old syntax, so lets quickly see that in action.

<template>
  <div class="products">
    <h1>A List of Nintendo Games</h1>
    <div>
      <div v-for="product in products" :key="product.id">
        <slot :product="product"></slot>
      </div>
    </div>
  </div>
</template>

<script>
export default {
  data() {
    return {
      products: [
        { id: 1, name: "Mario Maker 2", rating: 4, price: 40000 },
        { id: 2, name: "Breath of the Wild", rating: 5, price: 60000 },
        { id: 3, name: "Tetris 99", rating: 4, price: 8000 }
      ]
    }
  }
}
</script>

<template>
  <div id="app">
    <product-listing>
      <template slot-scope="{ product }">
        <span class="product_name">{{ product.name }}</span>
        <span class="product_rating">{{ product.rating }}</span>
        <span class="product_price">{{ product.price }}</span>
      </template>
    </product-listing>
  </div>
</template>

<script>
import ProductListing from './components/ProductListing'

export default {
  name: 'app',
  components: {
    ProductListing
  }
}
</script>

As you can see, the component is the same, however we are using the slightly more verbose slot-scope attribute on a template tag.

For more information around the reasoning for this change, take a look at the RFC which outlines the details of why it was changed.

Conclusion

This post has been very code heavy, and as I mentioned earlier, scoped slots were easily the most tricky part of learning the framework, but in later blog posts I will show you some examples of some very powerful patterns which utilise scoped slots and you'll see even more examples of how just important they are.

Forem: Richard Bagshaw

Mocking Dependencies with PHPUnit and Prophecy

What is Dependency Injection?

Hitting the database and services means slower tests

What is a mock and why do we need it?

Creating a mock with Prophecy

Should we mock everything then?

Do what helps you sleep at night

Javascript and the meaning of this

Figuring out what this means

What is binding?

Implicit Binding

Explicit Binding

Call()

Apply()

Bind()

new Binding

Window binding 🤮

Why is knowledge about all this binding useful to know?

Conclusion

Vue Scoped Slots - Screencast Tutorial

My Vim and Tmux Workflow for Web Development

An Introduction to Gatsby.js

What is Gatsby?

Installation

Creating our first page with Gatsby

Linking between our pages

Conclusion

The Constant Learning Cycle of a Web Developer

Learning new web development stacks and tools

Why we need to learn new skills as developers

A company culture of learning

How I Learn Effectively

Learn the concepts not the syntax

Don't try to learn everything

Don't Compare Yourself to Others

Paying for education is a great investment

Get Plenty of Sleep

Resources I use regularly

Conclusion

Vue.js Scoped Slots

What are regular slots?

What problems are scoped slots trying to solve?

How to use scoped slots

Why are scoped slots a source of confusion?

The deprecated syntax of scoped slots

Conclusion

Figuring out what `this` means

Why is knowledge about all `this` binding useful to know?