feat: RN 웹뷰 초기 세팅 #73
Conversation
LeeJeongHooo
requested review from
Andrevile,
ppinppini and
semnil5202
as code owners
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
semnil5202
left a comment
semnil5202
left a comment
There was a problem hiding this comment.
넵넵 정호님, 확인했습니다. 고생많으셨습니다! 🙏
apps/native/app/index.tsx
Outdated
| source={{ uri: 'https://core.depromeet.com' }} | ||
| onNavigationStateChange={handleNavigationChnage} | ||
| overScrollMode="never" | ||
| sharedCookiesEnabled={true} |
There was a problem hiding this comment.
추후 Android 와 iOS 간 동작 차이 확인이 필요한 부분
apps/native/app/_layout.tsx
Outdated
| @@ -1,5 +1,5 @@ | |||
| import { Stack } from "expo-router"; | |||
| import { Slot } from 'expo-router'; | |||
There was a problem hiding this comment.
- Stack: 네이티브 앱의 표준 내비게이션(Push/Pop)을 구현하며, 기본 헤더(Header)와 화면 전환 애니메이션을 포함합니다.
- Slot: 단순히 현재 경로에 맞는 컴포넌트를 렌더링하는 빈 컨테이너(Empty Placeholder) 역할만 수행합니다. (React Router의 과 유사)
UI 제어권 및 "Double Header" 방지
- Stack: 기본적으로 상단 내비게이션 바(뒤로 가기 버튼, 타이틀)를 강제합니다. 웹 서비스 내에 이미 GNB/Header가 있다면, 앱 헤더와 웹 헤더가 동시에 뜨는 이중 헤더 문제가 발생합니다.
- Slot: 아무런 UI 래퍼(Wrapper) 없이 자식 컴포넌트(index.tsx)를 그대로 노출하므로, 화면 디자인을 100% 웹뷰가 주도할 수 있습니다.
내비게이션 히스토리 관리 주체
- Stack: 앱 자체의 history stack을 관리합니다. (A 화면 → B 화면 이동 시 쌓이는 구조)
- Slot: 단순히 URL에 매핑된 컴포넌트만 교체합니다. 웹뷰 앱은 페이지 이동이 앱 레벨이 아닌 웹뷰 내부 URL 변경으로 일어나므로, 앱 레벨의 스택 관리가 불필요하거나 충돌할 수 있습니다.
There was a problem hiding this comment.
추후 네이티브 지면이나 로그인 화면을 별도로 구축해야 한다면, 최상위를 Slot 대신 Stack으로 감싸고 핸들링이 필요하겠네요.
Modal Group 이런것도 활용은 가능하겠군요.. (복잡해지겠지만)
There was a problem hiding this comment.
새로운 네이티브 지면이 생길 수 있다고 생각해서 Slot에서 Stack구조로 다시 변경하였습니다!
apps/native/app/index.tsx
Outdated
| return () => backHandler.remove(); | ||
| }, [canGoBack]); | ||
|
|
||
| const handleNavigationChnage = (navState: WebViewNavigation) => { |
There was a problem hiding this comment.
change 오타난 것 같아요! cspell 프로젝트에 도입하는 것도 괜찮겠네요.
apps/native/app/index.tsx
Outdated
| flex: 1, | ||
| }} | ||
| ref={webViewRef} | ||
| source={{ uri: 'https://core.depromeet.com' }} |
There was a problem hiding this comment.
요거 개발 환경 핸들링하는 env (ex: NEXT_PUBLIC_STAGE) 등으로 유틸 함수 만들어서 환경 분기해서 적용하면 좋을 것 같네요!
if(NEXT_PUBLIC_STAGE === 'development') return 'https://core.depromeet.shop';
retrun 'https://core.depromeet.com';
apps/native/app/index.tsx
Outdated
|
|
||
| export default function Home() { | ||
| const webViewRef = useRef<WebView>(null); | ||
| const insets = useSafeAreaInsets(); |
There was a problem hiding this comment.
요 친구와 css env 와 무슨 차이가 있나요??
There was a problem hiding this comment.
확인해보니,
useSafeAreaInsets (현재 코드): **앱(Native Container)**이 노치를 피합니다. 웹뷰가 노치 아래서부터 시작됩니다.
CSS env(): **웹 콘텐츠(Web)**가 노치를 피합니다. 웹뷰는 화면 꽉 차게(노치 뒤까지) 그려집니다.
라고합니다. 그리고 스타일 이슈가 생겼을 때 관리 주체가 웹이 더 편할 것 같은데.. 이건 우선 위와 같이 적용해보고 논의해보시죠.
- Immersive UI 적용을 고려한다면 env CSS 로 전환이 필요함.
변경한다면, 아래처럼 변경할 것
현재의 paddingTop: insets.top 코드를 제거하고,
웹뷰 스타일을 flex: 1로 유지한 뒤,
웹(Web) 프로젝트의 CSS에 padding-top: env(safe-area-inset-top);을 적용
| useEffect(() => { | ||
| const onBackPress = () => { | ||
| if (canGoBack && webViewRef.current) { | ||
| webViewRef.current.goBack(); | ||
| return true; | ||
| } | ||
| return false; | ||
| }; | ||
|
|
||
| const backHandler = BackHandler.addEventListener('hardwareBackPress', onBackPress); | ||
| return () => backHandler.remove(); | ||
| }, [canGoBack]); |
There was a problem hiding this comment.
아 ~ iOS는 하드웨어 뒤로가기가 없는데, 안드로이드는 있어서 이렇게 로직을 작성해도 iOS 까지 영향이 없군요.
아마 기본값 같은데, Webview 컴포넌트에
allowsBackForwardNavigationGestures={true}속성 넣어주는걸 권장하는군요. (개인적으로는 좀 회의적이긴 합니다. → 아직 잘 몰라서)
2 participants
📌 개요
웹뷰 초기 세팅입니다.
📋 변경사항
스크린샷
🙏 참고사항
리뷰 희망 기한