When an item is no longer needed, removing it will reduce memory. Let’s discuss a remove feature. As we walk through the simulation, we’ll discuss how the remove feature is different from the get feature. We’ll provide a clarification in our Requirements Document.
Let’s wrap up this lab and reflect on what you’ve accomplished.
There are many times when you need to add new parameters to an existing item that is already in the store. One way to do this is to get the existing item, add/combine/merge the new stuff, and then replace the existing item with the new merged item. But what if we could provide that functionality in the store? Hmm, for this to work, the Data Store would have to define what types of data can be merged together and how to do it. That means the Data Store is no longer data agnostic. As an exercise, let’s define a merge […]
Imagine that the default configuration parameters are loaded from a plugin, but you want to replace those parameters with your own implementation. To make this work, the data store needs a way to replace an existing item with a new one. What if the item doesn’t already exist in the store? Should we go ahead and add it? Or should we alert? Let’s explore deeper as we continue to plan out the requirements.
What if someone needs to check if an item exists in the store? That sounds like a viable use case, right? Let’s talk about adding this feature to our requirements.
Let’s talk about why we want an API for this component. Some of the reasons include: Developers using the Data Store do not need to know the implementation. They don’t need to know if it’s built in OOP, static class, or procedural. Rather, the API wires to the Data Store. It hides away the implementation, exposing public facing procedural functions to interact with it. Future proofs your work. Makes it easier to work with the Data Store.
We want our data store to be globally accessible to all plugins and the theme. But we want to control the access and interaction with the items in the store. Let’s talk about why both of these are important features.
Let’s define the container’s data type and how to retain the items in the container. There are different strategies: JSON file database in-memory cache – such as Redis in-memory using a PHP data type We’ll discuss the problems and strengths of each. If you’d like to learn more about in-memory PHP data type, checkout the Array Data Type in the PHP Docx.
Let’s discuss strategies for identifying the items in the data store. In this episode, you’ll: Figure out all of the important attributes for our identifiers Come up with a naming convention that supports those attributes More Information If you are interested in learning more about identifies, an Array Data Type in the PHP Docx is a great place to go. Check out the “Understanding the Keys” section to discover more about unique identifiers, which in this case is called a key.
Let’s document the basic attributes and functionality we discussed in the last episode. Here’s what you’ll be doing: Get overview of markdown. Here’s a link to a Markdown Cheatsheet. Add a docs/requirements/basics.md file to the plugin. Create a new branch with git. Commit the changes into the branch. Note: If you don’t have the git aliases set up yet on your machine, then stop here and go do the Git Productive lab. It will speed up your workflow.