수백 명의 기여자가 수개월간 열심히 노력한 끝에, React Native 코어 팀은 버전 0.60 출시를 발표하게 되어 기쁘게 생각한다. 이번 릴리스는 Android와 iOS 플랫폼 모두에서 중요한 마이그레이션을 처리하며, 많은 문제도 해결했다. 이 블로그 포스트는 이번 릴리스의 주요 내용을 다룬다. 항상 그렇듯, 더 자세한 정보는 변경 로그를 참고하기 바란다. 마지막으로, 이번 이정표를 달성하는 데 도움을 준 모든 기여자에게 감사한다!

접근성에 초점을 맞추기​

접근성 API에는 announceForAccessibility와 같은 다양한 개선 사항이 추가되었다. 또한 역할(roles), 액션 지원(action support), 플래그(flags) 등 여러 부분에서 개선이 이루어졌다. 접근성은 복잡한 분야이지만, 이러한 개선 사항이 A11Y를 조금 더 쉽게 만들어 줄 것으로 기대한다. 자세한 내용은 2019년 6월 React Native 오픈소스 업데이트를 참고하면 된다.

새로운 시작​

React Native의 시작 화면이 업데이트됐다! 새로운 UI를 만드는 데 도움을 준 많은 기여자들에게 감사한다. 이 새로운 "Hello World" 화면은 사용자를 더 친근하고 매력적인 방식으로 생태계에 맞이한다.

AndroidX 지원​

AndroidX는 안드로이드 생태계에서 중요한 발전을 이루었다. 기존의 지원 라이브러리 아티팩트는 더 이상 사용되지 않는다. React Native 0.60 버전부터는 AndroidX로 마이그레이션되었다. 이는 주요 변경 사항이며, 여러분의 네이티브 코드와 의존성도 마이그레이션해야 한다.

이 변경으로 인해 React Native 앱은 AndroidX를 사용해야 한다. 한 앱에서 둘을 동시에 사용할 수 없으므로, 앱 코드와 의존성 코드 모두 AndroidX 또는 기존 지원 라이브러리 중 하나를 사용해야 한다.

matt-oakes on discussions-and-proposals

여러분의 네이티브 코드는 직접 마이그레이션해야 하지만, @mikehardy, @cawfree, 그리고 @m4tt72가 node_modules를 패치할 수 있는 똑똑한 도구 "jetifier"를 만들었다. 라이브러리 관리자들은 업그레이드해야 하지만, 이 도구는 임시 해결책을 제공하며 AndroidX 버전을 출시할 시간을 벌어준다. 따라서 AndroidX 마이그레이션과 관련된 오류가 발생하면 이 도구를 사용해 보자.

기본 CocoaPods 설정​

이제 CocoaPods가 React Native iOS 프로젝트의 일부로 포함되었다. 이전에 사용하지 않았다면, 앞으로 iOS 플랫폼 코드를 열 때 xcworkspace 파일을 사용해야 한다. (팁: 루트 프로젝트 디렉토리에서 xed ios를 실행해 보자.) 또한, 내부 패키지의 podspec이 Xcode 프로젝트와 호환되도록 변경되었다. 이는 문제 해결과 디버깅에 도움이 될 것이다. 0.60 버전으로 업그레이드하면서 몇 가지 간단한 변경을 Podfile에 적용해야 한다. use_frameworks!와 관련된 호환성 문제가 있음을 알고 있으며, 이를 해결하기 위한 이슈를 추적 중이다.

Lean Core 제거 작업​

WebView와 NetInfo는 이전에 별도의 저장소로 분리되었으며, React Native 0.60에서는 이들을 React Native 저장소에서 완전히 이관했다. 또한, 새로운 App Store 정책에 대한 커뮤니티 피드백을 반영해 Geolocation도 분리했다. 아직 마이그레이션을 완료하지 않았다면 react-native-webview, @react-native-community/netinfo, @react-native-community/geolocation에 의존성을 추가해 작업을 완료해야 한다. 자동화된 솔루션을 원한다면 rn-upgrade-deprecated-modules를 사용해 볼 수 있다. 분리 이후 이 저장소들에는 100개 이상의 커밋이 이루어졌으며, 커뮤니티의 지속적인 지원이 기대된다!

네이티브 모듈 자동 연결 기능 추가​

React Native CLI 팀은 네이티브 모듈 연결 방식을 크게 개선한 자동 연결(autolinking) 기능을 도입했다. 이제 대부분의 경우 react-native link 명령어를 사용할 필요가 없다. 동시에 팀은 일반적인 연결 프로세스도 전면 개편했다. 위 문서에서 언급한 대로 기존에 연결된 의존성은 react-native unlink로 해제해야 한다.

업그레이드 헬퍼​

@lucasbento, @pvinis, @kelset, 그리고 @watadarkstar가 Upgrade Helper라는 훌륭한 도구를 개발했다. 이 도구는 업그레이드 과정을 더 간단하게 만들어준다. React Native 사용자가 브라운필드 앱이나 복잡한 커스텀 설정을 가진 경우, 버전 간 변경 사항을 쉽게 확인할 수 있도록 도와준다. 업그레이드 문서를 확인하고, 오늘 바로 여러분의 업그레이드 경로에 이 도구를 활용해보자!

라이브러리 관리자를 위한 주의사항​

AndroidX로의 변경은 거의 대부분 라이브러리 업데이트를 필요로 한다. 따라서 가능한 한 빨리 지원을 추가해야 한다. 아직 업그레이드할 준비가 되지 않았다면, 사용자가 빌드 시 라이브러리를 패치할 수 있는지 확인하기 위해 jetifier를 사용해 라이브러리를 점검해 보는 것이 좋다.

설정과 README를 업데이트하려면 autolinking 문서를 검토한다. 라이브러리가 이전에 어떻게 통합되었는지에 따라 추가 변경이 필요할 수도 있다. 의존성 인터페이스를 정의하는 방법에 대한 정보는 CLI의 dependencies 가이드를 참고한다.

감사합니다​

이번에 소개한 내용은 주요 업데이트 중 일부에 불과합니다. 더 많은 변화를 확인하려면 변경 로그를 살펴보세요. 앞으로도 더 많은 소식에 주목해 주시기 바랍니다. 그동안 0.60 버전을 즐겨보세요!

코드와 커뮤니티 건강​

지난 6개월 동안 550명 이상의 기여자가 React Native에 총 2800개의 커밋을 작성했다. 커뮤니티에서 400명의 기여자가 1,150개의 Pull Request를 생성했으며, 이 중 820개의 Pull Request가 병합되었다.

Lean Core 작업을 통해 웹사이트, CLI, 그리고 여러 모듈을 React Native에서 분리했음에도 불구하고, 지난 6개월 동안 하루 평균 Pull Request 수는 3개에서 약 6개로 증가했다. 현재 평균 오픈 Pull Request 수는 25개 미만이며, 대부분 몇 시간에서 며칠 내에 피드백과 리뷰를 제공한다.

의미 있는 커뮤니티 기여​

최근 커뮤니티에서 이루어진 몇 가지 멋진 기여를 소개한다:

• 접근성: React Native 0.60은 안드로이드와 iOS 모두에서 접근성 API를 크게 개선한 버전이다. 새로운 기능들은 모두 기본 플랫폼에서 제공하는 API를 직접 사용하므로, 안드로이드와 iOS의 네이티브 접근성 기술과 완벽하게 통합된다. Marc Mulcahy, Alan Kenyon, Estevão Lucas, Sam Mathias Weggersen, 그리고 Janic Duplessis의 기여에 감사한다:
  • 추가 접근성 역할 및 상태와 새로운 접근성 상태 API. 다양한 컴포넌트에 누락된 접근성 역할을 추가하고, 향후 웹 지원을 위한 새로운 API를 도입했다.
  • AccessibilityInfo.announceForAccessibility. 이전에는 iOS에서만 지원되던 기능을 안드로이드에서도 사용할 수 있게 했다.
  • 확장된 접근성 액션 지원. 사용자 정의 액션과 관련된 접근성을 처리하기 위한 콜백을 추가했다.
  • iOS 접근성 플래그 지원과 "모션 감소" 지원.
  • 안드로이드 키보드 접근성 개선. clickable 프로퍼티와 키보드 네비게이션을 통해 액션을 호출할 수 있는 onClick 콜백을 추가했다 (참고: 이 기능은 곧 focusable로 이름이 변경될 예정).
  • CALayers를 사용해 텍스트 그리기. iOS에서 텍스트가 확대되었을 때 사라지는 문제를 해결했다.
