RFC The Vue: Vuex 5

EPISODE 65

[INTRO]

[00:00:09] T: Hi, everybody. Welcome to Enjoy the Vue. I'm Tessa. Today on our panel, we have Alex.

[00:00:14] AR: Hello.

[00:00:16] T: And guest panelist, Ringo.

[00:00:18] R: Hi.

[00:00:19] T: How's everyone doing?

[00:00:20] R: Pretty good.

[00:00:22] AR: I'm pretty good.

[00:00:23] T: Have you all seen that there is a new RFC for the next version of Vuex?

[00:00:31] AR: Wait. I thought, didn't they just come out with Vuex 4?

[00:00:36] T: That's what I thought, too, but my buddy Alex told me that there is an RFC for Vuex 5 already. It looks pretty exciting.

[00:00:47] AR: Oh, yeah. Look at that. It looks like, Vuex 4 was really just meant to replace Vuex 3 in Vue 3. It's the same interface. Looking at this RFC, it looks like they are really going to change some stuff in Vuex 5. Yeah, this is actually exciting.

[00:01:14] T: Before we move forward with what's new, let's talk briefly about what Vuex is, which it looks like the basics are also covered in this RFC a little bit, which we'll link in the show notes. I like that a lot. Ringo, can you explain what Vuex is in a nutshell?

[00:01:33] R: Sure. To me, I think Vuex is more of a Redux pattern, but implemented in Vue.js. What you get is a store, which you can use to inject into your Vue components and can be accessed anywhere. Inside the Vue store, usually, you have different types of methods that you can go into that is called actions. We trigger actions. We call actions that triggers mutations that mutate our store, which is the values that we hold. This is probably not the best explanation, but it's something that I just – is how I understand it.

[00:02:16] T: Wait, so what's the difference between an action and a mutation?

[00:02:20] R: That's a good question. Before the RFC, I thought that, “Oh, you have actions for asynchronous behavior.” If you want to do some database calls to trigger some asynchronous updates, you would do it in actions. Then mutations is purely synchronous, and we use mutations to mutate the store.

[00:02:40] T: That had been my understanding as well. It sounded like, you were going to say, now you think differently or something. No?

[00:02:47] R: Well, just by taking a look at the RFC just now, I think that has changed.

[00:02:52] T: Well, that's interesting.

[00:02:54] AR: Yes. I think, one of the big complaints about Vuex so far has been, that there's a lot of boilerplate, when you're setting it up. First, you have to set up a state section to be able to track the state that you want to have that is reactive. Then you have to set up a mutation section, which is basically, a one-to-one with your state section where you say, “Okay, cool. I have this piece of state. Now I need a mutation to be able to update this piece of state.” You're always writing just functions that could be automated, or maybe aren't even really necessarily needed. Because ultimately, you're then committing a mutation from an action and updating a piece of state. I think, the current thinking is, why don't we just not have mutations and allow updates to state to happen in an action? That'll reduce the amount of code it takes to create a Vuex store.

[00:03:54] T: That's pretty exciting, because I feel the first time that I personally was introduced to that idea was that Chris Fritz's workshop at Vue Toronto in 2017. Then it sounded like, in 2019-2020, that had gone away, at least for the time being. To hear that it's finally coming four years later.

[00:04:17] AR: Yeah. I know that Chris was always a big – has always been a big proponent of you know, we shouldn't really have mutations. You should be able to just update state in an action. This is a change, I think, that has been a long-time coming. Part of it is that with getting Vuex updated to Vuex 4, I think, so that it would work with Vue 3, they really wanted to maintain backwards compatibility. They weren't going to implement that change in Vuex 4, because that would be too big of a breaking change. This is really the Vuex 5, it looks like, is really going to be the big leap into the future of changing the way that we think about Vuex.

