Is there a way to disable the nested field name feature in react final form?

Question

Please see react final form's docs here

I'm working on a form which obviously is powered by react final form. In the form component, I'm fetching data from an API server and the response body includes something like the following:

{
  "configs": {
    "name": "abc",
    "display.name": "Abc",
    "value": 12,
    "read.only": true
  }
}

As we can see that there are four different key/value pairs in the configs . react final form can display values like name and value just fine but not values like display.name and read.only since they have a dot -> . in their key.

I know I can change these dots ( . ) with something like underscores and it will work. But the problem is that our backend devs are saying that using dots ( . ) to separate key names is very common in the backend so replacing dots with other separators won't be an option.

I'm currently replacing these separators with underscores in the frontend but that logic is everywhere and I think there should a better way to solve this. Thanks!

Answer 1

I think the answer is that Final Form just doesn't support keys with dots. Final Form needs some way to know when to go a level deeper into the form values object.

The only solution I could imagine would be to somehow tell Final Form to use another character (similar to how you can choose a different "divider" character when doing search-and-replace in VIM) as the "dot". So you could refer to your display name as <Field name="configs/display.name" delimiter="/"/> , but this feels like a pretty extreme edge case.

Longer term, I'd like to allow providing a type-safe get/set lens for each field, which would also solve this problem.

Wish I had better news for you... 😢

Answer 2

Since you are locked with both a rigid backend naming and Final Form dotkey nested notation, unless you can change one of these two parameters I guess replacing dots with underscore is still the easiest solution. This is really not about coding itself, as there is basically 3 cases :

• Getting rid of Final Form and finding a new one, this could be costy especially if you have multiple devs working on this project. The cost of learning a new syntax, added to the complexity of handling new edge case is not worth it IMO.
• Writing a custom view from your backend. You could ask your backend dev to develop a custom viewset for forms so they can keep their dot notation internally. This is usually a bad idea since it could easily create a technical debt, with a side of the dev team not knowing why a particular method exists.
• The best is still what you did. Since frontend requires a special response format, it is frontend concern to adapt to what the backend sends, hence creating a custom middleware function that you apply to every incoming responses such as :

const JSONMiddleware = input => ( 
  Object.entries(input).reduce((ac, cv) => {
    const newKey = cv[0].replace('.', '_')
    ac[newKey] = cv[1]

    return ac
  }, {})
)

This is probably not optimal in terms of user experience but it is easier to maintain since the problem and its solution are in the same scope of development.