• 새 앱 화면: 커뮤니티가 새 앱 화면 디자인을 제안했고, 이는 0.60 버전에 구현되었다. 이 화면은 React Native를 처음 사용하는 대부분의 사용자에게 보여진다. 이제 초보 사용자는 문서로 바로 연결되며, 디자인도 곧 출시될 웹사이트 리디자인과 일치한다 🌟. Orta, Adam Shurson, Glauber Castro, Karan Singh, Eli Perkins, Lucas Bento, 그리고 Eric Lewis의 노력과 협업에 큰 감사를 표한다!
  • 새로운 앱 화면은 "React Native Show" 비디오 시리즈에서 확인할 수 있다.
• TurboModule 타입: 새로운 TurboModules 시스템은 네이티브에서 타입 안전한 작업을 보장하기 위해 모든 네이티브 모듈의 타입을 요구한다. 단 2주 만에 커뮤니티는 약 40개의 풀 리퀘스트를 보내 이 작업을 완료했다. 앞서 언급한 사람들 외에도 Michał Chudziak, Michał Pierzchała, Wojtek Szafraniec, 그리고 Jean Regisser와 여러 풀 리퀘스트를 보낸 모든 분들에게 감사한다.
• Haste: React Native는 2015년부터 “haste” 모듈 시스템을 사용해왔다. 이 시스템은 상대 경로 대신 전역 ID로 모듈을 가져올 수 있어 편리하지만, 많은 도구에서 잘 지원되지 않는다. James Ide는 React가 몇 년 전에 haste를 제거한 것과 유사하게 haste를 제거하는 것을 제안했다. 그는 umbrella task를 통해 모든 작업을 계획했고, 이를 구현하기 위해 18개의 풀 리퀘스트를 보냈다! 그의 트위터 스레드에서 더 자세한 내용을 확인할 수 있다.
• 안드로이드 프래그먼트: John Shelley가 제안한 안드로이드 프래그먼트를 통해 React Native를 작동하게 하는 아이디어가 합쳐졌고, 이는 0.61 버전에서 사용할 수 있다. 안드로이드 프래그먼트에 대해 더 알아보기.

Lean Core​

Lean Core의 주요 목표는 React Native의 모듈을 별도의 저장소로 분리하여 더 나은 유지보수를 가능하게 하는 것이다. 단 6개월 만에 WebView, NetInfo, AsyncStorage, 웹사이트, 그리고 CLI와 같은 저장소에서 총 800개 이상의 Pull Request가 처리되었다. 더 나은 유지보수 외에도, 이러한 프로젝트들은 React Native 자체보다 더 자주 독립적으로 릴리스될 수 있다.

또한, React Native 자체에서 더 이상 필요하지 않은 폴리필과 레거시 컴포넌트를 제거할 기회를 활용했다. 과거에는 JavaScriptCore(JSC)의 구버전에서 Map과 Set과 같은 언어 기능을 지원하기 위해 폴리필이 필요했다. 이제 React Native가 새로운 버전의 JSC를 포함하므로, 이러한 폴리필을 제거했다.

이 작업은 아직 진행 중이며, 네이티브와 JavaScript 양쪽에서 더 많은 요소를 분리하거나 제거해야 한다. 하지만 초기 징후로는, 점점 커지는 표면적과 앱 크기의 증가 추세를 뒤집는 데 성공한 것으로 보인다. 예를 들어, JavaScript 번들 크기를 살펴보면, 약 1년 전 버전 0.54에서 React Native의 JavaScript 번들 크기는 530kb였고, 6개월 만에 버전 0.57에서 607kb(+77kb)로 증가했다. 이제는 master 브랜치에서 번들 크기가 28kb 감소한 579kb로, 100kb 이상의 차이를 보이고 있다.

Lean Core 작업의 첫 번째 반복을 마무리하면서, React Native에 추가되는 새로운 API에 대해 더 신중하게 접근할 것이다. 또한, React Native를 더 작고 빠르게 만드는 방법을 지속적으로 평가하고, 커뮤니티가 다양한 컴포넌트의 소유권을 가질 수 있도록 지원할 방법을 모색할 것이다.

사용자 피드백​

6개월 전 커뮤니티에 "React Native에서 불편한 점은 무엇인가요?"라는 질문을 던졌다. 이를 통해 사람들이 겪고 있는 문제를 종합적으로 파악할 수 있었다. 몇 달 전에 해당 게시물에 답변을 남겼고, 이제 주요 이슈에 대한 진행 상황을 요약할 때가 되었다:

• 업그레이드: React Native 커뮤니티는 업그레이드 경험을 개선하기 위해 여러 노력을 기울였다. autolinking과 rn-diff-purge를 통한 더 나은 업그레이드 커맨드, 곧 출시될 업그레이드 헬퍼 웹사이트 등이 대표적이다. 또한 각 주요 릴리스마다 블로그 포스트를 발행해 주요 변경 사항과 새로운 기능을 알릴 예정이다. 이러한 개선 사항들은 0.60 릴리스 이후의 업그레이드를 훨씬 쉽게 만들어 줄 것이다.

• 지원 / 불확실성: Pull Request에 대한 활동 부족과 Facebook의 React Native 투자에 대한 불확실성으로 많은 사람들이 불만을 표시했다. 앞서 보여준 것처럼, 이제 더 많은 Pull Request를 받을 준비가 되어 있으며 여러분의 제안과 기여를 기대하고 있다.

• 성능: React Native 0.59는 더 빠른 버전의 JavaScriptCore(JSC)를 포함해 출시되었다. 또한 기본적으로 inline-requires를 쉽게 활성화할 수 있도록 개선했으며, 다음 몇 달 동안 더 흥미로운 업데이트를 준비 중이다.

• 문서: 최근 React Native 문서 전체를 개편하고 재작성하는 작업을 시작했다. 기여하고 싶다면 여러분의 도움을 기대한다.

• Xcode 경고: 기존의 모든 경고를 제거했으며, 새로운 경고가 발생하지 않도록 노력하고 있다.

• 핫 리로딩: React 팀이 새로운 핫 리로딩 시스템을 개발 중이며, 곧 React Native에 통합될 예정이다.

아쉽게도 아직 모든 부분을 개선하지는 못했다:

• 디버깅: 매일 발생하는 불편한 버그와 이슈를 많이 수정했지만, 디버깅 부분에서는 기대만큼 진전을 이루지 못했다. React Native의 디버깅 경험이 아직 부족하다는 점을 인지하고 있으며, 향후 이를 개선하는 데 우선순위를 둘 예정이다.

• Metro 심볼릭 링크: 아직 간단하고 직관적인 해결책을 제공하지 못했다. 하지만 React Native 사용자들이 다양한 임시 해결책을 공유했으니 참고하면 도움이 될 것이다.

지난 6개월 동안 많은 변화가 있었기 때문에, 같은 질문을 다시 던져보고자 한다. 최신 버전의 React Native를 사용 중이고 피드백을 남기고 싶다면, “React Native에서 불편한 점은 무엇인가요?”의 새 버전에 의견을 남겨주길 바란다.

지속적 통합​

페이스북은 모든 Pull Request와 내부 변경 사항을 먼저 페이스북의 저장소에 병합한 다음 모든 커밋을 GitHub로 동기화한다. 페이스북의 인프라는 일반적인 지속적 통합 서비스와 다르며, 모든 오픈소스 테스트가 페이스북 내부에서 실행되지는 않는다. 이 때문에 GitHub로 동기화된 커밋이 자주 오픈소스 테스트를 깨뜨리며, 이를 수정하는 데 많은 시간이 소요된다.

React Native 팀의 Héctor Ramos는 지난 두 달 동안 페이스북과 GitHub에서 React Native의 지속적 통합 시스템을 개선하는 데 집중했다. 이제 대부분의 오픈소스 테스트는 페이스북에서 React Native에 변경 사항을 커밋하기 전에 실행된다. 이로 인해 커밋이 동기화될 때 GitHub에서 CI가 안정적으로 유지될 것이다.

다음 소식​

