My schema properties keys are JSON Pointers that contain forward slashes / . This posed an issue early on when I needed to create a custom UISchema, but eventually I found the encode function from JSON Forms, and used that to encode the keys when creating the UI Schema.
I want to start adding asterisks to my custom renderers using the control.required, which, from what I’m understanding, it checks whether that field scope exists in the global required array.
The problem is, since I am doing encode on the UISchema due to my JSON paths containing pointers, the isRequired function doesn’t work properly since it doesn’t decode. So when it tries to check if the scope
Here is a sub-schema I use:
{
"/personal/email": {
"title": "Email with slash",
"description": "Email address With Slash",
"type": "string",
"format": "email"
},
}
When encoding, the scope on the uischema becomes #/properties/~1personal~1email, but the path in the global required is the original which isn’t encoded.
Is there any way around this until a fix for this is done?
Besides the fix in JSON Forms, the only way to fix it in your side is via custom renderers. In them you would calculate the errors to show with the patched variant.
However we can just merge your fix and release a new alpha, that’s likely more convenient for you.
@sdirix Btw, sort of on topic, is there a way to know in a custom layout whether the renderer that is rendered is required?
I’m asking because I have a custom layout to, among other things, show a header for each field rendered, and I need to put the asterisk in the header as well in case that field is required.
For now, I copied the isRequired function into my project and am using that, since that function isn’t available to import since it’s not being exported. But was wondering if there was a better way to do this. Also not sure exporting the isRequired is the best way forward to solve this, but if it is, let me know and I can create another PR.
Sadly there is no better way. We handle the isRequired analysis at binding time, which means that parent elements don’t have automatic access to them. Replicating the analysis in the parent is one approach to solving this and probably the cleanest one. The alternative would be to signal to the parent when a control is required, however that would make the analysis rendering dependent and could behave weirdly in edge cases.
