fix: [maps.Flatten] better handle keys with delimiter character via escape sequence

[crandles]

If a map key contains the given delimiter, it is not possible to unflatten it back to its original state.

To fix, escape the keys for the delimiter and an escape sequence character. Additionally, extend unflatten to handle the equivalent un-escape.

[knadh]

Thanks for the PR. But if . is a delimiter, it shouldn't be used as a part of a key to begin with.

In these two cases, say, a, b, c and a, b.c, in the API when one does ko.String("a.b.c"), how does one distinguish the hierarchy?

[crandles]

I'll add a test for that to verify (I haven't used those types much).

I think the goal would be to have that accessible via the escaped character sequence: a.b.c would target a,b,c, a.b~1c would target a, b.c

But if . is a delimiter, it shouldn't be used as a part of a key to begin with.

I'm working with user-supplied content which may have a wide array of input -- it isn't easy to tell what delimiter would be safe to use, which is why I thought to escape the keys.

If this isn't something you're interested in, I can close this.

[crandles]

Looks like my test is failing, so I'll move this back to draft. Let me know if this is something that could merge, else I'll just keep this as a fork.

---

as a note, the escape sequence is similar to how JSON Pointers work with special characters:

The characters ~ and / have special meanings in JSON Pointer, so if a key in a JSON object has these characters, ~ needs to be escaped as ~0, and / needs to be escaped as ~1.

Except instead of /, we care about delim

[knadh]

I think this is a niche usecase, escaping delimiter in config keys in this manner. I don’t think this is ideal for the core.