React Native의 미래에 대한 이야기를 놓치지 마세요! 앞으로 몇 달 동안 Facebook의 React Native 팀 멤버들이 Chain React와 React Native EU에서 발표할 예정입니다. 또한, 곧 출시될 0.60 버전도 기대해 주세요. 정말 흥미로울 거예요 ✨

이번 주, Eli White가 F8 2019에서 페이스북의 안드로이드와 iOS 앱에서의 React Native에 대해 발표했다. 지난 2년간 진행한 작업과 앞으로의 계획을 공유하게 되어 기쁘게 생각한다.

페이스북 개발자 웹사이트에서 영상을 확인해 보자:

발표 내용 요약:​

• 2017년과 2018년에는 React Native로 개발된 가장 큰 제품인 Facebook의 Marketplace에 집중했다. Marketplace 팀과 협력해 제품의 품질을 개선하고 사용자 경험을 더욱 즐겁게 만들었다. 현재 Marketplace는 Facebook 앱 내에서 Android와 iOS 모두에서 가장 높은 품질을 자랑하는 제품 중 하나다.
• Marketplace의 성능은 특히 중급 Android 기기에서 큰 도전이었다. 지난 한 해 동안 시작 시간을 50% 이상 단축했고, 더 많은 개선이 진행 중이다. 가장 큰 개선 사항들은 React Native에 통합되어 올해 후반에 커뮤니티에 공개될 예정이다.
• React Native를 통해 Facebook이 필요로 하는 고품질의 고성능 앱을 구축할 수 있다는 확신을 얻었다. 이 확신은 React Native의 핵심을 재구성하는 것과 같은 더 큰 도전에 투자할 수 있게 해주었다.
• Microsoft는 React Native for Windows를 지원하고 사용하며, 개발자들이 자신의 전문 지식과 코드베이스를 활용해 Microsoft의 Universal Windows Platform에 렌더링할 수 있도록 한다. 다음 주에 열리는 Microsoft Build에서 이에 대해 더 자세히 들을 수 있다.

오픈소스에 관한 React Radio 팟캐스트​

Eli의 발표는 최근 진행한 오픈소스 작업에 대한 이야기로 마무리된다. 우리는 3월에 진행 상황을 업데이트했고, 최근 Nader Dabit과 Gant Laborde가 Christoph를 초대해 그들의 팟캐스트 React Native Radio에서 React Native와 오픈소스에 대해 이야기를 나눴다.

팟캐스트 하이라이트:​

• 페이스북의 React Native 팀이 오픈소스를 어떻게 바라보는지, 그리고 React Native와 같은 규모의 프로젝트를 위한 지속 가능한 커뮤니티를 어떻게 구축하고 있는지 이야기했다.
• Lean Core 프로젝트의 일환으로 여러 모듈을 제거하는 작업을 진행 중이다. WebView와 React Native CLI와 같은 모듈은 분리된 이후 100개 이상의 Pull Request를 받았다.
• 다음으로는 React Native 웹사이트와 문서를 전면 개편하는 데 집중할 예정이다. 계속 지켜봐 주세요!

이번 에피소드는 곧 여러분이 즐겨 사용하는 팟캐스트 앱에서 확인할 수 있다. 또는 아래에서 바로 녹음본을 들을 수 있다:

React Native 0.59 버전을 소개합니다. 이번 릴리스는 88명의 기여자가 참여해 총 644개의 커밋으로 이루어진 대규모 업데이트입니다. 또한, 이슈 관리, 커뮤니티 활성화, 그리고 React Native를 가르치는 등 다양한 형태의 기여도 이루어졌습니다. 여러분의 노력에 감사드립니다. 이번 달에는 많은 사람들이 기다려온 여러 변경 사항이 포함되어 있습니다. 즐겁게 사용해 주시기 바랍니다.

🎣 훅스가 도입되었다​

이번 릴리스에는 컴포넌트 간에 상태 로직을 재사용할 수 있는 React 훅스가 포함되었다. 훅스에 대한 관심이 뜨겁지만 아직 잘 모르는 독자를 위해 몇 가지 유용한 자료를 소개한다:

• 훅스 소개는 훅스를 React에 추가한 이유를 설명한다.
• 훅스 개요는 내장 훅스에 대한 빠른 개요를 제공한다.
• 커스텀 훅스 만들기는 커스텀 훅스를 통해 코드를 재사용하는 방법을 보여준다.
• React 훅스 이해하기는 훅스가 열어준 새로운 가능성을 탐구한다.
• useHooks.com는 커뮤니티에서 관리하는 훅스 레시피와 데모를 소개한다.

여러분의 앱에서 훅스를 직접 사용해 보길 권한다. 우리가 경험한 것처럼 훅스의 재사용성이 흥미롭게 느껴질 것이다.

📱 업데이트된 JSC로 인한 성능 향상과 안드로이드 64비트 지원​

React Native는 여러분의 애플리케이션을 구동하기 위해 JSC(JavaScriptCore)를 사용한다. 안드로이드의 JSC는 몇 년 전 버전이어서 많은 모던 자바스크립트 기능을 지원하지 못했다. 더 나쁜 점은 iOS의 최신 JSC에 비해 성능이 떨어졌다는 것이다. 이번 릴리즈로 이러한 문제가 모두 해결되었다.

@DanielZlotin, @dulmandakh, @gengjiawen, @kmagiera, 그리고 @kudo의 멋진 작업 덕분에 JSC가 몇 년 간의 격차를 따라잡았다. 이로 인해 64비트 지원, 모던 자바스크립트 지원, 그리고 큰 성능 향상이 이루어졌다. 또한, 이제는 유지보수가 가능한 프로세스로 만들어 향후 WebKit 개선 사항을 별도의 노력 없이 활용할 수 있게 해준 점도 칭찬할 만하다. 이 작업을 가능하게 해준 Software Mansion과 Expo에게도 감사드린다.

💨 인라인 리퀘어를 통해 더 빠른 앱 실행​

React Native 앱이 기본적으로 뛰어난 성능을 발휘할 수 있도록 돕고자, Facebook의 최적화 기술을 커뮤니티에 제공하려고 한다. 이 기능은 '인라인 리퀘어'라고 불리며, Metro가 지연 로딩할 컴포넌트를 식별할 수 있게 한다. 이로 인해 앱이 필요한 리소스를 필요할 때 로드하므로, 앱 실행 속도가 느려지는 문제를 해결한다. 특히 컴포넌트 구조가 복잡하고 다양한 앱에서 가장 큰 성능 향상을 기대할 수 있다.

이 기능을 기본적으로 활성화하기 전에, 커뮤니티의 피드백이 필요하다. 0.59 버전으로 업그레이드하면 새로운 metro.config.js 파일이 생성된다. 여기서 옵션을 true로 설정하고 피드백을 보내주길 바란다. 앱의 성능을 측정하고 싶다면 성능 문서에서 인라인 리퀘어에 대해 자세히 알아볼 수 있다.

🚅 Lean Core 진행 중​

React Native는 크고 복잡한 프로젝트로, 리포지토리 구조가 복잡하다. 이로 인해 코드베이스는 기여자들이 접근하기 어렵고, 테스트가 힘들며, 개발 의존성으로서 불필요하게 비대해졌다. Lean Core는 이러한 문제를 해결하기 위해 코드를 별도의 라이브러리로 이전해 더 나은 관리를 목표로 하는 노력이다. 지난 몇 차례 릴리스에서 첫 단계를 진행했지만, 이제 본격적으로 시작할 때다.

여러분은 추가 컴포넌트들이 공식적으로 더 이상 사용되지 않는다는 것을 눈치챌 수 있을 것이다. 이는 좋은 소식이다. 이제 해당 기능을 적극적으로 유지보수하는 소유자가 생겼기 때문이다. 경고 메시지를 주의 깊게 확인하고, 새로운 라이브러리로 마이그레이션하라. 이 기능들은 향후 릴리스에서 제거될 예정이다. 아래 표는 컴포넌트, 현재 상태, 그리고 마이그레이션할 수 있는 새로운 위치를 나타낸다.

앞으로 몇 달 동안 더 많은 컴포넌트가 이 경로를 따라 더 가벼운 코어로 이동할 것이다. 우리는 이 작업에 도움을 필요로 한다. Lean Core umbrella로 가서 기여를 시작해 보라.

👩🏽‍💻 CLI 개선 사항​

