Test for existence of nested JavaScript object key

Question 1

If I have a reference to an object:

var test = {};

that will potentially (but not immediately) have nested objects, something like:

{level1: {level2: {level3: "level3"}}};

What is the best way to check for the existence of property in deeply nested objects?

alert(test.level1); yields undefined, but alert(test.level1.level2.level3); fails.

I’m currently doing something like this:

if(test.level1 && test.level1.level2 && test.level1.level2.level3) {
 alert(test.level1.level2.level3);
}

but I was wondering if there’s a better way.

Question 2

you might want to check a tangentially related question that was asked recently stackoverflow.com/questions/2525943/…

Question 3

See also stackoverflow.com/questions/10918488/…

Question 4

A couple of propositions there : stackoverflow.com/a/18381564/1636522

Question 5

Your current approach has a potential issue if level3 property is a false, in that case, even if the property exist will retur nfalse have a look at this example please jsfiddle.net/maz9bLjx

Question 6

simply you can use try catch also

Question 7

You have to do it step by step if you don't want a TypeError because if one of the members is null or undefined, and you try to access a member, an exception will be thrown.

You can either simply catch the exception, or make a function to test the existence of multiple levels, something like this:

function checkNested(obj /*, level1, level2, ... levelN*/) {
 var args = Array.prototype.slice.call(arguments, 1);
 for (var i = 0; i < args.length; i++) {
 if (!obj || !obj.hasOwnProperty(args[i])) {
 return false;
 }
 obj = obj[args[i]];
 }
 return true;
}
var test = {level1:{level2:{level3:'level3'}} };
checkNested(test, 'level1', 'level2', 'level3'); // true
checkNested(test, 'level1', 'level2', 'foo'); // false

ES6 UPDATE:

