Is it possible to opt out of dot notation or escape dot for field names?

[crutchcorn]

Discussed in #532

^{Originally posted by chrisirhc December 27, 2023}
I'm considering migrating a project this library but there are field names containing dots x.y but these aren't to indicate nested fields.
Is there a way to opt-out of the path behavior? I do see the value in this feature but could there be a capability to escape the field names perhaps (e.g. x\.y\.z)?

I'm happy to contribute this feature but want to understand if any interest.

[chrisirhc]

After investigating the implementation, how open would you be to accepting a path array (tuple, in TypeScript terms) as an argument?

Using a string to represent these escaped field names is not "full-proof" since there'll always be something that may need some form of escaping or a character that we pick that we need to treat specially. This increases complexity on the TypeScript utility functions significantly.

I see that we're already converting these some.path expressions to an array like ['some', 'path']. Would you be open to accepting the array itself? That way we leave it to the user to pass the path which can contain any form of special characters that the TypeScript utilities as well as the makePathArray functions don't need to handle.

Here are some examples of proposals and what their field name could look like:

Object	Today	Quoting the expression	Escaping the dot	Using a path array (tuple)
{'field': ''}	'field'
{'.dot': ''}	❌	'[".dot"]'	'\\.dot'	['.dot']
{'.dot"quote': ''}	❌	❌	'\\.dot"quote'	['.dot"quote']

I do like today's fieldApi name type-checking in that one field can only be specified in one way. I don't like to introduce multiple ways of specifying a field (e.g. accepting 'field', '["field"], "['field']"). But... here we are.

[crutchcorn]

@chrisirhc let me run this idea past the other maintainers. Admittedly, I'm kinda against the idea, but I seemingly can't rationalize my thoughts other than "Oh god the types as-is are so complex I don't want to remove or touch them" but the more I think about it the more I realize this API would probably fix the types, not make them more complex.

Even so, I'm only human and the idea of throwing away a huge amount of work gives me a physical migraine haha.

[chrisirhc]

No worries, sounds good. I think I understand where you're coming from.
I've gone a few times back and forth on this idea myself. I also don't like the idea of throwing away work. Will wait to hear back. 👍

[crutchcorn]

After talking with @fulopkovacs, I don't think we're going to move forward with this API. Here's why:

1. The lift of engineering would to refactor would be really heavy
2. name doesn't resonate well with us when it's an array. We would typically rather the property then be called accessor, but that introduces property name ambiguity (IE: Is this meant to be public or not?)
3. Like FS paths and URLs, there have to be some established patterns for our tooling to gather a basis on. While there's some arguments to be made to fix this; what about unicode characters or beyond? Should emoji be supported? (kinda joking, but there are semi-serious implications to this idea)
4. We're struggling to think of many edgecases where " or \\ would be needed to support in an object's key name.

That said, we deeply appreciate your help figuring out our path and we may revisit this sometime in the future (say 2.0) if enough community feedback indicates that this is something they're wanting.

Moreover, we suggest that instead of backticks and hard-to-read name properties, you might instead transform the object key-by-key (or with a utility to rename _ to . maybe) to solve this problem.

Thanks (and sorry) once again 😄