React Native의 커맨드라인 도구는 개발자가 이 생태계에 접근하는 첫 관문이다. 하지만 오랫동안 문제점이 지적되어 왔고 공식적인 지원도 부족했다. 이제 CLI 도구는 새로운 저장소로 이전되었으며, 전담 관리자 그룹이 몇 가지 흥미로운 개선 작업을 진행했다.

로그 형식이 훨씬 더 깔끔해졌다. 또한 명령어 실행 속도가 거의 즉각적으로 빨라졌다. 체감할 수 있을 정도의 차이가 있다:

🚀 0.59 버전으로 업그레이드​

여러분의 React Native 업그레이드 프로세스에 대한 피드백을 듣고, 향후 릴리스에서 경험을 개선하기 위해 조치를 취하고 있다. 0.59 버전으로 업그레이드하려면 rn-diff-purge를 사용해 현재 React Native 버전과 0.59 버전 사이의 변경 사항을 확인한 후, 수동으로 변경 사항을 적용하는 것을 추천한다. 프로젝트를 0.59 버전으로 업그레이드한 후에는 새롭게 개선된 react-native upgrade 명령어(이 명령어는 rn-diff-purge를 기반으로 한다!)를 사용해 0.60 버전 이상으로 업그레이드할 수 있다.

🔨 주요 변경 사항​

0.59 버전에서 Android 지원은 Google의 최신 권장 사항에 맞춰 정리되었다. 이로 인해 기존 앱에서 문제가 발생할 수 있다. 런타임 크래시와 함께 "이 액티비티에는 Theme.AppCompat 테마(또는 이를 상속한 테마)를 사용해야 합니다"라는 메시지가 표시될 수 있다. 프로젝트의 AndroidManifest.xml 파일을 업데이트하고, android:theme 값이 AppCompat 테마(예: @style/Theme.AppCompat.Light.NoActionBar)인지 확인하는 것을 권장한다.

0.59 버전에서는 react-native-git-upgrade 명령어가 제거되었고, 새롭게 개선된 react-native upgrade 명령어로 대체되었다.

🙏 감사합니다​

많은 새로운 기여자들이 플로우 타입에서 네이티브 코드 생성 활성화와 Xcode 경고 해결에 도움을 주셨습니다. 이러한 작업은 React Native가 어떻게 동작하는지 배우고 더 큰 선을 위해 기여할 수 있는 훌륭한 방법입니다. 감사합니다! 앞으로도 비슷한 이슈들을 기대해 주세요.

이번에 주목할 만한 주요 변경 사항들 외에도, 흥미로운 업데이트들이 많이 있습니다. 모든 업데이트를 확인하려면 변경 로그를 살펴보세요. 0.59 버전은 대규모 릴리스입니다. 여러분이 직접 사용해 보시길 기대합니다.

올해 남은 기간 동안 더 많은 개선 사항들이 예정되어 있습니다. 계속 지켜봐 주세요!

Ryan과 React Native 코어 팀

2018년 4분기에 우리는 React Native 오픈소스 커뮤니티에 더 많은 투자를 하기로 결정한 후 React Native 오픈소스 로드맵을 발표했다.

첫 번째 목표로 우리는 커뮤니티에서 가장 눈에 띄는 부분을 파악하고 개선하는 데 집중했다. 주요 목표는 미처리된 풀 리퀘스트를 줄이고, 프로젝트의 범위를 축소하며, 주요 사용자 문제를 식별하고, 커뮤니티 관리 가이드라인을 마련하는 것이었다.

지난 두 달 동안 우리는 예상보다 더 많은 진전을 이루었다. 자세한 내용은 아래에서 확인할 수 있다:

풀 리퀘스트 관리​

건강한 커뮤니티를 구축하려면 코드 기여에 신속하게 대응해야 한다. 지난 몇 년간 커뮤니티 기여 리뷰를 우선순위에서 밀려나게 하며 280개의 풀 리퀘스트가 누적되었다(2018년 12월 기준). 첫 번째 마일스톤에서 열려 있던 풀 리퀘스트 수를 약 65개로 줄였다. 동시에 하루 평균 풀 리퀘스트 개수는 3.5개에서 7개로 증가했으며, 이는 지난 3개월 동안 약 600개의 풀 리퀘스트를 처리했음을 의미한다.

풀 리퀘스트 중 약 3분의 2는 병합했고, 나머지 3분의 1은 닫았다. 병합하지 않고 닫은 경우는 오래되었거나 품질이 낮았거나, 프로젝트의 범위를 불필요하게 확장시키는 경우였다. 병합된 풀 리퀘스트 대부분은 버그 수정, 크로스 플랫폼 일관성 개선, 새로운 기능 도입과 관련이 있었다. 주목할 만한 기여로는 타입 안전성 개선과 AndroidX 지원 작업이 있다.

Facebook에서는 마스터 브랜치에서 React Native를 실행하므로, 모든 변경 사항을 React Native 릴리스에 반영하기 전에 먼저 테스트한다. 병합된 풀 리퀘스트 중 문제를 일으킨 것은 6개뿐이었다. 이 중 4개는 내부 개발에만 영향을 미쳤고, 2개는 릴리스 후보 단계에서 발견되었다.

커뮤니티 기여 중 눈에 띄는 예로는 업데이트된 “RedBox” 화면이 있다. 이는 커뮤니티가 개발자 경험을 더 친화적으로 만드는 좋은 사례다.

핵심 기능 최적화​

현재 React Native는 매우 넓은 기능 범위를 가지고 있으며, Facebook에서 자주 사용하지 않는 여러 유지보수되지 않은 추상화들이 포함되어 있다. 우리는 React Native를 더 작고 가볍게 만들기 위해 기능 범위를 줄이고, Facebook에서 주로 사용되지 않는 추상화들을 커뮤니티가 더 잘 관리할 수 있도록 작업 중이다.

첫 번째 단계로, Lean Core 프로젝트에 대해 커뮤니티에 도움을 요청했다. 응답은 압도적이었고, 모든 진행 상황을 따라가기 어려울 정도였다. 한 달도 채 되지 않은 기간 동안 완료된 작업을 확인해 보라!

가장 기쁜 점은 유지보수 담당자들이 오랫동안 해결되지 않은 문제들을 수정하고, 테스트를 추가하며, 오랫동안 요청받던 기능을 지원하기 위해 적극적으로 참여했다는 것이다. 이러한 모듈들은 React Native 내에서보다 더 많은 지원을 받고 있으며, 이는 커뮤니티에게 큰 도약임을 보여준다. 예를 들어, WebView는 많은 풀 리퀘스트를 받았고, CLI는 이제 커뮤니티 멤버들에 의해 유지보수되며 필요한 개선과 수정을 받았다.

주요 사용자 문제​

12월에 커뮤니티에 React Native에 대해 불만스러운 점을 물었다. 응답을 모아 각 문제에 대해 답변을 달았다. 다행히 커뮤니티가 겪는 많은 문제는 Facebook에서도 마찬가지로 발생하는 문제다. 다음 마일스톤에서 주요 문제 중 일부를 해결할 계획이다.

가장 많은 표를 받은 문제 중 하나는 React Native의 최신 버전으로 업그레이드할 때의 개발자 경험이었다. 불행히도 이 문제는 우리가 master 브랜치에서 React Native를 실행하기 때문에 직접 경험하지는 않는다. 다행히 커뮤니티 멤버들이 이 문제를 해결하기 위해 나섰다:

• Callstack의 Michał Pierzchała는 rn-diff-purge를 사용해 react-native upgrade를 개선했다. 또한 웹사이트에서 오래된 업그레이드 지침을 제거하기 위해 업데이트했다.
• iOS 프로젝트에서 기본적으로 CocoaPods를 권장할 계획이다. 이렇게 하면 React Native를 업그레이드할 때 프로젝트 파일의 변경을 줄일 수 있다. 또한 Lean Core의 맥락에서 더 많은 모듈을 기본적으로 연결할 것으로 예상되기 때문에, 서드파티 모듈을 설치하고 연결하는 것이 더 쉬워질 것이다.

0.59 릴리스​

React Native 커뮤니티, 특히 Mike Grabowski와 Lorenzo Sciandra의 도움 없이는 이번 릴리스를 진행할 수 없었다. 우리는 릴리스 관리 프로세스를 개선하고 앞으로 더 적극적으로 참여할 계획이다:

