[번역] React Native Learnings
react native 을 적용하려면 ?
원본 URL: https://medium.com/@srinuch1981/react-native-learnings-367e252c1900
소개
이 기사의 목적은 애플리케이션에 React Native 프레임 워크를 채택하려는 모바일 애플리케이션 개발 팀을 안내하는 것입니다. 이 문서는 애플리케이션 아키텍처, React Native 프레임 워크 디자인, React-Native 프레임 워크를 관리해야하는 일부 개발 항목 및 네이티브 개발과 비교할 때 개발 중에 직면 할 수있는 문제에 대해 설명합니다.
기본 혜택에 대응
React Native는 모바일 애플리케이션에서 기본 모양과 느낌을 제공하는 크로스 플랫폼 개발 프레임 워크입니다. 이러한 크로스 플랫폼 프레임 워크에는 다음과 같은 이점이 있습니다.
PoC는 각 플랫폼 (iOS 및 Android)에 대해 별도로 수행 할 필요가 없습니다. 따라서 빠른 평가에 도움이됩니다.
핵심 비즈니스 로직 및 단위 테스트는 각 플랫폼에 맞게 작성 될 필요는 없습니다.
UI 구현은 플랫폼별로 필요하지 않습니다. 플랫폼에 따라 기능 요구 사항 및 사용자 지정을 완료하려면 추가 노력이 필요합니다.
Android 용 MVP / MVVM 및 iOS 용 MVC / VIPER와 같은 다른 패턴을 고려한 별도의 애플리케이션 설계는 필요하지 않습니다.
유지 관리 노력을 줄여주는 단일 코드베이스.
네이티브 반응에 대한 평가 접근
React native는 여러 가지 방법으로 사용할 수 있습니다. Team은 기존 네이티브 모듈과 어떻게 통합 될 수 있는지 알고 싶습니다. 반응 네이티브 채택을 위해 다음 항목을 평가해야 함을 확인했습니다.
응용 프로그램에 필요한 기능을 기반으로 IOS 및 Android 플랫폼에서 가능한 코드 재사용 성
모바일 플랫폼에 고유 한 UI 및 API로 구성된 기존 기본 모듈의 통합은 BLE, 카메라 등입니다. 공통 모바일 애플리케이션 아키텍처가 IOS 및 Android 플랫폼에서 구현 될 때 발생할 수있는 복잡성
플랫폼 별 사용자 정의 금액 예. UI (flexbox를 사용한 목록 및 사용자 정의 레이아웃) 및 전환 기반 애니메이션
기존 응용 프로그램 시나리오를 기반으로 더 나은 탐색 라이브러리를 선택하기위한 경로 라이브러리 평가
푸시 알림에 대한 딥 링크 동작
Redux 디자인 패턴 채택
JS 네트워크 라이브러리 (즉, Axios, apisauce, apollo-link) 평가
응용 프로그램 아키텍처
응용 프로그램 스택
반응 탐색
React-Native 커뮤니티 중심의 탐색 라이브러리이며 순전히 JS 기반입니다. 그것은 반응 네이티브 커뮤니티의 초기 반응 네이티브 기반 응용 프로그램에 대한 많은 실험의 결과입니다.
리덕스
반응 기반 애플리케이션을위한 상태 관리 라이브러리. 핵심 원칙은 변경 불가능한 데이터와 순수한 기능으로 예측 가능한 상태 업데이트입니다. 중앙 집중식 상태 정보를 여러 구성 요소와 공유하는 데 도움이됩니다.
레덕 사가
Redux-Saga는 비동기 호출의 부작용을 관리하는 데 도움이됩니다. ES6 생성기를 사용하여 비동기 / 대기 기능처럼 비동기 코드를 읽을 수있게 만듭니다.
아폴로 링크
GraphQL 요청의 제어 흐름을 수정하기위한 인터페이스 라이브러리. 이것은 링크를 단일 목적 링크로 구성 할 수 있도록 설계되었습니다. Graphql 서버에서 API를 사용하기 위해 독립형 클라이언트로 사용
네이티브 모듈
기본 UI 화면에서 BLE, Amazon Fling, Amplify, Firebase 및 Authentication SDK를 지원하기 위해 여러 기본 SDK와 통합되었습니다.
도구
젠킨스
Android, iOS 용 CI 및 CD 서버로 사용됩니다. 자동화 및 코드 푸시를 위해 구성된 파이프 라인
코드 푸시
이 플러그인은 제품 개선 변경 사항을 최종 사용자에게 신속하게 푸시하고 피드백을 위해 새로운 기능을 출시 할 수 있습니다. 주요 장점은 새로운 APK / IPA를 공개하지 않고 JS 번들 변경 사항을 사용자에게 푸시하여 매장을 플레이 할 수 있다는 것입니다. 중간자 공격을 피하려면 항상 서명 메커니즘을 사용하십시오.
흐름
자바 스크립트에 대한 정적 유형 검사기이며 점진적으로 적용 할 수 있습니다. 큰 리팩터링에 도움이됩니다.
에스 린트
반응, 반응 기본 및 흐름 유형을 지원합니다. 프로젝트를 기반으로 규칙을 쉽게 구성 할 수 있으며 팀 구성원이 일관된 코드를 작성하는 데 도움이됩니다.
방사
패키지 종속성 관리 도구에는 다운로드 한 패키지를 캐시 할 수있는 기능이 있습니다
응용 프로그램 아키텍처 다이어그램
디자인 고려 사항
대상 응용 프로그램은 사용자 데이터를 위해 GraphQL 서버와 상호 작용하며, 작업을 기반으로 요청을 연결, 분할 및 채널화할 수있는 아폴로 링크 클라이언트를 사용합니다.
응용 프로그램은 redux-saga와 잘 어울리는 비동기 작업의 부작용에 전적으로 의존합니다. 소켓 상태에 따라 동작을 제어 할 수 있도록 여러 루트 사가를 설계했습니다 (즉, 소켓 연결이없는 경우 특정 동작 무시)
소켓 연결이 불안정 할 때 HTTP로 라우팅되는 몇 가지 중요한 작업을 제외하고는 웹 소켓 링크를 통해 통신이 이루어집니다.
이 응용 프로그램은 매우 복잡한 데이터를 처리하지만 여러 화면에서 사용되는 중요한 데이터 만 저장하려고합니다. 결과적으로 일시적인 결과이거나 해당 컨텍스트에서만 유용한 특정 이벤트 (6 단계)에 대한 상점 업데이트를 건너 뜁니다.
6 단계는 정기적 인 반응 리덕스 기반 디자인에서 벗어 났지만 불필요한 / 임시 데이터로 상점 업데이트를 피하는 가장 좋은 대안 중 하나입니다.
(예 : 현재 선택된 제품을 기반으로 대체 제품 또는 제안 제시 — 주어진 상황에서만 유효하고 데이터는 각 제품마다 크게 다를 수 있습니다. 상점에 전체 데이터를 저장하는 것은 오래된 데이터로 이어지기 때문에 좋지 않을 수 있습니다) . 애플리케이션에서 이와 같은 많은 유스 케이스를 식별했으며 컨텍스트를 기반으로 redux 상태를 업데이트하지 않았습니다.
사용 된 선택기, 데이터를 변환하고 기억하기 위해 다시 선택하여 불필요한 렌더링을 피하는 데 도움
아폴로 링크 체인
고려 사항
디버그 목적으로 처리 한 후 요청-응답 세부 사항과 함께 전체 조작 정보를 로그 할 수 있어야합니다 (구성 가능하며 프로덕션 빌드에서 제거 가능)
모든 작업에 대한 시간 초과를 구성하고 상태 코드를 기반으로 재시도 메커니즘을 제공 할 수 있어야합니다.
재 연결에 2 ~ 3 초가 걸리므로 간헐적 인 네트워크 문제를 처리하기 위해 요청을 대기하고 정상적으로 처리하고 싶습니다
조작에 따라 특정 오류를 처리하고 재시도 여부를 결정해야합니다.
간헐적 인 네트워크 문제를 피하려면 작업을 대기해야합니다
지리적 네트워크 대기 시간을 평가하기 위해 모든 요청에 대해 경과 시간과 상태 만 기록해야합니다.
테스트 도구
제품 품질, 코드 적용 범위 및 더 빠른 회귀 테스트 반복주기를 향상 시키려면 모든 모바일 애플리케이션에 더 나은 테스트 프레임 워크 및 도구를 식별하는 것이 중요합니다.
단위 및 통합 테스트
Jest:
반응 네이티브로 사전 설정되고 반응 네이티브로 사전 구성된 테스트 프레임 워크
사용 된 기능
스냅 샷 — 의도하지 않은 데이터 변경을 피하기 위해 UI 구성 요소 스타일링 및 작업 작성자를 추적
Mocks — 모의 네이티브 프레임 워크 API 및 타이머
스파이 — 행동 중심 시나리오에서 주로 사용되는 API 호출의 유효성 검사
코드 범위 — CI 서버에 결과를 제공하기 위해 JUnit과 통합
Enzyme:
얕은 렌더링, 이벤트 트리거 및 돔 조작으로 React 구성 요소를 테스트하는 라이브러리
Sinon :
Sinon은 독립형 라이브러리 (jest, spy, mock, ..와 같은 기능을 제공함)이지만 특정 시나리오에서 jest에 문제가 있었기 때문에 타이머를 진행시키는 데만 사용됩니다 (즉, 애니메이션 뷰의 최대 타이머 수에 도달했습니다)
End-To-End Testing
Appium에 대한 사전 경험이 있었지만 종단 테스트를 위해 Cavy 및 Detox를 평가했습니다. 응용 프로그램 흐름에 존재하는 기본 화면 (Native SDK Integrations, 즉 Social login)을 사용하여 두 플랫폼 (Android, iOS)에서 테스트하는 데 도움이되는 Appium을 마지막으로 선택했습니다.
학습 방법
JS Static Analysis
유형 검사 : 큰 코드 리팩터링에 도움이되고 자신감을 향상시키는 정적 유형 검사가 중요합니다. Flow를 사용하여 점진적인 접근 방식을 선택하는 것이 좋습니다
Lint : EsLint에는 기본 스타일이 있으며 규칙을 쉽게 구성 할 수 있습니다. 반응, 반응 기본, 흐름 유형 지원
React Native
크로스 플랫폼으로서 Android 및 iOS 모두에 적합합니다. 빌드 구성에 큰 어려움이 없습니다.
플랫폼 별 도구를 구성하고 설치하지 않아도되므로 인기있는 SDK (예 : Expo)와 상용구 (예 : Ignite, Pepperoni)를 식별하십시오. 제한 사항을 고려해야합니다 (즉, 제한된 API, 바이너리는 온라인으로 만 빌드 할 수 있음).
크로스 플랫폼 툴킷에 NativeBase 또는 React Native Elements를 사용하십시오. 응용 프로그램에 사용자 지정 스타일 구성 요소가없는 경우
플랫폼 별 UI가 없기 때문에 JS 코드의 거의 90 %가 두 플랫폼에서 공통적입니다 (%는 주로 UI에 따라 다름)
두 플랫폼에서 기능이 동일한 방식으로 작동한다고 가정해서는 안됩니다. 개발자는 두 플랫폼 모두에서 유효성을 검사하고 추정에서 플랫폼 별 동작 차이를 고려해야합니다.
창 크기에 따라 화면을 구현하기 위해 많은 노력이 필요하기 때문에 응용 프로그램을 다양한 장치 및 화면 크기로 확장하는 방법을 조기에 결정하십시오.
팀 구성원은 성능 및 동작 사용자 정의를 개선하기 위해 기본 플랫폼 별 사항을 알고 있어야합니다 (예 : 레이아웃 관리자를 사용하고 중복 계층을 줄이기 위해 계층 구조 식별)
React Native UI 화면과 기본 UI 화면간에 상태 또는 컨텍스트가 공유되지 않으면 잘 작동합니다.
기존 네이티브 모듈의 통합은 복잡하지 않지만 브리지를 통한 데이터 전송을 줄이십시오.
GIF 애니메이션 이미지는 기본적으로 iOS에서 지원되지만 안드로이드에서는 지원되지 않습니다. 프레스코 애니메이션 라이브러리를 추가해야합니다
List 렌더의 성능을 향상시키기 위해 항상 고유 키를 사용하십시오.
자동화 목적으로 Android에서 testID를 지원하지 않으면 접근성에 의존해야합니다 (응용 프로그램이 장애가있는 사용자를 대상으로하는 경우 응용 프로그램을 자동화 할 수 없음)
React Native
내부 상태 (유도 또는 일반 사용자 변경) 및 소품과 같은 여러 데이터 소스를 피하여 의사 결정을 더 어렵게 만듭니다.
구성 요소 및 컨테이너에 항상 Proptype을 사용하여 런타임시 입력 데이터 유형 유효성 검증을 추적하십시오.
기본적으로 노드 깊이 및 레이아웃 계산이 증가하므로 불필요하게 중첩 뷰를 피하십시오.
재사용이 가능한 멍청한 구성 요소 (내부 상태는 피함)만큼 빌드하고 복잡성을 줄이기 위해 컨테이너로 상태를 들어 올리십시오
특정 라이프 사이클 메소드 (예 : componentdidupdate, getDerivedStateFromProps)를 사용할 때주의해야합니다. 그렇지 않으면 우수 사례를 따라야합니다. 그렇지 않으면 여러 렌더링으로 끝날 수 있습니다.
UX는 응용 프로그램 성능을 향상시키기 위해 데이터 관계를 고려해야합니다 (즉, 렌더링이 증가 할 수 있으므로 여러 노드의 청취를 피함).
Navigation
응용 프로그램 사용 사례에 따라 탐색 라이브러리를 선택하십시오. 커뮤니티는 반응 네이티브 탐색을위한 JS 기반 솔루션이므로 반응 탐색을 제안하고 라우팅의 복잡성을 피하기 위해 JS와 기본 화면을 명확하게 분리합니다.
향후 커뮤니티의 지원이 없으므로 redux 통합을 피하십시오.
항상 활성 화면을 확인하고 쌓인 화면의 렌더링을 피하여 성능을 향상 시키십시오 (예 : 소품이 변경되어 둘 이상의 화면과 컨테이너가 렌더링되도록 트리거 할 수 있음)
Redux
UI를 기반으로 성능을 향상시키기 위해 리듀서를 디자인 할 때는 매우주의해야합니다 (즉, 딥 노드를 피하기 위해 정규화 고려)
상태 경로를 직접 참조하는 대신 선택기 / 재 선택을 사용하십시오. 선택기는 데이터를 변환하고 경로에 대한 의존성을 피할 수있는 유연성을 제공합니다.
가독성, 추상화 기능을 제공하고 여러 레이어를 분리하는 데 도움이되므로 일반 작업 대신 액션 제작자와 함께하십시오. 추가 상용구 코드에 대해 걱정하지 마십시오
오프라인 동작을 고려하고 미들웨어를 제공하여 사용자 정의
도전 과제
최신 버전으로 업그레이드하면 기능이 손상되어 어려움이 있습니다.
JS와 네이티브 모듈간에 동기 호출을 할 수 없습니다. 설계 단계에서 비동기 API 접근 방식을 고려해야합니다
항상 안드로이드, 특히 안드로이드에 네이티브 네이티브 반응, 새로운 API 또는 기능을 채택하기 위해 새로운 릴리스까지 기다려야합니다 (현재 안드로이드 지원 버전은 26입니다)
장기 패키지 업데이트에서 타사 패키지는 최신 React Native 버전과의 호환성 문제를 일으킬 수 있으며 복제로 이어집니다
일부 타사 패키지는 모든 응용 프로그램에서 유연하게 채택 할 수 없으며 PR이 병합되고 릴리스 또는 복제되어 개인 패키지로 유지 될 때까지 기다려야합니다.
그러나 JS와 기본 레이어 모두에서 충돌을 추적하는 더 나은 도구를 식별하기 위해
초기 화면로드 시간 향상 (약 25 ~ 6 초 번들 파일을로드하는 데 약 5 ~ 6 초 소요)
React Native으로 전환해야 할 이유
탐색, 애니메이션, 플랫폼 별 API 사용과 같은 응용 프로그램 기능에 전적으로 달려 있습니다.
기능의 차이가 적은 새로운 응용 프로그램을 시작할 계획입니다.
플랫폼에 관계없이 일관된 UI 디자인 및 기능.
기본 화면 범위를 제한하거나 기본 UI 경계를 잘 알고 있습니다.
기본 및 React 기본 UI 화면 탐색 간의 컨텍스트 전환 제한
복잡한 제스처 기반 기능을 사용하지 않습니다.
기본 화면과 JS 화면간에 응용 프로그램 상태 / 데이터를 공유하지 않습니다.
하드웨어 별 기능 API (BLE, NFC, 오디오 / 비디오, 카메라)의 사용 제한
결론
처음부터 개발되고 모범 사례를 따르는 대상 애플리케이션으로 React Native 프레임 워크의 이점을 누리십시오. 전체 개발 시간이 단축되고 두 플랫폼에서 단일 코드베이스 (90 %)를 공유 할 수 있습니다.
