Reading searchParams with "use cache" causes the build to hang

[zaiste]

Link to the code that reproduces this issue

https://github.com/zaiste/nextjs-searchparams-bug-use-cache

To Reproduce

Build the application

npm run build

Current vs. Expected behavior

Current: The build process gets stuck. Expected: The build process finishes

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.1.0: Mon Sep 30 00:10:31 PDT 2024; root:xnu-11215.40.63~39/RELEASE_ARM64_T6000
  Available memory (MB): 16384
  Available CPU cores: 10
Binaries:
  Node: 21.7.1
  npm: 10.9.0
  Yarn: 1.22.22
  pnpm: 9.12.2
Relevant Packages:
  next: 15.0.2-canary.6 // Latest available version is detected (15.0.2-canary.6).
  eslint-config-next: N/A
  react: 19.0.0-rc-1631855f-20241023
  react-dom: 19.0.0-rc-1631855f-20241023
  typescript: 5.3.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Developer Experience

Which stage(s) are affected? (Select all that apply)

next build (local)

Additional context

No response

[MatthewB05]

Also, is there a reason why the DatePicker doesn't use the system region settings ? It seems to be in US format and you have to manually set it to the value in ShortDateFormat, whereas my expectation would be that system formats are used except where the user specifically wants to specify a different format.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[FrankPohl]

I would expect that it uses the default format of the current system culture be it long or short, too. But setting the desired format in XAML or code behind would be OK. You never know whether it should be long or short format. But to use the short date format of the current system culture would be the best default. Using US format is not very useful.

