Alright, it’s code talk time! This last week has been rough. Just with everything going on it’s been stressing us out. But we were able to talk to some people and it helped us feel reconnected. That out of the way :3 let’s get into the code! So the fun part about this is that we can explain code on this very page! We can just go over the blog post page itself. Oh, by the way, we made the repo
@inject BlogService BlogDataService
Let’s start at the top of the code file. Which is a good idea, the top of code files is where you often find the most concise information. Look at just these four lines of code, what does it tell you? First we have page, this is how blazor app handles routing. So we know the url for this file, so if you are familiar with the site, you already know exactly what file this is. So we know this is the blog post file, and it takes an Id that is a number, and maybe with a type, which is ‘dev’ or ‘personal’ Which makes sense, the Id is for the post itself, and the type is for dealing with next/previous. So if you are familiar with web development, you might be wondering why we are passing information through the URL. This website is clearly a SPA. So let’s talk about the difference between stateful and stateless websites.
Stateful: The website/server keeps track of the current state of the website. Though things like keeping a connection with the server open. If you are on a website do a bunch of stuff and refresh it and it’s not even the same page anymore it’s for sure stateful. Think of it as a video game, if you game over, you have to start over. Every new request is added on top of what came before.
So clearly these are two extremes. More generally speaking it’s referred to how much a website is one or another. Also simplifying things a bit, but hopefully it gets the idea across. So our website is pretty even between the two. The framework, blazor, does keep track of a state, but you can choose how much of that state to rely on. Instead of passing something through the url, we could pass it though just as a code file, or state. Because we pass it through the url that means if you refresh this page, this post will still be here, and the type will still be set.
Next we implement IDisposable. So in C# interfaces start with a capital i(I) by best practice. So what is an interface? We aren't going to dive fully into inheritance right now... Turns out we already wrote about Inheritance
. The main point is interfaces are a “has-a” relationship.
//todo: implement tags and a search feature
So what does a “has-a” relationship mean when it comes to C#? Basically it is used for when a class can do something. In this case it can dispose. Many interfaces are used by implementing an event. So because IDisposable forces us to make a Dispose() method to even compile. So if you don’t know what disposing is when it comes to code. It means that when this file is unloaded, to do something. Which means, this page tracks state in some way. Leaving this page does something, likely with the server. Because we already know refreshing the page will still pull up more or less the same page, we know this page does something with the UI or with the state.
In this case it’s due to the website being a fairly stateless SPA. If we want the URL to change, without refreshing the page, and only call to the server for what is needed, while staying on the
same page, then we have to subscribe to an event so we can tell the page to refresh. While this does mean on a lot of pages we have to manage the state ourselves and write fairly repetitive code, it makes the code much more organized.
Thinking about it now, there is a better way to do that. So what would be best is to inherit from a page that implements adding the current state to be updated on route change. We just looked into it and there is an @inherits tag. Need to look into it a little more, but we think we can remove quite a lot of boilerplate code by moving most of the IDisposable state tracking to it’s own file. That’s great! This serves two purposes.
One: code reuse while still being able to override it
Two: it will be a one line change at the top of the file, and sense it won't be a generic IDisposable line we will know exactly what it’s added function is.
Thanks rubber ducks :3
So the last line, an inject, this let’s the front end file call C# code on the server. This is how we make API calls in blazor. Under the hood every time we call a method from an injected class, it is really an ajax call to the server (some exceptions, also talking about server side blazor). Isn’t that neat. So in order to get access to this file, we have to reference it in some way. This is accomplished in two steps.
One is that in the startup file that runs when the server starts we add this class as a singleton to the program (once made a video
on singletons, but those videos on coding were bad, text is much better). Basically being a singleton means that it’s state is shard across the whole server. So if we base something on the site on a singleton variable, it would affect every user. Best to think of them as fully static (in code terms) sense.
Next on the front end file itself with an inject. This tells the file that there will be a connection to this singleton. And because we name all singletons with Service, we know it’s a singleton, which means this file interacts with the server. And based on the name, which granted, could be better, tells us that it calls to the server to get information from the DB for the blog.
This is why naming and conventions are important. While sure, we have built the website by ourselves, if someone else was familiar with blazor, they could use lines like these to get an understanding of how the code likely functions. Self documenting code and refactoring. As we get more familiar with this framework we are learning how to use it better, which means in order to keep things consistent and easy to understand, we have to go back and update code.
This is something we already do when building new projects in something we are familiar with. Build reusable code and give things meaningful names. The more you do that, the easier it will be to maintain the code base. Right now if we wanted to change all the places where a page adds itself to the state event, we would have to change code on a few files. With that idea of inheriting, it would only be in one place. And because we keep our code clean and self documented, it is easy to go through and update/add things that we haven't touched in a while.
We just spent 2 pages talking about 4 lines of code. If you want to evolve from just a programmer to a software engineer, you need to think about code on this level. We are not just writing code to do things, we are always experimenting with code, applying what we know and building our knowledge. This is why software engineering is magical, it is a branch of science where you can experiment and learn with very little risk and for very little cost. Everything we use is built up from base ideas that have been tried and tested. It’s important to keep in mind that there could be better theories out there though. That’s what being a scientist means, changing your stance based on what currently seems the most right and then exploring.