• 주요 릴리스마다 커뮤니티 멤버들과 함께 블로그 포스트를 작성할 것이다.
• 사용자가 새 버전으로 업그레이드할 때 CLI에서 주요 변경 사항을 직접 보여줄 것이다.
• 릴리스에 걸리는 시간을 줄일 것이다. 자동화된 테스트를 늘리고 개선된 수동 테스트 계획을 마련하는 방법을 모색 중이다.

이러한 계획 중 상당 부분이 곧 출시될 React Native 0.59 릴리스에 반영될 것이다. 0.59 버전은 React Hooks, Android용 64비트 JavaScriptCore 버전, 그리고 다양한 성능 및 기능 개선 사항을 포함한다. 현재 릴리스 후보로 출시되었으며, 다음 2주 안에 안정화될 예정이다.

다음 단계​

앞으로 두 달 동안 우리는 진행 상황을 유지하면서 풀 리퀘스트를 계속 관리할 것이다. 동시에 미해결된 GitHub 이슈의 수를 줄이기 시작할 것이다. Lean Core 프로젝트를 통해 React Native의 범위를 계속 축소할 계획이다. 우리는 커뮤니티에서 가장 중요한 문제 5가지를 해결할 것이다. 커뮤니티 가이드라인을 마무리하면서 웹사이트와 문서 작업에 집중할 예정이다.

3월에는 Facebook 런던 사무소에서 커뮤니티 기여자 10명 이상을 초청해 여러 작업을 함께 진행할 예정이다. 여러분이 React Native를 사용하고 있다는 사실에 기쁘게 생각하며, 2019년에 우리가 진행 중인 개선 사항을 직접 확인하고 느낄 수 있기를 바란다. 몇 달 후에 또 다른 업데이트로 찾아뵙겠다. 그동안 여러분의 풀 리퀘스트를 병합할 예정이다! ⚛️✌️

2018년 React Native 커뮤니티는 React Native 개발 및 커뮤니케이션 방식을 여러 가지로 개선했다. 몇 년 후 이 변화가 React Native의 전환점이었다고 회상할 것이라 믿는다.

많은 사람들이 React Native 아키텍처의 재작성, 즉 Fabric에 대해 기대하고 있다. 이는 React Native 아키텍처의 근본적인 한계를 해결하고, JSI와 TurboModules과 함께 React Native의 미래를 성공적으로 이끌어갈 것이다.

2018년의 가장 큰 변화는 React Native 커뮤니티의 역량 강화였다. 처음부터 Facebook은 전 세계 개발자들이 React Native 오픈소스 프로젝트에 참여하도록 장려했다. 이후 릴리스 프로세스 등을 담당하는 핵심 기여자들이 등장했다.

이 멤버들은 커뮤니티 전체가 프로젝트의 미래를 결정할 수 있도록 다음과 같은 리소스를 통해 상당한 진전을 이루었다:

react-native-releases 📬​

이 저장소는 1월에 만들어져 두 가지 주요 목적을 가지고 있다. 첫째, 모든 사람이 새로운 릴리즈를 더 협력적으로 따라갈 수 있게 하고, 둘째, 특정 릴리즈에 어떤 내용이 포함될지 논의할 수 있는 공간을 제공한다. 누구나 체리 픽을 제안할 수 있도록 열려 있다(예: 0.57.8 및 이전 버전들).

이러한 접근 방식은 월간 릴리즈 주기에서 벗어나게 하는 원동력이 되었으며, 현재 0.57.x 버전에 적용된 "장기 지원" 방식의 기반이 되었다.

이러한 결정에 이르게 된 데에는 올해 생성된 다른 저장소도 큰 역할을 했다.

discussions-and-proposals 🗣​

이 저장소는 7월에 만들어졌으며, React Native에 대한 논의를 더 개방적인 환경에서 진행하기 위한 아이디어를 확장했다. 이전에는 메인 저장소에서 For Discussion 라벨이 붙은 이슈로 이 필요를 처리했지만, 다른 라이브러리(예: React)에서 사용하는 RFC 접근 방식으로 이 전략을 확장하고자 했다.

이 실험은 즉시 React Native 생명주기에서 역할을 찾았다. Facebook 팀은 이제 커뮤니티 RFC 프로세스를 사용해 React Native에서 개선할 수 있는 부분을 논의하고, Lean Core 프로젝트를 중심으로 노력을 조율하며, 그 외에도 흥미로운 토론을 진행하고 있다.

@ReactNativeComm 🐣​

React Native 커뮤니티의 다양한 활동(릴리스부터 활발한 토론까지)을 더 쉽게 따라갈 수 있도록, 우리는 새로운 트위터 계정 @ReactNativeComm을 만들었다. 이전에는 이러한 소식을 전달하는 방식이 우리가 원하는 만큼 효과적이지 않았음을 인지하고 있다.

해당 소셜 네트워크를 사용하지 않더라도, GitHub를 통해 저장소를 구독할 수 있다. 지난 몇 달간 이 기능이 개선되어 릴리스 알림만 받을 수 있게 되었으므로, 이를 활용하는 것도 좋은 방법이다.

앞으로 기대할 점 🎓​

지난 7-8개월 동안 핵심 기여자들은 React Native Community GitHub 조직의 개발 주도권을 더 많이 확보하고, 페이스북과의 협업을 강화하기 위해 노력했다. 하지만 이 조직은 다른 유사 프로젝트들이 갖추고 있는 공식적인 구조가 부족했다.

이 조직은 여기에 호스팅된 모든 패키지와 저장소에 일련의 표준을 적용함으로써 더 큰 개발자 커뮤니티에 본보기가 될 수 있다. 또한, 관리자들이 서로 도우며 커뮤니티에서 합의한 표준에 부합하는 고품질 코드를 기여할 수 있는 단일 장소를 제공할 수 있다.

2019년 초, 우리는 이 새로운 가이드라인을 적용할 예정이다. 여러분의 의견을 전용 토론에서 공유해 주길 바란다.

우리는 이러한 변화를 통해 커뮤니티가 더 협력적이 될 것이라고 확신한다. 그리고 1.0 버전에 도달했을 때, 우리 모두가 이 공동의 노력을 통해 (더욱) 훌륭한 앱을 계속 작성할 수 있을 것이다 🤗

우리처럼 이 커뮤니티의 미래에 대해 기대가 크길 바란다. 위에 나열된 저장소에서 진행 중인 토론에 참여하거나, 여러분이 만들어낼 멋진 코드를 통해 모두가 함께하는 모습을 보게 되어 기쁘다.

즐거운 코딩 되길 바란다!

올해 React Native 팀은 React Native의 대규모 재구조화에 집중했다. Sophie가 State of React Native 글에서 언급했듯, Facebook 외부에서 활발히 활동하는 React Native 사용자와 기여자들을 더 잘 지원하기 위한 계획을 구체화했다. 이제 우리가 진행해 온 작업에 대해 더 자세히 공유할 때다. 그 전에, React Native의 오픈소스에 대한 장기적인 비전을 먼저 설명하고자 한다.

React Native에 대한 우리의 비전은 다음과 같다:

• 건강한 GitHub 저장소. 이슈와 풀 리퀘스트가 적절한 시간 내에 처리된다.
  • 테스트 커버리지가 증가한다.
  • Facebook 코드 저장소에서 동기화된 커밋이 오픈소스 테스트를 깨뜨리지 않는다.
  • 의미 있는 커뮤니티 기여가 더 큰 규모로 이루어진다.
• 안정적인 API, 오픈소스 의존성과의 인터페이스를 더 쉽게 만든다.
  • Facebook이 오픈소스와 동일한 공개 API를 사용한다.
  • React Native 릴리즈가 시맨틱 버저닝을 따른다.
• 활기찬 생태계. 커뮤니티가 관리하는 고품질 ViewManagers, 네이티브 모듈, 그리고 다중 플랫폼 지원.
• 탁월한 문서. 사용자가 고품질 경험을 만들 수 있도록 돕고, 최신 API 참조 문서를 제공한다.

이 비전을 달성하기 위해 다음과 같은 주요 영역에 집중할 계획이다.

✂️ 코어 경량화​

