프론트엔드 데브코스 TIL #DAY19

23.10.13

📚 오늘 공부한 것

• 이벤트 버블링, 이벤트 델리게이션
• 낙관적 업데이트
• history api 적용과 url 파싱

😲 새롭게 알게된 것

이벤트 델리게이션 (Deligation)

이벤트 버블링의 특성을 이용하여, 상위 요소에 이벤트를 걸어 하위 요소의 이벤트를 제어하는 방법이다.

• 장점 & 사용하는 상황
  • 하위 요소가 많은 경우, 각각의 이벤트를 매번 새로 걸어주는 것보다 효율적이다.

application/json

에러 상황 : 서버에 POST 요청시 body에 보낸 내용이 무엇이든 "" (빈값)으로 들어가는 경우가 있었다.

원인 : Content-type이 text/plain 으로 되어 있다. 이는 서버에서 알맞은 형태로 인식하지 않는다. Content-type은 개발자도구 network탭의 'Request Header' 에서 확인할 수 있다.

해결 : POST의 경우라면 headers: { "Content-Type": "application/json"} 설정을 해주어야한다.

낙관적 업데이트

네트워크, 사용자 환경 등 다양한 이유로 api 처리가 느린 경우가 있을 것이다.
api 처리가 느려서 화면 반영이 느려지면, 사용자는 submit이 안된줄 알고 계속 입력을 넣을 수도 있다. 이를 예방하기위해 낙관적 업데이트를 사용한다.

서버에 요청을 했을 때 성공할 것이라고 낙관적으로 보고 화면을 먼저 업데이트 하는 것이다.

+ 페이스북도 이걸쓴다고 한다!
매번 로딩중 처리로 화면을 막는것도 안전하지만, ux를 고려하는 개발이 이런 것이구나 하는 생각이 들었다.

JSON.stringify()

JSON.parse를 이용할 때 전혀 다른 결과를 발생시킨다.

window.location

그냥 location 만으로도 사용 가능하다.

path를 가져올 땐? location.pathname
쿼리스트링(위 그림에선 파라미터)을 가져올 땐 ? location.search

🤨 고민 , 배운 점, 느낀 점

state 구조에 대한 이해

App.js에서 this.state의 구조는{username : '', todos : []} 이었고,
init함수에서 요청으로 받은 데이터를 저장한 todos는 [{content:, isCompleted:, _id:}. { } ] 였다.
이 todos를 통해 this.state를 갱신하는 코드는 다음과 같다.

this.setState({
    ...this.state, // 이건 {username : '', todos : []}
    todos, // [{content:, isCompleted:, _id:}. { } ]
  });

이때, 구조가 헷갈렸던 탓에 코드에 의문이 생겼다.
this.state안에 있는 todos는 방금 새로 입력한 투두 제외 투두들 전체이고,
todos는 새로 응답을 받은 거니까 새로입력한 투두 포함 투두들 전체이다.
굳이 이전것에 추가로 todos를 줄 필요있을까?라는 의문.

그래서 내 생각에 맞춰 다음과 같이 변경하였다.

this.setState({
    username,
    todos,
  });

this.state.todos는 필요없고 새로 받은 todo만 가지고 setState를 하면 된다고 생각했다. 작동엔 문제가 없다.

그렇다면, 어떤 코드가 더 효율적일까?
이점에 대해 고민을 하다가 다른 의견을 듣고 싶어서 팀원에게 물어봤고 다음과 같이 결론을 내려보았다.

지금은 username은 변하지 않은 채로 todos만 새로운 값으로 바꿔주는 것인데, 다양한 경우에서 username과 같은 변하지 않을 값들이 많아질 수 있다. 이때에는 이전값 모두를 복사한 후 새로운 값만 추가해주는 위의 코드가 효율적이라고 생각한다.

꼼꼼함과 ux

기술적으로, 성능적으로 뛰어난 코드를 작성하는 것도 중요한 능력이겠지만, 프론트엔드 개발자로서 좋은 UIUX를 만들어내는 능력도 필요하다고 생각하고 있었다.
이번 강의를 통해 좋은 UIUX는 어떻게 만들어내는 것인지에 대해 많이 배웠다.
한마디로 "꼼꼼함"이었다.
현재 화면이 로딩중인건지, 보여줄게 없어서 빈것인지를 알려주는 것, api처리가 느리더라도 사용자에게는 완료된 화면을 보여줌으로서 불편함을 주지 않는 것, 페이지 이동이나 변경이 있더라도 재접속시 화면 혹은 값들을 유지해주는 것 등.. 실제 사용자 입장이었을 땐 이런 소소한 것에도 불편함을 느껴보았지만 개발하는 입장에선 미처 고려 못했던 부분이어서 반성하게 되었다. 또 뭐가 있을까 ~

🤔 오늘 회고

강의 갯수도 수강시간도 코드도 많아서 오래걸렸지만, 그만큼 배울 것이 너무너무 많았다. 앞으로 프로젝트나 과제를 할 때 도움을 정말 많이 받을 것 같다. 야무지게 써먹어야지!

Keep

의문점 가지기. "이럴땐 이렇게에요~"라는 말씀에 '아 그렇구나'로 끝내지 말고 '왜일까? 요런 방법 저런방법은 어떨까?' 많이 생각하기. 그리고 실제로 해보기

Problem

섬세함 기르기! 변수명 등을 잘 못 부르거나 오타를 내는 등 소소한 실수 줄이기

Try

배운 용어나 문법에 대해 정리하기 그리고 체화하기