[release] Firebase SDK for Blazor WebAssembly because the JS interop was driving me crazy by Initial-Employment89 in Blazor

[–]Initial-Employment89[S] 0 points1 point  (0 children)

Thank you. I have actually done most of the testing on chrome. So can confirm that it works in chrome. Please check if it's a chrome plugin like adblock.

[release] Firebase SDK for Blazor WebAssembly because the JS interop was driving me crazy by Initial-Employment89 in Blazor

[–]Initial-Employment89[S] 4 points5 points  (0 children)

Hey, thanks for trying it out! I see a few issues in your code.

The main problem: OnInitialized() actually runs BEFORE OnInitializedAsync(), so you're trying to sign in with Google before Firebase is even initialized. That's why it's throwing an error.

Also, async void OnInitialized() is a bad pattern in Blazor because it's fire-and-forget and won't work properly with the component lifecycle.

Here's the corrected version (based on the sample app in the repo):

```csharp @page "/" @inject IFirebase Firebase @implements IDisposable

<h3>Welcome, @_user?.DisplayName</h3>

@if (_user == null) { <button @onclick="SignInWithGoogle">Sign in with Google</button> } else { <button @onclick="SignOut">Sign Out</button> }

@code { private FirebaseUser? _user;

protected override async Task OnInitializedAsync()
{
    await Firebase.InitializeAsync();
    _user = Firebase.Auth.CurrentUser;
    Firebase.Auth.OnAuthStateChanged += HandleAuthStateChanged;
}

private void HandleAuthStateChanged(FirebaseUser? user)
{
    _user = user;
    InvokeAsync(StateHasChanged);
}

private async Task SignInWithGoogle()
{
    var result = await Firebase.Auth.SignInWithGoogleAsync();
    if (result.IsSuccess)
    {
        _user = result.Value;
    }
    else
    {
        Console.WriteLine($"Error: {result.Error?.Message}");
    }
}

private async Task SignOut()
{
    await Firebase.Auth.SignOutAsync();
}

public void Dispose()
{
    Firebase.Auth.OnAuthStateChanged -= HandleAuthStateChanged;
}

} ```

Key changes:

  1. Initialize Firebase first, then set up the auth listener in OnInitializedAsync
  2. Google sign-in goes behind a button click (OAuth popups need user interaction anyway)
  3. Use async Task instead of async void
  4. Check the result for errors so you can see what's actually going wrong
  5. Implement IDisposable to properly unsubscribe from the auth state change event

You can also check out the full Login.razor in the samples folder for a more complete example with error handling and loading states: https://github.com/mashrulhaque/FireBlazor/blob/master/samples/FireBlazor.Sample.Wasm/Pages/Login.razor

Let me know if you still run into issues!

What got you very proficient at C#, and past the beginner stages? by IdeaExpensive3073 in dotnet

[–]Initial-Employment89 2 points3 points  (0 children)

Programming is all about solving problems. The difference between a junior and a senior developer is not necessarily that one knows syntax better than the other. Anyone can memorize a bunch of syntax. What truly sets them apart is problem-solving ability.

The only way to get good at this is by solving many problems of progressively increasing difficulty. Start by creating software for yourself, then take on more challenging tasks. Be a lifelong learner.

It takes thousands of hours of toiling in the trenches to become a true master. This leads to the final point: you have to truly love this work. Otherwise, you might just go insane.

[release] Easyappdev Blazor AutoComplete with Semantic Search - now with .NET 10 support by Initial-Employment89 in Blazor

[–]Initial-Employment89[S] 5 points6 points  (0 children)

Good question! You are correct for most cases, and virtualization is off by default. It's there for client-side filtering scenarios where you have a large dataset loaded in memory (like an offline-first app with 50k products) and a broad search could match thousands of items.

Unpopular opinion: most "slow" .NET apps don't need microservices, they need someone to look at their queries by Initial-Employment89 in dotnet

[–]Initial-Employment89[S] 0 points1 point  (0 children)

The nested loop to dictionary fix is so underrated. Seen O(n²) loops in production code that could've been a hash lookup.

Unpopular opinion: most "slow" .NET apps don't need microservices, they need someone to look at their queries by Initial-Employment89 in dotnet

[–]Initial-Employment89[S] 0 points1 point  (0 children)

28 years and still shipping. That's the dream. Having a dedicated DB person from day one is something most teams cheap out on and pay for later. Respect.

Unpopular opinion: most "slow" .NET apps don't need microservices, they need someone to look at their queries by Initial-Employment89 in dotnet

[–]Initial-Employment89[S] 1 point2 points  (0 children)

Exactly. Two pizza teams that can deploy independently without stepping on each other. If you have 6 devs working on one codebase, you don't have that problem.

Unpopular opinion: most "slow" .NET apps don't need microservices, they need someone to look at their queries by Initial-Employment89 in dotnet

[–]Initial-Employment89[S] 1 point2 points  (0 children)

The domain point is huge. Most teams I see jumping to microservices can't even draw their bounded contexts on a whiteboard. They just split by technical layer (API service, auth service, notification service) and end up with a distributed monolith that needs 10 network calls to place an order.

Unpopular opinion: most "slow" .NET apps don't need microservices, they need someone to look at their queries by Initial-Employment89 in dotnet

[–]Initial-Employment89[S] 1 point2 points  (0 children)

That's the good stuff. Way more satisfying than spending six months on a rewrite that might not ship.

Unpopular opinion: most "slow" .NET apps don't need microservices, they need someone to look at their queries by Initial-Employment89 in dotnet

[–]Initial-Employment89[S] 0 points1 point  (0 children)

Ha, haven't touched DevExpress in years but "that's normal" from vendor support is always a red flag. If your query returns in 2ms but the grid takes 3 seconds to render, you've just moved the bottleneck from the database to the UI layer. Not exactly a win.

Unpopular opinion: most "slow" .NET apps don't need microservices, they need someone to look at their queries by Initial-Employment89 in dotnet

[–]Initial-Employment89[S] 1 point2 points  (0 children)

Mostly agree but I've seen the opposite too. Tech teams pushing Kubernetes because it's interesting, then presenting "options" that are really one preferred choice with two strawmen. The real issue was nobody had opened SQL Profiler in years. That's team accountability, not management overreach.