0

I'm building out a component that accepts an input of dot notation. I want to validate the input and when I stopped to think about "what is valid dot notation" I figured this would be a simple way of doing it, but it almost seems too simple so now I'm wondering if I'm missing something:

function isValidDotNotation(content: string) {
  try {
    content.split(".")
    return true
  } catch (exception) {
    return false
  }
}

So:

  • dot notation is a way of specifying a namespace within a json data structure then it seems like our main concern is validating keys
  • JSON requires strings for keys
  • the split static method hangs off of String so you'd only be able to fire it on a string
  • Specifying an array index in dot notation just makes the square brackets part of a string (e.g. in example.widgets[0].name, widgets[0] is still a valid string when .split()
  • A single level dot notation string can still be split into a single array value (e.g. "test".split(".") still works)

So when we fire split, as long as we don't throw an exception the the string given should be a valid dot notation. It may or may not lead you to anything within the json structure, but as far as a valid value it should be good, right?

Am I missing any nuance here? I've seen examples of people looping through the structure and stuff, but it seems like overkill to validate unless I'm missing something.

Chris Schmitz
  • 20,160
  • 30
  • 81
  • 137

2 Answers2

2

string.split will never throw an exception when passed a string. Therefore, via these rules, any string is valid dot notation. In that case you only need to verify whether something is a string, which you can do like so:

typeof content === 'string'
chris coerdes
  • 221
  • 2
  • 5
  • 1
    Worth noting: OP shows a type annotation, if the code is supposed to be TypeScript, then even the `typeof` might be unnecessary, if the compiler option `strictNullChecks` (or `strict` which bundles together this with other options) is enabled. It makes `null` and `undefined` not assignable to any of the existing types. Thus `isValidDotNotation(null)` would throw a compilation error. The compiler option is only needed for `null` and `undefined` since `isValidDotNotation(42)` would already produce a compilation error, as it's a different type. – VLAZ May 11 '22 at 14:51
1

You're missing something. Your original code won't work with the input:

content1 = "example.widgets[.0].name"
content2 = "example.widgets[0].name."
Ronen
  • 195
  • 7
  • Define "won't work"… It'll `return true` alright… – deceze May 11 '22 at 14:29
  • Ahhhh, this is a good catch @Ronen. The `widgets[.0]` would be a valid string but is def invalid dot notation – Chris Schmitz May 11 '22 at 14:52
  • @ChrisSchmitz Are you sure it's invalid? Here is a matching json: `{ "example": { "widgets[": { "0]": { "name": "hello" } } } }` and [a demo](https://jsbin.com/jebucobali/1/edit?js,console) – VLAZ May 11 '22 at 15:02
  • :facepalm: yeah that's a good point. Man, yeah maybe your comment on the other answer is right, the type check at the compiler level is good enough, like I don't even need a validation function as long as I have a string value. the dot notation may not point to anything in the json object (like it's invalid relative to the json object), but as far as "something that could be considered dot notation" as long as it's a string it passes – Chris Schmitz May 11 '22 at 15:06
  • @ChrisSchmitz Technically might be true. You mentioned in the question that any string can be a valid key, which is true. Even `"foo."`, `".foo"` or `"....."` could work since since a key can be an empty string. Whether that's something you want to accept as valid is a different matter, however. It's equally possible to consider such keys invalid. And probably the vast majority of the time they would not show up anyway. There is also another possibility for "invalid" - built-ins like `"constructor"` or `"prototype"` which might not be acceptable. E.g. `"hasOwnProperty.a.b"` would likely error. – VLAZ May 11 '22 at 15:12