Tagged with Web Development
Vuelidate is reworking their project in light of Vue 3's release. It is only in Alpha, but I like the approach and integrated it into my Microservice demo I'm working on.
In light of this, I thought I'd talk about how Vuelidate is now working with the Composition API. While it is still early in development, I love the approach.
For this example, i'll point you to my Payment view in my Microservice project (a work in progress):
In the several years that I've been developing and teaching Vue, I've tried a lot of different ways to make ASP.NET Core and Vue play nice with each other. One of the strategies that I've seen employed (especially with Angular and React) is the Spa Framework Extensions out of Microsoft. Because Vue didn't work out of the box (or have a template) I dismissed this approach for a long time. Now that the platform has matured and there is an open source extension for Vue,
I thought I'd revisit it. Though I still think it's not exactly the right approach. Let's see why.
Originally, I thought the fix was to just deal with it separately. That meant opening it in VS Code or just using the command-line to run the project. I wanted something more integrated and I think I found a solution I don't mind.
I've been digging into Vue 3 a lot lately. One topic that a lot of people seem to be discussing whether to use Vuex or not in Vue's Composition API (that is prominent in Vue 3).
After looking and prototyping some of these options, I wanted to share my opinions. In this post, I'll review different strategies (including Vuex) and talk about the pros and the cons of each.
I started out with a simple Vue app, fresh from the Vue CLI. It's using Vuex and the Router via Vue 3 (RC 9 at the time of writing of this post). You can find the project on Github if you want to play with it:
I've been digging into Vue 3's beta for a while now. I like the new composition API, but it looks like there weren't that many quickstarts for getting a Vue 3 project going.
I decided to make a quick video to help you get started with it. The way that I create the project might change once Vue 3 gets to RC, but at least for two weeks, this should help some of you who want to get ahead of the curve. View it here:
In my spare time, I've been working on a micro-services example to try and make a minimum viable micro-service using ASP.NET Core. To make things that much harder, I've also decided to use Vue 3 for the front end. In for a penny, in for a pound.
After spending the last month with Vue 3 (or so), I've come away with some opinions that I thought I'd share. Some of these are because of the lack of support for Vue 3 for some of the common libraries I used, but in many ways it's a love letter to some of the features I really love. Her we go...
Developing on a Beta can be difficult. Lots of time there are inconsistencies between different versions of packages that are in different states. I haven't found this to be a particular problem with the Vue ecosystem.
Yet another of my talks that resulted from being bored at home and on Twitter. I had a great time talking to this great group.
Even though it was a .NET group, they were open to me digging into why I think Vue is a great choice for the right project. They had great questions too!
As promised here are links from the talk:
I recently offered my speaking skills on Twitter since I'm stuck at the house. My wife really wants me out of the house, but luckily I like the sound of my own voice enough that virtual talks fill that same void.
Since I'm doing these talks on Zoom, I'll be uploading the talks to YouTube to share them with as large of an audience as possible. This is the first of them.
The talk today was about Vue.js and how to use it with and without the Vue CLI. As promised here are links from the talk:
As Vue 3 continues it's relentless Beta drive (with almost daily Beta builds), all of us Vue developers have to get ready for changes. The one I want to mention today is the changes in mounting a new Vue object.
In prior versions, Vue used the global Vue object to specify things like plugins. In Vue 3, this changes to allow you to mount separate Vue instances with different plugins. Let me show you how.
With Vue 3 now in beta, some people are starting to look into it deeper (including me). While a lot of the features are meant to improve the performance and speed, the Vue team did decided to take out a feature lots of people use: filters.
Let's talk about why filters are gone. Then I'll show you a pattern I'm using to replicate the functionality.
As a review, in Vue 2 (and 1 actually), Filters were a way to format data in markup. For example:
As we're all in this crisis together, Pluralsight has opened up their entire library for free in April. No Credit Card needed! Just sign up.
If you haven't used Pluralsight before, I thought I'd recommend some courses (mine and others). If you're home, this is a great time to improve your skills and hide from the rest of your family. At least that's my plan.
The last couple of years I've needed a couple of new sites to promote things I'm working. Because I'm a .NET developer, my first instinct is always to just File->New an ASP.NET site. But should I?
Instead of using ASP.NET, these sites are typically one-pagers to promote something. I've done this with my https://helloworldfilm.com, https://imfinefilm.com, and most recently my COVID-19 state-by-state tracking site: https://covidstates.azurewebsites.net.
The benefit of skipping ASP.NET in these cases is simplicity. They're just HTML/CSS/JS. Since I don't need any server-side code running, I just create the HTML and post it. Even in the cases of the film sites, I use widgets (in my case with MailChimp) to collect emails instead of doing the email work server-side.
Assuming you read my last post, you should be ready to take your ASP.NET Core project and deploy it to Azure App Services. This post, I'll walk you through the process.
Much of what I will show you can certainly be done with the Azure CLI, but I'm not fancy, so I'll show you in the Azure portal. Hopefully that won't ruin my cool quotient among developers ; )
This will be a three part series:
I've been using Azure App Services (e.g. WebApps) for a few years now. I've been mostly happy with the result. Though I've had some trouble with the way that the App Service environment works from time to time (mostly with the version of .NET Core that is running).
To try and eliminate that (and possibly save some cost), I decided to switch my apps to use Docker Containers. I thought I'd share how I did it in case you want to do this as well.
This will be a three part series:
The new year is coming soon and that means it's time for my yearly look back at my life and industry. This was an odd year for me since I didn't do many conferences and stayed home to solve some issues and work on the film.
The year home did me a lot of good. My health is even better and first year without major kidney stone issues. If you've read my blog for a while, you might remember that I did this last year.
After being curmudgeonly about turning 50, I feel a lot better about it now that it's behind me. I still don't feel like retirement is coming soon. Luckily since I'm mostly teaching, most days I have time to code on my own, continue to make films, and be available to my family. I'm a very lucky person. I Here are some categories of my life.
I'm working on an example to explore some more complex modeling in EF (for SQL and NoSQL) but that's not ready so I thought I'd use it as a bed for some Validation testing I'm doing. The result is some exploration of the FluentValidation project that I haven't had time to dig into until now.
Validation is an interesting exercise in ASP.NET (Core) and trying to get it correct is quite difficult. Ultimately in this day of SPAs and mobile apps, we need a solution that handles the client and the server. If you don't validate on the server it just doesn't matter.
FluentValidation is a replacment for the existing validation attributes (DataAnnotations) that you might already be using. The idea is to separate the validation from the classes. To be clear, this doesn't replace setting up your Entity Framework types with Fluent API this is about server-side validation only. Think of it as a clearer way to define rules for validation of your models or DTOs.
I may be very late to the party, but once Gulp 3.x stopped working with recent versions of Node, I've been forced to update my projects to the newest version of Gulp.
I was hesitant to learn it as I often think of Gulp as just a side-line tool that I use for production. Luckily for me, the new Gulp is actually simpler and more intuitive. I wanted to write a quick blog post explaining how I converted them.
Let's start with my Gulp 3 version:
I was delighted to spend some time today at Connect.Tech conference. Great web conference and it was packed. So many excited people who wanted to talk about web technologies!
I saw some great talks before mine. I tried to convince the audience that Vuex would simplify not complicate their Vue projects. Hopefully I succeeded.
As promised, I wanted to share my slide and code.
Endpoint Routing was introduced in ASP.NET Core 2.2 but has been made a first class citizen of ASP.NET Core in 3.0. While you're old projects will continue to work without it, upgrading to Endpoint Routing will improve your applications.
Endpoint Routing is a system to handle routing across different middleware systems (e.g. MVC, Razor Pages, Blazor, SignalR and gRPC). By having endpoints that work with each other, you can think of a system more holistically then having terminal middleware that don't talk to each other. Let's see what that actually means in practice.
If you've seen the new project template, you've probably already noticed that setting up RazorPages and MVC look a bit different. First in the ConfigureServices:
I'm finally getting around to looking at updating my examples and courses to 3.0. This post is based on .NET Core Preview 8 so this might change in the future.
There are a number of great walkthroughs for moving your ASP.NET Core 2.x projects to 3.0. So I don't want to repeat that. Instead, I want to talk about what's happening, not just a list of things to do.
To discuss these changes, i'll talk about a project I'm current converting (CoreCodeCamp which is the basis for the Atlanta Code Camp), though it's a branch that likely won't be deployed until after the event.
I started writing services in websites back in the .NET 1.0 days. Originally I was doing just POX (Plain Old XML) services in a very crude way so we could get the job done for our internal systems back in the early 2000's.
This means I've been through the "new tech" crazy with services for a long time. I've spent much of the last year digging into different tech for services to interact with websites (though many of the same issues are for rich clients and IoT). I'm not done and don't know how right my assumptions are yet, but I thought I'd try to start a conversation.
While I've lived through POX, SOAP, and REST...I don't think this is another wave. I think this is a widening of options for services. But what does the service ecosystem look like right now? (Caveat: I'm going to miss your favorite idea, so feel free to add to the discussion below.)
I've been updating the Atlanta Code Camp website to improve our administration workflow. With the Call for Speakers coming up soon, I wanted to make sure we had a good way of picking only the best talks.
One of the things I've done is move it to a Single App with Vuex at the center of it. But I ran into an oddity with Vuex that I thought I'd share.
Much of the work I do in Vuex has to do with adding, updating and removing objects from the state. That works exactly the way I would expect. For example, I have a lot of mutations that looks like this:
There is a lot of buzz around the internet about Vue.js 3.0's announcement about a new composition model. There are a lot of questions about it and I think much of it is 'they moved my cheese' more than 'they're breaking everything'.
So let's talk about it...
Evan You's announcement in London last week scared a bunch of people, including me.
ASP.NET Core 3 seems to be taking a similar tact to version 1 as it is adding a lot of functionality and phasing it in with different previews. While a lot of the articles seem to be focusing on the non-ASP.NET features (e.g. WPF, WinForms, etc.), I thought it would be nice to let those of you who are ASP.NET devs know what is in Preview 6 just for you.
It feels a lot like the ASP.NET MVC/API side is being treated as mature and stable as there is are not a lot of surface changes. Microsoft does seem to be doubling down on Razor Pages and Blazor. It feels like they want .NET Core to be a good fit for different styles and backgrounds of developer. This release is no different.
Let's take a look at the details:
As you might have heard, GitHub has created it's own package registry. On the face of it, it might just feel like an opportunity to get more 'buy-in' into using GitHub, but I think something else is going on.
While most people are focusing on the support in NPM for the GitHub registry, they're actually supporting a package repository for a handful of package services. These include Nuget, Ruby Gems, Maven, and Docker. Why are they doing this?
The biggest benefit for people already using GitHub is to be able to expose their code as packages directly in the same environment. This limits the number of steps involved.
One of the first times I started working with Vue, I was concerned about it's long-term success. I was coming from Angular and their ecosystem is huge.
I was delighted to find that the ecosystem is pretty varied. The Vue website tries to make it easier to find the kinds of libraries and components that you might need. It comes from two places on the website.
On the Vue website, you can look in the Ecosystem menu: