Intended behaviour coherence of init only properties between C# code and DotVVM front-end

🌎 Discussion in English
1

Hello,

Title sounds a bit abstract so I’ll try to illustrate:

I have this property in a nested ViewModel (InboundSVM):
image
image

It has the value 0 by default.
Now, in markup I try to increment it by staticCommand and I receive the expected C# warning typical for invalid init-only assignment:

image
image1292×65 11.5 KB

After I make sure the staticCommand is triggered in the UI, I make a PostBack and check the client-side payload of the request:
image

Then, in the debug mode of VS 2022 I find that the back-end value of the property is indeed changed:

image
image760×289 16.5 KB

I’ve intended this post as a curiosity to share.

2

I understand it’s a bit weird, but I think we should keep this behavior as is. We should make sure we don’t allow assigning to init only properties on the server (i.e. in a command binding), as that would allow you to mutate an instance you assumed is immutable. Changing the value client-side does not really allow you to change the .NET object, as it currently does not exist. During deserialization, a new object is initialized anyway.

1 Like
3

Yes, the way of thinking regarding these init-only props is that they are init-only ooonly at the VM code level. Keeping in my mind that deserialization occurs and alien values from another universe come and populate properties from planet C# makes sense / helps.

4

Heh, turns out we allow it in command as well, that’s definitely a bad thing which should be fixed: Disallow asigning to init-only properties in bindings by exyi · Pull Request #1909 · riganti/dotvvm · GitHub

1 Like