🔎 Overview

This PR extends the current path syntax to allow for bracket notation.
The reasoning is to allow object keys that contains a "." (dot).
The current syntax only allow bracket notation for root level keys, but not for nested keys.

🤓 Code snippets/examples (if applicable)

const initialValues = {
 'links.twitter': '...',
 'userIds': {
 '123.456': '...'
 }
}
const { defineField } = useForm({initialValues});
defineField('[links.twitter]'); // works
defineField('userIds[123.456]'); // doesn't work

✔ Issues affected

Possibly closes #4762 ?

Discussion

From my perspective, there are 2 possible solutions for this issue (both are not mutually exclusive)

Solution 1 - Extend path syntax

• Advantage:

  • easier implementation, does not require too many code changes.

• Disadvantage:

  • requires manual path parsing, might fail for edge cases (I'm including a very basic implementation!)
  • might require external library for proper path parsing?

• Example implementation (first commit in this PR): 7d3308f

Solution 2 - Accept array as path

• Advantage:

  • shift the responsibility of providing the correct path to the user, no complex path parsing logic required
  • used for example in the Angular Forms module, in the FormControl get method

• Disadvantage:

  • Requires code changes in more place
  • Fixes for TS errors
  • Needs serializing logic for path arrays to store path state

• Implementation: This PR (both solutions are present)

From my understading, this PR does not contain any breaking changes, so could be released as a minor update.
At least, all tests are passing, but maybe I'm missing something?.

Notes

I would be very interested on this solution since I do work with forms that have keys containing dots and they don't work with the current version of this library - not without a patch at least. But at the same time, I understand that this proposed feature has not been fully discussed, so there is a chance that this PR will not be accepted, which would be sad, since I believe this functionality should in one form or another be added. For this reason, I'm creating this PR as a draft.

I'm happy to further discuss the issue and to update the PR if spec modifications are needed.