Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Blazor server-side and static fields #1721
I am wondering about behavior of static fields in server-side blazor. Since the server is a single process, static field values are shared between all sessions. There are no app-domains in .net core to isolate values between sessions. This behavior is inconsistent with client-side blazor, where static fields behave like one might assume, one value per client application/session.
Lot of simple cases where static fields might be used can be solved with DI, but there are a lot of world cases, and a lot of existing code/libraries, where shared value between sessions might be a problem.
I mainly worry about the inconsistency between client and server side blazor. Since a lot of articles I read tend to say, that if a code is designed "correctly", it should work on both, client and server side blazor almost transparently. Such inconsistency of a core language feature as are static fields might be a problem for some.
Has there been any thought about this issue?
I'd like to add to this by saying that I have experienced major such issues myself to a point where I had to give up on using a certain library because it was incompatible with server-side Blazor; while I'm not sure this can/should even be mitigated by Blazor itself, I think it's a good idea to discus the idea because it is a real-world scenario. The main issue is with client-side C# libraries for me because they were designed with app frameworks in mind and not server programs, so state information is usually stored globally. With the advent of WebAssembly, and Blazor's ability to transform .NET assemblies to target said platform, would it be feasible to allow certain libraries and user code to run in the browser? Could it also somehow be possible to add pseudo-
You're right that developers need to be careful about use of
Overall, I'm not aware there's anything specific we either could or should do to change this. If you have specific suggestions please let us know, but in all likelihood I think it's just something that developers need to know about (exactly like with
That's definitely not something we'd do by default, because (1) it would be very expensive in terms of server resources, and (2) it would break common patterns that you do want, such as using
I'll mark this closed because no specific action is planned. But please feel free to continue discussing or providing a specific suggestion if you have one.