React Native의 표면적을 줄이는 것이 우리의 목표다. 이를 위해 핵심이 아니거나 사용되지 않는 컴포넌트를 제거할 예정이다. 핵심이 아닌 컴포넌트는 커뮤니티로 이관하여 더 빠르게 발전할 수 있도록 할 것이다. 표면적이 줄어들면 React Native에 기여하는 것이 더 쉬워질 것이다.

WebView는 커뮤니티로 이관한 컴포넌트의 대표적인 예이다. 리포지토리에서 제거한 후에도 내부 팀이 이러한 컴포넌트를 계속 사용할 수 있도록 하는 워크플로우를 구축 중이다. 우리는 수십 개의 추가 컴포넌트를 식별했으며, 이들에 대한 소유권을 커뮤니티에 넘길 예정이다.

🎁 내부 도구 오픈소스화와 🛠 도구 업데이트​

페이스북 내부 제품 팀의 React Native 개발 경험은 오픈소스 커뮤니티와 상당히 다를 수 있다. 오픈소스 커뮤니티에서 인기 있는 도구들이 페이스북 내부에서는 사용되지 않을 수 있다. 동일한 목적을 달성하는 내부 도구가 존재할 수도 있다. 어떤 경우에는 페이스북 팀들이 페이스북 외부에서는 존재하지 않는 도구들에 익숙해져 있다. 이러한 차이점들은 우리가 앞으로 공개할 아키텍처 작업을 오픈소스로 공개할 때 어려움을 초래할 수 있다.

우리는 이러한 내부 도구 중 일부를 공개하는 작업을 진행할 것이다. 또한 오픈소스 커뮤니티에서 인기 있는 도구들에 대한 지원을 강화할 것이다. 다음은 우리가 다룰 프로젝트들의 일부 목록이다:

• JSI를 오픈소스로 공개하고 커뮤니티가 자체 JavaScript VM을 가져올 수 있도록 지원한다. 이를 통해 RN 초기 릴리스부터 사용되던 JavaScriptCore를 대체할 수 있다. JSI가 무엇인지에 대해서는 향후 포스트에서 다룰 예정이며, 그 동안 Parashuram의 React Conf 발표에서 JSI에 대해 더 알아볼 수 있다.
• 안드로이드에서 64비트 라이브러리를 지원한다.
• 새로운 아키텍처 하에서 디버깅을 가능하게 한다.
• CocoaPods, Gradle, Maven, 그리고 새로운 Xcode 빌드 시스템에 대한 지원을 개선한다.

✅ 테스트 인프라 구축​

페이스북 엔지니어는 코드를 배포할 때 모든 테스트를 통과하면 안전하다고 판단한다. 이러한 테스트는 변경 사항이 자체 React Native 환경을 손상시킬 가능성이 있는지 확인한다. 그러나 페이스북이 React Native를 사용하는 방식에는 차이가 있다. 이로 인해 우리는 오픈소스에서 React Native를 의도치 않게 손상시킬 수 있었다.

우리는 내부 테스트를 강화해 오픈소스 환경과 최대한 유사한 환경에서 실행되도록 할 것이다. 이를 통해 테스트를 통과하지 못한 코드가 오픈소스에 유출되는 것을 방지할 수 있다. 또한 GitHub에서 코어 리포지토리를 더 효과적으로 테스트할 수 있는 인프라를 구축할 것이다. 이를 통해 향후 풀 리퀘스트에 테스트를 쉽게 포함시킬 수 있게 된다.

이러한 노력은 감소된 표면적과 결합되어 기여자들이 더 빠르고 자신 있게 풀 리퀘스트를 병합할 수 있게 한다.

📜 공개 API​

페이스북은 오픈소스와 동일한 방식으로 공개 API를 통해 React Native를 사용할 예정이다. 이는 의도치 않은 호환성 문제를 줄이기 위함이다. 이를 위해 내부 호출 사이트를 변환하는 작업을 시작했다. 목표는 안정적인 공개 API를 확립하고, 이를 통해 1.0 버전에서 시맨틱 버저닝을 도입하는 것이다.

📣 커뮤니케이션​

React Native는 GitHub에서 기여자 수 기준 상위 오픈소스 프로젝트 중 하나이다. 이는 우리에게 큰 기쁨을 주며, 이러한 성과를 계속 이어가고자 한다. 투명성 증대와 열린 토론과 같은 기여자 참여를 유도하는 이니셔티브를 지속적으로 진행할 계획이다. React Native를 처음 접하는 사람들이 가장 먼저 마주하게 되는 문서는 지금까지 우선순위에서 밀려 있었다. 이를 해결하기 위해 자동 생성 API 참조 문서를 다시 도입하고, 사용자 경험 개선에 초점을 맞춘 추가 콘텐츠를 제작하며, 릴리스 노트를 개선할 예정이다.

타임라인​

앞으로 약 1년 동안 이 프로젝트들을 단계적으로 진행할 계획이다. 이미 진행 중인 작업도 있다. 예를 들어 JSI는 오픈소스에 이미 반영되었다. 반면, 표면적 감소와 같은 작업은 완료까지 시간이 더 걸릴 것이다. 커뮤니티에 진행 상황을 최대한 공유하도록 노력할 것이다. Discussions and Proposals 저장소에 참여해 주길 바란다. 이 저장소는 React Native 커뮤니티가 주도하는 이니셔티브로, 이 로드맵에서 논의된 여러 작업의 시작점이 되었다.

오랜 시간 동안 애플은 UIWebView 대신 WKWebView 사용을 권장해왔다. 앞으로 몇 달 안에 출시될 iOS 12에서는 UIWebView가 공식적으로 지원 중단될 예정이다. 리액트 네이티브의 iOS WebView 구현은 UIWebView 클래스에 크게 의존하고 있다. 이러한 변화를 고려하여, 리액트 네이티브의 WebView 컴포넌트를 WKWebView 기반으로 재구성한 새로운 네이티브 iOS 백엔드를 개발했다.

이 변경 사항의 마지막 부분은 이 커밋에 반영되었으며, 0.57 릴리스에서 사용할 수 있다.

이 새로운 구현을 사용하려면 useWebKit prop을 사용한다:

<WebView
  useWebKit={true}
  source={{url: 'https://www.google.com'}}
/>

개선 사항​

UIWebView는 웹뷰에서 실행되는 자바스크립트와 React Native 간의 통신을 정상적으로 지원하지 않았다. 웹뷰에서 메시지를 보낼 때, 우리는 이를 React Native로 전달하기 위해 해킹적인 방법에 의존해야 했다. 간단히 말해, 메시지 데이터를 특수한 스키마가 포함된 URL로 인코딩한 후, 웹뷰를 해당 URL로 이동시켰다. 네이티브 측에서는 이 네비게이션을 가로채고 취소한 후, URL에서 데이터를 파싱하여 최종적으로 React Native를 호출했다. 이 구현 방식은 오류가 발생하기 쉽고 보안상 취약점이 있었다. 이제 우리는 WKWebView의 기능을 활용해 이를 완전히 대체했으며, 이 소식을 기쁘게 전한다.

WKWebView가 UIWebView에 비해 갖는 다른 장점으로는 더 빠른 자바스크립트 실행 속도와 멀티 프로세스 아키텍처가 있다. 자세한 내용은 2014 WWDC를 참고한다.

주의 사항​

컴포넌트에서 아래와 같은 props를 사용한다면, WKWebView로 전환할 때 문제가 발생할 수 있다. 당분간은 이 props들을 사용하지 않는 것을 권장한다.

일관되지 않은 동작:

automaticallyAdjustContentInsets와 contentInsets (커밋)

WKWebView에 contentInsets를 추가해도 WKWebView의 뷰포트는 변경되지 않는다. 뷰포트는 프레임과 동일한 크기를 유지한다. 반면 UIWebView에서는 뷰포트 크기가 실제로 변경된다(만약 contentInsets가 양수라면 더 작아진다).

backgroundColor (커밋)

새로운 iOS WebView 구현체를 사용하면, 이 속성을 사용할 때 배경색이 깜빡이며 나타날 가능성이 있다. 또한 WKWebView는 투명한 배경을 UIWebview와 다르게 렌더링한다. 자세한 내용은 커밋 설명을 참고한다.

지원되지 않는 기능:

scalesPageToFit (커밋)

WKWebView는 scalesPageToFit prop을 지원하지 않기 때문에, React Native의 WebView 컴포넌트에서 이 기능을 구현할 수 없었다.