[00:05:00] T: Let's jump back to the definition for a minute. Because on the RFC, it says that Vuex is a flux-like architecture. Ringo had said, it's very Redux-like. Both are true. I feel like, I've heard flux-like architecture for so many years. At this point, I've completely forgotten what exactly flux is, since my first introduction to flux-like architecture was Redux. I feel when Redux came out, that was a really big game changer for React. I feel, also maybe MobX was around at the same time. Do either of you know what flux, or flux-like architecture is? Maybe we short into for architecture or something, because flux-like architecture is very hard to say.

[00:05:48] R: My very, very at rate memory, I think the difference is that the Redux have a single store as compared to flux, which is multiple store. In terms of details, is buried in that.

[00:06:04] AR: Flux is just, it's not necessarily an actual library. It is a methodology, I believe.

[00:06:15] T: Conceptual framework.

[00:06:17] AR: Yeah. It's a conceptual framework of just how should data flow through your application. Similar to how in Vue apps and Vue components, we're very much about – we're all about you put props in and you expect it to emit events up. Flux architecture is very similar in that you don't – you have very specific places where you can mutate state. You can't just mutate state from wherever. You would want to only update it in certain places, so that you control where that data is being updated.

[00:06:58] T: Nice. Yeah. Speaking of where data is, it seems like, the main use case for the Vuex store is communicating between components that don't have any direct, generational relationship. There's no parent and child, or great grandparent and great grandchild, or anything like that. Vue 3 introduced another way for components that are not related to communicate with each other, namely, the composition API. I guess, one could argue if one were so inclined, also the teleport feature. Do we even really need Vuex 5?

[00:07:41] AR: Yes.

[00:07:44] R: You can achieve similar functionalities with composition API, with the injection tokens syntax, but you also miss out on the UX toolings that you have from the dev tools. If you do want to retain the event trackings for the stores, and see how the store is being mutated in the dev tools, this may be something that you want to consider.

[00:08:11] T: If we had a composition API dev tool, then yeah, I'm not sure either, because I've certainly have more experience with Vuex than I do with the composition API. That is an idea I've seen floating around. Honestly, I don't think I've actually used the composition API. I'm trying to think of a moment. My impression is composition API feels a lot more personal. You're like, “Hey, I have this data that I want to use for this component and this component and this component.” It’s not an umbrella that embraces all your components and shares its information with everything in your Vue app. What do you think, Alex?

[00:08:56] AR: Yeah. I have a couple of little demo fun apps that I have, where I've used the composition API. I haven't actually had a chance to use it in production yet. I think, there are places where you could theoretically create your own flux style architecture-based thing around the composition API. Being that we live in Vue land, and we exist in the Vue ecosystem, I think that we have a way of saying, “Hey, rather than having to roll your own, if you want something like this, here's a way to do it.” Giving people that tooling is the Vue methodology. I think, that yeah, you're right. You could write your own store using just composition API and composition components. This is an easier way to set it up and let other people have a standardized way of doing it.

[00:09:59] T: That's a great point that I haven't heard yet in the composition API versus Vuex conversation, which is how much conceptual familiarity, or structural familiarity a tool like Vuex brings, which I think is something that Vuex docs and redux docs certainly highlight, but it's less addressed in the composition API versus Vuex discussion, which is Vuex has a very relatively defined structure for how to use it, versus something like composition API, which feels a bit more like a free for all, to me, onboarding developers, or transitioning between code bases is theoretically a little bit less – has a little bit less cognitive overhead and a little bit less new things to ingest, if you're using something like Vuex for most of your global data, or if it is event bus. I guess not, if you're using Vue 3.

[00:10:55] AR: No. No event buses. No even buses.

[00:11:00] T: Let's talk about what's different in Vuex 5. We already mentioned that actions are going to replace mutations and be able to directly mutate the state, which I think is both exciting. Also, it feels intimidating. The training wheels are coming off, or something. Because I'm so used to us having to explicitly separate those. I guess, you don't have to, but most code bases that I've seen do.

[00:11:31] AR: Yeah. That's one of the major changes. The other really big change it looks like, is that they're getting rid of modules.

[00:11:40] T: What do you mean by getting rid of it?

