| Website | https://jukka.snellman.online |
| Website | https://jukka.snellman.online |
As an update, I made sample project for those "generic strong IDs": https://github.com/jukkahyv/dotnet-entity-id
That includes Roslyn code generator for global usings (global using OrderId = Id<Order>). I've been using those for a while now, and it works.
With the new #dotnet project I've gone all in with value types, even using custom type for entity IDs.
record struct Id<T>(long Value)
It's better for type safety (can't mix IDs of different entities) and also for type inference.
If only #csharp had proper type aliases, so I could define UserId = Id<User>! global using helps, but it's still only project-specific. I want to write code generator that generates those global usings.
It just took me half day to figure out why my React Error boundary isn't working, and the answer seems to be only on the legacy docs page??
https://legacy.reactjs.org/docs/error-boundaries.html#how-about-event-handlers
"Error boundaries do not catch errors inside event handlers."
🤦‍♂️
Just saw this C# rule, and I have to say I disagree: https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1860
For the performance, sure, maybe, depending on the situation, but for readability, I find collection.Any() more readable than collection.Count() > 0.
#csharp #dotnet
AI generation when writing software is a false economy. You are replacing writing code with code review. Code review is harder and requires you to already have an understanding of the domain which often means that you would’ve even able to write it yourself to begin with. If you code gen something because you don’t know how to write it yourself, you by definition cannot review it without going though an effort equivalent to writing it yourself in the first place.
Unless of course you don’t care about code review and so doom yourself into treating software like magical incantations that break randomly for no perceivable reason; but no good mage would do that, surely.
Null object pattern works very well with C# nullable reference types and TypeScript strict null checks. I have been removing null values from code and replacing them with null objects.
For example, instead of passing null as "loggedInUser", use
const anonymousUser: User = {
id: "",
isLoggedIn: false
}
If you finally found the solution to your coding problem in a deep comment or something after having dozens of tabs open, you should write about it in your own blog.
Really. Describe the problem in your own words and the solution for it, even if the solution seems really obvious now. Doesn’t matter. Give credit and whatever, but use your own words because you will be surprised at how many people will land on it.
Write the blog post you wish you had found.