동기​

기술이 발전하고 모바일 앱이 일상생활에서 점점 더 중요해짐에 따라, 접근성 있는 애플리케이션을 만드는 필요성도 그만큼 커졌다.

React Native의 제한된 접근성 API는 개발자들에게 항상 큰 고민거리였다. 그래서 우리는 더 포괄적인 모바일 애플리케이션을 쉽게 만들 수 있도록 접근성 API를 몇 가지 업데이트했다.

기존 API의 문제점​

문제 1: 완전히 다르지만 유사한 두 가지 props - accessibilityComponentType (Android)와 accessibilityTraits (iOS)​

accessibilityComponentType와 accessibilityTraits는 각각 Android의 TalkBack과 iOS의 VoiceOver에게 사용자가 상호작용하는 UI 엘리먼트의 종류를 알려주는 프로퍼티이다. 이 두 프로퍼티의 가장 큰 문제점은 다음과 같다:

1. 두 프로퍼티는 사용 방법이 다르지만 동일한 목적을 가지고 있다. 기존 API에서는 두 프로퍼티가 플랫폼별로 분리되어 있어 불편할 뿐만 아니라 많은 개발자에게 혼란을 주었다. iOS의 accessibilityTraits는 17가지 값을 지원하는 반면, Android의 accessibilityComponentType는 단 4가지 값만 허용한다. 또한, 두 프로퍼티의 값은 대부분 겹치지 않는다. 심지어 입력 타입도 다르다. accessibilityTraits는 트레이트 배열이나 단일 트레이트를 전달할 수 있지만, accessibilityComponentType는 단일 값만 허용한다.
2. Android의 기능이 매우 제한적이다. 기존 프로퍼티를 사용할 때 TalkBack이 인식할 수 있는 UI 엘리먼트는 "button", "radiobutton_checked", "radiobutton_unchecked" 뿐이었다.

문제 2: 접근성 힌트 부재​

접근성 힌트는 TalkBack이나 VoiceOver를 사용하는 사용자가 접근성 엘리먼트에 액션을 수행할 때 어떤 일이 일어날지 이해하는 데 도움을 준다. 이러한 힌트는 설정 패널에서 켜거나 끌 수 있다. 이전에는 React Native의 API가 접근성 힌트를 전혀 지원하지 않았다.

문제 3: 반전 색상 무시하기​

시각 장애를 가진 일부 사용자는 화면 대비를 높이기 위해 휴대폰에서 색상을 반전시켜 사용한다. 애플은 iOS에서 특정 뷰를 무시할 수 있는 API를 제공한다. 이를 통해 사용자가 반전 색상 설정을 켜도 이미지와 비디오가 왜곡되지 않는다. 그러나 이 API는 현재 React Native에서 지원되지 않는다.

새로운 API 설계​

첫 번째 해결책: accessibilityComponentType (안드로이드)와 accessibilityTraits (iOS) 통합​

accessibilityComponentType와 accessibilityTraits 사이의 혼란을 해결하기 위해, 두 속성을 단일 속성으로 통합하기로 결정했다. 이는 두 속성이 기술적으로 동일한 기능을 목표로 했기 때문에 합리적이었다. 이를 통해 개발자는 접근성 기능을 구현할 때 플랫폼별 세부 사항을 고민할 필요가 없어졌다.

배경

iOS에서는 UIAccessibilityTraits를 모든 NSObject에 설정할 수 있는 속성이다. 자바스크립트 속성을 통해 전달된 17개의 트레이트는 Objective-C의 UIAccessibilityTraits 요소로 매핑된다. 각 트레이트는 long int로 표현되며, 설정된 모든 트레이트는 OR 연산으로 결합된다.

반면 안드로이드에서 AccessibilityComponentType는 React Native에서 만든 개념으로, 안드로이드의 속성과 직접적으로 매핑되지 않는다. 접근성은 접근성 델리게이트를 통해 처리된다. 각 뷰는 기본 접근성 델리게이트를 가지고 있다. 접근성 액션을 커스텀하려면 새로운 접근성 델리게이트를 생성하고, 커스텀하려는 특정 메서드를 오버라이드한 후, 해당 뷰의 접근성 델리게이트를 새 델리게이트로 설정해야 한다. 개발자가 AccessibilityComponentType를 설정하면, 네이티브 코드는 전달된 컴포넌트를 기반으로 새로운 델리게이트를 생성하고, 뷰에 해당 접근성 델리게이트를 설정한다.

변경 사항

새로운 속성을 위해 두 속성의 상위 집합을 만들기로 했다. 기존 속성인 accessibilityTraits를 주로 모델로 삼기로 결정했는데, 이는 accessibilityTraits가 훨씬 더 많은 값을 가지고 있기 때문이다. 안드로이드에서 이 트레이트의 기능은 접근성 델리게이트를 수정함으로써 폴리필로 구현된다.

accessibilityTraits는 iOS에서 설정할 수 있는 17개의 UIAccessibilityTraits 값을 가지고 있다. 하지만 이 중 일부는 새로운 속성에 포함하지 않았다. 이는 일부 트레이트를 설정했을 때의 효과가 잘 알려져 있지 않고, 많은 값이 실제로 거의 사용되지 않기 때문이다.

UIAccessibilityTraits 값은 일반적으로 두 가지 목적 중 하나를 가진다. UI 엘리먼트의 역할을 설명하거나, UI 엘리먼트의 상태를 설명한다. 우리가 관찰한 이전 속성의 사용 사례 대부분은 일반적으로 하나의 역할을 나타내는 값을 사용하고, 이를 "state selected", "state disabled" 또는 둘 다와 결합했다. 따라서 두 개의 새로운 접근성 속성을 만들기로 결정했다: accessibilityRole과 accessibilityState.

accessibilityRole

새로운 속성인 accessibilityRole은 Talkback이나 Voiceover에 UI 엘리먼트의 역할을 알려준다. 이 속성은 다음 값 중 하나를 가질 수 있다:

• none
• button
• link
• search
• image
• keyboardkey
• text
• adjustable
• header
• summary
• imagebutton

이 속성은 하나의 값만 전달할 수 있다. 일반적으로 UI 엘리먼트는 논리적으로 이 중 하나 이상의 역할을 가지지 않기 때문이다. 예외는 이미지와 버튼이므로, 두 가지를 결합한 imagebutton 역할을 추가했다.

accessibilityStates

새로운 속성인 accessibilityStates는 Talkback이나 Voiceover에 UI 엘리먼트의 상태를 알려준다. 이 속성은 다음 값 중 하나 또는 둘 다를 포함하는 배열을 가진다:

• selected
• disabled

두 번째 해결책: 접근성 힌트 추가​

이를 위해 accessibilityHint라는 새로운 속성을 추가했다. 이 속성을 설정하면 Talkback이나 Voiceover가 사용자에게 힌트를 읽어준다.

accessibilityHint

이 속성은 String 형태로 읽을 접근성 힌트를 받는다.

iOS에서는 이 속성을 설정하면 뷰의 해당 네이티브 속성인 AccessibilityHint가 설정된다. 이후 iPhone에서 접근성 힌트가 켜져 있으면 Voiceover가 이 힌트를 읽는다.

Android에서는 이 속성을 설정하면 힌트 값이 접근성 라벨 끝에 추가된다. 이 구현의 장점은 iOS의 힌트 동작을 모방한다는 점이지만, 단점은 iOS처럼 설정에서 이 힌트를 끌 수 없다는 것이다.

Android에서 이렇게 결정한 이유는 일반적으로 접근성 힌트가 특정 동작(예: 클릭)에 해당하기 때문이며, 플랫폼 간 동작을 일관되게 유지하고 싶었다.

문제 3의 해결책​

accessibilityIgnoresInvertColors

애플의 AccessibilityIgnoresInvertColors API를 자바스크립트로 노출했다. 이제 색상 반전을 원하지 않는 뷰(예: 이미지)에서 이 속성을 true로 설정하면 색상이 반전되지 않는다.

새로운 사용법​

이 새로운 속성들은 React Native 0.57 버전부터 사용할 수 있다.

업그레이드 방법​

현재 accessibilityComponentType와 accessibilityTraits를 사용하고 있다면, 새로운 속성으로 업그레이드하는 방법을 단계별로 안내한다.

