Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CultureSelector should call JS interop asynchronously #32365

Closed
hakenr opened this issue Apr 21, 2024 · 2 comments · Fixed by #32433
Closed

CultureSelector should call JS interop asynchronously #32365

hakenr opened this issue Apr 21, 2024 · 2 comments · Fixed by #32433
Assignees

Comments

@hakenr
Copy link
Contributor

hakenr commented Apr 21, 2024

Description

Although the first demo is "client-side only" (WASM), I believe the CultureSelector.razor versions in the article (definitely at least the BWA version) should use JS interop asynchronously. This means JavaScript should not be called from the set_Culture property setter, but from an asynchronous event handler, such as @bind-Culture:after or bind-Culture:set.

For consistency, all CultureSelector components should be refactored to remove any logic from set_Culture and instead utilize a separate event handler.

If you agree, I will prepare a PR for this.

cc @guardrex

Page URL

https://learn.microsoft.com/en-us/aspnet/core/blazor/globalization-localization?view=aspnetcore-8.0

Content source URL

https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/blazor/globalization-localization.md

Document ID

d6f07538-228e-9f96-680f-6c324caf11d6

Article author

@guardrex

Copy link
Contributor

😎 Welcome April! Summertime is almost here! 🌞

A green dinosaur 🦖 will be along shortly to assist. Stand-by ........

@guardrex
Copy link
Collaborator

guardrex commented Apr 21, 2024

Sure thing! 👍

Given that the new binding became available at 7.0, you'll need to retain the current approach for <7.0. Fortunately, these code examples are in the article's text. I think you'll just need to manage the versioning as you're dropping in the new code.

Side Note: There's an on-going internal discussion about the BWA approach here. You see that it basically extends the use of local storage from the standalone WASM (client-side only) approach. However, Hisham prefers dropping local storage on the client in a BWA in favor of hacking the loc cookie. I felt that the hacked-cookie approach is kind'a nasty 🤮 ... I'm referring to the JS that parses the cookie manually. However, Dan will have someone, Javier probably, look at the approaches and see which one will be the best. I don't think it has any bearing on what you plan to do here for this issue. I just mention it in passing as you work on the approaches.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants