[번역] 우리의 React Native로 전환
Our Transition to React Native
원본 URL : https://blog.khanacademy.org/engineering/our-transition-to-react-native/
네이티브 반응으로의 전환
Bryan Clark 작성
2017 년 Khan Academy는 iOS 및 Android 앱에서 React Native를 사용하기 시작했습니다. 올해 1 , 우리는 큰 이정표에 도달했습니다 : React Native 로의 전환이 완료되었습니다! 앱의 모든 화면은 React Native 2로 렌더링됩니다 .
2017 년 React Native의 초기 실험에는 몇 가지 요인이있었습니다.
iOS 및 Android 앱의 디자인은 유사한 상호 작용 디자인, 기능 및 콘텐츠 로 거의 동일했습니다 .
새로운 기능을 개발하기위한 데이터 디자인, 버그 및 조정이 다르므로 두 가지 코드베이스를 유지 관리하는 것은 쉽지 않습니다. (이것에 대해서는 1 분 후에 더 자세히 설명하십시오.)
우리의 모바일 팀은 작은 3 전환이 엔지니어 많은 수의 조정이 필요하지 않았다, 그래서.
우리 웹 사이트는 이미 React를 사용 하고 있었으므로 전환에 도움이되는 개념과 도구에 대한 사내 전문 지식을 보유하고있었습니다.
두 개의 별도 코드베이스를 유지 관리해야하는 문제에 대해 조금 더 이야기하겠습니다.
플랫폼마다 다른 버그가 나타납니다. 물론 이것은 React Native의 경우에도 해당되지만 훨씬 덜 일반적입니다.
새로운 기능을 구현하려면 두 플랫폼에서 설계, 엔지니어링 및 테스트를 조정해야했습니다 . 즉, 동시에 이상적으로 사용할 수있는 최소 두 명의 엔지니어 (iOS 및 Android)가 필요했습니다. 우리 팀과 같은 소규모 팀에게는 매우 어려운 작업이었습니다!
기능이 구축 된 후에는 두 플랫폼 모두에서 변경해야하므로 변경 하기 가 어려웠습니다 . 디자인 조정 및 업데이트가 어려웠습니다.
아키텍처는 플랫폼마다 크게 다릅니다. 우리의 iOS 코드베이스는 우리의 안드로이드 코드베이스보다 4 년이 더 오래되었습니다. iOS에는 Swift, ReactiveCocoa, Cartography 및 CoreData가있었습니다. Android에는 자체 종속성 및 데이터 흐름 디자인이 있습니다. 여기에 차이점이 추가되었습니다. 다른 플랫폼에서 기능을 빌리는 것은 종종 쉽지 않았으며 다른 플랫폼의 코드를 검토하기가 쉽지 않았기 때문에 엔지니어는 대부분 플랫폼에 의해 격리되었습니다.
전환 만들기
전환은 기본적으로 탐색, 스 트래들 링 및 멸종의 세 단계로 진행되었습니다. (베이스 캠프 힐 차트 는 이에 대한 은유입니다.)
탐색 (2017 년 초) 은 검색 탭과 같은 React Native의 첫 화면으로 네이티브 코드와 Javascript 코드 사이에 다리를 추가하기위한 초기 작업이었습니다. 거의 모든 네트워킹, 데이터, 비즈니스 로직 및 모든 "클라이언트 측 백엔드"항목이 브리지를 통해 전달되었습니다. 여기에는 많은 상용구가 포함되므로 꽤 지루했습니다.
스 트래들 링 (2017 년 중반에서 2018 년 중반) 이 가장 힘들었다. 우리는 React Native를 사용하기로 결정했지만 결승선에서 멀었습니다. 우리는 이제 기본 iOS, 기본 Android 및 React 기본 코드의 세 가지 사항을 고려해야했습니다. 엔지니어들은 변경을하기 위해 2 개 이상의 패러다임을 알아야했고 배울 것이 많았습니다!
멸종 (2018 년 중반에서 2020 년 중반까지) 은 제가 가장 좋아하는 부분이었습니다. 이 단계는 콘텐츠 데이터베이스 (우리의 많은 강좌, 비디오, 기사 및 연습)를 대규모 번들로 제공되는 기본 데이터베이스 (예 : CoreData)에서 경량으로 완전히 전환하는 여러 달의 노력 인 "스트리밍 토픽 트리"프로젝트로 시작했습니다. Javascript로 작성된 캐싱 라이브러리. 이제 클라이언트 측 콘텐츠 데이터베이스가 React Native에 있었기 때문에 구축 한 브리지를 거의 통과 할 필요가 없었으며 많은 네이티브 코드를 삭제할 수있었습니다. 올해 v7.0 릴리스는 마지막 기본 화면을 React Native로 업그레이드하고 휴대폰과 태블릿에서 내비게이션 디자인을 통합하는 마지막 추진이었습니다.
네이티브와 리 액트 네이티브의 혼합
우리는“화면 내용”에 React Native를 사용하고 해당 화면 주위를 탐색하기위한 기본 코드를 사용합니다. 몇 가지 근본적인 이유가 있지만 본질적으로“복잡한 구현이 어디에 존재 하는가”와“네이티브 앱이 네이티브를 느끼게하는 것”의 균형입니다.
앱에 대한 대부분의 "비즈니스 로직"은 화면 내용 (예 : 홈 탭 카드 내용 또는 책갈피 탭의 다운로드 규칙)에 있습니다. 이에 비해 탭 막대 또는 탐색 막대의 내용은 비즈니스 논리에 크게 의존하지 않습니다.
그러나 React Native로 작성된 탐색 모음 및 탐색 컨트롤러 는 작은 방식으로 모조품 으로 느껴 집니다. 기본 내비게이션 컨트롤러는 올바른 스 와이프 / 뒤로 제스처와 푸시 / 팝 애니메이션에 대한 올바른 애니메이션 타이밍을 제공합니다. 기본 내비게이션 바는 노치 아이폰을 쉽게 처리합니다. 기본 UIViewController에서 각 화면을 래핑하면 필요할 때 화면 수명주기에서 익숙한 위치를 제공합니다. (시스템 표준 탐색 모음을 모방하기 위해 열심히 노력한 라이브러리가 있지만 요구 사항을 충족하는 라이브러리는 찾지 못했습니다.)
2017 년에 실험을 시작했을 때 우리의 규칙은 앱이 여전히 네이티브를 "느껴야"한다는 것이었다. 확실히 불완전한 곳이 있지만, 우리가 만든 타협으로 인해 다른 많은 방법으로 앱을 크게 개선 할 수 있다고 확신합니다!
국제화 및 현지화
모바일 앱의 번역에는 콘텐츠와 플랫폼 문자열의 두 가지가 있습니다. 컨텐츠 문자열은 컨텐츠 관리 시스템에서 비롯됩니다. 예에는 대화 형 연습 문제, 비디오 내용 및 자막 또는 기사의 텍스트가 포함됩니다. (이러한 많은 콘텐츠 문자열은 앞에서 언급 한 "스트리밍 주제 트리"의 일부입니다.) 플랫폼 문자열은 모바일 앱의 코드베이스에 정의되어 있습니다. 예를 들어 '가입'버튼의 텍스트, 탭 바 항목의 제목 또는 설정 화면에 표시되는 텍스트가 있습니다.
플랫폼 문자열을 유지 관리하기위한 훌륭한 수제 인프라가 있습니다. JavaScript로 문자열을 정의하면 문자열을 기본 iOS 및 Android 문자열로 복사하는 스크립트를 작성했습니다. 이것은 매우 도움이되었습니다. 우리는 문제없이 네이티브와 리 액트 네이티브에서 문자열을 쉽게 재사용 할 수 있으며,이 "스 트래들 링"전환 기간에 크게 도움이되었습니다.
2015-2019 년부터 앱은 6 개의 로케일 만 지원했지만 이제는 19 세입니다! 공유 iOS 및 Android 구현은 스트리밍 주제 트리를 얻는 데 도움이되었으므로 추가 언어를 추가해도 앱 크기가 커지지 않습니다. 또한 라틴 이외의 문자를 쉽게 처리하는 React Native의 구성 요소를 설계 할 수있었습니다. Google 모바일 팀은 더 이상 모바일 앱의 범위를 확장하는 데 제약이 없습니다. 이는 특정 로케일로 번역 된 (대규모) 컨텐츠 라이브러리가 충분한 지 여부입니다. 이것은 우리의 국제 옹호자들에게 큰 사기 부양이었습니다. 전 세계 커뮤니티에 적합한 모바일 앱을 보유하게되어 매우 기쁩니다.
React Native 느낌
이 섹션은 좀 더 개인적인 의견이므로, 명심하십시오! 귀하의 마일리지가 다를 수 있습니다.
React Native 로의 전환은 완벽하게 장미 빛이 아니 었 습니다. 새로운 언어를 배우거나 새로운 구성 요소 수명주기 등과 같은 어려움이있었습니다. "걸음"기간은 특히 어려웠습니다. 네이티브 코드와 React Native 코드를 연결하는 데 지루한 상용구 코드가 많이있었습니다!
개인적으로, 특히 관련 값 열거 형, 편의 이니셜 라이저, 명명 된 매개 변수, 구조체 및 클래스에 함수 및 변수를 쉽게 추가 할 수있는 Swift에 대해 많은 정보가 누락 되었습니다.
그러나 React Native에는 많은 특전이 있습니다!
React Native는 UIKit보다 훨씬 가볍습니다 . 코드를 형성하고 리팩토링하는 것이 좋습니다. UICollectionView 용으로 작성하는 코드는 UITableView와는 다릅니다. 예를 들어 UIStackView와는 다릅니다. 그러나 React Native에서는 다소 걱정할 필요가 없습니다. 대부분의 경우 리팩토링 할 때 코드를 잘라서 붙여 넣을 수 있으며 그리드에서 목록으로 변경하는 것은 쉽지 않습니다. (이 특전과 SwiftUI의 특전 사이에는 많은 중복이 있습니다.)
개발자 툴링이 우수합니다. Xcode는 개발자로 등장한 곳이므로 그 단점을 알고 있지만 진정한 사랑은 이제 VSCode입니다. 확실히 배울 새로운 어휘 였지만, 저장을 누르면 코드를 자동 형식화하는 VSCode 플러그인이 있다는 사실은 확실합니까? 놀랄 만한! 우리의 코드 검토에는 실제로 많은 스타일 가이드 수정 프로그램이 필요하지 않은 많은 린터와 자동 수정 프로그램이 있습니다. 컴퓨터가 우리를 위해 서식을 지정하고 있으며 매우 유용 합니다.
Android 앱을 만들고 있으며 Android 앱을 작성하는 데 거의 능숙하지 않습니다. 추가 매개 변수 나 함수를 추가 할만큼 충분히 알고 있지만 Android의 건축가는 아닙니다. 그러나 훨씬 더 많은 Android 학습자에게 다가 가서 기능을 개발할 수 있습니다! 이것은 우리의 사명과 나의 개인적인 가치와 잘 일치하며, 여기에 참여할 수있어서 매우 기뻤습니다.
웹 프론트 엔드에 참여할 준비가 된 것 같습니다. 저는 모바일 개발자이지만 React Native에 익숙해 졌으므로 웹 응용 프로그램을 도와주는 데 많은 도움이되지 않았으며 모바일 팀의 상당 부분이 이미 그렇게하고 있습니다! 웹 개발을 시작하고 탐구하는 것이 좋습니다 (웹 엔지니어도 모바일 코드베이스에 기여하고 있습니다).
우리가 지금있는 곳
당사의 iOS 및 Android 앱은 플랫폼이 아닌 앱의 기능을 전문으로하는 엔지니어와 단일 코드베이스를 공유합니다. 즉, 시간이 지남에 따라 지정된 기능의 품질을 개선하는 데 도움이되며 초기 버전에서 모든 것을 가져와야한다는 느낌보다는 기능을 점진적으로 개선 할 수 있습니다.
공유 인프라 를 통해 GraphQL 로의 전환이 훨씬 쉬워졌으며, 이는 서버 측 전환을 Go로 단순화하는 것 입니다.
우리의 앱은 상당히 작습니다. 큰 번들 콘텐츠 라이브러리 데이터베이스에서 스트리밍 데이터베이스로 전환하면 앱 크기가 크게 줄었습니다. 그렇습니다.이 작업은 기본적으로 수행 할 수 있었지만이를 두 곳에서 조정하는 것보다 한 곳에서 구현하는 것이 더 쉬웠습니다.
우리는 웹 사이트와 훨씬 더 나은 댄스 파트너입니다. 이 전환 과정에서 모바일 디자인이 웹 사이트의 정보 디자인과 비슷해 지도록주의를 기울 였으므로 새로운 마스터리 챌린지 기능과 같은 새로운 크로스 플랫폼 기능을 쉽게 추가 할 수 있습니다. 엔지니어는 관심이있을 때 웹과 모바일간에 바운스 할 수있어 조직 전체에 더 친숙해집니다. Khan Academy에 관심이있는 프론트 엔드 엔지니어라면 모바일 앱과 웹 사이트에서 기능을 구축 할 수 있습니다.
우리는 여전히 앱에 네이티브 코드를 가지고 있으며, 훌륭합니다! 필요한 경우 Xcode 또는 Android Studio로 돌아와 iPad 멀티 태스킹과 같은 플랫폼 별 기능을 구현할 수 있습니다.
우리는있어 견고한 디자인 시스템 , 우리의 디자이너와 엔지니어가 신속하게 제품 개선을 조립하는 데 도움이됩니다. 모바일의 경우 터치 강조 표시, 접근성,로드 상태 등을 처리하는 표준 및 사전 구축 된 구성 요소를 갖는 등의 주요 방법으로 나타납니다.
무엇 향후 계획?
Khan Academy의 주요 엔지니어링 프로젝트는 Goliath 이며 백엔드를 Go 서비스 모음으로 다시 설계하고 있습니다. 우리의 통합 모바일 인프라는 이러한 전환에 도움을주었습니다. 모바일 팀이 6 명 이상이지만 여전히 새로운 기능과 수정 사항을 작성할 수 있습니다! 우리의 앱은 기능, 현지화, 품질 및 성능을 개선하고 확장 할 수있는 훨씬 더 나은 장소에 있습니다.
여기서 마무리하기 전 마지막주의 사항 : 완전 네이티브 앱도 훌륭하고 , 많은 사람들이 여전히 다른 프로젝트에서 앱 작업을 즐기는 것을 좋아합니다. (개인적으로, 내 마음은 여전히 Xcode에 속하며 Swift에서 생각하는 것을 정말로 좋아합니다!) 즉, React Native 로의 전환은 우리 팀에게 큰 도움이되었습니다. 그것은 모두를위한 하나의 진정한 선택은 아니지만, 우리를 위해 경이롭게 작용했습니다!