Von: MatthewB05 @.> Gesendet: Donnerstag, 20. Oktober 2022 18:54 An: dotnet/maui @.> Cc: Frank @.>; Author @.> Betreff: Re: [dotnet/maui] Date Formta property in DatePicker not working on Windows with date Format (Issue #10805)

Also, is there a reason why the DatePicker doesn't use the system region settings ? It seems to be in US format and you have to manually set it to the value in ShortDateFormat, whereas my expectation would be that system formats are used except where the user specifically wants to specify a different format.

Reply to this email directly, view it on GitHubhttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fmaui%2Fissues%2F10805%23issuecomment-1285869182&data=05%7C01%7C%7C66c76f7c092c4178da9908dab2bba215%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638018816202584882%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sae%2FeInYPkqC37DLGutqy5j1bZHpIGxIsmlyvLb5HRA%3D&reserved=0, or unsubscribehttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAALP5EOG7ZYHJP7VYCZS4P3WEF2JBANCNFSM6AAAAAARKEWK6I&data=05%7C01%7C%7C66c76f7c092c4178da9908dab2bba215%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638018816202584882%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=S1m5mM8PYAQcr%2Fe5%2FG1d2zm0DqQbf%2BK%2BTo4%2B2b2ydIk%3D&reserved=0. You are receiving this because you authored the thread.Message ID: @.@.>>

[MatthewB05]

In fact it's not just the date format that's broken, the entire control is ignoring regional settings on windows - the day/month names are in English and the week starting dates are all out by one day. On Android these are both correct.

[FrankPohl]

You are right, it was shown at the expected position but in my example the month was given as 02 and 00 was shown for the month.

[MatthewB05]

I've had to revisit this problem but with more MAUI knowledge, I've come up with the following workaround (to go in e.g. App.xaml.cs). I'm not sure if the bug is in MAUI or in WinUI (I actually lean towards the latter) but someone, somewhere, seems to have forgotten the existence of the world beyond the borders of the United States.

I'm not saying this is the best solution, but seems low-impact and universal in the application, and certainly covers my own requirements.

#if WINDOWS
            // default datepicker ignorant of date format and first day of week
            var userLanguages = global::Windows.System.UserProfile.GlobalizationPreferences.Languages;
            var dateFormat = new global::Windows.Globalization.DateTimeFormatting.DateTimeFormatter("shortdate", userLanguages);
            DatePickerHandler.Mapper.AppendToMapping("FixDateFormat", (handler, view) =>
            {
                handler.PlatformView.FirstDayOfWeek = (global::Windows.Globalization.DayOfWeek)(int)
                    System.Globalization.CultureInfo.CurrentCulture.DateTimeFormat.FirstDayOfWeek;
                handler.PlatformView.DateFormat = dateFormat.Patterns.FirstOrDefault() ?? "shortdate";
            });
#endif

[MatthewB05]

Though even then the day/month names are wrong, but easier to live with than the Sunday where Monday should be, and back-to-front dates, especially for an internal app.

[pocki]

The weekdays and months also wrong (english in my case) even if you set the language handler.PlatformView.Language in @MatthewB05 workaround.

[Zhanglirong-Winnie]

Verified this issue with Visual Studio 17.7.0 Preview 1.0. Can repro on Windows platform with sample project. DatePickerError-main.zip Windows: Android:

[drossoft]

Any progress with this? DatePicker is essential in any multilingual application. The migration from Xamarin to MAUI is really frustrating.

[Brosten]

I'm also struggeling with date and timepickers on windows. Sizing and positioning is a joke...

How do I "vote" for this issue? By subscribing? Giving thumbs up on the original post or in some other way?

[AndreKraemer]

For those struggling with localized dates in .NET MAUI Windows Apps, here’s a solution to get a properly formatted DatePicker:

1. In your Platforms\Windows\Package.appxmanifest, make the following changes: change this:

  <Resources>
    <Resource Language="x-generate" />
  </Resources>

to this:

  <Resources>
    <Resource Language="x-generate" />
    <Resource Language="en-US"/>
        <!-- Make sure to add your desired Language Codes here. I took de-DE as an example -->  
    <Resource Language="de-DE"/>	
  </Resources>

This ensures that your date picker uses the system’s default date format and has localized strings for months and days.

However, you might still encounter an issue with the first day of the week not being correct for your culture. To address this, modify the code in your MauiProgram.cs as follows (code taken from @MatthewB05's answer):

#if DEBUG
    		builder.Logging.AddDebug();
#endif

#if WINDOWS
      // use the correct first day of the week
      DatePickerHandler.Mapper.AppendToMapping("FixFirstDayOfWeek", (handler, view) =>
      {
        handler.PlatformView.FirstDayOfWeek = (Windows.Globalization.DayOfWeek)(int)
            System.Globalization.CultureInfo.CurrentCulture.DateTimeFormat.FirstDayOfWeek;
      });
#endif

      return builder.Build();

The result should be a DatePicker that adheres to your system’s settings and displays localized strings. Here’s a screenshot from my German system:

[jfversluis]

@AndreKraemer thanks for adding this! Is this the way to do it? Or is there anything we can add to .NET MAUI as well to make this a bit easier to work with?

[AndreKraemer]

This is a great question @jfversluis.

I've actually made an addition to the official documentation regarding localizing the datepicker, which you can find at this link.

The section I contributed outlines the process of adding culture codes to the Package.appxmanifest, which ensures localized texts and date formats. As WinUI3 necessitates the inclusion of all supported languages in the Package.appxmanifest (similar to how iOS apps require CFBundleLocalizations in info.plist), there might not be much we can add to .NET MAUI to simplify this further. We just have to hope that everybody reads the documentation 😁

Regarding the mapper for adjusting the first day of the week in the calendar to align with the users culture: While it could feasibly be integrated into .NET MAUI, there's a consideration to be made about consistency. If the first day of the week is changed without updating the calendar format (which needs to be done manually), it could lead to confusion among users.

There is a similar scenario with the TimePicker, as discussed in this GitHub issue. The issue revolves around the timepicker is alwys using the 12-hour format on windows, regardless of your regional settings. I dug a bit deeper and the reason is the default value for the TimePicker's format property being "t", which signifies the shorthand for the localized short time format. While this works seamlessly on Android and iOS, on Windows, "t" is disregarded, and the underlying code determines the format based on the presence of an uppercase H (like HH:mm).

To address this, I devised a small mapper to replace "t" with the actual short time string (such as hh:mm or HH:mm) from the system.

Now, here's where it gets interesting: While it might be tempting to incorporate this mapper directly into .NET MAUI, we must acknowledge that in a native WinUI3 app (without MAUI), the WinUI3 control itself doesn't respect the current locale and defaults to using the 12-hour format. Thus, there's a dilemma: Should the control behave differently in .NET MAUI and implicitly adopt the correct time format, or should it adhere to the user's expectations?

In both scenarios, integrating the mapper code into .NET MAUI might seem like the simpler option for most users. However, we need to be mindful that some individuals might find this confusing.

So, what's your perspective on this? Is there a general principle, such as ensuring that in MAUI, the control behaves akin to the native control if developers don't explicitly set any properties? Or should it align with user expectations?

[mijenner]

@AndreKraemer and others,

I tried to use the proposed workaround by adding languages to Package.appxmanifest, and it does work on starting an app. However if I, during runtime, change culture, it doesn't re-read the settings, or maybe I'm just doing it wrong? https://github.com/mijenner/MAUIappsFeatures

Kind regards, Michael