Alpine Store Basics
This episode is for members only

Sign up to access "Alpine Store Basics" right now.

Get started
Already a member? Sign in to continue
Playing
02. Life before state

Episodes

0%
Your progress
  • Total: 29m
  • Played: 0m
  • Remaining: 29m
Join or sign in to track your progress

Transcript

00:00
So we're going to start off asking the question, what happens if we don't use a store?
00:04
How do we communicate between Alpine components? And we're going to look at a very, very simple example, but it should very quickly become clear that this method of communication between components is unsustainable. So what we're going to do is look at a really simple example of having a navigation up here,
00:24
some kind of tasks list down here where we can use a button to create new tasks. And essentially, what we want to happen is the navigation to have an item inside of it that gives us the count of how many tasks we have. This could apply to anything, a to-do list, notifications, pretty much anything.
00:43
But basically, we just want to keep the two in sync, whether we're adding or deleting tasks. So I've already got Alpine just pulled in here, and we just have a standard HTML page. Let's get started on the component down here, which will create out this data. So we're going to go ahead and start with xData here.
01:00
And let's go ahead and add a tasks array. And we're going to need a method to create a task as well. Let's just keep this super simple by just accessing tasks and then just going ahead and pushing maybe just a random number to this.
01:15
We don't really care what the data in there is doing. Now, it's here that we want to dispatch some sort of event that can get picked up in nav, which will update the count in the navigation. Let's add that count in here now.
01:29
So let's just say we had a really simple span. Again, we're going to make this a Alpine component. And we want to say something like xTasks. So that's pretty much where we want to see that data.
01:40
OK, so in here, let's go ahead and implement a button. And we'll add an event handler to this to say that we want to create a task when we click it. And for the text here, we'll just say Create Task. So just really, really, really simple stuff here.
01:53
OK, so now what we want to do is figure out how we get the count of tasks. Now, inside of here, that's very, very simple. We can just use xText. And we can say tasks.length.
02:05
Because we're in this component, of course, we have access to that data. We don't in this component here. So let's just try this out. If I click Create Task, you can see that that increments the amount of items in that array.
02:17
So now that we've got that there, we need to figure out how to get that data, that length of tasks, up here. And for that, we would typically use dispatch. Now, we could just call this anything.
02:28
So we could say taskCount. And that would contain the current task count, which we know is just the length of the tasks array just here. So now that we've dispatched that, we can pick this up over on this component
02:43
and update maybe a piece of local data inside of here. Let's just call that tasksCount for now and just set that as a 0 by default. So inside of here, we can say on tasksCount. And that's on the window object.
02:58
Then we want to set the tasksCount that we're storing on this particular component from the event data that we get, which is this. And this will be under the detail property. So we can just say detail.
03:11
So that's going to go ahead and dispatch the count that we have after we perform this particular action. So this would need to go anywhere where we maybe delete a task. So for example, if you had a delete task function in here,
03:25
you would also have to dispatch that at that point as well, which gets a little bit annoying because we have some repetitive code there. But you'd have to basically dispatch this wherever the task count changed or the count of the tasks changed.
03:39
So now that we are listening for this event, we set tasksCount here to the amount we specified in here. So now we can go ahead and output this. Let's go ahead and use xText for this.
03:49
So xText. We'll back tick this so we can go ahead and pop in the tasksCount. And then we'll just say tasks, like so. So if we come over, by default, we end up with 0.
04:01
That's another issue that we would have to probably dispatch this on initialization if we already had tasks in here. So if there were three tasks in here, for example, we already don't have our state matching up.
04:14
So what we would have to do is go ahead and apply maybe the same thing on an init method, which is called by default, and just pretty much do the same thing. So now we end up, if we make sure this is actually working
04:26
by listening on the correct event, that's kept up to date. So we technically have our state being kept up to date. And when we hit Create Task, sure enough, this kind of keeps our state. I'm using the term state loosely, up to date.
04:41
So we've had to do a lot of work here. There's a lot of repetition through dispatching and listening on here. Imagine if you had another component where you needed to show some slightly different data about tasks somewhere else on the page
04:53
in another Alpine component. You're going to have to go ahead and dispatch another event inside of here, maybe for that particular information. Or over here, you would have to keep another copy of the tasks
05:05
so you could just use .length on that within this component. There are lots of different ways to do this, but hopefully this gives you a really good idea as to why state management is sometimes needed within components
05:17
if you are sharing a lot of data. So that's the problem. We've kind of created a kind of state management system here where we're at least keeping this data that we need up to date.
05:28
But this is completely and utterly unsustainable. So with that said and demonstrated, let's jump over to the next episode and look at how we can clear up this kind of thing with state management in Alpine.

Episode summary

In this episode, we kick things off by exploring what it actually looks like to build Alpine components without using a centralized store or state management. Basically, we try to answer the question: what happens if each component manages its own state and we need to keep them in sync?

To show why this matters, we build a simple example. There's a navigation bar that displays the total number of tasks, and a separate tasks list below it, with a button to add new tasks. The problem quickly becomes clear: we need to somehow keep these two components (the nav and the task list) in sync whenever tasks get added or removed.

We use Alpine's event dispatching to communicate between components. Whenever a task is created, we dispatch a custom event with the updated count, and then the nav listens for that event to update itself. It works, but as you'll see, it gets repetitive—every time we add or remove a task, we have to remember to dispatch an event. Initialization gets messy, too. And if we had a third component that needed the same info, we'd have to start duplicating even more logic.

By the end, it's pretty clear: manually wiring up data sharing like this is tedious and doesn't scale well. So, this episode sets the stage by demonstrating why state management is important, and leaves us ready to tackle a better approach in the next part of the course.

Episode discussion

No comments, yet. Be the first!