Add computed fields ?

[leplatrem]

Add computed fields ?

[n1k0]

onFieldChange=(name, value, data) => {

To be noted, we should allow intercepting any deeply nested updates here.

[OliverColeman]

@acouch I was having a similar issue (I think). The values of some fields on my form are constrained by others - eg can only add up to some maximum value. In Form.onChange I grab the formData and store it in some state. If I try modifying some of the values of the formData to satisfy the constraint before putting it into state then the other fields would always be one step behind. The solution for me was to do a deep clone of the formData property before mutating it. Potentially inefficient, but effective.

[acouch]

Anyone find a decent solution for this? If I intercept the state change similar to https://github.com/Kinto/formbuilder/blob/8ceae7585108c3fe8d0ed64882f9d856cf2ef9e7/formbuilder/components/EditableField.js#L43-L62 my slug field is always one character behind.

[lovato]

@OliverColeman I am having the VERY SAME issue you had. And your suggestion fixed my problem. Thanks man. "would always be one step behind".

[Natim]

I remember this was done in the formbuilder to compute the field id from the label.

See: https://github.com/Kinto/formbuilder/blob/8ceae7585108c3fe8d0ed64882f9d856cf2ef9e7/formbuilder/components/EditableField.js#L43-L62

[n1k0]

Do you guys have a dream API in mind for this here?

[Natim]

UISchema set to something like:

{
   "slug": {"populate_from": "title"},
}

Where slug and title are JSONSchema properties maybe?

populate_from could also be slugify_from

[leplatrem]

After discussion:

• We should keep this library as minimalist and focused as possible
• For the created date use-case, it is possible to use the onSubmit() function to alter the final object
• For the slug use-case, the idea would be to introduce a onFieldChange hook that can alter the field value (or other fields)

      <Form schema={schema}
            uiSchema={uiSchema}
            onFieldChange=(name, value, data) => {
               switch(name) {
                  case 'title':
                    return {...data, [name]: value, slug: slugify(value)};
                  default:
                    return {...data: [name]: value}
               }
            } />

[apkoponen]

Jdorns Json-editor uses the templates for this:

https://github.com/jdorn/json-editor#templates

[n1k0]

Hmm, nice though most often you're likely to want a little more than just templating... functions are probably better for advanced computations :)

[apkoponen]

Yup, templates do have their limitations.

[maartenth]

onFieldChange=(name, value, data) => {

Could I help with implementing this feature? I'm currently working on a project where this would be very welcome due to better integration possibilities with Redux reducers.

How do you see this in combination with the current onChange() function? Would all fields call onFieldChange instead, or both? And which one would come first?

[maartenth]

@n1k0 Bumping this question because you probably missed my comment above. :)

[n1k0]

@maartenth Form onChange should work as before, but reflect computed field values in formData.

As mentioned before, the trickiest part imo is to find a nice API for hooking into deeply nested fields. Using strings to identify these isn't an option in my world. All I can see atm is to introduce yet another new hooks prop which would be an object registering nested hook functions:

const schema = {
  type: "object",
  properties: {
    foo: {
      type: "object",
      properties: {
        bar: {type: "string"}
      }
    }
  }
} 

const hooks = {
  foo: {
    bar: (value) => value + "!"
  }
}

render(<Form schema={schema} hooks={hooks}/>)

We'll have to be careful with precedence here though. This should also work with array items as well.

Thoughts? /cc @leplatrem @olzraiti @frassinier and people interested

[maartenth]

Thank you for your reply and your thoughts. I will try to find a more elegant API.

[knilink]

How about

//SchemaField.js  
function getFieldComponent(schema, uiSchema, fields) {
   //....
   return (uiSchema["ui:enhancer"] || a=>a)(FieldComponent);
}

import propsMapper from "recompose/propsMapper";
//...
const uiSchema = {
  title: {
    'ui:enhancer': propsMapper(({value, onChange, ...rest})=>({
      onChange: value => onChange(slugify(value)),
      value: unslugify(value),
      ...rest
    }))
  }
};

For this case, I personally prefer simply

import propsMapper from "recompose/propsMapper";
import TextWidget from "react-jsonschema-form/TextWidget";

const uiSchema = {
  title: {
    'ui:widget': propsMapper(({value, onChange, ...rest})=>({
      onChange: value => onChange(slugify(value)),
      value: unslugify(value),
      ...rest
    }))(TextWidget)
  }
};

[n1k0]

It would feel odd to add data processing logic to uiSchema, which has always been intended to deal with presentation only.

Also, I'm still pretty much convinced that post-processing form data could (and should) be achieved in the form's onSubmit event handler.

[elisechant]

@n1k0 I would agree. I normalize payload before post. Or you might be able to use a controlled component to compute inline?

I feel like these solutions are pretty heavy on perf?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please leave a comment if this is still an issue for you. Thank you.