1. jscodeshift 사용하기​

가장 간단한 사용 사례는 jscodeshift 스크립트를 실행하여 해결할 수 있다.

이 스크립트는 다음 인스턴스를 대체한다:

accessibilityTraits=“trait”
accessibilityTraits={[“trait”]}

다음과 같이 변경한다:

accessibilityRole= “trait”

또한 이 스크립트는 AccessibilityComponentType 인스턴스를 제거한다. (AccessibilityComponentType을 설정한 모든 곳에서 AccessibilityTraits도 함께 설정했다고 가정한다.)

2. 수동 코드 변환 사용하기​

AccessibilityTraits를 사용했지만 AccessibilityRole에 해당하는 값이 없는 경우, 그리고 AccessibilityTraits에 여러 특성이 전달된 경우에는 수동으로 코드를 변환해야 한다.

일반적으로,

accessibilityTraits= {["button", "selected"]}

위 코드를 아래와 같이 수동으로 교체한다.

accessibilityRole="button"
accessibilityStates={["selected"]}

이러한 속성들은 이미 Facebook 코드베이스에서 사용되고 있다. Facebook의 코드 변환은 놀랍도록 간단했다. jscodeshift 스크립트가 약 절반의 인스턴스를 수정했고, 나머지 절반은 수동으로 수정했다. 전체 과정은 몇 시간도 걸리지 않았다.

업데이트된 API가 유용하게 쓰이길 바란다! 그리고 계속해서 앱을 접근 가능하게 만들길 바란다! #포용성

오랜 기다림 끝에 React Native 0.56 버전이 드디어 출시되었다 🎉. 이 블로그 포스트는 이번 새 버전에서 소개된 주요 변경 사항을 요약한다. 또한 지난 3월 이후로 무엇을 준비해 왔는지 설명할 기회를 갖고자 한다.

호환성 문제의 딜레마, 또는 "언제 릴리스할 것인가?"​

기여자 가이드는 React Native에 적용되는 모든 변경 사항이 거치는 통합 과정을 설명한다. 이 프로젝트는 다양한 도구들로 구성되어 있어, 모든 기능이 정상적으로 작동하도록 조율과 지속적인 지원이 필요하다. 여기에 프로젝트에 기여하는 활발한 오픈소스 커뮤니티까지 더하면, 그 규모가 얼마나 방대한지 짐작할 수 있다.

React Native의 높은 채택률을 고려할 때, 호환성을 깨는 변경 사항은 신중하게 처리해야 하며, 이 과정은 항상 원활하지는 않다. 코어 팀이 새로운 호환성 변경 사항을 통합하고 테스트할 시간을 확보하기 위해 4월과 5월 릴리스를 건너뛰기로 결정했다. 이 과정에서 전용 커뮤니티 커뮤니케이션 채널을 활용해 2018년 6월(0.56.0) 릴리스를 최대한 문제 없이 적용할 수 있도록 노력했다.

0.56.0이 완벽한가? 그렇지 않다. 모든 소프트웨어가 그렇듯 완벽하지는 않다. 하지만 "더 많은 안정성을 기다리는 것"과 "테스트 결과가 성공적이므로 진행할 수 있다" 사이의 균형점에 도달했고, 이제 릴리스할 준비가 되었다고 판단했다. 또한, 최종 0.56.0 릴리스에서 해결되지 않은 몇 가지 문제들 이 존재한다는 점도 알고 있다. 대부분의 개발자는 0.56.0으로 업그레이드하는 데 문제가 없을 것이다. 앞서 언급한 문제로 차단된 개발자들의 경우, 토론에 참여해 함께 해결책을 모색하기를 기대한다.

0.56.0을 더 안정적인 프레임워크를 위한 기본 구성 요소로 생각할 수 있다. 모든 예외 사항이 해결되기까지는 아마도 1~2주 정도의 광범위한 적용이 필요하겠지만, 이는 2018년 7월(0.57.0) 릴리스를 더욱 향상시킬 것이다.

이 섹션을 마무리하며, 총 818개의 커밋에 기여한 67명의 기여자들에게 감사의 인사를 전한다. 그들의 노력이 여러분의 앱을 더 나은 방향으로 이끌 것이다 👏.

그럼 이제, 더 이상 미루지 않고...

주요 변경 사항​

Babel 7​

여러분도 아시다시피, 최신 자바스크립트 기능을 사용할 수 있게 해주는 트랜스파일러 도구인 Babel이 곧 v7 버전으로 업그레이드된다. 이번 새 버전은 몇 가지 중요한 변화를 가져오기 때문에, Metro가 이러한 개선 사항을 활용할 수 있도록 지금이 업그레이드하기에 적절한 시기라고 판단했다.

업그레이드 과정에서 문제가 발생한다면, 관련 문서 섹션을 참고하길 바란다.

Android 지원 현대화​

Android 환경에서 주변 도구들이 크게 변화했다. Gradle 3.5, Android SDK 26, Fresco 1.9.0, 그리고 OkHttp 3.10.0으로 업데이트했으며, 심지어 NDK API 타겟을 API 16로 조정했다. 이러한 변경 사항은 문제 없이 적용되며 더 빠른 빌드 속도를 제공할 것이다. 더 중요한 점은, 개발자들이 다음 달부터 시행될 새로운 Play Store 요구사항을 준수하는 데 도움이 될 것이다.

이와 관련하여, Dulmandakh에게 많은 PR을 제출해 준 것에 대해 특별히 감사드린다 👏.

이 방향으로 더 나아가기 위해 필요한 몇 가지 단계가 있으며, Android 지원 업데이트에 대한 미래 계획과 논의는 전용 이슈에서 확인할 수 있다. 또한 JSC에 대한 별도의 이슈도 참고할 수 있다.

새로운 Node, Xcode, React, Flow 소식​

이제 React Native의 표준은 Node 8이다. 사실 Node 8은 이미 테스트 중이었지만, Node 6이 유지보수 모드로 전환되면서 본격적으로 채택했다. React도 16.4로 업데이트되었으며, 이번 버전에는 많은 수정 사항이 포함되어 있다.

iOS 8 지원을 중단하고, 이제 iOS 9가 지원 가능한 가장 오래된 버전이 되었다. iOS 8을 실행할 수 있는 기기는 모두 iOS 9로 업그레이드가 가능하므로 이 변경이 문제가 되지 않을 것으로 예상한다. 이로 인해 iOS 8을 실행하는 구형 기기를 위한 우회 코드를 제거할 수 있었다.

지속적 통합(CI) 도구 체인도 Xcode 9.4를 사용하도록 업데이트했다. 이제 모든 iOS 테스트가 애플의 최신 개발 도구에서 실행된다.

Flow 0.75로 업그레이드하여 많은 개발자들이 선호하는 새로운 오류 형식을 사용할 수 있게 되었다. 또한 더 많은 컴포넌트에 대한 타입을 추가했다. 아직 프로젝트에서 정적 타입 검사를 적용하지 않았다면, 런타임이 아닌 코딩 중에 문제를 발견하기 위해 Flow 사용을 고려해 보길 바란다.

그리고 다른 여러 가지...​

예를 들어, YellowBox는 디버깅을 훨씬 더 개선한 새로운 구현체로 교체되었다.

전체 릴리스 노트는 여기에서 확인할 수 있다. 또한 이 새로운 버전으로 업그레이드할 때 문제를 피하려면 업그레이드 가이드를 꼭 참고하길 바란다.

마지막으로, 이번 주부터 React Native 코어 팀이 월간 회의를 다시 시작할 예정이다. 회의에서 다룬 내용을 모두가 알 수 있도록 최신 정보를 제공할 것이며, 여러분의 피드백을 다음 회의에 반영할 수 있도록 노력할 것이다.

모두 즐거운 코딩하길 바란다!

Lorenzo, Ryan, 그리고 React Native 코어 팀 모두

추가: 항상 그렇듯, React Native는 아직 0.x 버전으로 많은 변화가 진행 중임을 상기시킨다. 따라서 업그레이드할 때 무언가가 여전히 충돌하거나 고장날 가능성이 있다는 점을 기억하길 바란다. 이슈나 PR을 제출할 때 서로 도움을 주고받으며, CoC를 준수하길 바란다. 화면 너머에는 항상 사람이 있다는 것을 잊지 말자.