1

i wonder how can i do to check undefined properties in the following case?

let foo = {
    bar: {
        f: {
            b: 90
        }
    }
}

I think that something

foo.bar && foo.bar.f && foo.bar.f.b ? foo.bar.f.b : null

maybe work but i believe exists a better manner.

Joaquin Noé
  • 25
  • 8
  • So if I understand correct, your solution might work but you are not sure, and you are looking for better way. Correct? – Rajesh Oct 26 '17 at 16:24
  • It was marked as duplicate, but just in case someone arrives here, what I would use in this case is: `((foo.bar||{}).f||{}).b||null` – Piyin Oct 26 '17 at 16:32
  • @Piyin That is too much processing. Simple way can be `try { return foo.bar.f.b } catch(ex) { return null }`. This keeps code simple and readable – Rajesh Oct 26 '17 at 16:34
  • @Rajesh At first I thought you were right, but I made a performance test and it looks like `try...catch` only wins after getting more than nine levels of nesting: http://jsfiddle.net/0o3ag3t6/1/ I could be wrong, though. So if you find any flaws, please let me know – Piyin Oct 26 '17 at 18:25
  • @Piyin please use jsperf to check performance. Using 1 or 2 cases will not give you actuate results. I'm on my mobile, so I'll share a link in a day or two – Rajesh Oct 27 '17 at 04:46
  • @Rajesh I tried, but it wasn't working. I found this one, though, and it still shows the `try...catch` approach is worse: https://jsbench.me/wij99za870/1 – Piyin Oct 27 '17 at 14:14
  • @Piyin Though expressions will be faster in most cases, if you have deeply nested array, try catch can win: https://jsperf.com/try-catch-vs-chained-expression/ – Rajesh Oct 28 '17 at 03:07
  • @Rajesh According to your link, `try...catch` is slower in all cases. Although, according to my first test, it is indeed faster to `try...catch` after the 9th level. So I'll just remember the nine in my head in case I ever have to do that. Even though I wouldn't actually use short circuit for more than four or five levels, it becomes a mess after that – Piyin Oct 28 '17 at 14:18
  • @Piyin i would stop using expression from 3 lever. Choosing either one Will save you 1-2 ms, which is not worth the time it takes to read/write/understand it. That's why i prefer readability over these hacks. But this is my opinion. You should choose which every you feel right and is easy to read. – Rajesh Oct 28 '17 at 15:47
  • @Rajesh Still, it wasn't "too much processing" after all. At least not for the case Joaquin Noé was asking about – Piyin Oct 30 '17 at 14:31

1 Answers1

2

You can use a module called lodash. It's actually amazing and simplifies a lot of work. In this case, for example, you'd use _.get(foo, 'bar.f.b', 'default');

If the property exists, it will return it, otherwise, it returns 'default'. You can change that third parameter to whatever you'd like, such as null.

Ted
  • 580
  • 4
  • 22
  • Great hint. However running loadash must be internally expensive code, I believe. – iquellis Oct 26 '17 at 16:25
  • You should ask OP if is fine with using a library or not. – Rajesh Oct 26 '17 at 16:26
  • 1
    @iquellis lodash has a standard performance benchmark and benefit of using a library, is you beat the browser compatibility issues – Rajesh Oct 26 '17 at 16:27
  • 1
    @iquellis , from my personal Dev experience, which is JS for years now, unless you are dealing with some sort of graphical engine, or millions of data (which you should avoid and segregate), it won't be expensive. Browsers and CPUs are fast enough these days to not bother about it. – Ted Oct 26 '17 at 16:28
  • @Rajesh I could ask, but in the web world nowadays, everything uses external libraries. It's the whole strength of JS, the community based libraries that make your code easier to do. – Ted Oct 26 '17 at 16:29
  • 1
    @Ted That may be true, but considering the fact that no libraries are tagged and neither OP has shared interest in solutions for library, it can attract unwanted comments/votes. Nonetheless, my comment was a suggestion. Hope it helps. :-) – Rajesh Oct 26 '17 at 16:32