[00:11:43] AR: In Vuex 3 and Vuex 4, if you have multiple things that you want to be able to track; you have users, but you also have blog posts, and you also have links. Those are each going out to their own API and they have their own state, their own thing. You can separate them into modules. There's a way that you can define a module and you can namespace it, so that it has its own area to work in within your store. With Vuex 5, they’re getting rid of that. Conceptually, what you would do is that you would have multiple stores. If you don't need a store in a certain thing, you only pull in the ones that you need.

[00:12:26] T: Wait, that's in Vuex 5, as opposed to Vuex 3, or Vuex 4? In Vuex before 5, you couldn't just use a specific – because I always understood modules as a sub-store within your store.

[00:12:37] AR: Basically.

[00:12:37] T: You can’t use just a sub-store. You have to bring in the whole store?

[00:12:41] AR: Instead of thinking of it as having one global store, you would have multiple global stores, is my understanding.

[00:12:57] T: I mean, I think we might have been looking at the same thing, actually. Because the thing that I find really interesting is that it's saying all of the stored data will be available under this context, just like a Vue component. Then when I'm flipping through the example, it's like, in the store, just from the getters, or the actions, or the state, you can say this dot, whatever the thing is, which I can't remember if that's really all that different from how it is or not, but more excitingly, you don't have to map getters, or map actions, or anything like that in your Vue component, you just import the store and then use it almost, it looks like, as though it were an ES module or something, where you have the store name.

In the example, they have a store called counter, and then everything is a property on counter. Which to me feels a lot more ergonomic and familiar pattern, than the previous way that we used to do it, or I guess, are doing it right now. The previous way that we will have been used to doing it, that ties into what you were saying about the multiple stores, or not having sub-stores, because you would just import the “module” that you theme.

[00:14:15] AR: Yeah, you would. Rather than having a global store where all of your data is and everything has access to it at all times. Within your component, you would have access to the Vuex model, the Vuex plugin. You would be able to in your – when you are making your store, you define a store. You say, “This is what my store looks like. This is all the things that it has a state, has getters, it has actions.”

Then you have Vuex, which you create an instance of Vuex and then you say, “Okay, cool. Hey, Vuex, give me this store information.” You give it the store that you have defined inside of the component. In that component, for instance, you would say, as a computed value, I have a computed value called counter. I'm going to bring in my store, my Vuex store called counter. We're bringing in that store. Then the counter computed value would return the value of this.$Vuex.store, counter store.

You would then be able to access all of the actions and all of the state and all of the getters via this .counter should be, this .counter count, this .counter double, if you have a getter that automatically doubles the count. Then if you need to dispatch an action, you don't call dispatch anymore, you just call this .counter.whatever, increment or something.

[00:15:55] T: Dare I say, this almost feels like mixins, but make it name-spaced. You’re just rolling all the stuff in. It feels cleaner somehow.

[00:16:04] AR: Yeah. I think, some of it is that since this is just for tracking state, mix-ins, that always had this magical hooking into method, hooking into lifecycle methods and stuff like that. It had a way to –

[00:16:20] T: Yeah. Like, where is it coming from?

[00:16:22] AR: Right. You're like, “I don't have a thing that’s set.” With Vuex, the whole point is that this is just state. There isn't a hook into the on-create event. It's really just state.

[00:16:38] T: Yeah. I wonder if any place is using Vue 3 in production yet, because I mean, Vuex isn't even out yet, but I'm already excited and ready to use these changes. I am never excited to use Vuex. Now, I'm super excited to use Vuex. I'm like, “Oh, God. I wish I had something that needed a store in Vuex 5, so I could try this out right now.”

[00:17:01] AR: Well, remember, this is still an RFC. It's open for comment as of today, March 4th. It isn't available yet.

[00:17:13] T: Yeah. I don't know that a comment being like, “Give it to me now,” is very useful, though.

[00:17:20] AR: Another thing that it looks like they're also doing with Vuex 5 to go with the whole Vue 3 composition API thing, is they're making composition-based stores.

[00:17:36] T: Yeah, what does that mean, a composition-based store?

