The .NET Stacks #43: 📅 DateTime might be seeing other people

#dotnet #csharp #azure

Happy Monday! I hope you have a productive week and get more traction than an excavator on the Suez Canal. (Sorry.)

One big thing: New APIs for working with dates and times
The little things: Hot reload, debugging config settings, Clean Architecture resources
Last week in the .NET world

One big thing: New APIs for working with dates and times

If you’re walking on the street and a person asks you the time, you can look at your watch and tell them. It’s not so simple in .NET. If you only care about the time, you need to call and parse a DateTime or DateTimeOffset and scrap any date information. This approach can be incredibly error-prone, as these structs carry time-zone-related logic that isn’t written for getting the absolute date and time. (That doesn’t even include its general weirdness, like DateTime.TimeOfDay returning a TimeSpan and DateTime.Date returning a new DateTime. Even on its best days, the DateTime struct is both overloaded and confusing.)

Over on GitHub, there’s a spicy issue (with some bikeshedding) discussing the possibility of a Date struct and a Time struct. Initially, Microsoft chose to expose the features as an external NuGet package. However, .NET developers are looking for the changes to be in the core of the .NET BCL APIs to avoid third-party library dependencies. The issue has a proposed API.

You may see these named differently as Visual Basic has used Date for three decades, and this would include a breaking change (and it might confuse folks using C# and VB). Right now, DateOnly seems to be the new name. I hope this is not a permanent name.

Here’s an interesting comment from the issue about a user’s scenario:

I’m instead interested in the Date class most of all … We have a lot of products that is valid from date X to date Y. When we used DateTimeOffset we always had to remember to start at date X 00:00:00 and end at date Y 23:59:59.999. Then we switched to NodaTime and used LocalDate from there and all a sudden we could just compare dates without bother about time. We store Date in the database and map the column to a LocalDate now instead of a DateTimeOffset (which makes no sense since Date in the DB don’t have time or offset) which makes our lives even easier.

This is all developers want from their SDKs: simplicity and predictability. The excellent NodaTime library provides these capabilities, but it isn’t coming from Microsoft—which stifles adoption. It’ll be great to have simpler APIs with working with dates or times, but it might be a while before we see it in the wild. (And for the record, DateTime isn’t going anywhere.)

The little things: Hot reload, debugging config settings, Clean Architecture resources

Say what you will about JavaScript (and believe me, I have), but it’s no mystery why it’s so widely used and adopted: the barrier of entry is low. I can open a text file, write some HTML markup (and maybe some JS), and open my web page to see the results. The instant feedback boosts productivity: in most common front-end frameworks, you can use “hot reload” functionality to see your changes immediately without having to restart the app.

That functionality is coming to ASP.NET Core (and Blazor) in .NET 6—we got a quick preview this week at Steve Sanderson’s talk at NDC Manchester. He showed off a promising prototype. Steve added and updated components (while preserving state), updated C# code, and worked well. The error handling looks nice, too—the app shows an error at the top of your page and will go away once you correct your issues and save. In some scenarios where you can’t do hot reload, your app will refresh your browser as it does now. This functionality is almost ready to show off to a larger audience—look for it in .NET 6 Preview 3, which will be released in the next few weeks.

He also showed off an ErrorBoundary component, allowing developers to have greater control over error handling in Blazor apps. As it is today, when unhandled exceptions occur, the user connection is dropped. With this new functionality, you can wrap an ErrorBoundary around specific markup, where unhandled exceptions in that section of code still allow users to access other parts of the app.

A month ago, our friend Cecil Phillip tweeted:

Cecil L. Phillip 🇦🇬

@cecilphillip

IConfigurationRoot.GetDebugView is really useful for inspecting your resolved configuration settings! 👨🏽‍💻 It's been around since .NET Core 3.0 and I never knew! 👀

docs.microsoft.com/dotnet/api/mic…
#dotnet #aspnetcore

15:42 PM - 17 Feb 2021

I never knew about this, either—it helps you discover your environmental variables and settings and where they’re getting read. (And, of course, it should be used for development purposes only so you don’t accidentally leak secrets.)

When it comes to recommending architecture solutions, I use the two words that consultants live by: It Depends®. Even so, there’s a lot to like about the Clean Architecture movement.

This week, Patrick Smacchia wrote about Jason Taylor’s popular solution template. Also, Mukesh Murugan has released Blazor Hero, a clean architecture template that includes common app scenarios under one umbrella. These are both good resources on understanding Clean Architecture.

Lastly, this is exciting:

dodyg

@dodyg

MapAction is a new way to create Web APIs without relying on Controller. (.NET 6 Preview 2)

github.com/dodyg/practica…

#aspnetcore

07:51 AM - 25 Mar 2021