The Blog
My Rants and Raves about technology, programming, everything else...
Should I Be Using the ASP.NET Core SPA Templates?
I've been writing demos for Vue, Angular, and React for my SignalR micro-courses over on my Wilder Minds site. For Angular and React, I started out with the the SPA templates, but I found them confusing and hard to do a minimal example.
I tend to suffer from "You Moved My Cheese" and wondered if I was throwing the baby out with the bathwater. Let me talk about my experiences creating projects with and without the templates.
My initial problem with the templates is that they are using node under the covers to handle the build of the project. I hate that these details are hidden from me, but I'm confortable with having a console window to keep a watch on my webpack-based projects (the Vue CLI, Angular CLI and React CLI all wrap webpack).
Vuex and Asynchronicity
If you're using Vuex for state management in your Vue.js applications, there is a good chance that you need to use async operations (e.g. API calls). I have been doing this a while, but falling back to using Promises in most cases.
As I've been using async/await in C# for a while and wanted to try out async and await in JavaScript. In implementing the change, I thought I'd share how I did this in a simple Vue app.
To start out, I have a little demo project where I'm making some API calls directly in Vuex via actions:
Vue's Single File Components vs. React's JSX
I have to admit, my first experiences with React several years ago were meet with a lot of cynicism. The idea of mixing JavaScript and Markup made me clutch my pearls to the core.
Now I know that you can use React without using JSX, but I think that is missing the point in a lot of ways. Of course, I'm not a React expert so I am sure you'll let me know how wrong I am ; )
In case you haven't used React yet, let me just talk about how JSX works. In React, when you build a component, you're mixing JavaScript with markup. The idea is that during compilation, the markup is replaced with DOM code to build up the markup you're specifying. For example:
Using Vue CLI Inside an ASP.NET Core Project
As many of my readers already know, I've become enamoured with Vue.js. Because of this, I've been using it more and more on projects.
Since I also deal with ASP.NET Core almost exclusively, I've been at odds with how to get the two technologies to work well together. Originally I had just used the JavaScript file, but as I've started building larger pieces, I've wanted to use projects built by the Vue CLI in ASP.NET Core. Here's how I've been doing it. Might not be right, but it's at least a way ; )
I'm going to assume you have used the Vue CLI and ASP.NET Core before. So I'm skipping a lot of steps like creating the ASP.NET Core project. I'm also going to assume you've opened up a console before and ran commands. Lastly, I'm assuming you're using Visual Studio (though shouldn't be much different if you're not), and that you have the Vue CLI installed.
Creating a Vuex Plugin
If you're building larger scale Vue objects and you're not using Vuex to centralize your state, please stop and go learn Vuex. Really.
For those of you still here, sometimes it's helpful to be able to monitor state changes to perform other tasks. For example, to send messages or communicate with servers that aren't about state (e.g. SignalR is a good example). That's where Vuex plugins come in.
A Vuex plugin is a simple function that is called once during the setup of a Vuex store. Typically you'd just create the function/arrow function taking an instance of the store:
export default store => {
};
Inside the function, you just want to subscribe to changes to the store as you need. An easy way to think about this is to use subscribe to a mutation:
export default store => {
store.subscribe((mutation, state) => {
if (mutation.type === "setError") {
// Alert someone
alert("Error occurred!");
}
});
};
The mutation that is passed in has a "type" and a "payload". With these properties of the mutation you can determine what to do. For example, the above example just pops up an alert (a really bad thing to do btw) when setError mutation is called. setError is a mutation in a store:
SignalR Micro Course
At my training site (Wilder Minds Training), I'm working on a new kind of course for me. I'm calling them Micro-Courses.
The idea behind these new courses is that they are short and teach one very discrete skill. My first one is SignalR!
I will probably be adding more SignalR micro-courses for it's use in different SPA networks fairly soon. If you have a course idea that you would like me to make, feel free to contact me.
A Vue to a Skill - New Article in Code Magazine
I'm back writing again. I've missed it. You'll see more and more articles in different publications from me in the near future.
The first of these articles is for Code Magazine. It's a quick overview of how Vue works and how you can use it for more than just SPAs. Check it out here:
Let me know what you think!
Vue.js Talk at Atlanta Vue Meetup
I had the opportunity to speak at the Atlanta Vue Meetup recently. This was a great group of people who had mostly had experience with Vue.js.
I'm so used to having to try and convince people to use Vue, that this was a fun talk to get people interested in using it in different ways than they are used to.
As promised, here are the slides and code:
Vue.js Presentation at the Atlanta .NET Users Group
I had a great time presenting to the Atlanta .NET Users' Group last night. I talked about where I think Vue.js.
I got to espouse my opinion (again) about SPA being large monoliths instead of building 'islands of functionality'. I learned a new achronym too, "Multiple Page Apps" or MPAs for this type of client-side dev.
As promised, I wanted to share the code and the slides:
Looking Back to 2018 and Forward to 2019
So it's the new year and I guess I'll join the party with my end of year wrap-up. It's been a big year for me and I'm excited about this next year.
If you've read my blog for a while, you might remember that I did this last year. My goals were a bit hit and miss. Some I did really well, and others I struggled. But I think that's the nature of it all.
This year I turn 50 and I feel old. When I started this job at 16, I didn't think I'd be doing it 34 years later, but here I am. And I'm still loving it. I still code almost every day, and continue to make courses. Here are some categories of my life.