[00:17:40] AR: Ringo, do you have thoughts? Have you gone down to that part yet?

[00:17:45] R: Not reading into it. I'm assuming this is based on the composition API, but it's using the Vuex traditional, Vuex syntax, we actually use leveraging the composition API in our store, is my guess.

[00:18:00] AR: Yeah. Rather than passing in an object that has a state section and getters section and an action section, you give the define store a function, where you define a store, you give it a name, because all of your stores now have to have a key. They have to have a key, so that you can reference it as something. Yeah, a key to string.

[00:18:22] T: Oh, meaning the name?

[00:18:23] AR: Yeah, the name. The name of it. They call it a key, because it's the key name.

[00:18:29] T: Fancy.

[00:18:30] AR: Fancy. You pass it a string, which is the name or key of it, and then a function. With that function, you can define refs, you can define computed, you can define actions as just functions. Then whatever you return is available on your Vuex store. If you've ever been in the situation like I have, where I use Vuex at work, and we have some stuff where we wanted to have private Vuex methods that do things internally, but we didn't want to expose to the outside world. It was very difficult. You'd have to define them outside the structure of UX. Then you'd need to make sure that you pass all the context in. It was a whole thing. With this –

[00:19:25] T: Can you explain what you mean by the private method? Something that you wouldn't use with Vue?

[00:19:30] AR: Yeah. It's just a method that you don't want anybody to use. It's something that you need to use internally. Like, I'm going to massage a bunch of data. I'm going to make it – I'm getting data from an API, but I want it to look this other way. I'm going to define a function and it doesn't need to be an action. It doesn't need to be a getter. It doesn't need to be a mutation. I just need a function that I put data in and spits data out. With that type of function, you're going to not define it within the structure of a Vuex store. With the composition thing, with this composition concept, you're able to define it within that composition function, but you don't have to return it and expose it. It can just be used internally. It's an internal implementation detail.

[00:20:23] T: Yeah. Because if you in the old way, if you include the function in the store, then you always have the risk of somebody thinking it's something you can use. Massaging data from the API is an unfortunate reality that many of us had to face. With this, we don't have to worry about that, because we can explicitly define what is available outside of the store component. That about it?

[00:20:47] AR: Yup, that's about it.

[00:20:48] T: Nice.

[00:20:50] R: Circling back to what we were talking about earlier, the difference between composition API and using Vuex store. Looking at Vuex store using the composition API syntax is very similar to how we would use the Vuex store without Vuex-ish as need.

[00:21:08] T: But use the Vuex store without Vuex?

[00:21:11] R: Right, to use the composition API to replace Vuex store. The way that this is implemented is very similar to how we can use Vuex store, but with composition API. You define some key, or strings to say, “Hey, this piece of store can be accessed by this thing.” Then basically, is just returning composition API objects, which is how you would do it also without Vuex.

[00:21:43] T: The composition API store still gets stored with my other stores, right? This isn't something that users would be putting directly inside their component. Okay, people are nodding.

[00:21:57] AR: Because of the new way that you would add a Vuex store to a component, you would still import it into the component and then have to use it in the component, but you wouldn't be using it –

[00:22:12] T: It wouldn't be defined in the component with it.

[00:22:14] AR: Right?

[00:22:17] T: I feel like, I'm so used to seeing the composition API explicitly in a component. When I'm looking at this and thinking about Vuex, I'm like, “Well, that wouldn't make sense. It probably wouldn't be there.” Just looking at the snippet of code that they show, I'm not a 100% sure. I feel like, if some of your store was with your other stores, and then some of it was in components, now that really feels like, make sense all over again.

[00:22:41] AR: Yeah. With stores, you really want to define all of them all in one place, so that everything, all your components can access them. If you define a store in a component, then might as well just make the data be in the component.

[00:22:56] T: Yeah. I like to put all of my stores and components in one file, so that I never have to worry that it's not in the current context.

[00:23:03] AR: It's so much easier just to put all your components into one file. It's better for prototyping and put 10 components in one file and just prototype super-fast. It's amazing.

