Skip to content
Figuring out how technologies are maid under the hood is one of the things I love to do. Ever since I started using Blazor and going in-depth into its features, I can’t stop wondering how things are made internally.
This post is the start of a series about, you guess it, Blazor Internals.
How to pass values to all children (multiple levels), both in Blazor and React, and what are the differences between the two
There are times where I needed to do some things dynamically and I typically think of Expression Trees to do it. Don’t get me wrong, Reflection does the job most of the time, but it’s known to be very slow in almost all cases. I happen to have a bit of experience in the former.
I was working these days on my library Blazor.Diagrams and I needed to write some documentation to show all the available/possible options. I could’ve done it manually, but there was quiet a few settings and I didn’t want to have to update the table every time new ones are added.
After working with Spring Boot for a couple of months now, one thing that I find lacking in ASP.NET Core (C#) is Aspect Oriented Programming (AOP).
In computing, aspect-oriented programming (AOP) is a programming paradigm that aims to increase modularity by allowing the separation of cross-cutting concerns. It does so by adding additional behavior to existing code (an advice) without modifying the code itself, instead separately specifying which code is modified via a “pointcut” specification, such as “log all function calls when the function’s name begins with ‘set’”.
Immutability has been getting popular these last years, especially with the rise of not only functional programming and but also JS frameworks such as React.
It’s an important concept for many reasons, but I won’t get into it in this blog post because it’s not the point. Although I would urge you to either read The Dao of Immutability or watch Jon Skeet’s The changing state of immutability in c# video, which explain it in details.