DEVOCEAN

안녕하세요 Teus입니다.

올해 DEVOCEAN을 통해서 스터디를 진행했습니다.

제가 준비한 주제는 React를 활용해서 크로스플랫폼을 플랫폼 어플리캐이션을 만드는 React Native입니다!

이번주는 12주차, 마지막주에 진행한 스터디 내용을 다루는 포스팅 입니다!

0. 스터디 운영

스터디시간에 다들 다음주는 뭐할지 궁금해하던 마지막 아이스브레이킹 입니다.

이번시간에는 LJia님께서 준비해주신 마피아게임으로, 마지막 아이스브레이킹을 진행 했습니다.

(룰을 설명하고 진행해주시는 Jia님)

(잡았다 요놈)

아쉬운 마지막 아이스브레이킹을 뒤로하고, 이번주에 배운 내용을 살펴봅니다.

이번주역시 React이외에 라이브러리를 사용해서 React Native App을 보다 효율적으로 활용하는 방법에 대해서 다룹니다.

App의 전역 상태관리를 할 수 있는 Recoil에 대해서 알아보도록 하겠습니다

1. Recoil

Recoil의 경우 atom이라고 하는 method를 통해서 createstate와 비슷한 동작을, useRecoilState를 통해서 useState와 비슷한 인터페이스를 제공합니다.

보시면 알겠지만 Recoil은 React Hook과 굉장히 유사한 사용경험을 가지고 있습니다.

import {atom, useRecoilState} from 'recoil';
const counterState = atom({
    key : 'counterState',
    default : 0
})

const Counter = () => {
    const [counter, setCounter] = useRecoilState(counterState)
}

Recoil을 다른 컴포넌트에서 접근시키기 위해서는 RecoilRoot를 사용합니다.

이 패턴 역시 ContextAPI 혹은 Redux와 유사한 것을 볼 수가 있습니다.

import {RecoilRoot} from 'recoil';
const App() => {
    return (
        <RecoilRoot>
            <myApp/>
        </RecoilRoot>
    )
}

이때 전역 State는 하나의 값이 아니라, 여러값을 관리하겠죠?

이때 Recoil같은 경우 다수의값을 을 선택적으로 접근하게 할 수 있는 selector 라고하는 method를 제공합니다.

import {atome, selector, useRecoilState} from 'recoil';
const myInfoState = atom({
    key : "myinfoStete",
    default : {
        id : 1,
        username : "john",
        diaplayName : "Jony",
        isActive : true
    }
})