[00:23:12] T: These are some hot Vue best practice tips here.

[00:23:16] AR: Hot. Don't take Alex's advice, practices here.

[00:23:22] R: Yeah. Also, think is interesting, the whole idea behind composition API is to extract logics within the Vue components, so that it can be reused. Yeah, composition API doesn't necessarily have to be in a Vue components. It can be a separate file that is being reused either for imports, or for injects from a Vue instance.

[00:23:44] AR: It can also be used to create patterns that you see happening repeatedly in multiple places in your code base, too.

[00:23:53] T: Yeah. I'm really curious what patterns we're going to see across developers and code bases as composition API gets more widely adopted, because I feel there's so many less and more confusing ways to use it. It's simultaneously exciting and intimidating.

[00:24:13] AR: Yeah. A pattern that we tend to use at work for Vuex, we actually made an entire class to generate the various parts of a Vuex store, so that we can very quickly add calls, like fetch calls to the API. It creates all the all the getters we would need, all of the managing the loading state, rejected state, error state. Being able to just very quickly go, okay, cool. Create a new store module and add this state, add these getters, add these mutations, add these actions has cut down a lot and it's made it easier for us to prototype, or build things a lot faster. With this, I can see that happening here as well, where you go, “Okay, cool. Go ahead and just make my generic fetch handler, composition API function stuff.”

It just generates all of that stuff and returns all the things that you need access to. Then you can just spread that in a return from your thing. Voila, you now have a new store thing that you can access anywhere and call that API and have all of the benefits of tracking loading state and error state and what have you.

[00:25:33] T: Another interesting thing I noticed here that didn't even occur to me is that when you use a composition store, you don't have to reference the dot value part of each property, which I feel is the thing that tripped up a lot of Vue developers when composition API came out. Which I think is very nice. I also wonder, if it's going to cause confusion, especially among maybe newer to Vue developers, over like, when do I need this dot value thing and when don't I need the dot value? Or if it will encourage a trend of always using composition API within a store?

Now, I feel like, we’re one of those YouTube videos, where we got a leak of the next camera, or the next console, and we're just speculating on what it's going to be like. I guess, that's what we're doing.

[00:26:23] AR: Yeah. I mean, a little bit. I mean, yeah. I think, it'll be interesting for sure to see what the future holds for Vue and Vuex, as far as adoption of the composition API and how people write components from here on out.

[00:26:41] T: Yeah. Speaking of changes, let's talk a little bit about how Vuex 5 is proposing automatic store registration. This seems potentially related to the whole idea that we don't need modules. It also seems like, they're cached.

[00:27:00] R: I think that the key takeaway there, just by looking at the box, is that the store is not registered until it’s used. If you register a store, but you never actually reference it anywhere, it actually won't be included. It won't be activated in your code.

[00:27:17] T: Correct me if I'm wrong, but I feel the main difference here is with the existing flow, I have my root store. Then I have all my modules, and I include them all on the root store, then I have the main – the papa store that I can use everywhere. Then with the new way, it's just, I have all my store sections, or chunks, I guess. Anytime I decided to import one of those chunks into my component, that's when that store would get registered for the first time, but then exist for any other components that want to use it. When Webpack is compiling, it won't include any chunks that are not being used in any components. Is that right?

[00:27:57] R: Yeah. It allows cost of the things to be a little bit easier for the Turings. Because before, [inaudible 00:28:02] know what is being used or not. Now, with this different store, it allows the Turing to do that.

[00:28:10] AR: This feels a lot like register and unregister module, the way that Vuex is currently implemented. You can hot load modules on the fly, in the current implementation of Vuex, but it's not something that you typically do. It looks like, with Vuex 5, that's going to be the standard.

[00:28:33] T: I mean, is there an unload? I didn't see that part.

[00:28:37] AR: I did not see that part either. That'd be a great comment to make.

