https://avo.cool logo
Join Discord
Powered by
From my brief testing here, adding `required: true...
# avo-2
s
From my brief testing here, adding 
required: true
to a field changes the UI, but doesn't truly make the field required (in the HTML sense or the server-side validation sense). That true in others experiences?
l
Yes. That is correct. The 
required
option is only a cosmetic one. It's mentioned in the docs too. https://docs.avohq.io/2.0/field-options.html#required
we have an issue open to try to automatically figure it out from the model validations. that would deprecate the 
required
option. or at least make it optional. https://github.com/avo-hq/avo/issues/972
s
I'm fine with auto-figuring it out (unless otherwise specified as 
required: true
or 
required: false
), but sometimes you want to require it in a form even if it's not required at the model level, so let's please not lose that. Especially since we have the block form of calculating required. Moreover, I really think we should require it at the HTML5 level (at the very least) recognizing that for things like Key Value, Trix, Tags, etc. 
require
different approaches (pun intended). This isn't sexy work, but I very much think it's worth it.
I'm currently working on a PR to make 
readonly
allow a callable -- and readonly does appear to change the markup in most places well. I'm just blocked on writing a decent test for it. After that, I'll see if I can use that pattern for 
required
.
l
I agree with what you mentioned here. 
required
to be auto-detectable but overridable from the option.
I haven't thought about adding HTML validation until now. Mostly because Rails provides very good validation messages
but I think it would be useful. at least for the "simple" fields
for the test, mark a field as readonly (or find one that's already 
readonly
) and you should be able to do a css query for the 
disabled
attribute
if you hit any snags, put up a PR and we could pair up 💪
s
Yep. I'm going to do this for 
readonly
4 Views
PreviousNext
Powered by