feat: add basic bracket notation support, accept path array #5068
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🔎 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)
✔ 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:
Disadvantage:
Example implementation (first commit in this PR): 7d3308f
Solution 2 - Accept array as path
Advantage:
Disadvantage:
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.