[00:28:41] T: This whole thing feels very exciting in a very weird way. Because I feel I'm more familiar with this non-existent Vuex 5 than I am with the existing Vuex 3 that I've been using for the past few years. It also looks like, there's some limited support for circular store references, which is interesting and feels dangerous and like an exciting, let's break some stuff way. They do note that you should try to avoid circular references. There's also a reference to hoisting, which is always exciting.

[00:29:17] AR: Yeah. With the circular references, A, it's typically, you don't want to have a bunch of in classic Vuex, you don't want to have a bunch of modules referencing other modules, because then, everything starts turning into spaghetti code a little bit, but you can. You can do that. Likewise, you don't necessarily want to be able to go way overboard with referencing information in other stores, like having two stores refer to each other simultaneously. A circular reference is you have store A, store A refers to store B. Store B refers to store A. At that point, you now have a circular reference where in theory, you could accidentally trigger something in store A, that trigger something in store B, which triggers something in story A, which triggers something in store B. It is a circular reference.

[00:30:05] T: That my own grandpa problem.

[00:30:07] AR: Yes, the going back in time and killing your own grandfather to stop yourself from being born. Things get weird when that happens. With using, you can use stores and other stores in Vuex 5. If you use the traditional object definition way where you have a use section, and you can say, use this other store as part of this module. Then anywhere in your getters, or in your methods, you can reference that other store and get data from it.

Yeah. In the composition store, you can only access other stores within function calls. If you're making a function that calls computed, you should be able to use it there. If you're making a function call that you're going to return it as an action, should also work there. It won't work in just the base part of the component, or in the base part of the store when you're defining it. In your composition function, you can't reference the state of the other store as it may or may not have actually been instantiated yet.

[00:31:18] T: Yeah. I mean, I feel in an ideal world, those cafeteria food trays, or children's plates that have the separate sections. I think there was a big scene in the Robin Williams movie, Toys like this. All the food is neatly separated, and it doesn't touch. In the ideal world, that's how I would want all of my store chunks to operate, is that they wouldn't touch. Realistically, we know that a pea is going to get into the mashed potatoes at some point.

It looks like, there's three remaining big aspects of the Vuex 5 RFC that we haven't talked about yet, which is plugins, TypeScript support, and then SSR and hydration. The SSR hydration part seems the most exciting to me. I'd like to talk a bit about plugins, because I feel plugins is this magical word that you say, “Oh, and you can incorporate whatever you like with plugins.” Then everybody is like, “Ah, that makes my life so much easier.” I'm just sitting there like, “What the heck does that mean?” The example given in the RFC is bringing in axios, which is certainly is with Vuex quite often, as a plugin.

[00:32:24] AR: Yeah. With Vuex plugins, it looks like for five, as long as you import the plugin when you create the Vuex instance. Not when you create the store, but when you actually create the Vuex instance, you can then apply it throughout all of your Vuex stores. For instance, if you want to add axios, you would add it on the store properties, and then pass it in as a plugin. Where this gets interesting is that that means, in theory, you could add a reference to your Vue router, in your Vuex store, so your store actions could, in theory, trigger router actions.

[00:33:16] T: Right. Real quickly, in the existing implementation, if I want to use UX multiple modules, I mean, axios multiple modules, would I have to delete all of them? I mean, import axios in every single module?

[00:33:27] R: Yeah. I think, this also allow us to mock things out pretty much easier. Because now, the copy is within the real instance. It's control part of Vue. Instead of us using some copyist set like module marking, we can just mock the plugin that is being injected into Vue, which allow us to catch, pass much easier without going through the whole mocking just its module.

[00:33:55] T: Yeah. That's another thing about this RFC that feels really exciting. I feel like, there's a lot of positive implications for store testing, which was we talked about in our last episode is always super fun to do. By super fun. I mean, very tricky. Is a plugin like how we have flux-like architecture? Does it basically imply a certain type of API? Is the idea that any plugin output in my store has an expected input and output? What’s a plugin?

