Currently, MyButton has 3 [Parameters]. If you add them, a new [Parameter] will have to be defined. In order to avoid constantly updating this Component, we use the '@attribute' provided by Blazor.
Now we have an interface where we can enter a log, but a log means writing every day. How can only one article be enough? Let's add a blog.
If we want to add a button to clear the data of the form, the fastest way is to add a button with the name "reset". At this time, two buttons will be used, and we can use Blazor's core concept: component encapsulation.
Now every time you start a project, the default path will be '/', but we currently don't have a Component to apply this route. It's a bit troublesome to switch to 'Post' yourself. In addition, the pattern of the Menu does not match the name. Let's adjust it.
All services you create must be registered with Startup.cs (Blazor Server) or Program.cs (Blazor WebAssemlby), but you don't have to do some basic services yourself.
Yesterday, I saw that the code of `FetchData.razor` was too long. For convenience, we extracted the part of `@code` and made it into another file.
The question arises, why does Blazor know that WeatherForecastService can be called here?
Most of the Windows Forms applications I encounter do not exist or have extremely low unit test coverage. And they are often difficult to maintain, with hundreds or even thousands of lines of code behind the various Form classes in the project, but it doesn't have to be.
Since I originally used ASP.NET Core API + Blazor Server, I will use Blazor Server to demonstrate it. I will make up for my experience after studying Blazor WebAssembly in the future.
After downloading Visual Studio, first create a Blazor solution, in which you can create a Blazor Server project. You can choose the location of the solution (Note: The new version of Visual Studio separates the Blazor Server and the new project template of Blazor WebAssembly, which is more intuitive)