옵셔널 체이닝

통신을 통한 데이터는 아무리 협의를 봤다해도 어떻게 변해서 들어올 지 단언할 수가 없다. 따라서 프론트 코드를 짤 때 가장 중요하게 생각하는 것 중 하나가 통신을 통해 들어온 데이터가 이상하더라도 구동하는 데 에러가 나지 않도록 처리하는 에러 처리이다. 옵셔널 체이닝은 에러 처리하는 데 유용한 기능으로, 객체에 접근하는 에러 처리를 간단히 할 수 있게 돕는다. 

아주 옛날 프로젝트의 코드를 유지보수해야할 일이 생겼는데, 코드의 바벨이 ES11이 지원이 안되었다. 그러다보니 옵셔널 체이닝도 사용할 수 없었고 에러처리하는데 코드가 잔뜩 길어지다보니 새삼스레 이 기능에 대해 다시 돌이켜보게 되며 오늘의 글을 작성본다.

 

 

옵셔널 체이닝 기본

옵셔널 체이닝은 객체, 함수, 배열 요소 등에 안전하게 접근할 수 있게 해주는 기능이다. 

 

일반적으로 객체 내부에 무언가 있다고 믿고 " . "을 통해 그 내부로 접근하는데, 이 지정한 무언가가 없을 경우 에러가 발생해버릴 수 있다.

// test 객체에 접근하기
const test = {
 exam: '테스트'
}
console.log(test.exam) // '테스트'

// test 객체 내부에 없다면?
const test = {}
console.log(test.exam) // 'TypeError: Cannot read property 'name' of undefined'

 

위와 같이 test 안에 아무것도 없는데 안으로 들어가거나 혹은 test 자체가 없는데 안으로 접근하려는 시도가 있다면 에러를 뱉고만다. 따라서 위와 같은 에러를 방지하기 위해서 보통 if문을 사용하여 일일이 객체와 객체의 값이 존재하는 지 확인하여야한다.

const test = {
  exam: '테스트'
}

if(test && test.exam){
  console.log(test.exam) //'테스트'
}

 

 

객체가 단순한 구조라면 짧게 끝낼 수 있지만 객체 안 구조가 복잡하고 많아진다면 그만큼 코드는 복잡해질 것이다.

하지만 옵셔널 체이닝을 쓴다면 복잡한 구조도 간결하게 작성할 수 있다.

const test = {
  exam: '테스트'
}
if(test?.exam) {
  console.log(test.exam) //'테스트'
}

const test = undefined
if(test?.exam) { 
  console.log(test.exam)
}else{
   // undefined로 바뀌어서 else문으로 간다
}

 

옵셔널 체이닝은 객체 안을 접근 하는데 접근이 불가하여 에러가 나는 것을 에러로 보내는 것이 아니라 undefined로 반환해준다. 에러가 아닌 undifined로 반환됨으로 if문에서 else를 타 안정적인 코드 운영을 가능하게 해주는 것이다.

 

 

 

옵셔널 체이닝으로 배열 확인하기

코드를 짜다보면 항상 객체 안에 배열이 있는 모양을 가장 많이 다루게된다. 그리고 보통 배열은 배열함수를 통해 가공하게 되는데, 배열함수를 쓰기 위해서는 해당 값이 배열인지 확인하지 않으면 틈만 나면 에러를 뱉게 된다.

옵셔널 체이닝은 이러한 배열을 확인할 때 간결하게 쓸 수 있게 해줘서 많이 쓰는 기능이다.

 

옵셔널 체이닝으로 객체 안에 들어있는 값이 배열인지 그리고 그 배열 안에 값이 있는지 없는지도 확인이 가능하다.

const test = {
  items: ['A','B']
}

if(test?.items?.[0]) {
  console.log(test.item[1]) //'A'
}

 

위와 같이 코드를 작성한다면, test가 접근 가능한지, items에 접근가능한지, items 배열의 0번째 요소가 존재하는지 확인 가능하게 된다. 

 

배열 안 값이 존재하는지는 상관없고 배열인지만 확인하려한다면 Array.isArray과 옵셔널 체이닝을 통해 간단하게 구현할 수도 있다.

const test = {
  items: []
}

if(!Array.isArray(test?.items)) {
  console.log(test.item) // []
}

 

 

 

마무리

옵셔널 체이닝를 남용하면 어디서 에러가 발생했는지 몰라서 추적하기 힘들기에 추후 디버깅에 방해가 될 수 있다. 따라서 옵셔널 체이닝은 반드시 필요한 곳에서만 쓰여야하지만...

실제로 코드 작업하면서 특히 통신을 통한 반환값은 언제 어떻게 들어올지 몰라서 방어적으로 코딩하다보니 옵셔널 체이닝을 다소 남용했다. 덕분에 코드는 간결해졌고 에러 처리는 확실히 잡았지만 확실히 디버깅 측면에서 다소 어려움을 느꼈던 것 같다.

앞으로 코드 짤 때 옵셔널 체이닝에 너무 매달리지 말고 좀 더 분할해서 코드를 나누는 것도 생각해봐야겠다.