[00:34:24] R: Yeah. I mean, it depends on the plugin that you’re injecting. What I think is going to be interesting is how is this plugin going to work with TypeScript, being that the instance is being injected into Vue. The language, the Vue, doesn't necessarily know what methods you have access to, because you are not directly referencing it in the file. I think it'll be interesting, because well, the change that we're going to talk about next is TypeScript support. After reading the PR docs, it looks like they actually have that cover.

At the full TypeScript support, they mentioned a session about plugins, the plugins offer must provide some typing interface for the plugin. Then it will extend the compositions store contacts, which allows us to have TypeScript support for the plugins.

[00:35:18] T: The impact of that is basically when I use the store in my component, and I start typing this dot store name, it'll autofill with all the properties on the store that I can use and what inputs they expect, right?

[00:35:33] R: Yes. I think, it's more than just store name. I think it's store and then there's the plugins that you’re actually using. In some cases, it may be axios. Status.startaxios. Then, once you have, you reference that particular plugin, then you have all the APIs that is available for that plugin.

[00:35:51] T: Nice. I mean, this feels such a big change. I almost wonder if this RFC comes out as is if there would be – if it would be more like a fork, rather than an iteration. There would be the Vuex 3, 4 pattern people, or I guess, users. Then the Vuex 5 pattern users, because it just seems quite a significant mind shift.

[00:36:12] AR: Yeah, this is a really, really big change in how things work.

[00:36:18] T: The last mentioned feature in the RFC that we haven't talked about yet is serialization and hydration. It says, that it can also apply to SSR Hydration. Correct me if I'm wrong, but serialization is basically taking all of your data and flattening it into one giant string. Then, when you want to hydrate where reuse that data, after you've stored it as that giant string, then you take that giant string and translate it back into its original form.

[00:36:48] AR: Yes. that is my understanding of it, too. It's a way to basically say, “Okay, cool. When I made this page, this was the state of my store.” You figure out how to put it all back together.

[00:37:03] T: Yeah. It looks like, they're suggesting having some built-in support for doing that, so you could save it to the user's browser data, or cookies, or something, which feels that could be quite nice. I don't know what security implications would be there, but I like that a lot. Before we wrap, I just want to talk about how nice this RFC is. To be fair, I haven't read that many. For example, when the composition API one came out, I remember that was pretty tough to get through. This one, the way it's structured, it first explains the existing Vuex implementation. It does a pretty good job of covering most of the bases of what the new changes are, why they're making them, what the advantages and potential caveats would be, versus the old application. Then other related ideas that are also interesting, or I guess, relevant, and crucial, but including comments about whether they would be addressed in this RFC, versus a different RFC and why, overall, it just feels very clean and well thought out.

[00:38:07] AR: Yeah. This is an RFC that makes me very excited about the future.

[00:38:12] T: Yeah. With that, it's time to move on to this week's picks. Ringo, would you like to go first?

[00:38:20] R: My pick is going to be Wandavision, which is a show on Disney Plus. Highly recommend it. If you're a Marvel fan, you should watch it.

[00:38:32] T: Nice. How about you, Alex?

[00:38:35] AR: This week, I have a pick. I know. It's crazy. It’s like, I've never had a pick before.

[00:38:42] T: That never happens.

[00:38:44] AR: My wife, Allison, loves candles. She loves candles a lot. She also really likes books. Specifically, she likes fiction, sometimes fantasy, sometimes science fiction, but she generally in general, she likes fiction. There is a company called Frostbeard Studio, who they make book-themed candles. We have quite a few of them. They all smell wonderful. I can highly recommend them. For instance, the names of them are also fantastic. For instance, you have one that is called Through the Wardrobe. It is spruce, applewood and snow is what it smells like.

[00:39:38] T: Snow.

[00:39:40] AR: Yeah, because when they in Narnia, or in the Narnia Chronicles, when they went through the wardrobe –

[00:39:46] T: The Lion, the Witch and the Wardrobe, right?

[00:39:48] AR: The Lion, the Witch and the Wardrobe. They were in the middle of the forest and it was snowing. They're trying to elicit that sensory thing.

