Introduction Discovering more efficient ways to handle data queries can be quite enlightening. I recently had an “aha” moment with Entity Framework projections that I’d like to share, especially since it’s a pattern I’ve been using for quite some time.
The Initial Setup I’ve set up an example ASP.NET Core Web API with the following entities:
public class CategoryEntity { public int Id { get; set; } public string Name { get; set; } = null!
Introduction While creating a SOAP API in ASP.NET Core 6.0 with SoapCore, I ran into a problem: my XML response had an extra layer that shouldn’t be there. The system using the API couldn’t work with this additional nesting.
Looking for solutions in various StackOverflow discussions and even a past GitHub issue, nothing seemed to work.
So, the decision was made to try something else - CoreWCF.
To illustrate the impact of our changes, let’s compare the SOAP messages before and after the transition.
Introduction As developers, we’re always looking for ways to write cleaner, more efficient code. One common scenario we encounter is the need to handle potentially null values safely. In C#, nullable reference types have been a significant step forward in my opinion, but they can sometimes lead to extra checks and assertions.
I recently stumbled upon a neat trick that simplifies this process and wanted to share it with my team - and now with you.
Introduction When working with JavaScript/TypeScript projects, whether that’s React, Node, or something else, I often find myself needing to print out the value of a variable to the console.
To do this, I’d usually begin by typing out console.log and then copy and paste the variable name into the parameters to get console.log("foo", foo)
Easy enough, but can get quite repetitive and tedious. So, I thought, “it’d be cool if I could just click on a variable and automatically copy a console.
The Problem Recently, while working on a project using React-Admin, I encountered a frustrating issue. I had an Edit component with a TabbedForm set to pessimistic mode, and a custom data provider based on React-Admin’s simple REST provider. Everything worked fine until the server-side validation kicked in.
The validation rule was straightforward: it ensured that no two entities shared the same name. If the rule was violated, the server would correctly return a 400 error with a message, which I displayed in a toast notification.