const isActiveState = selector({
    key : "isActiveState",
    get : ({get}) => get(myInfoState).isActive,
    set : ({set}, newValue) => {
        set((myinfoState, prevState) => {
            return {...prevState, isActive : newValue}
        }
    }
})

const myComp = () => {
    const [isActive, setIsActive] = useRecoilState(isActiveState)
}

Redux와 유사하지만, 보시는것처럼 좀더 편리한 인터페이스를 제공하는 것을 볼 수 있습니다.

하지만 이미 Context API의 UX 편리해진 시점에서, 크게 사용의 필요성이 느껴지진 않네요.

여기까지 React Native를 다루는 기술 책에서 핵심 내용들만 추려보았습니다!

2. 최종발표회

이번주는 12주동안 진행한 스터디 + 조별과제의 마지막 시간 입니다.

처음에 진행 방법을 조정하는데 어려움이 있던것을 생각하면, 다행히 중도하차인원 없이 모든 스터디원분들이 마지막까지 열심히 달려주셨습니다.

그럼 마지막 최종 발표회를 보실까요?

1조. 싱그럼

1조는 식테크(식물 제테크)를 주제로한 싱그럼 이라는 App으로 과제를 마무리 했습니다.

(발표를 맡아주신 KMS님)

1조의 경우 아이디에이션이 오래 걸렸고, 실제 코드로 구현하기 시작한 시간이 늦은 편 이었습니다.

그래서 와이어프래임 수준에서 App을 구현하였습니다.

특이사항으로는 공공데이터를 사용해서 App에 적용했고, 이 결과를 모두같이 확인할 수가 있었습니다.

(공공데이터를 불러오다가 에러가나버린....🤣)

자료를 보시면 알겠지만, App의 상세화면 설계는 충분히 되었지만

프로젝트의 설계 대비 시간의 부족으로 아쉬움이 남은 프로젝트 입니다.

(프로젝트 진행전 완료된 설계들)

2조. 득근득근

2조의 경우, 득근득근이라는 주제로 운동 루틴을 관리할 수 있는 App 프로젝트를 진행 했습니다.

(2조의 발표는... 또 접니다😅)

2조의 경우 지난 식단, 운동관리 어플리캐이션에 더불어서 카카오지도 API를 접목해서 주변 헬스장정보를 찾을수 있게 하려했습니다.

2조같은 경우 Nested Conext API, Nested Router가 되었을 때 발생한 문제점들에 대해서 공유하는 시간이 있었습니다

Nested구조가 될 경우, Hook을 사용해서 router, Context에 접근할 경우 원하지 않는 결과가 발생하는것을 확인 하였습니다(다른 값이 지목된다던가, 전달한 Params가 사라진다던가...)

그래서 개발 과정에서 발생할 수 있는 위와같은 내용을 스터디원분들과 공유하는 시간이 되었습니다.

3조. 책장정리

(PPT가 너무 이뻐서 가지고왔습니다 ㅎㅎ)

3조는 책장정리라는 이름으로, 책을 중고거래 할 수 있는 App 프로젝트를 진행 하였습니다.

중고거래를 할 수 있는 다양한 플랫폼이 있지만, 중고책을 전문적으로 다루는 플랫폼이 없다는것, 여러분들 알고 있으셨나요?

저같은 경우도 중고 서적을 매매하고싶지만, 아무래도 중X나라, 당X마켓 에서는 주요한 상품이 아니다보니

일반적인 분들은 알X딘 중고서점 등에 중고책을 팔으신 걸로 압니다.

저같경우도 이러한 점 때문에 굉장히 기대를 했던 프로젝트중 하나 입니다.

(3조 발표를 진행해주신 KSW님)

(중고책 거래의 현 상황파악 및 가치를 중점적으로!)

(다수의 현직자로 구성된 팀이다보니 확실한 초기기획....?)

(확실한 초기기획 및 설계를 보여준 3조)

3. React Native

위와같은 충분히 흥미로운 프로젝트가 있었지만, 안타깝게도 실제 배포까지 되진 못하였습니다.

약간의 핑계를 붙여서 React Native에 대한 이야기를 잠깐 해보고자 합니다.

1. 크로스플랫폼

React Native에서 가장 강조하는것은 JavaScript를 활용해서 IOS, Android 두개의 플랫폼을 한번에 개발할 수 있다는 점 입니다.

하지만 Modal-ActionSheetIOS, Statusbar-react-native-safe-area-context등등.... 다양한 상황에서 IOS와 Andorid에 대응되는 코드를 작성 해야 합니다.

제가 기대한 크로스플랫폼 : 알아서 IOS, Android에 맞게 컴포넌트를 만들어주는 어썸함

현실 : IOS, Andorid에 맞게 컴포넌트를 따로따로 만들어줘야하는 안어썸함

그래서 IOS와 Android에서 모두 정상적으로 돌아가게 만들기 위해서는

두배 가량의 코드를 작성 해야하고, 이 부분에서 예상과는 많이 달랐습니다.

2. 빌드문제

두번째는 빌드 문제입니다

빌드하다가 에러가 나는 것이야 개발자들의 일상이라고 할 수 있죠.

하지만 React Native의 경우 빌드중 에러가 발생하는 경우가 많고

가장 중요한게 어떤 에러인지 일반 사용자가 알기가 어렵습니다

(Error발생에 따른 Trace가 어렵습니다)

특히나 IOS빌드의 경우 추가적인 Bridge 구조때문인지 빌드Error 발생 빈도가 높았습니다.

그래서 맥북으로 IOS 시뮬레이션중 에러때문에 빌드 문제를 해결하는데 생각보다 많은 시간이 필요했습니다

빌드시 발생한 문제에 대한 명확한 Trace가 없다는점이 굉장한 아쉬운점 이었습니다.

3. WebView

마지막으로 명확한 대체제 라고 할 수 있습니다.

React Native공부를 시작할때 많인 개발자 지인들이 한 말이 기억납니다.

그냥 webView로 하는게 더 편하지 않아요"

AysncStorage를 사용해서 App자체로만 동작하는 경우를 제외하고

Client <-> Server구조로 동작하는 App같은 경우 WebView를 사용해서 완전히 대체할 수가 있는게 사실입니다.

기존 React를 사용하던 프론트앤드 개발자 입장에서는 React Native를 사용하는 것 보다 React로 빌드 후 WebView를 사용하는 좋은 대체제가 있고 할 수 있습니다.

4. React Native 정식 Release를 기다리며

하지만 아직 다행이라고 할 수 있는점은 React Native가 정식 Release가 된 것이 아니라는 점 입니다.

아직까지 1.00버전이 배포되지 않아고, 계속해서 버그픽스 및 개선이 되고 있습니다

(최근에 0.72버전의 배포)

Flutter를 개발중이신 관악구미화원님의 말에 따르면, 확실히 Flutter대비 React Native의 빌드에러를 처리하는게 어렵다고 하였습니다.

React Native가 정식 버전에 가까워짐에 따라 가장 큰 문제가되는 빌드에러에 대한 처리 방법, Error Trace가 개선될 것을 기대해 봅니다.

미숙했지만, 재미있었던 12주의 DEVOCEAN 스쿨, React Native 스터디는 여기까지입니다!

하지만 React Native 스터디의 마지막 포스팅은 아닙니다!

React Native 스터디 마지막 포스팅으로, 개발자들에게 스터디란 어떤 의미인가? 로 찾아 오겠습니다.

언제나 행복한 하루 되시길 바랍니다!

RN스터디 12주차 포스팅을 마치며, RN스터디 마지막 포스팅으로 찾아오겠습니다.

감사합니다!

(함께 12주동안 즐겁게 공부해준 RN스터디원들과....)