[00:39:58] T: Snow as a scent. I mean, it has a scent. Just the idea that you could inject it into a candle, I'm like –

[00:40:03] AR: I'm from the south. I don't know if snow has a scent. We don't really get it down here in Georgia. When we do, everybody panics and screams –

[00:40:11] T: I would think, they’d include [inaudible 00:40:12] as a scent.

[00:40:13] AR: Yeah. It's mass pandemonium when we get snow down here, because it's just – we think that it’s the end of the world. There's this weird white stuff coming from the sky. I haven't ever noticed a smell.

[00:40:24] T: Ringo, you look pretty excited about these candles.

[00:40:28] R: Being from New York City, I can definitely tell you snow on the street definitely have a scent.

[00:40:33] T: Not that smell. Those are snow mix-ins. That's not the smell of snow. I remember, I saw a comment on a meetup once where somebody had said, “Eat the snow.” Then the meetup organizer simply replied, “This is New York.” I don't know why, but that has stuck in my mind for the last two years, rent-free.

[00:40:57] AR: Nice.

[00:40:58] T: Okay. I guess, that makes it time for my pick, which is mask chains. Mask chains are like the chains that people used to wear for their glasses. I don't know if they still do. I feel it's always been associated with a certain generation. Not a specific generation, but always the generation that is on the middle-aged to older end, or librarian trope maybe, that you can hook it. If you wear glasses, you can hook it on to the – are they called arms? Everybody's wearing glasses, except me. Are they called arms, like over your ear. They're laughing at me.

[00:41:39] AR: I don't know. I'm new to glasses. These are my first pair.

[00:41:42] T: Oh, congratulations.

[00:41:43] AR: I know. I can see again. It's amazing.

[00:41:46] T: Yeah. You can hook it on to the price of your glasses right behind your ear. Then you can take off your glasses and just hang them around your neck when you're not wearing them. It's very similar to that, but it's for your face mask. When these first started coming out, I was like, “I don't know if I really need that or not.” Personally, I really don't having things around my neck, which is what usually ends up happening with a mask when I'm not wearing it.

I decided to finally try it out. It's so much nicer than having my mask sitting on my chin, or under my chin. I don't know if it's safer, or more hygienic to have it around your neck, versus in your pocket. Because on the one hand, you can air it out. On the other hand, all that air is touching it. You don't know it's in the air. It's nice. The one I got came with a little clip. I can either clip it to my shirt, or clip the mask a little bit folded closed. I'll add a link to some mask chains on Etsy or something, because I think the one that I got might be a little bit hard to find. Yeah.

[00:42:54] AR: All right, so now that you have these mask chains, if you do get glasses, are you going to be one of those people that has glasses chains, so that you can wear them around your neck when you don't need them?

[00:43:05] T: Do you mean, I would have my mask chain? I don't know if you've ever worn multiple necklaces, but that can get a little bit tricky.

[00:43:15] AR: I have not worn multiple necklaces. You’ve got me there.

[00:43:18] T: Yeah. Then imagine if on top of that I had wired headphones.

[00:43:22] AR: Yeah. No, that does not sound – That's not going to work. Just keep your airpods in all the time. That's all you got to do.

[00:43:30] T: If only you could chunk necklaces like you could chunk modules. They do have these things that let you hook multiple necklaces to a single core. I don't know what to call it. It's like a stem with little rings coming off either side, so you can keep them stacked in a certain order to theoretically help prevent necklaces from tangling.

Maybe somebody will make something like that for glasses and mass chains. I can't imagine there's a big enough market, or that it would be an accessible enough product that it would see mass adoption. I guess, last year was pretty unpredictable. Who knows what 2021 will bring, right?

[00:44:08] AR: Indeed.

[00:44:10] T: That's all for this week's episode. If you aren't following us on Twitter, you can find us @EnjoyTheVueCast. On that note, if you aren't subscribing to us yet, why not? Please do. If you have time, leave us a review. Finally, remember to tell at least one friend what you enjoyed about this week's episode. Thanks for listening and until next time, enjoy the Vue.

[END]