앞으로 새로운 것을 알아냈지만 단독으로 글을 내기에는 분량이 애매할 때 해당 시리즈를 가져와 글을 작성할 예정이다
우아한테크코스도 끝난 지금 새로운 글 시리즈 출간이 필요했으므로 😎 나 홀로 시작하는 챌린지이다. 이번주 배운 점, 짤막한 회고글 등을 작성할 예정이다.
리액트의 이벤트 위임 🛠️
<button onClick={onButtonClick}>클릭</button>리액트에서 익숙한 문법이다. 버튼에 클릭이벤트를 등록하는 것이다.
그런데, 여기서 onClick을 통해서 우리가 정해준 클릭 이벤트를 리액트는 어디에 등록을 어디에 하고 있는 걸까? button 엘리먼트 인걸까?
답은 root element이다!
Dan 형님의 말씀
그렇다 리액트는 이벤트를 등록할 때에 각각의 앨리먼트에 등록하는 것이 아닌 root element에 모두 이벤트를 위임시켜버리는 것이다.
참고로 React17부터 기존의 html document에서 root element로 이벤트 위임의 위치가 변경되었다. 해당 이유는 하나의 어플리케이션에 서로 다른 버전의 리액트가 존재할 때에 두 버전 모두 document level에 이벤트를 부착하게 되면 버전이 다른 리액트 끼리의 충돌 때문에 버그 발생이 쉬운 환경이 되었다. 이에, 업데이트를 통해 각자 자신의 root element에 이벤트를 부착하여 관리하여 위험 요소를 제거하였다.
왜 리액트는 이벤트 위임을 사용하였을까? 라고 생각해본다면 답은 간단한것 같다.
관리비용을 줄이기 위해서 일 것 같다.
이벤트 위임을 사용하게 되면,
동적인 엘리먼트에 대한 이벤트 처리가 쉬워진다.
또한 자식 엘리먼트가 새로 생성 될 때마다 동적으로 추가되는 이벤트가 없어지기 떄문에 메모리 사용량이 줄게된다.
그리고 상위 엘리먼트에서만 이벤트 버블링 현상을 통해 처리할 수 있기 때문에 하위 엘리먼트에서는 자유롭게 추가 삭제가 가능하다.
이러한 이벤트 위임의 장점을 취하기 위해서 리액트에서는 이벤트 위임을 사용한 것 같다.
또한 브라우저마다 지원하는 이벤트에 차이가 있기 때문에 리액트는 브라우저간 호환을 위하여 NativeEvent 그대로가 아닌 SyntheticEvent를 활용하여 감싸는 방식을 채택하였다.
react-dom-bindings>src>events>ReactSyntheticEventType
type BaseSyntheticEvent = {
isPersistent: () => boolean,
isPropagationStopped: () => boolean,
_dispatchInstances?: null | Array<Fiber | null> | Fiber,
_dispatchListeners?: null | Array<Function> | Function,
_targetInst: Fiber,
nativeEvent: Event,
target?: mixed,
relatedTarget?: mixed,
type: string,
currentTarget: null | EventTarget,
};웹뷰는 왜 쓰는 걸까? 🤔
프론트엔드 개발자로써 취직 준비를 하면서 문득 이런 생각이 들었다. 이 회사들 왜 나를 뽑아야하는가? 정확히는 프론트엔드 개발자를 말이다.
최근 거의 모든 서비스가 앱으로 제공되고 있다. 오히려 웹으로만 지원되는 서비스를 찾는것이 더 힘들 정도이다.
그렇다면 한 가지 의문점이 든다. 그렇다면 왜 서비스에 웹이 필요할까? 앱으로만 제작하면 되는 것이 아닌가 싶다.
하지만 앱으로만 서비스를 제작하게 되면 몇가지 불편한 점이 생기게 된다.
IOS, Android로 나누어져 있는 진영
스마트폰은 크게 아이폰과 안드로이드 폰으로 나눠지게된다. 그리고 그 둘의 운영체제는 각각 Swift와 Kotlin(또는 자바)를 사용하고 있다.
그러다보니, 같은 서비스와 같은 화면을 보여주고 있다고 하더라도 두 가지의 언어로 작성하여야 한다는 점에서 리소스 낭비가 있게 된다.
앱의 한계
해당 요소는 생각하지 못했던 부분이였는데, 송요창님의 블로그 글에서 알 수 있었다.
앱으로 수정사항등을 배포시에 앱 스토어에 승인을 받아야 고객에게 출시가 가능하다. 해당 과정은 아무리 빠르게 진행된다고 하여도 회사에서 웹을 통해서 배포를 하는 것 보다는 느릴 수 밖에 없다.
또한 중대한 버그가 발생하였을 때에 빠른 대응이 불가능하다.
절차상 필요한 과정들이 있기 때문이다.
그리고 무엇보다 유저가 어떤 앱을 사용하고 있을지에 대한 문제도 존재한다.
앱을 업데이트하는 것은 유저의 선택에 달려있다. (최근에는 업데이트를 하지 않으면 앱 사용을 막기도 하긴 말이다) 유저가 앱 업데이트에 동의하지 않는다면, 유저는 업데이트 되지 않은 앱을 계속해서 사용할 것이고 그렇다면 회사에서는 해당 버전에 대한 서비스 또한 제공 해주어야 한다.
웹뷰의 등장
이런 단점을 해결할 수 있는 것으로 등장한 것이 웹뷰이다.
앱에서 웹을 사용할 수 있도록 지원한 기능이다.
웹을 앱에서 작동이 가능하게 되면서 코드의 수정 사항들이 웹을 통해 바로 유저에게 보여질 수 있게 되었다.
또한 유저가 앱을 업데이트 하지 않았다 하더라도 웹뷰를 통해서 보여주는 내용은 서버에서 실시간으로 받아오는 화면이기 때문에 수정된 서비스들을 바로 바로 보여줄 수 있다.
이 점 덕분에, 빠른 반영과 빠른 유저의 피드백을 받아볼 수 있다.
또한 IOS, Android 각각 다르게 코딩을 진행할 필요 없이 웹을 만드는 방식 그대로 한 번에 두 운영체제에 대해서 대응이 가능해진다.
웹뷰의 한계
장점만 있을 것 같은 웹뷰에도 한계점이 존재한다.
바로, 앱 위에서 돌아가는 웹뷰라는 한계점이다.
웹이다 보니 네이티브들이 가능한 디바이스 작동들에 바로 접근이 불가능하다. 또한 웹뷰를 켤 때마다 서버와의 통신이 일어나기 때문에 서버 자원이 더 사용 될 수 밖에 없다.
그리고, 해당 js, html, css등을 받아와 파싱 렌더링하는 과정을 거치기 때문에 네이티브보다 화면에 보여지는 속도가 느릴 수 있다.
이러한 한계점을 극복하기 위해 여러가지 해결책이 있다.
우선, 네이티브들이 가능한 디바이스 작동이 가능하게 하게 위해
딥링크를 통해서 새로운 화면 인스턴스를 생성하여 이동시키거나
앱, 웹 간 공통된 함수를 제공하는 방법을 통해서 공통된 함수를 window 등의 전역객체에 등록을 하여 앱과 웹에서 모두 작동이 가능하게 하거나 앱에서 인터페이스를 띄울 때에 웹에서 사용할 수 있는 함수들을 넘겨줄 수 있다.
속도가 느리다는 단점은, 성능 최적화와 캐시등을 활용하여 시간 단축을 진행할 수 있다.