Here is a shorter version of the original function, using ES6 features and recursion (it's also in proper tail call form):

function checkNested(obj, level, ...rest) {
 if (obj === undefined) return false
 if (rest.length == 0 && obj.hasOwnProperty(level)) return true
 return checkNested(obj[level], ...rest)
}

However, if you want to get the value of a nested property and not only check its existence, here is a simple one-line function:

function getNested(obj, ...args) {
 return args.reduce((obj, level) => obj && obj[level], obj)
}
const test = { level1:{ level2:{ level3:'level3'} } };
console.log(getNested(test, 'level1', 'level2', 'level3')); // 'level3'
console.log(getNested(test, 'level1', 'level2', 'level3', 'length')); // 6
console.log(getNested(test, 'level1', 'level2', 'foo')); // undefined
console.log(getNested(test, 'a', 'b')); // undefined

The above function allows you to get the value of nested properties, otherwise will return undefined.

UPDATE 2019年10月17日:

The optional chaining proposal reached Stage 3 on the ECMAScript committee process, this will allow you to safely access deeply nested properties, by using the token ?., the new optional chaining operator:

const value = obj?.level1?.level2?.level3

If any of the levels accessed is null or undefined the expression will resolve to undefined by itself.

The proposal also allows you to handle method calls safely:

obj?.level1?.method();

The above expression will produce undefined if obj, obj.level1, or obj.level1.method are null or undefined, otherwise it will call the function.

~~(削除) You can start playing with this feature with Babel using the optional chaining plugin. (削除ここまで)~~

Since Babel 7.8.0, ES2020 is supported by default

Check this example on the Babel REPL.

🎉🎉UPDATE: December 2019 🎉🎉

The optional chaining proposal finally reached Stage 4 in the December 2019 meeting of the TC39 committee. This means this feature will be part of the ECMAScript 2020 Standard.

Question 8

arguments is not actually an array. Array.prototype.slice.call(arguments) converts it to a formal array. Learn

Question 9

this'd be a lot more efficient to do var obj = arguments[0]; and start from var i = 1 instead of copying the arguments object

Question 10

I put together a version with try/catch for austerity sake, and no surprise - performance is awful (except in Safari for some reason). There are some answers below that are pretty performant, along with Claudiu's modification which is also significantly more performant than selected answer. See jsperf here jsperf.com/check-if-deep-property-exists-with-willnotthrow

Question 11

In ES6 the args variable declaration can be removed and and ...args can be used as the second argument for the checkNested method. developer.mozilla.org/en/docs/Web/JavaScript/Reference/…

Question 12

This is a very unmaintainable. If any property keys change (they will), all devs on the project would have to 'string search' the entire codebase. This isn't really a solution to the problem, as it introduces a much bigger problem

Question 13

Here is a pattern I picked up from Oliver Steele:

var level3 = (((test || {}).level1 || {}).level2 || {}).level3;
alert( level3 );

In fact that whole article is a discussion of how you can do this in javascript. He settles on using the above syntax (which isn't that hard to read once you get used to it) as an idiom.

Question 14

@wared I think it is interesting mostly for how concise it is. There is a detailed discussion of the performance characteristics in the linked post. Yes it always does all the tests, but it avoids creating temp vars, and you can alias {} to a var if you want to prevent the overhead of creating a new empty object each time. In 99% of cases I would not expect speed to matter, and in cases where it does there is no substitute for profiling.

Question 15

@MuhammadUmer No, the point of (test || {}) is that if test is undefined, then you're doing ({}.level1 || {}). Of course, {}.level1 is undefined, so that means you're doing {}.level2, and so on.

Question 16

@JoshuaTaylor: I think he means if test is not declared, there'll be a ReferenceError, but that's not a problem, because if it's not declared, there's a bug to be fixed, so the error is a good thing.

Question 17

you said "which isn't that hard to read once you get used to it". Well, these are signs you know already this is a mess. Then why suggest this solution? It is prone to typos and gives absolutely nothing to readability. Just look it! If i have to write an ugly line, it should asswell be readable; so i'm going to just stick with if(test.level1 && test.level1.level2 && test.level1.level2.level3)

Question 18

Unless I'm missing something, this won't work for boolean end-properties that might be false... sadly. Otherwise I love this idiom.

Question 19

Update

Looks like lodash has added _.get for all your nested property getting needs.

_.get(countries, 'greece.sparta.playwright')

https://lodash.com/docs#get

Previous answer

lodash users may enjoy lodash.contrib which has a couple methods that mitigate this problem.

getPath

Signature: _.getPath(obj:Object, ks:String|Array)

Gets the value at any depth in a nested object based on the path described by the keys given. Keys may be given as an array or as a dot-separated string. Returns undefined if the path cannot be reached.

var countries = {
 greece: {
 athens: {
 playwright: "Sophocles"
 }
 }
 }
};
_.getPath(countries, "greece.athens.playwright");
// => "Sophocles"
_.getPath(countries, "greece.sparta.playwright");
// => undefined
_.getPath(countries, ["greece", "athens", "playwright"]);
// => "Sophocles"
_.getPath(countries, ["greece", "sparta", "playwright"]);
// => undefined

Question 20

Lodash really needs a _.isPathDefined(obj, pathString) method.

Question 21

@MatthewPayne It'd be nice perhaps, but it really isn't necessary. You could do it yourself really easily function isPathDefined(object, path) { return typeof _.getPath(object, path) !== 'undefined'; }

Question 22

Lodash has this same functionality itself:

_.get(countries, 'greece.sparta.playwright', 'default'); // → 'default' _.has(countries, 'greece.spart.playwright') // → false

Question 23

even better would be _.result

Question 24

If you need to determine multiple different paths consider: var url = _.get(e, 'currentTarget.myurl', null) || _.get(e, 'currentTarget.attributes.myurl.nodeValue', null) || null

Question 25

I have done performance tests (thank you cdMinix for adding lodash) on some of the suggestions proposed to this question with the results listed below.

Disclaimer #1 Turning strings into references is unnecessary meta-programming and probably best avoided. Don't lose track of your references to begin with. Read more from this answer to a similar question.

Disclaimer #2 We are talking about millions of operations per millisecond here. It is very unlikely any of these would make much difference in most use cases. Choose whichever makes the most sense knowing the limitations of each. For me I would go with something like reduce out of convenience.

Object Wrap (by Oliver Steele) – 34 % – fastest

var r1 = (((test || {}).level1 || {}).level2 || {}).level3;
var r2 = (((test || {}).level1 || {}).level2 || {}).foo;

Original solution (suggested in question) – 45%

var r1 = test.level1 && test.level1.level2 && test.level1.level2.level3;
var r2 = test.level1 && test.level1.level2 && test.level1.level2.foo;

checkNested – 50%

function checkNested(obj) {
 for (var i = 1; i < arguments.length; i++) {
 if (!obj.hasOwnProperty(arguments[i])) {
 return false;
 }
 obj = obj[arguments[i]];
 }
 return true;
}

get_if_exist – 52%

function get_if_exist(str) {
 try { return eval(str) }
 catch(e) { return undefined }
}

validChain – 54%

function validChain( object, ...keys ) {
 return keys.reduce( ( a, b ) => ( a || { } )[ b ], object ) !== undefined;
}

objHasKeys – 63%

function objHasKeys(obj, keys) {
 var next = keys.shift();
 return obj[next] && (! keys.length || objHasKeys(obj[next], keys));
}

nestedPropertyExists – 69%

function nestedPropertyExists(obj, props) {
 var prop = props.shift();
 return prop === undefined ? true : obj.hasOwnProperty(prop) ? nestedPropertyExists(obj[prop], props) : false;
}

_.get – 72%

deeptest – 86%

function deeptest(target, s){
 s= s.split('.')
 var obj= target[s.shift()];
 while(obj && s.length) obj= obj[s.shift()];
 return obj;
}

sad clowns – 100% – slowest

var o = function(obj) { return obj || {} };
var r1 = o(o(o(o(test).level1).level2).level3);
var r2 = o(o(o(o(test).level1).level2).foo);

Question 26

it should be noted that the more % a test has - the SLOWER it is

Question 27

what about lodash _.get() ? how performant is it comparing to those answers?

Question 28

Each method of these is slower or faster than other ones depending on situation. If all keys are found then "Object Wrap" could be fastest, but if one of the keys is not found then "Native solution/Original solution" could be faster.

Question 29

@evilReiko Any method will be slower if no keys are found but in proportion to each other it's still pretty much the same. However, you are right – this is more of an intellectual exercise than anything else. We are talking about a million iterations per millisecond here. I see no use case where it would make much difference. Me personally I would go for reduce or try/catch out of convenience.

Question 30

How performant is it compared to try { test.level1.level2.level3 } catch (e) { // some logger e }

Question 31

You can read an object property at any depth, if you handle the name like a string: 't.level1.level2.level3'.

window.t={level1:{level2:{level3: 'level3'}}};
function deeptest(s){
 s= s.split('.')
 var obj= window[s.shift()];
 while(obj && s.length) obj= obj[s.shift()];
 return obj;
}
alert(deeptest('t.level1.level2.level3') || 'Undefined');

It returns undefined if any of the segments is undefined.

Question 32

Worth noting that this method is very performant, at least in Chrome, in some cases outperforming @Claudiu modified version of selected answer. See performance test here: jsperf.com/check-if-deep-property-exists-with-willnotthrow

Question 33

var a;
a = {
 b: {
 c: 'd'
 }
};
function isset (fn) {
 var value;
 try {
 value = fn();
 } catch (e) {
 value = undefined;
 } finally {
 return value !== undefined;
 }
};
// ES5
console.log(
 isset(function () { return a.b.c; }),
 isset(function () { return a.b.c.d.e.f; })
);

If you are coding in ES6 environment (or using 6to5) then you can take advantage of the arrow function syntax:

// ES6 using the arrow function
console.log(
 isset(() => a.b.c),
 isset(() => a.b.c.d.e.f)
);

Regarding the performance, there is no performance penalty for using try..catch block if the property is set. There is a performance impact if the property is unset.

Consider simply using _.has:

var object = { 'a': { 'b': { 'c': 3 } } };
_.has(object, 'a');
// → true
_.has(object, 'a.b.c');
// → true
_.has(object, ['a', 'b', 'c']);
// → true

Question 34

I think the try-catch approach is the best answer. There's a philosophical difference between querying an object for its type, and assuming the API exists and failing accordingly if it doesn't. The latter is more appropriate in loosely typed languages. See stackoverflow.com/a/408305/2419669. The try-catch approach is also far clearer than if (foo && foo.bar && foo.bar.baz && foo.bar.baz.qux) { ... }.

Question 35

You can also use tc39 optional chaining proposal together with babel 7 - tc39-proposal-optional-chaining

Code would look like this:

 const test = test?.level1?.level2?.level3;
 if (test) alert(test);

Question 36

Note that this syntax will almost certainly change, as some TC39 members have objections.

Question 37

Probably but this will be available in some form in time, and that's the only thing that matters .. It's one of the features I miss the most in JS.

Question 38

The syntax did not change and has full support in all major browser latest versions - developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/…

Question 39

Thanks, I was becoming disgusted with JavaScript. I don't know why I've never seen this syntax in anything until now.

Question 40

how about

try {
 alert(test.level1.level2.level3)
} catch(e) {
 ...whatever
}

Question 41

I don't think try/catch is a good way to test for existence of an object: try/catch is meant to handle exceptions, not normal conditions such as the test here. I think (typeof foo == "undefined") at each step is better -- and in general, there's probably some refactoring required if you're working with such deeply nested properties. Also, try/catch will cause a break in Firebug (and in any browser where break-on-error is turned on) if an exception is thrown.

Question 42

I vote on this, because browser will check the existence twice if you use other solutions. Lets say you want to call ´a.c.b = 2´. Browser has to check the existence before modifying the value (otherwise it would be a memory error caught by OS).

Question 43

The question still remain: witch one is faster for browsers to set up a try catch or call hasOwnProperty() n times?

Question 44

Why is this bad again? This looks cleanest to me.

Question 45

I would say: If you expect that the property exist than it is okay to wrap it into a try block. If it then doesn't exist it is an error. But if you're just lazy and put regular code into the catch block for the case that the property doesn't exist try/catch is misused. Here a if/else or something similar is required.

Question 46

This question is old. Today you can use Optional chaining (?.)

let value = test?.level1?.level2?.level3;

Source:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining

Question 47

This is not what is asked.

Question 48

caniuse.com/mdn-javascript_operators_optional_chaining

Question 49

ES6 answer, thoroughly tested :)

const propExists = (obj, path) => {
 return !!path.split('.').reduce((obj, prop) => {
 return obj && obj[prop] ? obj[prop] : undefined;
 }, obj)
}

→see Codepen with full test coverage

Question 50

I made your tests failed setting the value of the flat prop to 0. You must care about type coercion.

Question 51

@germain Does this work for you? (I explicitly compare === for the different falsys, and added test. If you have a better idea, let me know).

Question 52

I made your tests failed again setting the value of the flat prop to false. And then you might want to have a value in your object set to undefined (I know it's weird but is is JS). I made a positive false value set to 'Prop not Found':

const hasTruthyProp = prop => prop === 'Prop not found' ? false : true const path = obj => path => path.reduce((obj, prop) => { return obj && obj.hasOwnProperty(prop) ? obj[prop] : 'Prop not found' }, obj) const myFunc = compose(hasTruthyProp, path(obj))

Question 53

Can you fork my codepen (top-right, easy), correct & add tests, and send me the URL of yours? Thanks =)

Question 54

It's irresponsible to leave this unedited after three years. This easily fails on falsy values as @germain pointed out. If this was thoroughly tested, you have some buggy code.

Question 55

I tried a recursive approach:

function objHasKeys(obj, keys) {
 var next = keys.shift();
 return obj[next] && (! keys.length || objHasKeys(obj[next], keys));
}

The ! keys.length || kicks out of the recursion so it doesn't run the function with no keys left to test. Tests:

obj = {
 path: {
 to: {
 the: {
 goodKey: "hello"
 }
 }
 }
}
console.log(objHasKeys(obj, ['path', 'to', 'the', 'goodKey'])); // true
console.log(objHasKeys(obj, ['path', 'to', 'the', 'badKey'])); // undefined

I am using it to print a friendly html view of a bunch of objects with unknown key/values, e.g.:

var biosName = objHasKeys(myObj, 'MachineInfo:BiosInfo:Name'.split(':'))
 ? myObj.MachineInfo.BiosInfo.Name
 : 'unknown';

Question 56

I think the following script gives more readable representation.

declare a function:

var o = function(obj) { return obj || {};};

then use it like this:

if (o(o(o(o(test).level1).level2).level3)
{
}

I call it "sad clown technique" because it is using sign o(

EDIT:

here is a version for TypeScript

it gives type checks at compile time (as well as the intellisense if you use a tool like Visual Studio)

export function o<T>(someObject: T, defaultValue: T = {} as T) : T {
 if (typeof someObject === 'undefined' || someObject === null)
 return defaultValue;
 else
 return someObject;
}

the usage is the same:

o(o(o(o(test).level1).level2).level3

but this time intellisense works!

plus, you can set a default value:

o(o(o(o(o(test).level1).level2).level3, "none")

Question 57

°0o <°(())))><

Question 58

I like this one, because it is honest and throws an "undefined" in your face when you don't know your Object type. +1.

Question 59

As long as you keep the statement in parens you can also call it happy clown technique (o

Question 60

Thanks Sventies. I love your comment . It is quite nice angle to look from - such conditions are mostly used in "ifs" and always surrounded with external brackets. So, yes, it is mostly a happy clown indeed :)))

Question 61

You really need to be in love with parenthesis to go for this one...

Question 62

create a global function and use in whole project

try this

function isExist(arg){
 try{
 return arg();
 }catch(e){
 return false;
 }
}
let obj={a:5,b:{c:5}};
console.log(isExist(()=>obj.b.c))
console.log(isExist(()=>obj.b.foo))
console.log(isExist(()=>obj.test.foo))

if condition

if(isExist(()=>obj.test.foo)){
 ....
}

Question 63

This swallows any other error that may occur.

Question 64

I didn't see any example of someone using Proxies

So I came up with my own. The great thing about it is that you don't have to interpolate strings. You can actually return a chain-able ~~(削除) object (削除ここまで)~~ function and do some magical things with it. You can even call functions and get array indexes to check for deep objects

function resolve(target) {
 var noop = () => {} // We us a noop function so we can call methods also
 return new Proxy(noop, {
 get(noop, key) {
 // return end result if key is _result
 return key === '_result' 
 ? target 
 : resolve( // resolve with target value or undefined
 target === undefined ? undefined : target[key]
 )
 },
 // if we want to test a function then we can do so alos thanks to using noop
 // instead of using target in our proxy
 apply(noop, that, args) {
 return resolve(typeof target === 'function' ? target.apply(that, args) : undefined)
 },
 })
}
// some modified examples from the accepted answer
var test = {level1: {level2:() => ({level3:'level3'})}}
var test1 = {key1: {key2: ['item0']}}
// You need to get _result in the end to get the final result
console.log(resolve(test).level1.level2().level3._result)
console.log(resolve(test).level1.level2().level3.level4.level5._result)
console.log(resolve(test1).key1.key2[0]._result)
console.log(resolve(test1)[0].key._result) // don't exist

The above code works fine for synchronous stuff. But how would you test something that is asynchronous like this ajax call? How do you test that?

fetch('https://httpbin.org/get')
.then(function(response) {
 return response.json()
})
.then(function(json) {
 console.log(json.headers['User-Agent'])
})

sure you could use async/await to get rid of some callbacks. But what if you could do it even more magically? something that looks like this:

fetch('https://httpbin.org/get').json().headers['User-Agent']

You probably wonder where all the promise & .then chains are... this could be blocking for all that you know... but using the same Proxy technique with promise you can actually test deeply nested complex path for it existence without ever writing a single function

function resolve(target) { 
 return new Proxy(() => {}, {
 get(noop, key) {
 return key === 'then' ? target.then.bind(target) : resolve(
 Promise.resolve(target).then(target => {
 if (typeof target[key] === 'function') return target[key].bind(target)
 return target[key]
 })
 )
 },
 apply(noop, that, args) {
 return resolve(target.then(result => {
 return result.apply(that, args)
 }))
 },
 })
}
// this feels very much synchronous but are still non blocking :)
resolve(window) // this will chain a noop function until you call then()
 .fetch('https://httpbin.org/get')
 .json()
 .headers['User-Agent']
 .then(console.log, console.warn) // you get a warning if it doesn't exist
 
// You could use this method also for the first test object
// also, but it would have to call .then() in the end
// Another example
resolve(window)
 .fetch('https://httpbin.org/get?items=4&items=2')
 .json()
 .args
 .items
 // nice that you can map an array item without even having it ready
 .map(n => ~~n * 4) 
 .then(console.log, console.warn) // you get a warning if it doesn't exist

score 734 · Accepted Answer · 2010-04-13 16:12:50Z

You have to do it step by step if you don't want a TypeError because if one of the members is null or undefined, and you try to access a member, an exception will be thrown.

You can either simply catch the exception, or make a function to test the existence of multiple levels, something like this:

function checkNested(obj /*, level1, level2, ... levelN*/) {
 var args = Array.prototype.slice.call(arguments, 1);
 for (var i = 0; i < args.length; i++) {
 if (!obj || !obj.hasOwnProperty(args[i])) {
 return false;
 }
 obj = obj[args[i]];
 }
 return true;
}
var test = {level1:{level2:{level3:'level3'}} };
checkNested(test, 'level1', 'level2', 'level3'); // true
checkNested(test, 'level1', 'level2', 'foo'); // false

ES6 UPDATE:

Here is a shorter version of the original function, using ES6 features and recursion (it's also in proper tail call form):

function checkNested(obj, level, ...rest) {
 if (obj === undefined) return false
 if (rest.length == 0 && obj.hasOwnProperty(level)) return true
 return checkNested(obj[level], ...rest)
}

However, if you want to get the value of a nested property and not only check its existence, here is a simple one-line function:

function getNested(obj, ...args) {
 return args.reduce((obj, level) => obj && obj[level], obj)
}
const test = { level1:{ level2:{ level3:'level3'} } };
console.log(getNested(test, 'level1', 'level2', 'level3')); // 'level3'
console.log(getNested(test, 'level1', 'level2', 'level3', 'length')); // 6
console.log(getNested(test, 'level1', 'level2', 'foo')); // undefined
console.log(getNested(test, 'a', 'b')); // undefined

The above function allows you to get the value of nested properties, otherwise will return undefined.

UPDATE 2019年10月17日:

The optional chaining proposal reached Stage 3 on the ECMAScript committee process, this will allow you to safely access deeply nested properties, by using the token ?., the new optional chaining operator:

const value = obj?.level1?.level2?.level3

If any of the levels accessed is null or undefined the expression will resolve to undefined by itself.

The proposal also allows you to handle method calls safely:

obj?.level1?.method();

The above expression will produce undefined if obj, obj.level1, or obj.level1.method are null or undefined, otherwise it will call the function.

~~(削除) You can start playing with this feature with Babel using the optional chaining plugin. (削除ここまで)~~

Since Babel 7.8.0, ES2020 is supported by default

Check this example on the Babel REPL.

🎉🎉UPDATE: December 2019 🎉🎉

The optional chaining proposal finally reached Stage 4 in the December 2019 meeting of the TC39 committee. This means this feature will be part of the ECMAScript 2020 Standard.

arguments is not actually an array. Array.prototype.slice.call(arguments) converts it to a formal array. Learn
this'd be a lot more efficient to do var obj = arguments[0]; and start from var i = 1 instead of copying the arguments object
I put together a version with try/catch for austerity sake, and no surprise - performance is awful (except in Safari for some reason). There are some answers below that are pretty performant, along with Claudiu's modification which is also significantly more performant than selected answer. See jsperf here jsperf.com/check-if-deep-property-exists-with-willnotthrow
In ES6 the args variable declaration can be removed and and ...args can be used as the second argument for the checkNested method. developer.mozilla.org/en/docs/Web/JavaScript/Reference/…
This is a very unmaintainable. If any property keys change (they will), all devs on the project would have to 'string search' the entire codebase. This isn't really a solution to the problem, as it introduces a much bigger problem

CollectivesTM on Stack Overflow

Test for existence of nested JavaScript object key

64 Answers 64

Update

Previous answer

getPath

ES6 answer, thoroughly tested :)

→see Codepen with full test coverage

Stop searching when undefined

Ensure each level one by one

Linked

Hot Network Questions

CollectivesTM on Stack Overflow

64 Answers 64

Update

Previous answer

getPath

ES6 answer, thoroughly tested :)

→see Codepen with full test coverage

Stop searching when undefined

Ensure each level one by one

Linked

Related