Lazy load JS modules

[stsrki]

closes #3150

Adds the lazy load support for JS modules. It should work better when running along with the async code.

[David-Moreira]

I don't have time to test this today. But this seems equivalent to the previous version? Even if you had the Lazy, it should be working the same? Am I missing smthg?

[stsrki]

I don't have time to test this today. But this seems equivalent to the previous version? Even if you had the Lazy, it should be working the same? Am I missing smthg?

It was a guess since I cannot reproduce it.

[stsrki]

I think my last comment where I check the button element is not null has fixed the issue. But I still think we should keep the Lazy loading changes. @David-Moreira Do you agree?

[David-Moreira]

I think it's okay to deploy it with either of the ways. But Let me do some testing later today. Unless you want to go with a release right away.

[stsrki]

I will rather wait. If all is good then I will release it tomorrow.

[David-Moreira]

We've gone back to have race conditions on the js calls.
If you switch very quickly between pages you'll eventually get it. (I'm guessing it might be more noticeable on worst connections on server or slower processing devices on wasm)

I don't think it's anything to do with the modules, but I believe this might be because we ended up fixing Dispose? Since it's now calling dispose correctly... now these race conditions are back.
To solve this:

• Maybe null checking every dotnet object reference in js?
• Delay dotnet object reference disposal by a few ms?
• Is this such a low happening that we could swallow the exception?
• Any "Cancellable work" patterns (similar to async Cancel token) out there that we can do in js?
• Would not explicitly setting dotNetObjectRef = null; be helpful? Since the GC should eventually get rid of it anyway, null or not null. (At least under normal circumstances, if it thinks no component has a hold of it.)

If you figure it out in the meantime great! Otherwise I can help you on the weekend.

[stsrki]

I tried to fast switch between pages but maybe my PC is faster.

---

• Maybe null checking every dotnet object reference in js? Yes, we can do that.
• Delay dotnet object reference disposal by a few ms? NO, I don't want this to slow down the app in any way if possible.
• Is this such a low happening that we could swallow the exception? What do you mean? try catch block?
• Any "Cancellable work" patterns (similar to async Cancel token) out there that we can do in js? Really don't know 🤔
• Would not explicitly setting dotNetObjectRef = null; be helpful? Since the GC should eventually get rid of it anyway, null or not null. (At least under normal circumstances, if it thinks no component has a hold of it.) We can set them to null if we didn't already.

[David-Moreira]

Some pages are easier. Try between table / forms pages. I tried with blazor.server so there shouldn't be much diff in processing between our pcs? It's not like my pc is a stone! 😅

[stsrki]

I'm still unable to reproduce. Clicking as fast as I can between pages. Even enabled Slow 3G.

[David-Moreira]

• Maybe null checking every dotnet object reference in js? Yes, we can do that.
  R: OK.
  Delay dotnet object reference disposal by a few ms? NO, I don't want this to slow down the app in any way if possible.
  Is this such a low happening that we could swallow the exception? What do you mean? try catch block?
  R: YEA
  Any "Cancellable work" patterns (similar to async Cancel token) out there that we can do in js? Really don't know 🤔
  R: haha
  Would not explicitly setting dotNetObjectRef = null; be helpful? Since the GC should eventually get rid of it anyway, null or not null. (At least under normal circumstances, if it thinks no component has a hold of it.) We can set them to null if we didn't already.
  R: Oh, I meant removng the dotNetObjectRef = null instead.

[stsrki]

@David-Moreira So what did we agree on in the end. This is OK to merge?