what’s the VVM convertion?
for example:
<asp:HiddenField ID=“_maxHiddenField” ClientIDMode=“Static” />
Didn’t find anything in the Cheat Sheet…
Maybe
[Bind(Direction.ServerToClient)]
public string SomeValue { get; set; }
<input type="hidden" value={value: SomeValue} />
But I don’t see the utility of the input hidden since you can use the value from the view model
1 Like
yes, that’s a solution / work around. I would be nice though if it is in the cheat sheet. There is also the part where there is no counterpart for the . So it would be useful to mention here that there is NO dotvvm control and the solution might be your suggestion.
I’d say it is unconventional to use hidden fields in DotVVM, we normally keep data in the view model and read that in a command or staticCommand.
However if you want to submit a form, @wolfstudiodev’s answer is the correct way. I’d not consider using HTML a workaround 
We only try to provide controls when it’s needed, particularly when you need backwards value binding or some events.
Following only from @exyi’s first paragraph,
As I am also dealing with migrating WebForms markup, I also asked this myself.
What I’ve understood is that while in WebForms the sole purpose of having HiddenField was for persisting values through multiple server<->client trips, a value not to be seen by the user in the browser (not shown in the page), the same has to be achieved through MVVM.
While WebForms persisted through the page’s ViewState, I’ve learned that DotVVM persists state instead through the properties of the view model which by themselves are not shown in the page to the user. So we’ve settled for simply:
As this is equivalent to having it decorated like this:
[Bind(Direction.Both)]
public string SomeValue { get; set; }
Where direction “Both” ensures the persistence to be as expected from the behaviour of the HiddenField in WebForms.
Also maybe helpful for migrating some use scenarios of HiddeField controls,
[Protect(ProtectMode.SignData)] and [Protect(ProtectMode.EncryptData)] … see: Viewmodel protection | DotVVM Documentation
To finalize this topic I would still like to read a final, official convertion (maybe similar to the ) for the HiddenField from the DotVVM team / tomasherceg…
1 Like
Also it would be very useful to be considered by the online convertion tool.
See Advancing the “ASPX to DotVVM Converter” online migration tool
In 99% of cases, the hidden fields are not needed in DotVVM. The only use of them is when some JS library relies on them or when you need to use <form method=post/get> for some compatibility reasons with older pages.
Normally, everything exposed as public properties in the ViewModel is transferred between the client and the server, so if you make a postback, you find all values there - you do not need to look in the hidden fields.
If you need JavaScript code to access values from the viewmodel, you can use dotvvm.state or ko.dataFor/dataFor(element) to retrieve the viewmodel or its part related to the particular HTML element.
That’s why the converter does not do anything about hidden fields. I don’t want to have them removed because it may be sensible to keep them in some cases.
I will extend at least the cheat-sheet with the guidance of hidden fields.