Posts

If there is one thing that I see developers looking into Vuex getting hung up on the most, it’s these weird map functions that are in Vuex. The syntax is just so damn weird. What the hell are these ... things doing? Why do I need them sometimes and not others?

Once you start using Vuex to manage the shared data of your Vue application, it becomes less clear on where or how to call your back-end API. I think everyone starts out making API calls in the created function of your component. But that doesn’t scale past a handful of components. Then, they end up loading in the same data over and over again and each component has it’s own copy, which is impossible to keep in sync. You lose the efficiency of having one part of the system in control of the data when you do that and on a larger application, this very quickly falls apart.

When I first started using Vue, one thing I got continually wrong was how to load an image into a Vue component dynamically. At first, I found that using an absolute URL worked, but that was only useful if I was storing the images on a CDN or other external site. If I included the images in my project, as either lightweight icons or static images, then using an absolute URL, with hostname and all, didn’t really work. What about when I wanted to test some new images locally or on a dev server? Linking directly to the images in production just wasn’t going to cut it.

One big question people have when building frontend applications is, what’s the best way to keep backend data synced with my frontend data? You seem to always get different answers from different people and the dreaded “It depends”. Well, what does it depend on?

One of the questions that comes up time and again concerning Vuex is “Do I always use a getter when accessing data? Or can I directly access the raw state?” It’s one of those things you hear about that you should do, but no one seems to really explain why. And do you really need to create a getter for every single piece of data that you put in the store? Isn’t that just a bunch of unneeded boilerplate and duplication?

If you’re like me, when you first ran into Vuex, you probably wondered “How the heck does this work?” It’s not immediately obvious how these types of state management systems work, especially if you come from an SQL background. And do I even need it? In fact, the Vuex documentation has a quote that sums it up pretty well:

Welcome to further reading and notes from the Your Own Personal Bootcamp talk. It was great seeing you all at PyOhio this year and I can’t wait to come back again. I hope that, if you were able to see the talk, you were able to pull something away from the talk and had as much fun watching it as I did giving it.

It’s a common question I’ve seen around and one that I’ve wondered about myself at times. When using Vuex, why is it said that state should only be changed via mutations? Is it really that big a deal? Can’t I just change it directly? It sure seems to work just fine that way.

Looking for how to format dates in Vue 3? If you’ve used Vue for any length of time, you soon find that it doesn’t have a lot of the fancy formatting options that some of the other frameworks seem to have out of the box. I get the feeling that Vue is very focused on minimalism and adding features that aren’t core to the framework is not something they want to do. One of those features, however, is formatting dates.

If you’re working in Vue, the Vue CLI is an amazing thing. There are a lot of moving parts in modern JavaScript development and the CLI makes managing these very easy.