> 웹 프론트엔드 > JS 튜토리얼 > 내 웹 개발 사고방식이 어떻게 React Native에서 나를 잘못된 길로 이끌었나요?

내 웹 개발 사고방식이 어떻게 React Native에서 나를 잘못된 길로 이끌었나요?

Mary-Kate Olsen
풀어 주다: 2024-12-18 15:37:18
원래의
833명이 탐색했습니다.

How my web development mindset led me astray in React Native

첫 번째 React Native 앱을 만들 때 웹 개발에 대한 사전 경험이 있었습니다. iOS와 Android용 React를 사용하는 것은 내 기술의 자연스러운 확장처럼 보였습니다.

하지만 웹 개발자의 사고방식이 항상 기본 앱 개발로 잘 전환되는 것은 아니라는 사실을 어렵게 깨달았습니다.

내비게이션을 예로 들어 보겠습니다. 웹에서 각 사이트는 일반적으로 고유한 페이지 레이아웃을 만듭니다. 머리글, 사이드바, 바닥글은 모두 맞춤 제작되었습니다. 간단한 요소로 시작할 수도 있지만 이는 단지 빈 캔버스일 뿐입니다. 기능적이고 시각적으로 매력적으로 만들려면 JavaScript와 CSS를 사용해야 합니다.

이러한 맞춤화는 브랜드 아이덴티티의 일부가 됩니다. 헤더가 다른 사이트의 헤더와 유사하다면 일반적인 것으로 느껴집니다.

네이티브 앱 개발로 전환했을 때도 같은 마음가짐을 갖고 있었습니다.

저는 모든 것에 대한 맞춤형 구성 요소를 꼼꼼하게 디자인했습니다. 뒤로 버튼과 제목을 사용하여 나만의 헤더를 만들었습니다. 사용자 정의 화면 전환과 애니메이션을 만들었습니다. 안전 영역을 직접 관리하고 화면 방향을 추적하여 전환을 애니메이션화하기도 했습니다. 나는 맞춤형 하단 탭을 만들었습니다. 내 앱이 다른 사람의 앱과 닮지 않도록 하기 위한 모든 것입니다.

실수라는 사실을 깨닫는 데는 그리 오랜 시간이 걸리지 않았습니다.

기본 앱 사용자는 앱 전체에서 일관된 패턴을 기대합니다. 또한 탐색과 같은 기본 UI 요소의 품질에 대한 기대도 높습니다. 예를 들어 iOS에서 사용자는 여러 화면을 뒤로 이동하려면 뒤로 버튼을 길게 누르기를 기대합니다. 이것이 없으면 경험이 불완전하다고 느껴집니다.

그렇다면 왜 바퀴를 재발명해야 할까요? 기본 구성 요소는 이미 플랫폼에 최적화되어 있습니다. 처음부터 사용자 정의 헤더를 만드는 대신 기본 헤더를 사용하고 색상을 조정할 수도 있었습니다. 더 좋은 점은 사용자 정의를 완전히 건너뛰고 UIKit 구성 요소를 직접 사용할 수 있다는 것입니다. 사용자는 '기본'이라는 느낌과는 거리가 멀고, 앱이 iOS 생태계에 얼마나 자연스럽게 어울리는지 높이 평가했을 것입니다.

Reddit용 Apollo와 같은 앱의 성공을 경험해 보세요. 사람들은 iOS의 기본 디자인 언어를 수용하여 플랫폼의 자연스러운 확장처럼 느껴지기 때문에 좋아했습니다.

이는 웹 개발과 뚜렷한 대조를 이룹니다. 웹에서는 빈 캔버스로 시작하여 모든 것을 직접 구축합니다. 즉시 사용 가능한 기본 요소는 투박하고 매력적이지 않은 경우가 많습니다. 버튼은 회색입니다. 입력의 윤곽이 가혹합니다. 일관된 기준을 얻으려면 CSS 재설정이 필요할 수도 있습니다.

