리액트 네이티브와 웹 공존 문제 해결 접근법

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

앱 개발

대상자

리액트 네이티브와 웹 연동 개발자, 프레임워크 전환 과정에서 애로사항을 겪는 팀

난이도: 중급~고급 (소스코드 이해 및 디자인 패턴 적용 필요)

핵심 요약

• onMessage 기반 통신의 한계:

- onMessage에서의 무한 분기 처리로 유지보수성 저하

- 양쪽 플랫폼에서 동일한 통신 함수 재선언 필요로 개발 효율성 저하

• 비동기 처리 문제:

- 일방향 통신으로 성공/실패 여부 확인 불가, Promise 구조 도입 필요

- tRPC 영감을 받은 브리지 패턴 도입으로 타입 안전성 및 양방향 통신 가능

• 버전 호환성:

- 앱 스토어 업데이트 지연으로 인한 과거 버전 호환성 문제 해결 방안 제시

섹션별 세부 요약

1. 서비스 배경 및 기존 문제점

• Cordova 기반 서비스 전환 필요성:

- Vue2 기반 웹 앱을 앱 스토어에 배포하기 위해 Cordova 사용

- Lighthouse 점수 저하로 인한 라이브러리 업데이트 필요성

• 리액트 네이티브로의 전환 과정:

- 기존 Vue.js 코드를 WebView로 래핑 후 리액트 네이티브와 공존 구조 확보

- 인앱 브라우저, 네이티브 네비게이션, 공유 데이터 통신 필요성 제기

2. 기존 WebView 통신 방식의 한계

• onMessage 기반 통신:

- postMessage로 메시지 전송, onMessage로 처리 (단일 방향)

- 예시 코드:

```javascript

// 웹에서 리액트 네이티브로 메시지 전송

window.ReactNativeWebView.postMessage('openInAppBrowser');

// 리액트 네이티브에서 웹으로 JavaScript 주입

this.webviewRef.injectJavaScript('console.log("Received")');

```

• 문제점:

- onMessage 내 분기 처리로 코드 복잡도 증가

- 동일한 기능이 웹/앱 양쪽에서 재선언 필요

- 비동기 처리 불가로 성공 여부 판단 불가

3. 새롭게 제안된 브리지 패턴

• tRPC 영감을 받은 구조:

- 타입 안전성 보장, 별도 스키마 정의 없이 API 구축 가능

- 서버-클라이언트 구조 모방 (리액트 네이티브: 서버, WebView: 클라이언트)

• 브리지 구현 방식:

- createWebView에 브리지 주입

- linkBridge 실행 시 openInAppBrowser 등 기능 직접 사용 가능

- Promise 구조로 성공/실패 처리 가능

- 미선언 함수 실행 시 에러 발생으로 안정성 보장

4. 구현 시 고려사항

• 타입 안전성:

- tRPC의 procedure 선언 방식 도입 (서버/클라이언트 간 타입 동기화)

• 버전 호환성:

- 앱 스토어 업데이트 지연으로 인한 기능 호환성 검증 필요

- 사용자 에이전트 확인 통해 기능 선택적 실행

결론

• 리액트 네이티브와 웹 간 통신 문제 해결:

- onMessage 기반 방식 대신 브리지 패턴 도입

- tRPC 영감을 받은 타입 안전성 및 양방향 통신 구조 확보

- Promise 기반 비동기 처리로 성공/실패 여부 판단 가능

• 실무 적용 팁:

- 기존 코드의 onMessage 분기 처리를 브리지 기반으로 재구성

- 리액트 네이티브에서 WebView 통신 함수 선언 후, 웹에서 해당 함수 직접 사용

- 버전 호환성 검증 로직 추가 (사용자 에이전트 기반 기능 조건 처리)