Like so many other things in life, starting a new feature is the hardest part. We're creating something out of nothing. It's not an easy task to define how that "something" should appear. But we'll try. Let's begin with one example of how the system should behave, using TDD.
Let's drop down a level and write a test to ensure that, when experience is awarded to a user, an announcement (or event) is made to the rest of our application. Later, we'll listen for this announcement and grant any necessary achievement badges to the user.
It sounds like we'll need an
Achievement Eloquent model, as well as its associated database table. Let's use TDD to construct both.
In this episode, we'll construct the relationship between a user and their respective achievements. As you'll see, this is a prime use-case for a generic pivot table.
Leading up to this episode, I've been doing some thinking. Yes, we can store achievement badges within the database, but where do we put the logic that determines if the given user should be granted that badge? This led me to considering a different path we might consider. In this episode, let's tinker around with that idea. If we like it, we'll keep it. If we don't, we'll revert!
In the previous episode, we tinkered with the idea of not using a database at all for determining and fetching a user's acquired achievement badges. Let's talk about that refactor - including the pros and cons to such an approach - before ultimately reverting in favor of a better solution for our needs.
Now that we've reverted the previous lesson's work, we can move on to a clean approach. In this lesson, we'll build the necessary system to register and sync achievements with any given user, based on newly awarded experience.
In this episode, we'll discuss two equally valid ways to organize all of the achievement-related files, including service providers, events, listeners, etc.
*Series still in development. Check back often for updates.