이러한 불만을 완화하기 위해 웹 UI 라이브러리가 존재하지만 이는 패치워크 솔루션입니다. 이에 비해 iOS와 같은 기본 플랫폼에는 응집력 있고 아름답게 제작된 디자인 기본 요소가 함께 제공됩니다. 탐색, 애니메이션, 메뉴, 타이포그래피, 색상 및 아이콘은 모두 전문가가 세심하게 디자인하여 원활한 사용자 경험을 제공합니다. 이는 단순한 도구가 아니라 수십 년간의 개선을 통해 형성된 디자인 시스템입니다.

이것을 감상하는 데 너무 오랜 시간이 걸렸습니다. 처음에는 Apple의 휴먼 인터페이스 가이드라인을 읽어보지도 않았습니다.

2019년에는 React Native 앱이 네이티브 앱을 고품질로 모방한 것처럼 느껴질 때가 많았습니다. 그들은 그 부분을 보았지만 그것을 잘 느끼지 못했습니다. React Native의 철학은 항상 기본 플랫폼과 일치하는 것이었지만 실제로는 많은 라이브러리가 실제를 사용하는 대신 네이티브 구성 요소를 모방한 JavaScript 기반 구성 요소에 의존했습니다.

예를 들어 Android의 React Native 앱은 Material Design 헤더를 자주 사용했지만 실제 네이티브 헤더 구성 요소를 활용하지 않고 JavaScript로 구현되었습니다.

웹 개발자로서 저는 이 추상화가 매력적이라고 ​​생각했습니다. 이를 통해 사용자 정의를 완벽하게 제어할 수 있었습니다. 그러나 이러한 접근 방식은 종종 사용자 경험을 저하시키는 미묘한 불일치로 이어졌습니다.

React Native 개발자에게만 책임이 있는 것은 아닙니다. 당시에는 네이티브 코드로 작업하는 것이 번거로웠으며 특히 Expo를 사용하는 경우에는 더욱 그렇습니다. 기본 기능을 추가하려면 Expo를 포기하고 전체 스택을 재구성해야 하는 경우가 많았습니다. 네이티브 코드가 포함된 라이브러리는 React Native 업데이트와 동기화되지 않는 경우가 많아 개발자는 완전히 이해하지 못하는 Objective-C 또는 Java 파일과 씨름해야 합니다.

'JS 기반'은 라이브러리의 판매 포인트가 되었으며 개발자에게 기본 종속성을 처리할 필요가 없다고 약속했습니다.

JavaScript와 네이티브 코드의 구분은 웹 우선 사고방식을 강화했습니다. 왜 모든 일에 JavaScript를 사용하지 않나요?

다행히 React Native 생태계가 발전했습니다. 오늘날에는 훨씬 적은 구성으로 Swift 및 Kotlin을 사용하여 기본 모듈을 작성할 수 있습니다. 더 좋은 점은 Expo가 이제 네이티브 코드를 지원한다는 것입니다. 이러한 개선으로 인해 네이티브 우선 개발의 접근성이 높아졌으며 라이브러리가 네이티브 기본 요소를 수용하도록 장려되었습니다.

예를 들어 React Navigation은 기본 구성 요소를 사용하는 방향으로 전환하여 광범위한 개발자 맞춤 설정보다 원활한 사용자 경험을 우선시했습니다.

이러한 변화는 React Native의 더 밝은 미래를 의미합니다. 기본 도구를 사용하기가 더 쉬워짐에 따라 해당 플랫폼에 속하는 것처럼 보이고 느껴지는 앱을 구축할 수 있습니다.

그러니 내 실수로부터 배우세요. 플랫폼의 도구를 사용하고 디자인 철학을 수용하세요. 그리고 무엇보다도 규칙을 깨기로 결정하기 전에 규칙을 숙지하세요.

위 내용은 내 웹 개발 사고방식이 어떻게 React Native에서 나를 잘못된 길로 이끌었나요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

원천:dev.to
본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
저자별 최신 기사
인기 튜토리얼
더>
최신 다운로드
더>
웹 효과
웹사이트 소스 코드
웹사이트 자료
프론트엔드 템플릿