참고자료

Intro

페이지의 전환이 빨라야 한다.

로딩이 빨라야 한다.

• Modern Web 로딩은 과거와 달리 단순히 웹이 켜지는 한 순간만을 의미하는게 아니다.

  큰 단계는 총 4가지로,

1. Is it happening?

First Paint, First Contentful Paint = Navigation start, call responded 상태 metric

2. Is it useful?

First Meaningful Paint = Enough content rendered metric

3. Is it usable?

Time to Interactive = Can users interact with the page metric

4. Is it delightful?

등의 상태로 구분할 수 있다.

Reference : LightHouse performance metrics

속도는 어떻게 측정할 수 있는가?

Data

• Lab Data : 사전에 설정된 기기와 특정 네트워크 세팅을 통해 실험하듯 수집할 수 있다.
  
• Field Data : real-world loading을 통해 수집할 수 있다. => CX 와 밀접하다.
  

Tool (from Google)

1. Lab Data => LightHouse 등
   
2. Field Data => CrUX(Chrome User Experience Report) 등
   

Performance Budget : Load Speed Metrics

• Set Examples

  

  Reference : How to stay fast

RAIL

• Web App life-cycle four aspects

• 

  Reference : RAIL

• 전반적으로 100ms 이내의 reaction 속도를 가질 경우, 유저는 상당히 만족할 수 있습니다.
  100 ms 이후에는 특정 interaction이 깨질 수 있으나, 대부분의 Web은 100 ms ~ 1 sec 정도의 속도로 움직입니다.
  1 sec가 넘어갈 경우, 유저의 집중이 분산될 수 있는 상태가 되며, 10 sec가 넘어가면 특정 task에 대해 낙담하거나, 불쾌해할 수 있습니다.

  
  

• 그러나 유저가 스스로 환경에 대한 인지를 하고 있다면 약간 다른 문제가 됩니다.
  예를 들어, 5G or 4G, 아주 빠른 인터넷을 사용하고 있고, 하이 퀄리티의 device를 사용한다면 나열된 시간대와 일치하는 user focus를 관찰할 수 있습니다.
  반면 3G 환경에 모바일 기기를 사용하는 유저라면 약간 더 인내심이 생길 수 밖에 없겠죠.
  이 때는 보통 5 sec 정도의 conversion에도 만족할 수 있을겁니다.

  
  

그래서 위 RAIL 각 모델별로 목표하는 최선을 살펴보면

Response : under 50 ms

현실적으로 불가능하면, Response의 경우 User를 방해하지 않는 선에서 100ms까지는 괜찮을 수 있습니다.
Input handling이 예시입니다. 단순히 생각했을 때, 실제로 input handling은 50 ms 정도의 속도를 가집니다.
다만, 다음 입력을 queue에 저장함으로 유저를 방해하지 않는 선에서 100 ms 정도의 속도로 real-world에서 동작합니다.

Animation : under 10 ms

단순합니다. 60 frames 정도 되는 Animation을 구현하면 16ms 정도인데, 그 이하로 떨어뜨릴 경우 더 좋다는 말이 됩니다.
위 Animation은 모든 Animation에 해당합니다. Visual 뿐 아니라, Scroll, Dragging, etc. 전부 말입니다.
그러나 목표와는 달리, 60 frames 정도의 퀄리티로 구현하는 것을 최우선으로 하면 됩니다.

Idle : maximize idle time

응답 유효시간을 최대로 하여 user input을 50 ms 이내로 처리하는 것이 목표입니다.
Conversion, first load 당시 전부를 Load 하는게 아니라, lazy를 걸어 순차적으로 50ms 이내에 load하게 하는 것 또한 maximaize idle time을 준수한 하나의 방법입니다.

Load : 그래도 under 5 sec ( target : 3G network & mid range mobile device)

사실 첫인상과도 같습니다. 그러니 optimize code를 최대한 적용하든, image를 작게 하든, 어떤 방법을 사용해서든 first loads time을 줄이는게 좋습니다.
이는 Conversion 또한 예외는 아닙니다.
해당 target의 추가적인 load는 2 sec under speed를 준수하는 것이 좋습니다.

• 추가 정보 Reference : RAIL

Node에도 python의 openCV와 같이 이미지를 바이너리 코드로 변경해서 합성해주는 라이브러리가 있습니다.

정확하게는 배경이 되는 이미지에 특정 이미지를 쌓는 형태로, 덮어쓰는 것과 같이 동작하는 것 같습니다.

예시 )

from

to

mergeImages

대표적인 Image merge library인데, 저는 merge-images 라는 라이브러리를 활용해서 여러 이미지를 한 장에 합치는 스크립트를 작성했습니다.

install

1. npm i merge-images
2. npm i canvas

Node, npm(or yarn)이 있다면 두 라이브러리를 설치하면 됩니다.

참고링크

logic

로직은 생각보다 간단합니다.

1. 사진파일이 들어있는 경로의 파일명을 가져와 저장한다.
2. 파일 이름을 라이브러리가 원하는 구조로 변경한다.
3. 2에서 정제한 Array를 정제해 output 파일명을 결정합니다.
4. 합성재료로 2, 3을 사용해 합성한다.

의 flow로 진행됩니다.

그럼 코드를 볼까요?

const { writeFile } = require("fs");

const mergeImages = require("merge-images");
const { Canvas, Image } = require("canvas");

// 1. 파일명을 가져온 뒤, 배열에 저장한다.
const readFiles = () => {
  const fs = require("fs");

  // 5장의 사진을 합치기 위해 폴더(카테고리)로 나눈 뒤, 하나씩 다섯개의 폴더를 리스트화합니다.
  const IMG_FOLDER_LIST = [
    "dir1", // 파일에서 이미지에 접근할 상대경로
    "dir2",
    "dir3",
    "dir4",
    "dir5"
  ];

  // 각 5개 경로의 파일을 읽어옵니다. (2차원 Array)
  const fileReader = (dirArr) => {
    return dirArr.map((dir) => fs.readdirSync(dir).map((fileName) => dir + "/" + fileName));
  };

  // 불러온 파일명 Array를 반환
  return fileReader(IMG_FOLDER_LIST);
};


// 2. 라이브러리가 원하는 자료구조 형태로 변경합니다.
const fileNameGenerator = (prevFileNameArr) => {
  const fileNames = [];

  // 입력받은 2개의 Array에 대해 모든 경우의 수에 대해 합성합니다.
  // 최종적으로 5개 카테고리별로 각각 2장의 사진이라면 2^5 개의 element를 갖는 array가 나오게 됩니다.

  // input : [string[], string[]] (파일명 Array tuple)
  // => [[1,1], [2,2]]
  // output : [[1,2], [1,2], [1,2], [1,2]]

  // 만약 3개의 카테고리라면,
  // input: [[string[]], string[]]
  // => [[[1,2], [1,2]...], [3,3]]
  // output : [[1,2,3], [1,2,3], ...]
  for (let i = 0; i < prevFileNameArr[0].length; i++) {
    for (let j = 0; j < prevFileNameArr[1].length; j++) {
      if (typeof prevFileNameArr[0][i] === "string") {
        fileNames.push([prevFileNameArr[0][i], prevFileNameArr[1][j]]);
      } else {
        fileNames.push([...prevFileNameArr[0][i], prevFileNameArr[1][j]]);
      }
    }
  }

  return fileNames;
};

// 3, 4.
// 3은 내부함수로 구현했고,
// 4는 2, 3을 가지고 하나의 아웃풋(합성된 사진)을 만들어냅니다.
const mergeImage = (fileNamesArr) => {
  // 초기에는 2개의 카테고리, 2장의 이미지를 먼저 합성하기 위해 구조를 변경합니다.
  // input : [[1,1], [2,2]] 
  // ouput : [[1,2], [1,2], [1,2], [1,2]]
  let generatedArr = fileNameGenerator(fileNamesArr.slice(0, 2));

  // 이후 과정은 사진을 한장씩 추가하는 형태의 반복문입니다.
  // 3장이라면, [[1,2,3], [1,2,3], ...] 으로요
  for (let i = 2; i < fileNamesArr.length; i++) {
    let newArr = fileNameGenerator([generatedArr, fileNamesArr[i]]);
    generatedArr = newArr;
  }

  // 반복 이후 모든 파일명이 담긴 배열을 정제합니다.
  // 원하는 output naming을 위한 로직이니, 마음대로 custom할 수 있습니다.
  const outputNameArr = generatedArr.map((el) => {
    return el.map((el2) => {
      return el2.split("_")[4].split(".")[0];
    });
  });

  // 2의 과정을 마친 Array 내부의 원소들을 순회하며 라이브러리 메서드를 적용합니다.
  // Array elem (img files read, merge) => b64
  // b64 => png write
  // generatedArr를 기준으로 파일명을 분리했기 때문에 outputNameArr는 동일 조합에 대한 mapping이 이루어져 있습니다.
  generatedArr.forEach((imgs, idx) => {
    console.log(outputNameArr[idx]);
    mergeImages(imgs, {
      Canvas: Canvas,
      Image: Image,
    }).then((b64) => {
      const b64Data = b64.replace(/^data:image\/png;base64,/, "");
      writeFile(`./data/_OUTPUT/merged/${outputNameArr[idx].join("_")}.png`, b64Data, "base64", (err) => {
        console.log(err);
      });
    });
  });
};

코드는 생각보다 길지 않습니다.

정상적으로 동작하는 것도 잘 확인했고, 결과물도 나쁘지 않았습니다.

Refactoring

1. 성능 개선을 위해 초기 코드에서 정규표현식을 최대한 제거하고, 문자열을 split으로 처리하기로 했습니다.

split.join.replace => split[] 로 변경

Js Array search 속도를 고려해 index 접근 방식으로 복잡도를 줄일 수 있을까 시도했으나, 근본적인 문제는 그게 아니었습니다.

2. 라이브러리 메소드 자체가 느리다.

라이브러리를 사용하는 입장에서 이런 얘기를 하면 안되는데, 속도가 조금 늦은 감이 있습니다.

물론, 2장의 이미지를 합성할 때는 상당히 빠릅니다.

문제는 제가 5장의 이미지를 합성하기에 기하급수적으로 복잡도가 올라갑니다.

한번에 다수의 이미지를 합성하는게 문제인 것으로 판단되는데, 추후 generate 방식과 마찬가지로 2장씩 합성하는 loop로 해결해보는건 어떨지 고민하고 있습니다.

이상입니다.

해당 문서는 B6, 딥러닝으로 확장하는 프론트엔드 현주소 영상을 보고 정리한 글입니다.

도입부

먼저, FE deep learning의 경우 SIFT, SURF 등 영상처리 algorithm에 대해 알 필요는 없습니다.

Keypoint Detector -> Feature Detector -> Feature Matching 의 과정의 결과가 어떤지 집중해야 합니다.

고로, 우린 적당한 모델을 찾아 input shape을 정하고, output feature 결과를 잘 가져다 쓰는게 맞다고 생각했습니다. 그러기 위해서 서치해본 결과, pre-trained model을 제공하는 WebGL을 활용하기로 했습니다.

그렇게 만들어진 것은 사진을 입력받아 닮은 포켓몬을 반환해주는 하나의 Web-App 입니다.

결과물 : pokemon-ai.com

IDEA

1. feature model 선별, 약 700 마리의 Poketmon feature
2. 비교적 가벼운 모델, MobileNet v2 선택
3. 모델을 ts.js 포맷으로 추출하고, Client에서 ts.js로 model 로딩
4. kNN query를 위해 feature indexing
5. 선택 기능을 구현, 모델을 추론해 해당 이미지 feature 추출

WebGL

• GPU 가속을 활용한 자바스크립트 딥러닝 라이브러리
• 문서화가 잘 되어있으나, 처음 딥러닝 프레임워크를 사용한다면 러닝커브가 있음
• 직접 학습이 아닌 pre-trained model을 제공하고 있어 좋다.
• Python keras model load 가능 -> ts.js model 추출이 가능한 이유

TF.js

Backend

• CPU Backend : Pure-JS(node)
• WebGL Backend : 다른 Backend에 비해 지원하는 항목이 많다.
• WASM Backend : 자료 부족 / 지원 범위가 좁다
• WebGPU Backend : 자료 부족 / 지원 범위가 좁다
• Node Backend
• React Native : Expo

model 추출

1. Python code로 model 추출 : inputShape 지정
2. json 형태 model async load
3. image (HTML elements) -> crop()으로 inpuShape 일치
4. (H, W, C) 형태의 inputShape 에 대해 squeeze -> GlobalAveragePooling2D() 사용

추론 결과

첫 회고

1. 배경이 있어 원하는 결과가 나오지 않았다.
2. 얼굴만 crop해보는건 어떨까?
   • Smartcrop.js, Pico.js, etc...
3. 얼굴 segmentation도 TF.js가 해주는건 어떨까?
   • BodyPix Segmentation 모델을 사용해보자!

어차피 tf.js 쓸거면 얼굴 seg도 tf.js보고 맡기자. 마찬가지로 성능보다 빠른 속도가 우선이니, 경량화된 Model(MobileNet V1)을 사용하자.

24가지 신체 부위에 대한 Seg 중, 왼쪽 얼굴과 오른쪽 얼굴만 분할하기로 결정했다.

Person Segmentation with Body-Pix

얼굴만 뽑아서 했더니 비교적 덜 칙칙한 포켓몬이 나와 만족스러웠다.

Deployment

Architecture

• AWS S3
• AWS Cloudfront
• AWS ACM
• AWS Route53

결과적으로 Realtime Crop이 가능했고, 속도도 꽤나 잘 나왔다. 닮은 포켓몬을 미리 load했던 시연 영상이지만, 실제 loading도 1~2초 정도 지연시간만을 가진다.

WebGL이 아닌 CPU 가속 러닝이었다면 10초 정도 걸린다.

얼굴이 여러개라면

• 실제로 얼굴이 2개인 포켓몬이 나타날 수도 있다.

  • Feature vector에서 형태를 잘 찾는 것 같다.

• 사진 내 얼굴이 여러개일 경우 전부 feature로 잡아 또가스 같은 포켓몬이 나오기도 한다.

모바일 지원

문제

• 데스크탑에서는 잘 지원되나, 모바일에서는 빈번하게 죽었다.
• GPU memory를 많이 잡아먹는게 아닐까?
  1. 이미지 선택
  2. 얼굴 Seg
  3. (224, 224, 3) resize
  4. feature vector 추출

flow 디버깅 결과 이미지를 선택한 후 얼굴 Seg할 때 메모리가 터지는 현상이 빈번했다.

해상도가 큰 이미지를 Seg할 때 Body-Pix model running 중에 터졌다.

• 해상도 변경 없어 메모리 이슈 발생, 입력 이미지의 해상도 변경.
• 이후 안정성은 향상되었으나, memory 누수가 존재.

tf.Tensor를 활용할 때는 메모리 관리를 명시적으로 해줘야한다는 docs 내용을 발견했다.

• tf.memory(), tf.dispose()를 사용해 메모리를 명시적으로 관리하기로 했다.
• GPU memory Ran out 발생 시, CPU Backend로 변경하도록 수정했다.

test case는 80명 정도로, 문제가 재발할 수도 있다.

개선사항

1. Imagenet pre-trained model이라 feature를 잘 추출하지는 못한다.
2. kNN query를 활용해서 5개 중 가장 귀여운 포켓몬을 보여주는 방식을 선택했다.

Medical AI with tf.js (응용사례)

안저이미지 분류

Vuno(발표자 회사)에는 눈의 이상소견을 찾아주는 deep learning classification 제품이 있다. 제품 모델은 GPU Server에 두고, 좌안, 우안 구분을 업로드 시점에 FE에서 처리해보는건 어떨까

결과적으로 꽤나 괜찮았다.

그러나 100%는 아니었고, 해당 기능 배포를 위해서는 전용 UX가 필요하겠다는 결과를 얻었다.

모달리티 분류

의료영상에는 Pixel Array 뿐 아니라, 환자정보, 영상 메타정보 등이 있다.

해당 영상이 어느 부위의 어느 축을 기준으로 촬영한 영상이다 등의 정보 = 모달리티

비표준, 누락, 익명화 등에 의해 메타정보 신뢰도가 떨어진다.

회사 프로젝트에 실제로 적용해보도록 했다.

FE deep learning

장점

• 서버와 통신할 필요 없어 dektop Web App의 경우 FE에서만 추출이 가능해서 빠르다.
• Client GPU resource 사용이 가능하다.
• 기존 백엔 모델 포팅이 간편하다.
• 간편한 모델이 많이 있다. (Ex. Body-Pix)

단점

• 딥러닝 모델이 노출되어 회사 자산이 외부에 공개된다.
• tfjs 의 경우 고수준의 API가 아닌 webgl tensor를 만든 경우 gc가 돌지 않는다.
• 모바일의 경우 적은 리소스로 메모리 터지는 경우가 빈번하다.
• tfjs의 경우 webgpu, wasm backend가 안정적이지 않다.

결론

FE에서 딥러닝을 한다는 것은 해결할 문제가 더 많아진다는 것이며, 수동 작업을 반자동으로 향상시킬 수 있었습니다. 경우에 따라 서버 리소스 사용이 줄어든다. 딥러닝 모델이 노출되고, 클라이언트 사양과 서버 리소스 트레이드 오프가 필요하다.

작성자 결론

기존 영상처리 및 Deep learning 실무에서 사용하던 성능 높은 모델은 아직 FE에서 사용하기에는 부담이 되는 것 같다. Client의 GPU memory를 사용하기에 memory 최적화가 어느 수준으로 이루어져야 할지도 난관이라고 생각한다.

그러나 python으로만 가능하던 기존의 deep learning을 javascript에서도 활용할 수 있다는 점이 보다 javascript community의 힘을 강하게 해줄 수 있다고 생각한다.

한줄평 : 시간이 된다면 tf.js도 한 번 해보자.

반갑습니다.

어제는 Redux -> RTK의 순서가 아닌 RTK -> Redux 순서로 공부하는 글이었습니다.

그렇기에 오늘은 약간의 코드와 다량의 개념들로 글이 이루어질 것 같습니다.

지난 글에서는 코드를 보며

• Provider component
• Store
  • configureStore()
• Action
• Reducer
• dispatch

등에 대한 개념을 RTK를 통해 알아보았습니다.

그런데 해당 방식은 서순이 맞지 않기도 하고, 놓치는 부분이 약간씩 생기는 것 같아 Redux의 개념을 RTK로 이해해보는 식으로 변경해볼까 합니다.

이번 글은 기존의 Redux에서 왜 RTK를 사용하는지? 그리고 어떤 개념들이 RTK를 사용하게 만들었는지 체크해보겠습니다.

그럼 시작해보겠습니다.

2. Redux

보통 가장 처음 생각하고 넘어갔어야 할 3가지 원칙을 어제 글에서는 적지 않았었습니다.

그런데 공부하다보니 대부분의 포스팅, 도서, 강의에서 강조하는 내용이 3가지가 있어 적고 시작하겠습니다.

약간 복무신조 느낌이네요.

1. Single source of truth : 스토어는 단 하나만 존재해야 한다.
2. Read-only state : 상태는 불변 그 자체다.
3. Changes from pure functions : 순수 함수로만 변경해야 한다.

하나씩 생각해보죠.

SSOT(Single source of truth)

Redux는 단 하나의 상태 객체, Store를 구성할 것을 강조합니다.

1. 먼저 앱의 확장성을 고려했을 때, 하나의 자바스크립트 객체를 활용하는 것이 Client - Server 요청 처리를 단순화하기 때문입니다.

2. 그리고 이전의 객체가 저장되어 있다면 redo - undo를 쉽게 구현할 수 있기 때문입니다.

3. 디버깅에 용이하기 때문입니다.

자, 보통의 개발자가 좋아하는 키워드 하나로 표현할 수 있겠죠?

분명 "유지보수"에 용이할 수 있다. 가 포인트입니다.

Read-only, Immutable

변경에 있어 하나의 가능성만을 남겨두고, 단방향 플로우를 구현해야 하는 이유.

디버깅에 용이하다. 유지보수에 도움이 된다. 프로젝트 안정성을 보장한다.

하나의 컨벤션을 준수하는 것으로 수많은 오류를 회피할 수 있습니다.

그런데 이런 이유 말고 왜 불변이라는 표현을 사용해야만 할까요?

슬슬 감이 오시듯,

상태는 Redux 뿐 아니라, React도 강조하고 있는 개념인 불변성을 가진 객체로 관리되어야 합니다.

그건 바로 변경 탐지의 이유때문입니다.

React가 상태, props의 변경을 어떻게 체크하는지 생각해보면 왜 불변성을 유지해야 하는지도 알 수 있습니다.

React는 Shallow compare를 통해 Rendering 최적화를 이뤄냈으니, 한 번 해당 키워드 글을 읽어보면 좋습니다.

Change from pure function

순수함수? 쉽게 볼 수 있는 키워드는 아닙니다.

그런데 크게 신경써야 할 부분은 바로 이 부분입니다.

하나의 스토어, 불변객체인 State 관리, 그보다 난해한 것은 내가 작성한 Reducer가 순수함수가 맞을까? 하는 고민이 가장 어려울 것 같습니다.

순수함수는 I-O(Input - Output)이 명확해야 합니다.

어떠한 Side-Effect도 존재하지 않는 함수를 순수함수라 명합니다.

예를 들어보면,

지난 프로젝트에서 다루었던 dayjs() 의 유틸함수 중 일부는 순수함수가 아닙니다.

현재 시점의 Date() 객체의 data를 다루는 함수의 경우 다양한 상황에서 버그가 발생할 수 있습니다.

대표적 예시로 Github Actions에서의 test 환경은 KST 환경과 다른 UTC 환경입니다.

그럴 경우 Date() 객체의 data는 한국 시각이 아니니, I-O 자체가 틀어져버리는 이슈가 발생하게 됩니다.

그러나 반대로

특정 date String을 입력으로 받아 milliSec로 변경해주는 로직의 경우 Side-Effect가 존재하지 않습니다.

변경("2021-10-28"); // return 대충 밀리초(12321313213)

이런 함수가 바로 순수함수입니다.

즉, 앞으로의 상태변경 로직은 순수함수로만 작성되어야 한다. 정도만 이해하면 될 것 같습니다.

Why Redux?

Redux를 알아보았을 때, Store 하나로 프로젝트 전체의 상태를 관리한다는 것은 때로 매우 까다로울 수 있으며, 때로는 프로젝트 내부의 Cost가 높아질 수도 있습니다.

거기다 불변객체가 비교에는 용이하지만, re-Render가 적은 경우 객체 단순 변경이 어쩌면 더 좋은 퍼포먼스를 자랑할수도 있습니다.

순수함수를 고려하는 것 또한 개발자의 입장으로써 쉬운 일은 아닐 수 있죠.

그럼에도 Redux는 확장을 고려할 때 사용해야 하는 하나의 솔루션으로 인정받았습니다.

실제로 인턴십 중에도 Redux를 실무에 사용하고 있다는 것을 듣기도 했고, 지금의 회사도 Redux를 사용하고 있습니다.

그래서인지 Redux를 사용할 때는 모두 입을 모아 "더 고민해보고, 다시 고민해라." 라는 말을 하기도 합니다.

하지만 상태관리 이슈에 부딪혀본 저와 같은 사람들이라면 이제는 도전해볼 때가 되었습니다.

가보죠.

Flow

먼저, Redux의 동작흐름은 어제 말씀드린것처럼

이런 식으로 구성되어 있습니다.

이를 하나씩 생각해보면

Action

Action은 특정 상태에 대한 하나의 정의입니다.

통상적으로 객체 형태이며, type 프로퍼티를 필수적으로 갖는 JS Plain Object입니다.

Middleware

Reducer 실행 전, 거쳐가는 하나의 레이어 개념입니다.

Middleware에는 보통 Reducer의 예외처리를 하거나, 상태값을 디버깅하는 로직을 추가할 수 있습니다.

그 외에도 Action에 대한 비동기 처리를 가능하게 한다던가(redux-thunk), 특정 Action을 기반으로 동작하는 하나의 chaining(redux-saga)을 구현할수도 있습니다.

라이브러리를 주로 활용하는데, 위 두 예시가 자주 사용되는 라이브러리입니다.

Middleware의 경우 function compose로 구현되는데, 이는 클로저 개념을 응용하는 방식입니다.

주로

const middleware = store => next => action => next(action)

의 형태를 가집니다.

어제 까보았던 RTK의 store API를 적용해서 생각하면,

const middleware = ({getState, dispatch}) => next => action => next(action)

으로 디테일하게 표현할 수 있습니다.

Reducer

(prevState, action) 둘을 전달받아 newState를 반환하는 하나의 function입니다.

const reducer = (prev, action) => new

의 구조로 이루어져 있다고 생각할 수 있습니다.

Redux는 Reducer를 위한 라이브러리입니다.

그러니, Reducer를 얼마나 잘 작성하고, 잘 다룰 수 있느냐가 사실상 관건이 아닐까 생각합니다.

Store

단일 JS object입니다.

프로젝트 전체의 상태를 보유하기도 하고, 경우에 따라 일부만 보유할 수도 있습니다.

어제 보았던 store의 내부에는 다양한 property가 존재하는데, 이를 store API라고 표현하기도 합니다.

모든 상태의 집합체라고 생각할 수 있습니다.

또한 값을 직접 수정할 수 없기에 dispatch 메서드를 지원합니다.

dispatch를 reducer 내부 등에서 호출할 경우 store는 쌓인 순서, queue에 담아두는 것과 같은 순서로 처리합니다.

View

UI단, interaction을 접수받는 유일무이한 창구입니다.

저는 항상 View도 단방향 통신을 한다고 말하는데, 유저의 눈과 손을 분리해서 생각하기에 View도 하나의 순환구조가 형성된다고 생각합니다.

눈에 영향을 끼치고, 손에게 영향을 받으며, 흐름에 맞게 다른 시스템 구조의 누군가에게 영향을 끼치게 됩니다.

특정 Action의 Trigger이기도 합니다.

RTK, ReduxToolKit

이제 Redux를 어느정도 알아봤으니, RTK에 대해 얘기해봅시다.

Redux Toolkit은 Redux의 다양한 기능을 보다 쉽게 사용할 수 있는 메서드를 지원합니다.

공식문서에도 잔뜩 있기도 하고, 구체적인 내용은 적지 않겠습니다.

그런데 새로운 개념 하나 둘 정도는 확실히 짚고 넘어가봅시다.

Slice? AsyncThunk? what the...

분명 template을 하나 만들면 이상한 키워드들이 좀 있습니다.

AsyncThunk라던가 혹은 Slice가 그 예시가 될겁니다.

어쩌면 어제 적었던 configureStore()도 그 예시중에 포함됩니다.

그런데 AsyncThunk나 configureStore 정도는 이름만 봐도 느낌이 있는데, Slice? 이건 정말 모르겠습니다.

그러니 한 번 짚고 넘어가봅시다.

Slice

Slice는 Reducer + Action 입니다.

?

왜 이렇게 되어있는지 의문이시겠지만, 분명 그런 개념이라고 명시되어 있습니다.

이 Slice를 통해 어제 Redux 개념을 공부하려다보니 분명 구멍이 생겼을 정도로 가히 파격적인 개념입니다.

다시 어제의 코드를 가져와봅시다.

const initialState: CounterState = {
  value: 0,
  status: "idle",
};

export const counterSlice = createSlice({
  name: "counter",
  initialState,
  reducers: {
    increment: (state) => {
      state.value += 1;
    },
    decrement: (state) => {
      state.value -= 1;
    },
    incrementByAmount: (state, action: PayloadAction<number>) => {
      state.value += action.payload;
    },
  },
  extraReducers: (builder) => {
    builder
      .addCase(incrementAsync.pending, (state) => {
        state.status = "loading";
      })
      .addCase(incrementAsync.fulfilled, (state, action) => {
        state.status = "idle";
        state.value += action.payload;
      });
  },
});

이제 눈에 확 들어오는 친구들이 몇 있습니다.

• initialState : 초기 상태값입니다. 따로 할당된 값은 블럭 위에 있습니다.

• reducers : Action type을 key로 갖는 reducer function의 집합체입니다.

• extraReducers : pending, fulfilled, reject 등의 비동기 Promise 상태에 따라 변경되는 새로운 State를 반환하는 reducer 입니다. 예외처리기입니다.

이정도면 Slice는 참 간단히 이해할 수 있겠습니다.

근데 incrementAsync는 어디에 있을까요?

createAsyncThunk

여기 있습니다.

// counterAPI.ts
export function fetchCount(amount = 1) {
  return new Promise<{ data: number }>((resolve) =>
    setTimeout(() => resolve({ data: amount }), 500)
  );
}

...

// counterSlice.ts
export const incrementAsync = createAsyncThunk("counter/fetchCount", async (amount: number) => {
  const response = await fetchCount(amount);
  return response.data;
});

이게 뭐시여... 싶으시겠지만, RTK를 활용한 비동기 처리 로직 사용법의 예시입니다.

axios를 쓰면 fetch가 어색하듯, createAsyncThunk도 어색합니다.

그러나 해당 요청결과를 extraReducer 내부에서 당연히 필터할 수 있고, 기존 custom hooks 를 활용한 로직 결과 반환을 Slice 파일 내에서 처리할 수 있다는 소소한 장점도 생깁니다.

그러니 thunkAction도 유용하게 사용해봅시다.

RTK middleware?

Middleware layer의 예시를 RTK식으로 표현할 수도 있습니다.

export const incrementIfOdd = 
  (amount: number): AppThunk =>
    (dispatch, getState) => {
      const currentValue = selectCount(getState());
      if (currentValue % 2 === 1) {
      dispatch(incrementByAmount(amount));
      }
  };

홀수일 때 더하는 로직인데, 익숙한 표현이 하나 보입니다.

그 전에 AppThunk는 custom type 입니다.

실제로는 TunkAction type을 대입한 것과 같은 구조기에 return type은 (dispatch, getState) => {} 와 같습니다.

(dispatch, getState) => {}

확실히 Redux middleware와 유사한 구성이죠?

또한 currentValue의 경우 prevState에 해당합니다.

dispatch(action())도 보이네요.

생각보다 이제 보이는게 좀 있는 것 같습니다.

마치며

Redux -> RTK 구조로 공부하는게 어제보다 효율도 잘 나오고, 개념 이해도 쉬웠던 것 같습니다.

둘 다 사용할거니까 어차피 둘 다 하긴 했어야 합니다.

그런데 로드맵이 있다면 Redux 개념 -> RTK 순서가 훨씬 도움이 되었던 것 같네요.

그럼 오늘은 이정도로 마치겠습니다. 읽어주셔서 감사합니다.

반갑습니다. 오랜만입니다.

취업 후 일주일 정도 여유를 가지고 있습니다.

매일 알고리즘 풀이도 조금씩 하며 시간을 보내느라 오랜만에 글을 적게 되네요.

11월 1일 출근 전까지 그래도 회사 스택에 대한 공부를 하며 시간을 보내볼까 합니다.

많은 것들을 공부하기에는 현재 고향에 내려와있어 조금 어려울 것 같지만, 그래도 Redux, Redux toolkit / saga, React query 정도는 한 번 사용해볼까 합니다.

오늘은 Counter를 제공하는 기본 template을 활용해 Redux를 뜯어보며 이해해보겠습니다.

2. template 뜯어보기

먼저, RTK, Redux Toolkit Quick Start 방법 중 하나인 CRA template을 생성해야 합니다.

npx create-react-app my-app --template redux-typescript

명령어를 터미널에 입력해 typescript template를 생성할 수 있습니다.

해당 프로젝트의 기본 구성은 4가지 카운터 기능입니다.

index 파일부터 한 번 열어보며 생각해보겠습니다.

Redux를 사용해본 적 없고, 기본 개념 정도만 알고 있는 상태로 RTK를 공부하는 글입니다. 따라서 깊은 분석이 아닌 유추와 적당한 검색을 통해 해결해나가는 과정을 기록하겠습니다.

2.1 index.tsx

Index 파일에는 우리가 쉽게 볼 수 있는 ReactDOM.render 메서드 호출이 있습니다.

import React from "react";
import ReactDOM from "react-dom";
import "./index.css";
import App from "./App";
import { store } from "./app/store";
import { Provider } from "react-redux";

ReactDOM.render(
  <React.StrictMode>
    <Provider store={store}>
      <App />
    </Provider>
  </React.StrictMode>,
  document.getElementById("root")
);

주목해야 할 부분은 HOC, Provider가 하나 있고, store 라는 것을 불러와 Provider의 props로 사용한다는 점입니다.

대충 생각해봤을 때, RN의 Navigation, React의 Router와 같이 HOC로 다른 컴포넌트를 감싸 무언가 전달하려고 하는구나 정도로 생각이 됩니다.

그렇다면 Provider 먼저 확인해봅시다.

Provider

Provider는 어떤 컴포넌트일까요?

먼저 index.d.ts 파일을 확인해보면,

export interface ProviderProps<A extends Action = AnyAction> {
    store: Store<any, A>;
    context?: Context<ReactReduxContextValue> | undefined;
    children?: ReactNode;
}

export class Provider<A extends Action = AnyAction> extends Component<ProviderProps<A>> { }

Provider라는 컴포넌트는 Context API에서의 개념과 거의 동일하게 보입니다.

ProviderProps의 interface 내부에는 store, context, children 등의 개념들이 자리하고 있습니다.

context와 children은 이름만 봐도 React 유저라면 어라? 할 수 있을 정도의 친숙한 이름이지만, Redux만의 특별한 개념은 store에 있는 것 같습니다.

다른 2개의 프로퍼티, context, child는 옵션이지만, store는 필수로 구현해야 합니다.

그렇다면 store는 대체 뭘까요?

천천히 열어보며 어떤 개념일지 유추해봅시다.

2.2 store.ts

그럼 자연스럽게 store.ts 파일을 확인해봅시다.

import { configureStore, ThunkAction, Action } from '@reduxjs/toolkit';
import counterReducer from '../features/counter/counterSlice';

export const store = configureStore({
  reducer: {
    counter: counterReducer,
  },
});

export type AppDispatch = typeof store.dispatch;
export type RootState = ReturnType<typeof store.getState>;
export type AppThunk<ReturnType = void> = ThunkAction<
  ReturnType,
  RootState,
  unknown,
  Action<string>
>;

결과적으로 index.tsx에서 사용하는 store 객체는 configureStore() 메서드의 return 값입니다.

인자로는 {reducer : {counter : counterReducer}}를 전달받고 있네요.

아래로는 AppDispatch, RootState, AppThunk 등의 타입이 정의되어 있습니다.

여기서 새로운 typescript 활용이 나오는데, ReturnType<T> 입니다.

RootState의 경우 <typeof store.getState>를 ReturnType 제네릭에 넣어줌으로써store.getState의 return 값 타입으로 추론하라는 말이 됩니다.

그렇다면 store 객체는 어떻게 구성되었길래, dispatch, getState 등의 내부 메서드를 보유하고 있는걸까요?

그리고 ThunkAction은 대체 뭘까요?

하나씩 파헤쳐봅시다.

Action, Store, View

잠시 개념을 보자면, Redux는 store라는 하나의 객체에서 앱 전체의 상태를 관리한다고 합니다.

나아가 Redux는 Action => Store => View 구조로 동작하고 있습니다.

단, View는 user interaction을 담당하기 때문에 View는 Action의 Trigger가 될 수 있습니다.

그렇기에 View => Action => Store => View 의 순환구조로 이해할 수 있습니다.

그 외에도 다양한 개념이 있는데, 튜토리얼 단계에서 이해해야 할 것은 Action, Store, View의 circulation 정도인 것 같습니다.

또한 실제 순환이라는 개념에 맞도록 Simplex, 단방향으로 통신하는 구조를 갖습니다.

"영향을 끼칠 수 있는 존재는 정해져있다." 가 대부분 순환 시스템의 핵심이라는 생각이 강해서인지 미리 생각해두면 확 와닿는 것 같습니다.

이제 개념은 대충 정리되어 있으니, 관계별로 필요한 내용들을 조금씩 끼얹으며 코드 분석을 해봅시다.

configureStore

앞서, Store는 View에 영향을 끼치는 존재인 것을 확인했습니다.

우선은 RTK의 configureStore() 메서드의 선언을 보며 store 객체가 어떤 항목들을 포함하고 있는지 확인할 수 있기는 한데...

export declare function configureStore<S = any, A extends Action = AnyAction, M extends Middlewares<S> = 
    [ThunkMiddlewareFor<S>]>(options: ConfigureStoreOptions<S, A, M>): EnhancedStore<S, A, M>;

그런데 사실 선언을 봐도 잘 모르겠습니다.

간단하게 console.log()를 찍어보면,

store는 이런 구성으로 이루어져 있고, configureStore의 return 결과는 해당 메서드들로 구성된 객체라는 것을 알 수 있습니다.

type 선언으로 유추하고자 한다면 EnhancedStore => Store 의 방법으로도 확인할 수 있습니다.

또한 store 내부에는 reducer를 포함하는 등의 내용은 존재하지 않습니다.

이유는 간단합니다. 다른 개념이니까요.

Reducer의 개념은 잠깐 아래 항목에서 다루겠습니다.

그러나 store를 생성하는 시점에 store가 프로젝트의 Reducer를 인식할 수 있는 이유는

configureStore 메서드는 기존 createStore() 메서드의 결과와 달리 parameter로 넘겨준 객체의 reducer {Object}에 대해 자동으로combineReducer() 메서드를 실행하기 때문입니다.

원리는 store를 정의하는 시점에서 root reducer에 해당 reducer를 할당하는 구조인 것 같은데, 기존 Redux에 비해 얼마나 편해진것인지 체감하기엔 전례가 없어 모르겠습니다.

parameter를 관찰하는 방법은

RTK 공식문서 configureStore

또는 type 선언 중 ConfigureStoreOptions를 참고하는 방법이 있습니다.

요약하자면,

1. configureStore 는 dispatch, subscribe, getState 등의 메서드를 포함하는 객체를 반환한다.

아직은 어디다 쓰는지 모른다.

2. store를 configureStore로 정의하는 시점에 전달되는 reducer 객체는 combinedReducer 메서드를 통해 rootReducer에 할당되는 것처럼 보인다.

rootReducer는 또 뭘까.

정도로 요약할 수 있습니다.

이어서,

Reducer

돌아돌아 결국 Action => Store => View의 관계에 필요한 Reducer라는 키워드를 알 수 있었습니다.

rootReducer 단어를 먼저 접하긴 했지만, 사실 Redux는 Store와 Action 사이에 Reducer라는 특별한 레이어가 존재합니다.

Reducer 는 다시 특정 Action과 Store의 State로 구성됩니다.

다시 생각하면

View => Action => Reducer => Store => View 의 구조로 순환하는게 Redux라고 볼 수 있습니다.

그럼 이 Reducer의 예시 코드를 한 번 볼까요?

export const counterSlice = createSlice({
  name: "counter",
  initialState,
  reducers: {
    increment: (state) => {
      state.value += 1;
    },
    decrement: (state) => {
      state.value -= 1;
    },
    incrementByAmount: (state, action: PayloadAction<number>) => {
      state.value += action.payload;
    },
  },
  extraReducers: (builder) => {
    builder
      .addCase(incrementAsync.pending, (state) => {
        state.status = "loading";
      })
      .addCase(incrementAsync.fulfilled, (state, action) => {
        state.status = "idle";
        state.value += action.payload;
      });
  },
});

이것저것 잔뜩 정의되어 있습니다.

이 중, reducers property를 보면, 함수 3개가 보입니다.

그 중 action을 가지고 있는 함수는 incrementByAmount() 라는 이름의 함수입니다.

그렇다면 나머지 둘은 action이 존재하지 않는 걸까요?

엄연히 얘기하면 그건 아닙니다.

그 전에 사실 타고 들어가자면 selector, dispatch 개념도 먼저 알아야 하는데, Store의 state를 직접 변경하지 않도록 하는 하나의 장치 정도로 얕게 이해하고 넘어갑시다.

실제 dispatch가 사용되는 위치는 Button onClick() 시점에 사용되기에 action 객체의 type이 존재하지 않는 것이지, 일종의 action 개념은 존재한다고 생각해도 되는게 아닐까 합니다.

action은 type이라는 분류 키워드가 존재하고, 하나의 action 객체에 type과 커스텀 프로퍼티가 함께 있습니다. 원래의 Redux에서는 이 dispatch 에 action 객체를 전달받는 콜백함수를 전달해 store의 state를 변경합니다.

라고 유추하는 것이지, 명확한 사실은 아닙니다.

Redux가 아닌 RTK니까요.

요약하자면,

1. Action과 Store 사이에는 [action, state] 구조로 이루어진 Reducer가 존재한다.

2. Store state는 dispatch 메서드로 변경해야 한다.

3. Reducer는 연산 레이어로 볼 수 있다.

정도가 되겠습니다.

오늘은 여기까지 하고, 다음 글에서 좀 더 깊게 이어서 다뤄보도록 하겠습니다.

level1 문제 정리 repo

블로그 글은 오래만이네요.

숨고 인턴십이 끝나고 열심히 PS와 놓쳤던 학습을 다시 진행하고 있었습니다.

일주일 조금 넘게 문제를 열심히 풀었더니 어느새 프로그래머스 코테연습 level1 Javascript 문제는 다 풀게 되었습니다.

시작이 10만등인가... 5만등인가 기억은 나지 않지만, 그래도 랭킹도 좀 올랐습니다!

아직까지는 할 만 했던 것 같은데, level2는 얼마나 어려워질지 걱정이 좀 되네요.

그래도 문제를 풀며 보다 재밌는 방식으로 자료구조나 알고리즘 공부를 했던 것 같습니다.

이론보다 실습이 더 꽂히는 타입인가봅니다.

과정에서 에라토스테네스의 체, 탐욕법, 아직은 생소한 다양한 개념들을 맛볼 수 있었고, 문제를 열심히 풀고 다른 사람들의 풀이를 보며 현타가 오기도 했습니다.

다른 사람 풀이에 자극 받아 쉬운 문제들로는 메서드 체이닝에 지속적으로 도전했고, 지금은 대부분 함수 결과를 리턴하는 방식으로 코드를 작성하고 있습니다.

이제 보니 표현식이 아닌건 좀 불편하긴 하네요...

정규표현식, replace()

일부 문제를 거치며 정규표현식과 문자열 다루는 것에 익숙해질 수 있는 시간이었습니다.

카카오 블라인트 채용 테스트(아마 가장 쉬운 문제일겁니다.) 같은 경우에는 정규표현식이 없으면 상당히 긴 코드라인과 반복을 통한 문자열 처리가 들어가야하는데, 정규표현식으로 풀면 무척 간단해서 사실 꿀 좀 빨았습니다.

프로젝트 진행 중에 바빠서 따로 공부할 시간이 없어 손을 놓고 있었는데, 정규표현식을 통한 문자열 처리를 문제풀이에서 본격적으로 사용하다보니 꽤나 익숙해진 것 같기도 합니다.

그래도 아직 다양한 기호로 이루어진 정규식이 바로 떠오르지 않기는 합니다.

아, 구린 정규식을 전달한 replace() 같은 경우에는 split - method - join 보다 성능이 좋지 않을 수 있습니다.

또 .replace() 체이닝을 하면 효율성 테스트를 뚫는 것은 가끔 어려울 수 있습니다.

그러니 잘 작성된 정규표현식과 한 번의 메서드 호출을 작성하는게 심신에 이롭겠다는 생각을 하게 되었습니다.

벨로그 작성이 뜸한 이유

안그래도 블로그에 해당 문제풀이를 하며 생각했던 것을 기록할까 했는데 역으로 작성했던 코드를 보며 이전 기억을 거슬러가는게 좀 더 머리에 남는 것 같기도 하고, 하루에 10문제 가까이 풀기에 블로그에 적기에는 상당히 오랜 시간이 소요되는 것 같아 포기했었습니다.

TMI 머신이라 문제 하나에 한 페이지씩 작성할 것 같다는 생각에 그만..

사실 이력서와 포폴도 문제였지만요.

대신 기록은 필요하니 Repo를 하나 만들어서 README에 문제별 분류를 해두었습니다!

코드를 보더라도 이게 어떤 문제였는지 역으로 유추할 수 있도록 간단한 핵심 내용을 오른편에 적어두었습니다.

재업 - level1 문제 정리 repo

PS만 하다보니 블로그에는 소홀해졌지만, 깃허브는 놓지 않았습니다!

마치며

최근에는 열심히 작성한 이력서로 지원도 하고 있고, 서류 통과해 면접 일정도 잡힌 곳이 있기도 해서 블로그가 썰렁하긴 할 것 같습니다.

만약 level2 문제가 어렵고, 기록하지 않으면 애매하겠다 싶으면 README를 좀 더 열심히 적는 방법을 사용할 것 같네요.

벨로그와 깃허브의 컨셉을 분리하는 구조로 운영하기로 했으니, PS 관련 글은 여기서 마치겠습니다.

그럼 다들 남은 주말 푹 쉬시고, 다음주 이 때 쯤에 다시 주차 보고로 돌아오겠습니다!

안녕!

안녕하세요.

오랜만에 글을 적는 것 같습니다.

저는 어제부로 드디어 PS를 시작했습니다.

알고리즘 이론도 없고, 가진건 JS 메소드 몇개와 얼마전 합류한 정규표현식 친구 외엔 없습니다.

그럼에도 프로그래머스의 문제를 열심히 풀고, 남들의 풀이를 이해해보려 합니다.

현재 이틀동안 3개의 문제를 풀었고, Repo로 풀이를 관리하는 방법을 선택했습니다.

PS 레포

앞으로 열심히 레포를 채워넣을 예정입니다.

현재는 level1 수준이지만, 이번달 목표는 level2 진입 정도로 생각하고 있습니다.

바빠도 오전에는 꼭 문제를 하나 이상 풀겠습니다.

2. 공부

매일 조금씩 그동안 사용했던 기술스택과 CS를 조금씩 녹여낼 예정입니다.

React 후기

이번 챕터는 React 개념과 후기를 적어보도록 하겠습니다.

먼저, 기본적인 사고방식을 복습하고 넘어가겠습니다.

선언형과 상태

React는 선언형 라이브러리입니다.

선언의 이전에 React에는 State, 상태라고 하는 특별한 개념이 존재합니다.

상태는 특정 컴포넌트가 갖는 유니크한 형질로 볼 수 있습니다.

예를 들어, 지구 어딘가에 임의의 김동우가 있다면 김동우의 상태는 여러가지가 있습니다.

키가 크거나, 작거나, 덩치가 크거나, 작을 수도 있겠죠.

우리는 덩치가 큰(State) 김동우(Component)를 생각하고 해당 상태에 맞는 코드로 컴포넌트를 그려내기만 하면 됩니다.

그리고 덩치가 큰 상태의 반대인 작은 상태의 김동우를 코드에 녹여낼 수도 있습니다.

덩치가 큰 김동우를 만들기 위해 필요한 일련의 프로세스, 밥을 잘 먹이거나, 운동을 더 열심히 시키거나 하는 과정을 배제한 상태로 말이죠.

덩치가 작은 상태라면? (조건부 렌더링) -> 이런 모습이어야 해. (view 변경)

라는 사고방식으로 말이죠.

그냥 사고하고, 작성하면 React는 View를 조작합니다.

바닐라로 DOM의 상태를 변경하기 위해 특정 DOM 노드를 지정하고, 값을 넣어주고, 스타일을 변경하기 위해 JS 내부에서 함수로 변경하던 과정은 React에 존재하지 않습니다.

그냥 덩치가 크다면 이렇게 생겼어.

그런데 덩치가 작다면 이렇게도 생겼어.

특정 컴포넌트의 View를 State에 따라 변경하는 것이 바로 React입니다.

그렇다면 React는 어떻게 View를 HTML, CSS 없이 변경할 수 있는걸까요?

단순합니다.

그냥 Javascript 코드 내부에서 HTML을 조작하면 됩니다.

!!!..

React는 JSX를 활용해서 상태에 따라 바뀌는 HTML elements를 생성합니다.

render() 메소드, 혹은 특정 함수형 컴포넌트의 반환값이 바로 HTML elements입니다.

아무것도 몰라도 됩니다.

실제로 존재하지 않는 Tag를 <>로 감싸기만 해도 React는 잘 그려줍니다.

이렇게 HTML elements를 그려내는 하나의 함수, 혹은 클래스를 우리는 컴포넌트라고 부릅니다.

제가 만드는 대부분의 React App은 컴포넌트들의 조합입니다.

그리고 모든 React App이 컴포넌트들의 조합이죠.

그러나 막 만든 컴포넌트와 대충 조합된 구조는 분명 문제를 야기합니다.

예를 들어, depth가 무척 깊은 컴포넌트라면

Prop Drilling

이 발생할 수 있습니다.

Props는 분명 어딘가에서 오는 State입니다.

대부분 상위 컴포넌트(Parents)에서 State를 관리하고, 자식 컴포넌트(Child) View와 연결된 State를 Props로 물려받는 것이 React에서는 올바른 방향이라고 얘기합니다.

문제는 wrapping된 컴포넌트의 depth가 깊을 때, 불필요한 렌더링이 발생하거나, 혹은 사용하지도 않는 State를 Props로 전달받고, 다시 Props로 하위 컴포넌트에 전달해주어야 하는 안티패턴이 나타난다는 점입니다.

이를 Prop drilling이라고 합니다.

React가 제시하는 방향성은 언제나 State의 위치는 어지간하면 상위 컴포넌트인데, 이러한 상황에서는 해당 방향이 올바른가? 하는 의구심을 품게 됩니다.

저는 해당 라이브러리를 사용할만큼 큰 프로젝트를 다뤄본 적은 없기에, 나름대로 React의 방향성을 지키며 어떻게 프로젝트를 구성할 수 있을지 생각해보는 시간을 가졌습니다.

1. 상태관리 라이브러리

2. 적절하게 분포된 State

3. 넓이로 확장

세 가지 방법 정도가 있지 않을까 생각을 했는데, 확실히 2번은 타협에 가까워 팀 단위 개발에서 주관이 부딪힐 문제가 있다고 생각합니다.

그 외 3번은 조삼모사의 느낌이 드는 것 같습니다.

결과적으로 3번은 React의 State 설계 방향성을 완벽히 어기기도 합니다.

과정에서 Redux를 하나의 HOC로 바라보고, 상태관리 라이브러리를 선택하는 것이 React 개발 방향성과 일치하는 것이 아닐까 하는 결론에 도달할 수 있었습니다.

이 과정에서 Context API, 컴포넌트 합성 등에 대해서도 고민했습니다.

그러나, 대부분 상황에서 Redux는 해답이 될 수 있지만, Context API와 합성은 제약이 발생할 수 있다는 점에서 극히 일부에 적용될 수 있다는 생각을 했습니다.

Context API는 쉽게 생각하면 styled component의 Theme Provider와 같은 HOC 개념입니다.

컴포넌트 합성과 Context API의 경우 결국 하나의 컴포넌트에서 wrapping하는 패턴이 동일하다고 판단되어 Redux와 비교가 어려운 것 같습니다.

상황에 따라, 명확한 목적에 따라 방법을 구분할 수 있는 개발자가 되어야겠습니다.

3.

이것저것 적다 보니 글이 장황한 것 같습니다.

내일은 좀 더 깊은 이야기와 개념, 문제풀이로 뵙겠습니다.

밤이 늦었네요.

그럼 전 이만 물러가도록 하겠습니다.

반갑습니다. 오랜만이네요!

연휴동안 푹 쉬기도 했고, 지난주 목요일, 기업협업을 마치고 드디어 자유의 몸(?)이 되었습니다.

막상 끝내니 섭섭하기도 하고, 남는 것이 많아 좋기도 했습니다.

회고 내용은 굳이 적지 않겠습니다!

회고보다는 이후 예정사항을 조금 정리해둘까 합니다.

그럼 시작하겠습니다.

2. 기업협업 종료 이후

이것저것 부족한게 많았습니다.

협업 내내 CS에 기반한 DB 지식도 없었을뿐더러, 로직을 작성하는데 필요할법한 알고리즘 & 자료구조 지식도 거의 전무했습니다.

이게 정말 필요했나? 생각해보면 또 그렇지 않을 수도 있지만,

분명 저는 DB에서 데이터를 가져와 사용했어야 했고, 그 과정에서 Object 형태의 데이터를 정제하기도 했습니다.

사용한 방법으로 데이터를 요청하는 것이 최선이 맞는지, 그리고 가져온 데이터의 형태가 최적의 형태였을지 그런 것들을 정말 잘 모르겠습니다.

코드가 지저분한건 그런 것들에 대한 저의 지식이 없기 때문일겁니다.

그래서 앞으로 무엇을 공부할거냐?

2.1 코드 없는 알고리즘과 데이터 구조

네. 바로 책(e-book도 있음)입니다.

내일부터는 아마 이 책을 조금씩 읽어보며 녹여내지 않을까 생각하고 있습니다.

책의 수준이 어떤지, 그리고 이 책이 정말 도움이 되는지 그런 것들은 사실 지금 레벨에서 중요하지 않다고 생각합니다.

아는 것이 많지 않으니까, 보면 도움이 되겠죠.

2.2 기본적인 CS 지식 & 언어 동작원리

DB는 물론, 이제 앞으로 준비해야 할 것은 다양한 CS 지식과 언어에 대한 당연히 알아야 할 탐구입니다.

브라우저, 네트워크 통신, JS는 어떻게 컴퓨터와 소통하는지, ...etc, 다양한 것들을 조금씩 알아볼까 합니다.

현재 알고 있는 것들도 분명 많을테지만, 정리하며 곱씹어나갈 시간이 필요한 것 같습니다.

급하지 않은 시점에 꼭 필요한 공부라고 생각합니다.

2.3 Jest

지금도 하고 있고, 오늘도 잠깐 도전해보았습니다.

먼저, Jest를 활용한 unit test 1차 작성은 완료된 시점입니다.

오늘에서야 드디어...

일주일 동안 로직에 대한 test를 작성하며, 실제 로직의 문제점을 발견하기도 했고, test 로직이 잘못된 경우도 분명 있었습니다.

github actions CI를 활용하면, 내 test 로직이 왜 통과가 안될까? 하는 화도 나지만, 분명 strict한 test를 진행할 수 있었던 것 같습니다.

로컬에서는 그냥 대충 초록불인데, actions는 PR 통과를 시키지 않아서 좋았던 것 같습니다.

그렇게 coverage 채우기 프로젝트를 어느 정도 마치긴 했습니다.

표의 항목을 어떻게 활용할지는 아직은 숙제인 것 같습니다.

완벽히 작성한 파일에서 어떤 부분이 문제인지도 확인해야겠네요.

2.4 Redux

Redux는 고도화 과정을 논의할 때 나온 하나의 숙제입니다.

기존 presenter 단에서 관리하던 state들이 꽤 있는데다가, props interface를 좀 정리하고 싶다는 막연한 생각부터 시작이 된 것 같네요.

기왕 이렇게 고도화 할거라면 Redux를 사용해보자! 하는 마음이 있습니다.

2.5 여유가 된다면

프로젝트 고도화 내용 중 일부였던 구현되어있지 않은 View를 작성할 것 같습니다.

My page tab or Meeting tab View를 구현할 것도 같네요.

다만, 언제까지나 "여유가 있다면" 입니다.

셋이 하던 프로젝트를 혼자 고도화 할 예정이니까요.

2.6 프로그래머스?

네. 이제 취업시장에 나가야 하니 본격적으로 알고리즘 문제도 한 번 풀어볼까 합니다.

책을 괜히 산게 아니었습니다.

현재는 계획 중인데, 아마 내일부터는 문제를 하나씩 풀어볼 것 같습니다.

짤막하게 TIL에도 올릴 것 같네요.

3. 그래서

달라질 것은 없는 것 같습니다.

그냥 하던 공부를 계속 할거고, 하던 프로젝트를 더 좋은 방향으로 나아가게 하기 위해 고민할 것 같습니다.

일상은 변화가 없을거고, 제가 하는 것들은 언제나 같지 않을까 생각합니다.

공부하고, 적용하는 일을 하기로 마음먹었으니까요.

다만 이제 일상도 Trello로 관리하기로 한 것은 어떤 느낌일지 궁금하긴 합니다.

그러니까 앞으로도 화이팅입니다.

반갑습니다.

오늘은 드디어 노래를 부르던 unit test library, Jest를 사용하는 날이었습니다.

그 외에도 제목에서 보듯, GitHub에서 제공하는 branch 단위의 CI, actions를 적용해보았습니다.

총평은...

• repo에 actions를 test하며 적용하는데에는 아직 꽤 시간이 걸린다!

  빌드 단계에서 npm install을 이용했기 때문에 그렇긴 합니다.

• Jest는 조금 더 써봐야 알 것 같다. 그러나 없는것보다 훨씬 낫다.

  보다 더 확장된 test 개념이 필요할 것 같다. 현재는 비즈니스 로직만 test중.

• actions + Jest로 PR test 자동화, CI가 가능하다.

  더 다양한 actions도 알아봐야겠습니다. ㄹㅇ 신세계임.

그럼 어떤 방법으로 합쳐서 사용했는지, 그리고 test의 예시코드는 어떤 형태인지? 부족하지만 올려볼까 합니다.

2. Jest

Jest를 사용하는 방법은 간단합니다.

1. React-Native 기준, npm i -D jest 하나면 그냥 뚝딱! 사용할 수 있습니다.

2. 그리고 테스트 해볼 로직이 가득한 파일과 1:1 대응으로 TS project 기준, ~.test.ts 파일을 만들고 내부에 코드를 작성하면 됩니다.

// dayjs.test.ts (utils logic test)

test('[DayJS Logic] dayOfWeekDate test : (I)dayNum(0-6) (O)yearMonth string 반환 검사', () => {
  for (let i = 0; i <= 6; i++) {
    const [year, month, day] = dayOfWeekDate(i).split('-');
    expect(parseInt(year, 10)).toEqual(NOW_YEAR_NUM);
    expect(parseInt(month, 10)).toBeLessThanOrEqual(12);
    expect(parseInt(day, 10)).toBeLessThanOrEqual(31);
  }
});

3. 이후 프로젝트 폴더 위치에서 npm test만 입력해주면? 바로 test가 실행됩니다.

4. 추가적으로 프로젝트 내의 test 파일이 어느정도의 테스트를 진행하고 있고, 앞으로 얼마나 더 진행해야 하는지 확인하려면 npx jest --coverage를 실행해주면 됩니다.

이런저런 과정들을 거쳤지만, Jest를 사용하는 것은 큰 문제가 아니었습니다.

추후 Native logic을 가져다 사용할 수 없는 경우가 있다는데, mocking 등과 같은 키워드로 해결할 수 있다는 힌트도 얻었습니다.

이외에도 UI components test, Redux chunk action 등에 대한 키워드도 들었는데, 약간 먼 미래라 여기다 적어두기만 하겠습니다.

터미널에서 test 결과도 볼 수 있습니다. ㅋㅋ

3. GitHub actions

오후 내내 actions와 씨름했습니다.

도움받은 블로그 링크를 올려둘테니, 관심있는 분은 사용해보셔도 될 것 같습니다!

actions는 MS를 등에 업은 GitHub의 project CI 기능입니다.

대표적으로 push와 pull_request 두 기능을 trigger로 삼아 자동으로 특정 테스트가 실행되는 등의 관리가 가능합니다.

remote push, PR 둘 다 관리할 수 있기에 앞으로 더 많은 유저들이 사용하지 않을까 싶습니다.

actions는 사실 단일 기능보다 특정 외부 라이브러리와 함께 사용할 때 빛을 발하는 것 같습니다.

이를테면, Jest 같은 test library와 말이죠.

마켓플레이스에 다양한 actions가 존재하니 필요하면 거기서 가져다 사용해도 좋습니다.

Github 마켓플레이스 : action

저는 오늘 action이 돌아가는걸 좀 보려고 직접 타이핑하며 하나의 스크립트를 만들어봤습니다.

아래 스크립트는 jest와 연동된 스크립트입니다.

보시면 npm install, npm test 등의 익숙한 명령어들이 보입니다.

name: PR_Test

on: [pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Setup Node
        uses: actions/setup-node@v1
        with:
          node-version: "14.x"

      - name: npm_install
        run: npm install

      - name: run_test_code
        run: npm test

      - name : if_fail
        uses: actions/github-script@v4
        with:
            github-token: ${{ secrets.TOKEN }}
            script : |
              const ref = "${{github.ref}}"
              const pull_number = Number(ref.split("/")[2])
              console.log(pull_number, ref.split("/"), github.ref)
              await github.pulls.createReview({
                ...context.repo,
                pull_number,
                body : "테스트코드를 다시 확인해주세요. ",
                event : "REQUEST_CHANGES"
              })
              await github.pulls.update({
                ...context.repo,
                pull_number,
                state: "closed"
              })
        if: failure()

• script : ~의 경우 javascript 문법으로 이루어져 있습니다.

• on : [pull_request] 부분은 해당 event일 때를 의미합니다.

  이 부분이 가장 중요한게, 초기설정에는 branch : [~] 와 같은 코드가 포함되어있습니다.

  그러나, branch를 특정할 경우 feature/~, etc... 등의 brach에서 올리는 PR을 자동으로 발견하지 못하는 상황이 있었습니다.

  이에 수동으로 빌드하고, 수동으로 테스트하며 actions를 완성했네요.

Jest가 깔려 있는 프로젝트의 CI 환경을 구축하고 싶으시다면 가져다 사용하시면 됩니다!

외에도 push event, PR에 대해 많은 action이 존재합니다.

jobs, github-token 설정하는 방법 등은 구글에 정리글이 많이 있으니 궁금하신 분들은 좀 돌아보셔도 될 것 같네요.

action 탭에서 이렇게 테스트를 통과하지 못한 PR을 확인할수도 있습니다.

굳이 확인 안해도 PR은 테스트를 통과하지 못할 경우 자동으로 closed 처리됩니다. 이것도 설정할 수 있습니다. (closed || 단순 merge 제한)

4.

오늘도 이것저것 신문물을 접해보며 벙쪄있는 하루였습니다.

그래도 테스트가 돌아가는걸 보니까 상당히 즐겁더라구요.

내일은 테스트 로직을 잔뜩 만들어볼 예정입니다.

그럼 내일은 로직을 들고 오겠습니다! 좋은 하루 되세요!

오늘은 기업협업을 프로젝트 발표가 있는 날이었습니다.

개인적으로 프로젝트 발표인 만큼 로직이나 아키텍쳐 등과 같은 발표를 할까 했지만, 발표에 그런 내용을 넣는 것은 큰 의미가 없다는 생각이 들어 시각자료만 만들어두었습니다.

또한 네이버 사다리가 저는 발표가 아닌 Refactoring과 시연 준비를 담당하도록 지시했기에 열심히 발표 아이디어를 제공하고, 시연 전까지 부족했던 부분을 채워넣는 역할을 했습니다.

네이버 갓다리..

열심히 만들었던 Architecture 시각화 자료 => ReadMe에 넣을 예정이다.

아무튼 이런저런 일이 있었는데, 오늘은 Fix를 하는 일이 대부분이었기 때문에 로직을 다루는 일이 주류였습니다.

열심히 PR을 올리며 수정했었네요.

역시 되돌아봐도 참 고생 많았던 것 같습니다.

2.

로직을 fix해야 하는 상황들이 많았다는 것은 아무래도 TDD 방식의 개발이 아니어서인가? 하는 생각이 들었습니다.

어떤 문제가 야기될 수 있는지 인지할 수 없는 개발이라고 생각되네요.

당장 View에 보여질 기능들을 빠르게 구현하다보니 놓친 부분이 많기도 한 것 같습니다.

Refactoring 사항을 좀 체크하며 fix를 진행했는데,

Repository에서 데이터를 처리하는 함수들 중에는 중복이 많기도 하고, 또 hooks 내부에서 좀 더 잘 처리하면 될 것 같은 것들도 있었던 것 같습니다.

그리고 무엇보다도 있어서는 안될 일 중 하나인, View에 Data가 잘못 표시되는 상황이 오늘 많았습니다.

그래서 내일은 Jest를 이용한 test file을 좀 추가해볼 생각입니다.

3.

2번의 생각이 왜 들었는지, 오늘 fix된 사항들을 보며 다시 생각해보고자 합니다.

1. TimeStamp 기준 변경 => serverTime으로 변경 ( 디바이스 시간 무시 )
2. Maps 위치정보 전달 (latitude, longitude)
3. 출퇴근 toggle (useEffect 조건 및 초기값 변경)
4. 이번주 근무 공휴일 제외 logic 및 조건부 렌더 반영
5. 일 평균 근로시간 null 조건 추가
6. 일평균 근로시간 logic 수정
7. 근무예정 margin 추가
8. 근무일지 월요일 기준 지난주 일과 불러오기 logic 추가
9. Day workTime avg logic fix
10. DetailLog logic fix

위 리스트를 각 항목에 맞게 재배치하면,

ADD

• Maps 위치정보 전달 (latitude, longitude)
• 이번주 근무 공휴일 제외 logic 및 조건부 렌더 반영
• 근무예정 margin 추가
• 근무일지 월요일 기준 지난주 일과 불러오기 logic 추가

MODIFY

• TimeStamp 기준 serverTime으로 변경 ( 디바이스 시간 무시 )
• 출퇴근 toggle (useEffect 조건 및 초기값 변경)

FIX

• 일 평균 근로시간 null 조건 추가
• 일평균 근로시간 logic 수정
• Day workTime avg logic fix
• DetailLog logic fix

로 분류할 수 있습니다.

이 중 FIX에 해당하는 사항들은 실제 시연 전 UI Test 단계에서 나온 소중한 녀석들인데, 사실 조금 더 신경썼다면 나올 필요 없었던 친구들이기도 합니다.

1. 로직을 짤 때, 단순히 구현에 초점을 맞추기보다는 조금 더 고민하는 시간이 필요하지는 않을까 생각이 들었습니다.

2. 또는 충분한 테스트를 활용한 개발 조건이라면 이런식으로 배포 전에 빨리 알아낼 수 있다는 점이 정말 매력적일 수 밖에 없지 않을까? 하는 생각이 들기도 했습니다.

4.

중구난방식 서술인데, 오늘은 요약이 좀 가능한 것 같습니다.

1. 역할분담은 역시 네이버 사다리다.

2. View에 기능이 빨리 구현되는 것만이 때로는 정도가 아닐 수 있다.

3. Fix에 해당하는 사항들을 돌아보고, 다음 로직은 신중히 작성하자.

4. UI test도 test다. 툴을 알아보고 나중에 사용해보자!

이상입니다. 읽어주셔서 감사합니다.

안녕하십니까. 오늘은 사실 정말 내용이 없습니다.

확실하게 느낀 것은 저는 디자인에 재능이 정말 없다는 것과 디자이너 분들의 재능과 노력이 얼마나 대단한 것인지 느낀 것 같습니다.

또한 퍼블리싱을 하다 보니, 앱 퍼블리싱을 하시는 분들도 정말 대단한 분들이라는 생각이 드는 것 같습니다.

SafeAreaView... 이 녀석아 정신 좀 차려봐..

그래서 오늘은 공부를 했다기보다, 맨땅에 열심히 헤딩을 했다는 생각이 드는 것 같습니다.

아래 칸을 열심히 채워야 하는데... 왜 채워지지 않는지 고민이 많습니다.

그렇기에 오늘은 TIL보다 해당 레이아웃을 수정하는데 열을 쏟고 싶습니다.

다음주 월요일! 대망의 발표가 끝나고 완성작을 들고 오겠습니다.

그럼 좋은 금요일 되세요.

반갑습니다.

오늘은 흘러가듯 한 챕터로 글을 마치겠습니다.

오늘 내용은 제목 그대로 기능 쳐내기를 좀 했습니다.

예상치 못한 부분에서 꽤나 고민을 하기도 했고, 오랜만에 라이브러리 공식문서 나들이를 좀 했던 것 같습니다.

date-picker! calendar! calendar-picker!

이런 녀석들을 좀 보다보니 react-datePicker가 얼마나 혜자였는지 알 수 있었습니다.

라이브러리를 까보면서 원하는 기능이 뭐가 있는지도 열심히 탐구했으나, 결과적으로 만든 함수와 기능을 사용하지 않기로 결정되었습니다.

조금 아쉽지만, 다음에 또 필요하면 그 때 사용하도록 하죠!

썸네일은 오늘 팀이 함께 쳐낸 기능들입니다.

뭐가 많기는 많네요

실제로 view에 보여지는 것은

극히 일부의 기능들인데, 로직의 수는 꽤나 많습니다.

현업에서 이보다 훨씬 큰 규모의 프로젝트를 진행하시는 분들은 얼마나 힘들지 가늠이 잘 되질 않네요.

오늘 가장 힘들었던 부분은 사실

1. firebase DB에
2. calendar로 pick한 각 day date의 주차를 의미하는 week date 로 접근해
3. 반환된 값 내에서 실제 pick한 day date 사이의 data를 추출하고
4. 다시 반환값 내에 추출된 day date로 접근하여
5. 실제 근무했던 log를 얻어낸 뒤 배열로 정렬하고
6. log data의 시작과 끝 값으로 계산한
7. 근무시간(number)를
8. 순회 중에 반복하며 더해준 뒤
9. 원하는 시간값(number)을
10. string화 하는

부분이었습니다.

무려 두시간 가까이 생각했던 것 같습니다.

그 이유는

두 번 정제했음에도 거지같은 자료구조를 만든 과거의 제가 있습니다.

무튼 저런 비스무리한 무언가를 가져다가

async getWorkTimeAverage(startDate: string, endDate: string): Promise<any | null> {
    const uid = auth().currentUser?.uid;

    const startWeek = calcWeekOfYear(startDate);
    const endWeek = calcWeekOfYear(endDate);
    let commuteDayArray: string[] = [];
    let commuteTime = 0;

    try {
      let commuteData = await database()
        .ref(`/${uid}/commuteData`)
        .orderByKey()
        .startAt(`${startWeek}`)
        .endAt(`${endWeek}`)
        .once('value', snapshot => {
          return snapshot.val();
        });

      // 해당 일자 사이의 timeStamp 값 commuteDayArray에 저장.
      Object.values(Object.values(commuteData)[0].value).forEach((week: any) => {
        Object.keys(week).forEach(day => {
          if (stringToMilliSec(startDate) < parseInt(day, 10) || parseInt(day, 10) < stringToMilliSec(endDate)) {
            commuteDayArray.push(day);
          }
        });
      });

      Object.values(Object.values(commuteData)[0].value).forEach((week: any) => {
        commuteDayArray.forEach(commuteDate => {
          if (week[commuteDate]) {
            let start: any = Object.values(week[commuteDate]).sort()[0];
            let end: any = Object.values(week[commuteDate]).sort()[Object.values(week[commuteDate]).sort().length - 1];
            commuteTime = end - start + commuteTime;
          }
        });
      });
      return [
        endWeek - startWeek > 0
          ? calcMiliSecTimeHourMinuteString(commuteTime / (endWeek - startWeek + 1))
          : calcMiliSecTimeHourMinuteString(commuteTime),
        endWeek - startWeek > 0 ? commuteTime / (endWeek - startWeek + 1) : commuteTime,
      ];
    } catch {
      return null;
    }
  }

이런 과정을 대충 슥- 거치면?

이렇게 귀여운 데이터로 바뀝니다!

endWeek - startWeek > 0
          ? calcMiliSecTimeHourMinuteString(commuteTime / (endWeek - startWeek + 1))
          : calcMiliSecTimeHourMinuteString(commuteTime)

이 부분이 해당 데이터의 형태를 결정하는 부분인 것 같습니다.

그 외에도 슬슬 상태관리를 신경써볼까? 해서 Redux 공부를 추석동안 했으나,

아직 적용하지 않았기에

custom hooks 를 이전보다 더 잘 활용하는 방법을 찾고, 듣도 보도 못했던 self state Refactoring을 해버렸습니다.

의존성 배열에 인자로 받은 timeStamp를 추가함으로써 지속적인 load 기능을 담당하는 하나의 state가 만들어진 것 같습니다.

이건 오늘 좀 새로운 발견이라 놀랐습니다.

그만큼 제가 React FC에 대한 근본이 없다는게 아닐까요.

여전히 typeScript는 공부중입니다만, 현재는 에러메세지 처리하며 실력쌓기가 진행되는게 아닐까 싶네요.

그래도 언제나 strict로 코딩하고는 있습니다.

이것저것 많이 하다 보니까 오늘 생각의 흐름대로 적어버렸습니다.

다음엔 더 좋은 내용들로 찾아올게요. 읽어주셔서 감사합니다.

일주일간 온전히 프로젝트에 집중했습니다.

정말 더없이 즐겁기도 했고, 머리카락이 꽤나 빠진게 아닐까 싶을 일주일이었습니다.

난생 처음 DB를 설계해보기도 하고,

No SQL! 어거지로 가보자는 마인드입니다.

처음으로 경험해본 React-Native 개발에 필요한게 뭐가 있을지 고민하기도 했습니다.

전혀 얕고 간단하지 않은데, 쉽다고 한 사람은 누군지 궁금하기도 했습니다.

오우, native 좀 칠 줄 아는 사람인가봅니다.

그래도 이것저것 경험해보고, 세팅해보고, 또 세팅해본 결과...

진짜 개발이 뭔지 어렴풋이 알게 되는 느낌이기도 합니다.

개발은... 어쩌면 모두가 호환 가능한 세팅이 아닐까요..?

네. 잡설은 그만 하도록 하고, 중요한 키워드를 적어보겠습니다.

1. 일은 정말로 비례하지 않더라.

2. 로직짜는게 제일 행복한 시간이다.

3. Redux... 이젠 정말 시작하자!

로 집중해보도록 하겠습니다.

PR은 그짓말 안해...

2. 일은 정말로 비례하지 않는다.

네. 일이라는 것은 정말 난이도가 비례하지 않더라는게 가장 중요한 내용인 것 같습니다.

분명 planning에서 열심히 포커를 칠 때는 "아 ㅋㅋ 이쯤이야" 했던 것들도 절대 그렇지 않았습니다.

애초에 기준이 1점짜리인데 5점짜리로 평가된 기분이랄까요.

이상하게 하나 해결하는데 이것저것 손볼게 많았습니다.

이런 간단한 프로젝트조차 예상하지 못한 부분에서 변수가 많았는데, 실제 현업에서 진행하는 프로젝트의 cost는 어떨지 상상할 수 없게 되었습니다.

라이엇 클라이언트 구리다고 욕하던 제가 부끄러워지는 일주일이었습니다.

그래도 덕분에 클린 아키텍처, 왜 클린 코드 하는지 잘 알게 되었습니다.

하나의 로직을 수정하는데 있어 거미줄이 될 경우 정말 지옥을 맛볼 수 있지 않을까 하는 생각이 점점 들기 시작했거든요.

분명 어딜 손봐야 하는지 알면서도, 잘 모르기에 모두 찍어보는 과정을 경험해야 해서 더 어려운 것 같습니다.

보통은 Repository 선에서 정리되는데... 불안하더라구요.

그러니 우린 아는 선에서라도 최대한 깔끔하고, 명확한 코드를 짜는 것으로 시작해야 할 것 같습니다.

1. DRY-KISS? SOLID? S만 지켜도 꽤나 준수한 코드가 나온다.

   아 ㅋㅋ 자꾸 카운터에서 햄버거 만들게 시키지 말라고 ㅋㅋ

2. 이 로직이 현재 파일에 있어도 될지만 잘 고려해도 된다.

   어차피 대부분은 틀린 답이니까.

3. 어거지로 구분하더라도, 독립된 구조로 구분해보려 노력하자.

   이게 그 개방....폐쇄...뭐 그런건가유...?

사실 LID는 적용할 틈도 없었지만, pratt의 조언들이 점점 SOLID를 공부할수록 맞아 떨어지는 것 같아 소름이 돋고 있습니다.

그러니, SOLID를 공부하는게 옳지 않을까 싶습니다.

3. 로직짜는게 행복한 시간이다!

네. 지옥같은 세팅을 수차례, 아니? 매일 오전마다 경험하면서 오늘 처음 들었던 생각입니다.

로직을 구성하는 하루가 제일 보람차고, 행복한 시간들입니다.

오전 내내 android와 ios 사이에서 줄타기하는 이 시간들,

cd android && ./gradlew clean

npm cache clean --force

X code -> command + shift + k or excluded architecture + url scheme,

npx react-native run-ios, npx react-native run-android

거기에 AVD manager wipe data, pod deintegrate && install, arch -x86_64 시리즈...

또 수도 없이 많지만, 이제는 정말 세팅광이 되어버린 수준입니다.

알지도 못했던 .plist 뒤져보기, AppDeligate 훔쳐보기, build.gradle 털기 등등...

정말 많은 세팅을 진행하지 않았을까 하고 생각이 듭니다.

심지어 android는 아직도 app crush를 수시로 뱉어대고 있습니다.

에러코드는 이제 우습지도 않아...

그러니 모두 로직을 짤 수 있는 시간을 소중히 생각하길 바랍니다.

저는 이제 컴퓨터랑 슬슬 대화를 하고 있어요 😂

4. Redux... 내가 간다!

이야... 이것저것 참 많죠?

버튼 event 하나에 필요한 state입니다.

문제는 저런 버튼 말고도 progress bar, cell... 다양한 것들이 하나의 view에 나타난다는 점이죠.

전부 다른 data를 load하고, save해야 합니다.

이제는 하나의 presenter에서 useEffect로 관리하는 것은 극히 비효율적일 수 밖에 없습니다.

원래라면 component 분리로 어떻게든 해결했겠지만, presenter라는 view HOC 개념을 적용해서 이렇게 된거긴 합니다.

따라서 Redux와 hook을 적절히 혼용하며 상태를 관리하는건 어떨까! 하는 생각이 들었습니다.

꿈만 같은 이야기이긴 한데, 추석 사이에 빠르게 쳐서 다음주 중으로 Redux까지 적용하는게 목표입니다.

5.

그냥저냥 한 주를 잘 보낸것 같기도 합니다.

PR만 봐도 어거지로 짠 로직이 꽤나 있구나... 싶기도 하고, 이제 클린 아키텍쳐 비슷한 무언가로도 로직 위치를 결정할 수 있기도 하니 성장한게 아닐까 싶네요.

그래도 아직 한참 남았습니다.

firebase DB 구조만 봐도 부족함이 느껴지고, 매번 로직을 짤 때 DB 구조를 변경하고 있으니까요.

그래도 아름답다... 그죠?

아무튼 우리 모두 화이팅입니다.

즐거운 추석 되시고, 추석 내내 풀리지 않던 문제 잘 풀리시길 기도할게요.

모두 행복하세요!

반갑습니다.

오늘은 새로운 것과 이전의 것을 함께 다루니 온고지신과도 같네요!

네. 제목 그대로 React-native-community/geolocation 을 이용한 것과 기존 만들어둔 DB 구조에 대한 고민이 주제입니다.

오늘의 키워드는 office hour 시간에 나온 것들과 이전 프로젝트 구현에 있어 느꼈던 것들을 모아보겠습니다.

• date와 log
• appstate
• geolocation & reverseGeolocation

이정도가 되겠습니다.

차례대로 가보시죠.

2. date와 log

이전까지의 DB 구조에서 통근 data를 관리하는 방식은 다음과 같았습니다.

예)

commute : {
  "end" : "13:00:00",
  "start" : "01:00:00",
  "time" : number~,
  "timeLag" : "12:00:00",
}

문제는 해당 구조로 자료를 저장할 경우

• 다양한 기기에서 출퇴근을 관리할 때 데이터가 꼬일 수 있다.
• 당일 출퇴근 버튼을 여러번 눌렀을 때, 올바르게 반영할 수 없다.

등과 같은 이슈가 발생할 수 있습니다.

저는 당장 당일 출퇴근 toggle에 대해서만 고민하고 있었는데 pratt은 다기종까지도 고려할 수 있는 것을 보고 좀 더 넓게 볼줄도 알아야겠다는 생각이 들었습니다.

경험과 지식은 역시 위대한 것 같습니다.

따라서, 해당 방식이 아니라 출근과 퇴근의 경로를 분산시키는 방법을 사용하는 것은 어떨지 힌트를 받았습니다.

지금 당장 생각해보면

{ 
  commute : [...year[...week{...day}]],
  startlog : [...year, [...week, [...day]]],
  endlog : [...year, [...week, [...day]]] 
}

혹은 start와 end log를 매일 리셋시키는 방법을 사용하는건 어떨까 싶기도 합니다.

아직 당장은 데이터를 어떤 방법으로 구성하는게 효율적일지 잘 모르겠습니다.

그러나 No SQL! 그냥 갈아엎고 다시 만들기도 쉬우니 막 해보겠습니다.

3. Appstate

App은 현재 우리 폰만 보더라도 background와 foreground라는 개념이 존재합니다.

이를 구분할 수 있는 개념이 Appstate인데, 자세한 사항은 RN 공식 문서를 추천드리겠습니다.

처음 알게된 키워드인데, 본격적으로 사용하기 전에 저도 정독할 예정입니다.

steve 화이팅!

4. geolocation

네. 라이브러리입니다.

휴대전화의 위치센서를 사용할 수 있는 기가 막힌 라이브러리죠.

android studio는 왜... 문제인지 모르겠습니다.

그래도 ios에서 테스트해본 결과 괜찮았습니다.

알아보니 샌프란시스코에 있더라구요...

위 날짜와 시간은 하드코딩입니다!

아직 DB가 완성이 아니라 불러오기도 뭐해서 우선은 그대로 두었습니다.

오늘 steve가 로직을 작성하고, 제가 refactoring 했던 코드 올리고 마치겠습니다.

다들 좋은 목요일밤 되세요!

MainUseCase

import {MAPS_API_KEY} from '../../../env.json';

import {UsingFirebaseDB} from '../../data/repository/UsingFirebaseDB';
import {ILocation} from '../../presentation/interface/IGeolocation';

export class MainUseCase extends UsingFirebaseDB {
  async reverseGeolocation(location: ILocation) {
    const {latitude, longitude} = location;

    const adressCall = await fetch(
      `https://maps.googleapis.com/maps/api/geocode/json?latlng=${latitude},${longitude}&language=ko&key=${MAPS_API_KEY}`,
    );
    const adressJson = await adressCall.json();

    const addressArr = adressJson.results[0].formatted_address.split(' ');
    const locationAddress = `${addressArr[2]} ${addressArr[3]}`;

    return locationAddress;
  }
}

useLocation

import {useEffect, useState} from 'react';
import {MainUseCase} from '../../domain/useCase/MainUseCase';
import {ILocation} from '../interface/IGeolocation';

import Geolocation from '@react-native-community/geolocation';
import {Alert} from 'react-native';

const mainLogic = new MainUseCase();
const {reverseGeolocation} = mainLogic;

export const useLocation = () => {
  const [location, setLocation] = useState<ILocation | null>(null);
  const [address, setAddress] = useState<string>('');

  useEffect(() => {
    if (location === null) {
      Geolocation.getCurrentPosition(
        position => {
          const {latitude, longitude} = position.coords;
          setLocation({latitude, longitude});
        },
        error => {
          if (error.code === 1) {
            Alert.alert('위치확인 승인이 필요합니다');
          } else if (error.code === 2) {
            Alert.alert('위치확인을 사용할 수 없습니다.');
          } else {
            Alert.alert('시간이 초과되었습니다.');
          }
          console.log(error.code, error.message);
        },
      );
    } else {
      reverseGeolocation(location).then(locationAddress => {
        setAddress(locationAddress);
      });
    }
  }, [location, address]);

  return [address];
};

MainPresenter

import React, {useEffect, useState} from 'react';
import {useLocation} from '../../hooks/useLocation';
import {Main} from './Main';

export const MainPresenter = ({navigation}: any) => {
  const [address] = useLocation();

  useEffect(() => {}, []);
  return <Main navigation={navigation} address={address} />;
};

네. 반갑습니다.

본격적인 프로젝트의 시작입니다.

정말 즐거운데, 이게 참 즐겁다가 불행하다가 정말 모르겠습니다. 이제는 저도 모르겠네요.

뭐든 새로운 기술을 사용해보는건 참 흥미롭습니다.

뭐 때문에 막힐지 모르니까 매일이 크레바스 위를 걷는 기분인 것 같네요.

그래도 오늘 할당을 다 채웠다는 사실이 정말 기쁩니다.

오늘 일감

• Text 제한하기(min 20, max 300)
• 실시간으로 당일, 전일 데이터 관리하는 로직 작성하기
  • 00:00 기준 오늘 할일 => 어제 한 일 이동(DB load : on)
  • 저장하기 (DB save : set) 버튼 구현
  • 터치 시 수정기능 (TextArea)

완료사항

• Text 제한하기(min 20, max 300) ✔️
• 실시간으로 당일, 전일 데이터 관리하는 로직 작성하기 save & onLoad로 해결? ✔️
  • 00:00 기준 오늘 할일 => 어제 한 일 이동(DB load : on) ✔️
  • 저장하기 (DB save : set) 버튼 구현 ✔️
• 터치 시 수정기능 (TextArea) ✔️
• DB 설계 일부 변경하기 (task dir) ✔️
• dayjs 로직 정리하기 ✔️

돌아보니 이것저것 그래도 좀 했네요.

나름 즐거운 하루인건 맞았나봅니다.

2. firebase DB setting error(android)

오늘은 신박한 DB 연동 문제가 있었습니다.

이상하게 어제까지만 해도 잘 되던게 오늘 갑자기 자고 일어나니 모르쇠로 일관하더라구요.

android는 참 알다가도 모르겠습니다.

꾸역꾸역 세팅을 처음부터 다시 설정하며, firebase project 설정을 다시 추적하던 중에 이유를 알 수 있었습니다.

• google-services.json을 확인해보니,

   "project_info": {
    "project_number": "~",
      ---
    "firebase_url": "https://~", // firebase_url 이 녀석이 없었습니다..
      ---
    "project_id": "~",
    "storage_bucket": "~"
  },

저게 왜 없어졌는지 저는 정말 알다가도 모르겠더군요.

아마 초기세팅에서부터 빠져있었거나, 아니면 중간에 DB연동 이슈를 해결하려고 이리저리 적용하다 사라진게 아닐까 싶습니다.

firebase DB를 사용하는데 어려움이 있으신 분들은 이걸 보고 해결하시면 어떨까 싶기도 하네요.

1. 저것 말고도 해결과정에서 android studio에 직접 google-services.json을 드래그해서 refactor 할 경우 프로젝트가 박살나는 것도 하나의 이슈였습니다.

   당황하지 않고, 바로 clone 다시 만들기. local에서 작업파일 살려오기.

이것저것 원시적인 방법으로 돌아가지 않을 수 있었습니다.

때로는 일차원적인 방법이 가장 최고일지도 모르겠네요.

3. dayjs

이녀석 참 물건이었습니다.

제 벨로그를 보셨던 분들은 그동안 제가 Date()와 얼마나 많은 싸움을 했었는지 아실 수도 있겠습니다.

1차 프로젝트에서의 countdown timer, 2차에서의 calendar... 3차는 DB와 Date?

그냥 대충 dayjs().~ 해버리면 뚝딱입니다.

물론 필요한 로직 정도는 짜야겠지만, 변환과정을 생략할 수 있다는건 축복인 것 같습니다.

그래서 이번 로직은 가독성이 상당히 좋습니다.

로직도 아니고, 그냥 뭐랄까요... 어... 좀 더 편하게 가져다 쓰기?

그 쯤 되는 것 같습니다.

필요하신 분들은 꼭 써보시길 바랍니다.

2019년 기준 moment.js는 개발을 중단하기로 했습니다. 또한 moment.js는 오래된 라이브러리임에 따라 안정성을 유지한 채 확장하기 어렵고, 사용 목적에 비해 큰 메모리를 차치하기에 요즘은 dayjs로 갈아타고 있다고 합니다.

dayjs의 경우 지속적으로 개발하고 있고, locale도 100여개 정도를 지원한다고는 합니다.

이정도 프로젝트에서는 뭘 사용해도 상관없겠지만요.

import dayjs from 'dayjs';
import 'dayjs/locale/ko';

dayjs.locale('ko');

export const dayjsNow = () => {
  return dayjs().format('YYYY-MM-DD HH:mm:ss');
};

export const nowYear = () => {
  return dayjs().year();
};

export const nowMonth = () => {
  return dayjs().month() + 1;
};

export const nowDate = () => {
  return dayjs().date();
};

export const nowTime = () => {
  return `${dayjs().hour()}:${dayjs().minute()}:${dayjs().second()}`;
};

export const nowDateArray = () => {
  return [nowYear(), nowMonth(), nowDate()];
};

export const todayYearMonthDate = () => {
  return dayjs().format('YYYY-MM-DD');
};

export const yesterdayYearMonthDate = () => {
  const yesterday = `${nowYear()}-${nowMonth()}-${nowDate() - 1}`;
  return dayjs(yesterday).format('YYYY-MM-DD');
};

export const timeLag = (fromDayString: string, subDayString: string) => {
  const time = dayjs(subDayString).valueOf() - dayjs(fromDayString).valueOf();
  const hour = Math.floor(time / (60 * 60 * 1000));
  const minute = Math.floor((time / (60 * 1000)) % 60);
  const seconds = Math.floor((time / 1000) % 60);

  const workedTime = `${hour}:${
    minute < 10 ? '0' + minute : minute
  }:${seconds}`;
  return workedTime;
};

이전 프로젝트에서는 year, month, day data를 따로 요청할 일이 없었는데, 이번 DB 특성상 따로 사용할 일이 있어 우선은 빼두었습니다.

셋 다 사용하게 될 경우에는 array method를 사용하는게 나을 것 같네요.

개인적으로 slice와 split을 좋아하지 않기도 하고, 최적화에 있어 유의미하지 않겠다는 판단이 들어 따로 두었습니다.

그래도 프로젝트 후반부에는 어떨지 모르겠습니다.

4.

그 이외에도 뭐...

import React, {useEffect, useState} from 'react';
import {WorkLogUseCase} from '../../../domain/useCase/WorkLogUseCase';

import {WorkLog} from './WorkLog';

const workLogLogic = new WorkLogUseCase();
const {buttonDisableTest, getYesterdayWorkLog, getTodayWorkLog, saveWorkLog} =
  workLogLogic;

const loadWorkLog = (
  setYesterdayWorkLogText: React.Dispatch<React.SetStateAction<string>>,
  setTodayWorkLogText: React.Dispatch<React.SetStateAction<string>>,
) => {
  getYesterdayWorkLog().then(workLogObj => {
    if (workLogObj !== null) {
      setYesterdayWorkLogText(workLogObj.workLog);
    }
  });
  getTodayWorkLog().then(workLogObj => {
    if (workLogObj !== null) {
      setTodayWorkLogText(workLogObj.workLog);
    }
  });
};

export const WorkLogPresenter = () => {
  const [yesterdayWorkLogText, setYesterdayWorkLogText] = useState<string>('');
  const [todayWorkLogText, setTodayWorkLogText] = useState<string>('');
  const [saveOrInsert, setSaveOrInsert] = useState<string>('저장하기');
  const [saveButtonDisabled, setSaveButtonDisabled] = useState<true | false>(
    true,
  );
  const [insertCheck, setInsertCheck] = useState<true | false>(false);

  useEffect(() => {
    if (!insertCheck) {
      loadWorkLog(setYesterdayWorkLogText, setTodayWorkLogText);
    }
    if (yesterdayWorkLogText !== undefined && todayWorkLogText !== undefined) {
      buttonDisableTest(yesterdayWorkLogText.length, todayWorkLogText.length)
        ? setSaveButtonDisabled(true)
        : setSaveButtonDisabled(false);
    }
  }, [yesterdayWorkLogText, todayWorkLogText, insertCheck]);

  return (
    <WorkLog
      yesterdayWorkLogText={yesterdayWorkLogText}
      todayWorkLogText={todayWorkLogText}
      setYesterdayWorkLogText={setYesterdayWorkLogText}
      setTodayWorkLogText={setTodayWorkLogText}
      saveOrInsert={saveOrInsert}
      saveButtonDisabled={saveButtonDisabled}
      setInsertCheck={setInsertCheck}
      saveWorkLog={() => {
        saveWorkLog(yesterdayWorkLogText, todayWorkLogText);
      }}
    />
  );
};

이런 녀석이나

import {WorkLogRepository} from '../../data/repository/WorkLogRepository';

export class WorkLogUseCase extends WorkLogRepository {
  buttonDisableTest(yesterdayTextLength: number, todayTextLength: number) {
    if (
      yesterdayTextLength < 20 ||
      todayTextLength < 20 ||
      yesterdayTextLength >= 300 ||
      todayTextLength >= 300
    ) {
      return true;
    } else {
      return false;
    }
  }

  saveWorkLog(yesterdayWorkLogText: string, todayWorkLogText: string) {
    if (
      yesterdayWorkLogText.length < 20 ||
      todayWorkLogText.length < 20 ||
      yesterdayWorkLogText.length >= 300 ||
      todayWorkLogText.length >= 300
    ) {
      return;
    } else {
      return super.setWorkLogInDB(yesterdayWorkLogText, todayWorkLogText);
    }
  }
}

이런 녀석,

import {UsingFirebaseDB} from './UsingFirebaseDB';
import {todayYearMonthDate, yesterdayYearMonthDate} from '../../utils/dayjs';

import {IWorkLog} from '../../presentation/interface/IWorkLog';
export class WorkLogRepository extends UsingFirebaseDB {
  async getYesterdayWorkLog(): Promise<IWorkLog | null> {
    try {
      const workLog = await super.getDataFromDB(
        `/uid/task/${yesterdayYearMonthDate()}`,
        'value',
        snapshot => {
          return {...snapshot.val()};
        },
      );
      return workLog;
    } catch {
      return null;
    }
  }
  async getTodayWorkLog(): Promise<IWorkLog | null> {
    try {
      const workLog = await super.getDataFromDB(
        `/uid/task/${todayYearMonthDate()}`,
        'value',
        snapshot => {
          return {...snapshot.val()};
        },
      );
      return workLog;
    } catch {
      return null;
    }
  }

  async setWorkLogInDB(yesterdayLogText: string, todayWorkLogText: string) {
    try {
      await super.setDataToDB(
        `/uid/task/${yesterdayYearMonthDate()}/workLog`,
        yesterdayLogText,
      );
      await super.setDataToDB(
        `/uid/task/${todayYearMonthDate()}/workLog`,
        todayWorkLogText,
      );
    } catch {
      console.log('DB update Error! : WorkLog');
    }
  }
}

이런 녀석이 있긴 합니다.

load 함수를 useCase로 뺄까 말까 고민중인데, 아무래도 인자가 setState 함수에 해당하기 때문에 고민이 되는 것 같습니다.

그 이외에 디테일한 수정은 팀의 방향성에 맞춰 리팩토링 & unit test 시간에 진행하기로 결정했습니다.

그럼 오늘도 모두 고생하셨습니다.

저는 내일 다른 글로 뵙겠습니다. 감사합니다.

그림은 밥 삼촌의 The Clean Architecture 책에 나오는 다이어그램입니다.

오늘은 꼭 Clean architecture를 적용하겠다는 일념하에 하루종일 코드만 바라보고 있었습니다.

그런데 역시 마법은 일어나지 않았고, 큰 고뇌에 빠지기만 하나 싶던 와중에 가뭄에 단비같은 Office hour 시간이 찾아왔습니다.

무게를 가볍게 하는 것 또한 clean architecture의 본래 목적이었음을 잊었기에 고민이 깊어지지 않았나 생각이 듭니다.

이어서 코드로 보겠습니다.

2.

Repository

먼저, repository의 형태입니다.

import database, {FirebaseDatabaseTypes} from '@react-native-firebase/database';

type EventType = FirebaseDatabaseTypes.EventType;
type DataSnapshot = FirebaseDatabaseTypes.DataSnapshot;

export class UsingFirebaseDB {
  getDataFromDB(
    dir: string,
    eventType: EventType,
    successCallback: (a: DataSnapshot, b?: string | null) => any,
  ) {
    return database().ref(dir).once(eventType).then(successCallback);
  }

  setDataToDB(dir: string, value: any) {
    return database().ref(dir).set(value);
  }

  updateDataInDB(dir: string, value: any) {
    return database().ref(dir).update(value);
  }
}

결과를 생각했을 때, 이러한 코드는 사실 respository 중에서도 베이스가 되는 파일이어야 할 것 같습니다.

1. repository는 단순히 CRUD 메서드의 추상만 존재하는 것이 아니라 실질적인 접근이 이루어지는 로직을 다루어야 한다.

2. 이어서 useCase에서도 나오겠지만, repository의 무게가 가벼워질수록 useCase에서 처리할 로직이 많아지고, 이는 본래 유연한 변경이 가능해야 한다는 조건과 다른 형태의 App이 된다.

3. 후에 DB를 통째로 바꾸어야 하는 상황에서 어떻게 비교적 간단하게 처리할 수 있을지 고민하는 것으로 repository를 만들자.

등의 조언을 office hour 시간 Q&A를 통해 얻을 수 있었습니다.

이어서 useCase로 넘어가봅시다.

useCase

import {Alert} from 'react-native';

import {UsingFirebaseDB} from '../repository/UsingFirebaseDB';
import {
  GoogleSignin,
  statusCodes,
} from '@react-native-google-signin/google-signin';
import auth from '@react-native-firebase/auth';

import {CLIENT_ID} from '../../../env.json';
export class SignInUseCase extends UsingFirebaseDB {
  async getAccessUserEmailFromDB() {
    try {
      const email = await super.getDataFromDB(
        '/access/email',
        'value',
        snapshot => {
          return [...snapshot.val()];
        },
      );
      return email;
    } catch {
      return null;
    }
  }

  async signInGoogleAuth() {
    GoogleSignin.configure({
      webClientId: CLIENT_ID,
    });

    try {
      const userInfo = await GoogleSignin.signIn();
      const {idToken, user} = userInfo;
      const googleCredential = auth.GoogleAuthProvider.credential(idToken);
      await auth().signInWithCredential(googleCredential);
      return user;
    } catch (e) {
      if (e.code === statusCodes.SIGN_IN_CANCELLED) {
        console.log('유저가 로그인 취소');
      } else if (e.code === statusCodes.IN_PROGRESS) {
        console.log('로그인 진행 중');
      } else if (e.code === statusCodes.PLAY_SERVICES_NOT_AVAILABLE) {
        console.log('플레이 서비스를 사용할 수 없음');
      } else {
        console.log('그외 에러');
      }
      Alert.alert('다시 로그인 해주세요');
      return {};
    }
  }
}

useCase의 로직은 제가 작성한 getAccessUserEmailFromDB와 Steve가 작성한 signInGoogleAuth로 이루어져 있습니다.

singleton을 깊게 공부하지 않았기에 적용에 대해서는 아직 잘 모르겠습니다만, 최적화를 고려할 때 필요한 부분에 적용하자는 마인드입니다.

useCase의 문제는 다음과 같았습니다.

1. repository에서 다룰 수 있는 메서드를 굳이 다루고 있다.

2. 이어서 나오겠지만, 비즈니스 로직을 지나치게 보수적으로 정했다.

정도가 Q&A 시간에 머리에 떠올랐던 것 같습니다.

그럼 이어서 presenter & view를 봅시다.

Presenter & View

먼저, presenter입니다.

import React, {useEffect, useState} from 'react';

import {SignInUseCase} from '../model/useCase/SignInUseCase';
import {SignIn} from '../view/SignIn';

interface SignInUser {
  id: string;
  name: string | null;
  email: string;
  photo: string | null;
  familyName: string | null;
  givenName: string | null;
}

const signInLogic = new SignInUseCase();
const {getAccessUserEmailFromDB, signInGoogleAuth} = signInLogic;

const handleSocialSignIn = (
  setSignInUserInfo: React.Dispatch<React.SetStateAction<SignInUser | {}>>,
) => {
  signInGoogleAuth().then(userInfo => {
    setSignInUserInfo(userInfo);
  });
};

const loadAccessEmail = (
  setAccessUserEmail: React.Dispatch<React.SetStateAction<string[] | null>>,
) => {
  getAccessUserEmailFromDB().then(email => {
    setAccessUserEmail(email);
  });
};

const signInValidation = (
  signInUserInfo: SignInUser | {},
  accessUserEmail: string[] | null,
) => {
  if (signInUserInfo && accessUserEmail?.includes(signInUserInfo.email)) {
    return true;
  } else {
    return false;
  }
};

export const SignInPresenter = ({navigation}: any) => {
  const {navigate} = navigation;

  const [accessUserEmail, setAccessUserEmail] = useState<string[] | null>([]);
  const [signInUserInfo, setSignInUserInfo] = useState<SignInUser | {}>({});

  useEffect(() => {
    if (accessUserEmail !== null && accessUserEmail.length === 0) {
      loadAccessEmail(setAccessUserEmail);
    }
    if (signInValidation(signInUserInfo, accessUserEmail)) {
      navigate('Main');
    }
  }, [accessUserEmail, signInUserInfo]);

  return (
    <SignIn
      handleSocialSignIn={() => {
        handleSocialSignIn(setSignInUserInfo);
      }}
    />
  );
};

1. presenter의 경우 설계 목적과 달리 광범위한 로직을 포함하고 있습니다.

제 생각에 useCase로 일부 이전해야 할 부분이 있는 것 같습니다.

예를 들자면, signInValidation, handleSocialSignIn, loadAccessEmail 등의 함수는 useCase에 작성되는게 맞는 것 같습니다.

그 외에는 딱히 없는 것 같으니 넘어가도록 하겠습니다.

이어서 view입니다.

import React from 'react';
import {StyleSheet} from 'react-native';
import {Image, VStack} from 'native-base';
import {GoogleSigninButton} from '@react-native-google-signin/google-signin';

interface ISignInProps {
  handleSocialSignIn: () => void;
}

export const SignIn = ({handleSocialSignIn}: ISignInProps) => {
  const {googleButton} = style;

  return (
    <VStack flex={1} bg="white" justifyContent="center" alignItems="center">
      <Image
        source={require('../../data/images/soomgo_logo_rgb.png')}
        alt="Logo"
        w="70%"
        resizeMode="contain"
        marginBottom={75}
      />
      <GoogleSigninButton
        style={googleButton}
        size={GoogleSigninButton.Size.Wide}
        color={GoogleSigninButton.Color.Light}
        onPress={handleSocialSignIn}
      />
    </VStack>
  );
};

const style = StyleSheet.create({
  googleButton: {
    position: 'absolute',
    bottom: 90,
  },
});

네. view는 view 답네요.

딱히 문제는 없어보이지만, 굳이 문제라면 nativebase와 RN component를 섞어서 사용해야 한다는 점?

그런 부분이 문제가 아닐까 싶습니다.

3.복기

오늘의 문제

Repository

1. repository는 단순히 CRUD 메서드의 추상만 존재하는 것이 아니라 실질적인 접근이 이루어지는 로직을 다루어야 한다.

경로, 요청, CRUD를 혼합한 특정 기능에 요구되는 DB 요청 메서드를 만들자.

2. repository의 무게가 가벼워질수록 useCase에서 처리할 로직이 많아지고, 이는 본래 유연한 변경이 가능해야 한다는 조건과 다른 형태의 App이 된다.

독립적인 형태로! 가볍게! DRY-KISS는 필수!

3. DB를 통째로 바꾸어야 하는 상황이라면 어떻게 비교적 간단하게 처리할 수 있을지 고민하는 것으로 repository를 만들자.

코딩을 줄일 수 있다면 줄이는 것이 언제나 고려사항에 있어야한다.

UseCase

1. repository에서 다룰 수 있는 메서드를 굳이 다루고 있다.

애매모호함을 탈피할 수 있도록 기준을 세우자.

2. 비즈니스 로직을 지나치게 보수적으로 정했다.

사실 일단 모아두고 나중에 분배하는 방법도 나쁘지 않아보인다.

Presenter

1. presenter의 경우 설계 목적과 달리 광범위한 로직을 포함하고 있습니다.

이제 누가 useCase?

View

1. nativebase와 RN component(StyleSheet)를 섞어서 사용해야 한다.

좀 더 문서를 읽어본다면 해결할 수 있지 않을까~

이상입니다.

지옥같은 하루였습니다.

생전 처음으로 레포를 싹 다 갈아엎고 다시 만들 일이 있을 줄은 몰랐네요.

이게 다~ 안일했던 저의 잘못이라는게 누굴 탓할 수 없어 가슴이 아픕니다.

먼저, 오늘의 교훈부터 읊고 시작하겠습니다.

1. commit 관리를 생활화하자.

2. rebase는 선택이 아니라 필수다.

3. pull은 신중하게 하자.

4. 다시는 후회하지 말자.

앞으로 다시는! 후회하지 않았으면 좋겠습니다.

git 갈갈이를 벌써 3번은 한 것 같은데, 이제는 바닥도 없긴 합니다.

아무튼 이런 저런 노가다 끝에 결과적으로는 모든 commit을 정리할 수 있었고, PR 이후 merge된 대부분의 내용을 건졌습니다.

아 ㅋㅋ

캬~ 낭만있다... 그죠?

흔적도 없는 repo를 보니? 이번 주말 상태가 어떨지 보이는 것 같습니다.

그래도 이제 git은 두렵지가 않습니다.

이렇게 성장한거겠죠...?

2.

여기서 꿀팁 몇 개 전달해드리자면,

1. !reject? 깝치지마. push -f 는 신이다.

2. merge? 그것도 rebase -i 가 다 해준다.

3. commit 정리? 그것도 rebase -i HEAD~~ 가 다 해준다.

4. 하위 branch에서 막무가내 pull? 그것도 rebase가 다 해결해준다.

5. git이 꼬여도 오늘 하루는 날렸다고 생각하고 차근차근 main부터 살려나가면 된다.

commit 복사가 된 상태다? 무지성 rebase.

무조건 git rebase로 다 정리하면 됩니다.

과정은 지옥일 수 있습니다. 무자비한 conflict 뭐 그런거..

가장 high level의 branch commit이 답도 없다면, 언제든 지저분한 commit이 재발할 수 있습니다.

여러분, 모두 rebase를 생활화 합시다.

rebase 알아도 코 베이는 무서운 gitHub 세상이니까요...

3.

Firebase DB 연동에서 android 친구를 좀 소홀히 했더니, 어김없이 android 친구가 DB 연동이 싫다며 거부하고 있습니다.

지 멋대로 method를 거부하고 있길래 오늘도 열심히 build.gradle을 뒤지며 빠진 부분을 체크했는데, 혹시 RN 유저분들 중 잊으신게 있다면 꼭 보고 해결하셨으면 좋겠습니다.

/ android / app / build.gradle

1. implementation 확인해보기

dependencies {
    implementation platform('com.google.firebase:firebase-bom:28.4.0')
    implementation fileTree(dir: "libs", include: ["*.jar"])
    //noinspection GradleDynamicVersion
    implementation "com.facebook.react:react-native:+"  // From node_modules
    implementation "androidx.swiperefreshlayout:swiperefreshlayout:1.0.0"

    implementation 'com.google.firebase:firebase-analytics'
    }

저 중에 가장 중요한건 platform, firebase-bom과 com.google.firebase~analytics 부분입니다.

둘 중 하나만 없어도 사실상 firebase 왜 쓰냐? 이런 말이 나올 수 있습니다.

2. apply 확인해보기

apply plugin: 'com.google.gms.google-services'

위 플러그인 apply 안했으면 사실상 팥 없는 호빵 상태입니다.

DB연동이 되든 아니든 저거 안넣으면 사실상 firebase - android & ios 가 아닌 firebase - ios 입니다.

아~ 안드로이드 말고 ios가 힙하다고~

인정하지만, 그래도 둘 다 개발해야죠 ... 🥲🥲

4.

그런데 왜 저는 위 두 사항을 뒤늦게 적용해도 android 친구가 DB를 열어주지 않을까 싶기도 합니다.

네. 그 문제는 다음 글에서 꼭! 해결하겠습니다.

실패하면 초기세팅부터 다시 시작하겠습니다.

결국 해결한다는 말이 되겠네요!

그럼 오늘도 읽어주셔서 감사합니다! 모두 화이팅!

프로젝트의 시작인 하루입니다.

이것저것 참 많은 일들이 있었지만, 오늘은 하루종일 꽂혀 있던 Firebase realTimeDataBase의 설계, No SQL - document에 대한 내용으로 작성할까 합니다.

기존 RDB와는 좀 달리 생각해야 하는데, 마냥 쉽지 않아서 좀 난항을 겪고 있습니다.

또한 firebase의 경우 쿼리문을 통한 접근을 따로 지원하지 않고, 다양한 메소드를 통해 DB 자료를 검색할 수 있습니다.

• 관계가 정의된 상태가 아닐 때 data를 어떻게 저장해야 할까?

• 저장된 데이터를 어떻게 메소드를 덜 사용하면서 효율적으로 가져올 수 있을까?

• Date 데이터를 보관한다면 key를 어떻게 설정하는게 좋을까?

이런저런 고민이 참 많았습니다.

숙소 예약을 담당했던 전 프로젝트 팀원에게 조언을 구할까 했지만, 한 번 혼자 힘으로 첫 DB 설계를 시작해보고자 합니다.

2.

우선 No SQL은 정말 말 그대로 설계하기 나름인 것 같습니다.

스키마도 존재하지 않고, 그렇기에 PK, FK 등과 같은 제약도 없습니다.

따라서 확장하고 싶으면 마음껏 하는게 맞지만, 최적화는 다른 문제입니다.

firebase의 경우 document, JSON 형태의 DB 구조입니다.

원하는 결과를 위해 하나의 특정 key로 접근하는 구조로 만들어진 것이죠.

"저장해야 할 대부분의 데이터는 Date String이기에 이를 년, 월, 주 단위로 최적화하기 위해 데이터를 옮기는 방법은 어떨까?" 가 바로 첫번째 생각이었습니다.

그러나 해당 방법은 각 key의 value가 서로 의존성을 갖게 됩니다.

예를 들어,

1. 일별 데이터를 주(key)에 담는다.

2. 월요일에는 주를 초기화하고, 특정 월(9)에 주 데이터를 담는다.

3. 다음 월로 넘어가는 10.01 00:00에 월을 reset하고, 특정 년에 월 데이터를 담는다.

가 되는데, 이렇게 될 경우 너무 번거롭고 지나치게 많은 로직을 발생시키는 것 같았습니다.

따라서 해당 방법은 가차없이 폐기했습니다.

예상 구조는

{
  userId : { 
    userInfo : {...},
    year : {"1" : [...], ..., },
    month : {"1st" : [...], ..., },
    week : [{...}],
    day : {start : "", end : "", time : number},               
  },

  userId : {...},
}

이런 느낌이었는데, 모르니까 참 용감한 것 같습니다.

코드로 써보니까 정말 택도 없네요.

3.

다음 방법은 그냥 틀을 빡세게 잡고 가는 방법입니다.

{
  userId : {
    userInfo : {...},
    "2021" : { 
      "1" : {
        "1st": {
          "Mon" : {
            "start" : Date, 
              "end" : Date, 
              "time" : number,
          },
          ...
        },
        ...
      },
      ...
    },
    "2022" : {...}
  }
}

이런 느낌이 되겠네요.

그리고 이걸 한 번 더 묶어버리면,

{
  userId : {
    userInfo : {...},
    commuteData : {
      "2021" : { 
        "1" : {
          "1st": {
            "Mon" : {
              "start" : Date, 
                "end" : Date, 
                "time" : number,
            },
            ...
          },
          ...
        },
        ...
      },
      "2022" : {...}
    }
  }
}

가 되는 것이 아닐까 생각합니다.

그럼 년, 월, 주, 요일로 각각 따로 접근할 수 있기는 합니다.

firebase method는 하나의 dir 경로로 접근하는 것과 같은 방식으로 데이터에 접근하게끔 구성되어 있습니다.

그런데 사실 아직 이게 개발 단계에서 옳은 방법인가에 대해 검증하지는 못한 것 같습니다.

이것저것 No SQL에 대해 공부하고 있는데, 어떤게 효율적일지 잘 모르겠습니다.

저는 아직까지는 이렇게 구성하는게 좋을 것 같다는 생각이 고정적인 것 같습니다.

접근에 용이하고, 로직에서 활용도가 높은 구조일 것 같아서 그런 것 같습니다.

무지의 늪에 빠져 도전하고 깨져봐야 아나봅니다...

그럼 오늘도 깨져보러 가겠습니다! 화이팅!

1.

오늘은 정말 새로운 주제입니다.

RN을 사용하는 사람들에게 재밌는 lib 일 것 같습니다.

기존 RN의 StyleSheet와는 달리 인라인으로 style props를 작성할 수 있고, 다양한 기능들을 지원하고 있는 nativebase 입니다.

처음 봤을 때는 부트스트랩인가? 싶었는데, 비슷하긴 한 것 같습니다.

다만, 조금 더 유저의 노력이 들어갑니다.

그래도 디자인에 대한 부담을 줄일 수 있으니 관심있으신 분들은 사용해보시면 좋을 것 같습니다.

각종 토이 프로젝트에서 사용하기 좋은 느낌입니다.

2.

그래서 오늘은 nativebase로 refactoring을 좀 해봤습니다.

여전히 좀 구리긴 합니다만, 그래도 나름의 스타일이 들어간 것 같아서 기분은 좋았습니다.

디자인 멈춰!

다양한 style hooks를 지원하고 있기에 버튼을 눌렀을 때 전체 배경색의 변경 등의 기능도 가능합니다.

다음 프로젝트는 아마도 nativebase를 애용하지 않을까 싶네요.

3.

지난주부터 계속 고민하던 바로 그 주제입니다.

Clean Architecture

해당 개념을 읽고, 공부했을 때는 분명 아~ 그런가보다 수준이었는데 막상 프로젝트에 적용하려니 각종 로직들을 수정하는 것은 물론 class와 추상에 대한 공부를 다시 하는게 맞지 않을까 생각이 들었습니다.

그래서 현재는 개념 학습을 위해 다양한 function 으로 내부가 이루어져 있는 구조입니다.

먼저, 글을 열심히 읽어본 결과, 현재 To Do List 의 경우 firebase를 사용하고 있기 때문에 data layer를 따로 고려하지 않아도 될 것 같다고 생각했습니다.

그러나 DB 접근 method class를 선언해두었기에 Repository 개념 정도는 가지고 갈 수 있었습니다.

useCase에 존재해야 하는 로직은 어떤 형태일지도 고민이 되었고, useCase 비즈니스 로직이 어떤 기능들을 수행하는지도 고민이 되었던 것 같습니다.

그리고 무엇보다도 View와 Presenter를 분리하는 일도 쉽지 않았습니다.

차근차근 해결해나간 결과, 나름의 기준을 정해보았습니다.

3.1

계층간섭이 가능한 개념은 계층 내에서 단 하나만 존재하기로 약속하자.

저는 위 글과 같이 presenter - useCase - repository 셋을 선택했습니다.

presenter와 repository는 서로 접점이 없어 각 계층에서 어떤 일이 벌어지는지 알 수 없도록 구현했습니다.

: presenter는 respository에 접근할 수 없고, 반대의 경우도 마찬가지라고 생각했습니다.

가장 고민이 되었던 것은 useCase입니다.

useCase의 경우 양방향으로 소통할 수 있는 구조인 것으로 보이는데, 현실적으로는 repository에서 받아온 DB method를 생성해서 실제 로직에 사용하는 식으로 구현되었습니다.

3.2

약속된 기능만을 수행할 수 있도록 작성하자.

useCase에서는 repository의 DB method를 내부에 생성했기 때문에 DB 접근이 가능합니다.

그러나 presenter는 DB에 접근하는 로직을 내부에 보유하지 않아 접근할 수 없습니다.

presenter의 경우 해당 프로젝트에서는 handle~ 등과 같은 View control이 가능합니다.

그러나 DB에 접근하기 위해서는 View에 특정 메소드를 호출해야 합니다.

분명 View와 useCase는 접점이 존재하지 않는데, 어떻게 작성해야 할지 고민이 많았던 것 같습니다.

signIn 기능이 대표적인 예시인데,

signIn의 presenter를 제 멋대로 작성해본 것을 코드로 올려보겠습니다.

import auth from '@react-native-firebase/auth';
import {checkUserInfoInDB} from '../../../domain/SignIn/usecase/authLogic';

...

export const signInCheck = (signInInfo: any): void => {
  const userId = auth().currentUser?.uid;

  checkUserInfoInDB(`users/${userId}/user`, signInInfo);
};

극단적이긴 한데, signInCheck() 이라는 하나의 함수를 정의해두고, 내부에서 userInfo가 DB에 존재하는지 확인하는 함수를 호출합니다.

presenter에서는 약속대로 DB에 접근하지 않지만, 현재 로그인한 유저가 맞는지 auth 메소드를 통해 점검하고 있습니다.

명확하게 분리하기 위해서는 사실 useCase에 auth()가 존재해야 하는데, 해당 부분을 어떻게 옮기는게 맞을지도 지속적으로 고민하고 있습니다.

극히 작은 규모의 프로젝트에서 어거지로 presenter와 useCase를 분리하려다 보니 이런 고민이 생기는 것 같습니다.

앞으로는 cleanArchitecture 이전에, class로 어떻게 계층 내부에서 인터페이스화했는지를 더 공부해야 할 것 같습니다.

그래서 요즘은 java 코드를 더 많이 보게 되는 것 같습니다.

3.3

해당 개념에 대해 조악하게나마 적용해보니 유일하게 느낀 점이 있었습니다.

유지보수에 무조건 유리할 수 밖에 없겠다! 하는 점입니다.

어떤 부분이 문제가 생기면 어딜 참고하면 되는지 바로 알 수 있고,

예를 들면 DB에서 유저정보를 불러오지 못하는 것 같아요! => presenter 내 경로, useCase 내 DB 로직 점검

그러나 아직도 두 계층을 확인해야 한다는 점에서 제 계층분리가 잘못되었다는 것을 알 수 있는 것 같습니다.

하나로 줄일 수 있는 방법을 늘 고민하는데, 아직은 쉽지 않은 것 같습니다....

또한 로직의 길이가 짧아지고, KISS 원칙을 잘 지킬 수 있게 되는 것 같았습니다.

하나의 함수 내부 로직을 고민하고, 또 고민하기 때문입니다.

그렇기에 좋은 도전이었다고 생각합니다.

4.

주절주절 참 많이도 썼는데, 사실 잘 몰라서 그렇습니다.

시행착오를 수도 없이 겪었는데, 머리 속에서 수도 없이 고민했기에 글로 적는 것이 마냥 쉽지가 않네요.

그럼에도 더 무언가를 공부하고, 도전하는 기분이 들어 좋았던 것 같습니다.

해당 주제를 다시 가지고 온다면 그 때는 누구에게나 자랑하듯 보여줄만한 코드들과 함께 왔으면 좋겠습니다.

그러기 위해 더 열심히 살아야겠네요.

그럼 이번 글은 여기서 마치겠습니다. 읽어주셔서 감사합니다.

1.

드디어 ToDoList 항목까지 DB와 연동할 수 있었습니다.

현재 DB에 저장되는 정보는 사용자의 google 계정 info, todos가 있습니다.

app의 개별 데이터는 사용자 id를 title로 갖는 독립적인 테이블의 형태로 저장됩니다.

그렇기에 app 사용자 사이에는 절대 영향을 끼치지 않습니다.

중앙에 실시간으로 반영되는 app별 DB가 완성된 것으로 생각이 듭니다.

2.

무엇보다도 신기했던 점은 noSQL DB를 직접 사용해보니 RDB에 비해 확장성이 좋을 수 밖에 없다는 것이 느껴진다는 점입니다.

그냥 원하는 데이터를 원하는 키워드로 큰 고민 없이 편하게 확장할 수 있었습니다.

각 테이블 사이에 관계가 없기 때문에 독립적으로 구성되고, 각각의 테이블에서 원하는 정보들을 조합해 하나의 app service를 구성할 수 있습니다.

그래서 1, 2차 프로젝트에 비해 3차 프로젝트의 데이터 구조는 생각보다 덜 복잡하지 않을까 생각했습니다.

기껏해야 2가지 정보만을 담고 있는 ToDoList app이지만 어서 큰 프로젝트를 만들어보고 싶어지네요.

3.

드디어 class 형태로 다양한 메서드들을 정의했습니다.

사용자를 고려하는 마음으로 만들다보니 module 내 type file을 다시 import 하는 경우도 있었습니다.

어떤 점이 문제인지는 명확히 모르겠으나, lib 내에서 정의한 type, interface를 굳이 한 번 더 사용하는 느낌이라 석연치 않았던 점은 있었습니다.

그래도 나름 메서드를 만들어두고 사용하다보니 상당히 편한 점이 많았습니다.

login은 한 번 사용하기에 몰랐지만, DB 관련 메서드들은 정말 편했습니다.

3.1

database.ts

import database from '@react-native-firebase/database';
import {FirebaseDatabaseTypes} from '@react-native-firebase/database/lib';

type Snapshot = FirebaseDatabaseTypes.DataSnapshot;

export const useDb = class {
  dir: string;

  constructor(dir: string) {
    this.dir = dir;
  }

  on(
    eventType:
      | 'value'
      | 'child_added'
      | 'child_changed'
      | 'child_moved'
      | 'child_removed',
    callback: (data: Snapshot, previousChildKey?: string | null) => void,
  ): void {
    database().ref(this.dir).on(eventType, callback);
  }

  set(value: any, onComplete?: (error: Error | null) => void): void {
    if (onComplete) {
      database()
        .ref(this.dir)
        .set(value)
        .catch(res => {
          onComplete(res);
          return;
        });
    }

    database().ref(this.dir).set(value);
  }

  update(
    value: {[key: string]: any},
    onComplete?: (error: Error | null) => void,
  ): void {
    if (onComplete) {
      database()
        .ref(this.dir)
        .update(value)
        .catch(res => {
          onComplete(res);
          return;
        });
    }

    database().ref(this.dir).update(value);
  }

  remove(): void {
    // 사용할 때 신중하게 생각해주세요. DB 테이블을 통째로 날리는 메소드입니다.
    database().ref(this.dir).remove();
  }

  push(value: any): void {
    database().ref(this.dir).push(value);
  }
};

별거 없어 보이지만, 생각보다 정말 편했습니다.

3.2

googleSignIn.ts

import {GoogleSignin} from '@react-native-google-signin/google-signin';
import auth from '@react-native-firebase/auth';

import {WEB_CLIENT_ID} from '../config';

export interface GoogleUserInfo {
  idToken: string;
  serverAuthCode: string;
  scopes: string[];
  user: {
    email: string;
    id: string;
    givenName: string;
    familyName: string;
    photo: string;
    name: string;
  };
}

export class GoogleSignInMethod {
  googleSignIn(setUser: Function): void {
    GoogleSignin.configure({
      webClientId: WEB_CLIENT_ID,
    });

    const signIn = async () => {
      try {
        const userInfo = await GoogleSignin.signIn();
        const {idToken} = userInfo;
        const googleCredential = auth.GoogleAuthProvider.credential(idToken);

        await auth().signInWithCredential(googleCredential);
        await setUser(userInfo);
      } catch (error) {
        console.log(error);
      }
    };

    signIn();
  }

  googleSignOut(setUser: Function): void {
    GoogleSignin.configure({
      webClientId: WEB_CLIENT_ID,
    });

    const signOut = async () => {
      try {
        await GoogleSignin.signOut().then(() => {
          auth().signOut();
        });
        await setUser(null);
      } catch (error) {
        console.log(error);
      }
    };

    signOut();
  }
}

기존 signUp 과정이 있었던 것을 어떻게 처리할까 고민하다가 그냥 과감히 삭제했습니다.

생각해보니 DB에 저장할지 말지를 결정하면 되는 문제였기 때문에 class 내부에서 해당 관련 내용을 포함하지 않는 것이 KISS 원칙을 준수하는 것 같았습니다.

따라서 최초 로그인 당시의 DB 저장은 해당 클래스 내부에서 판단하는 것이 아닌, 버튼이 눌린 시점의 view에서 판단해야겠다고 생각했습니다.

3.3

이에 Login.tsx 파일의 내부도 변경되었습니다.

import React, {useState, useEffect} from 'react';
import {
  StyleSheet,
  SafeAreaView,
  View,
  Text,
  TouchableOpacity,
} from 'react-native';
import {GoogleSigninButton} from '@react-native-google-signin/google-signin';
import {GoogleUserInfo, GoogleSignInMethod} from '../../utils/googleSignin';
import auth from '@react-native-firebase/auth';
import {useDb} from '../../utils/database';

const checkUser = (signInInfo: any): void => {
  const userId = auth().currentUser?.uid;

  const dbUserInfo = new useDb(`/users/${userId}`);

  dbUserInfo.on('value', snapshot => {
    if (!snapshot.val()?.googleInfo && signInInfo) {
      dbUserInfo.set({googleInfo: {...signInInfo.user}});
      return;
    }
  });
};

export const SignIn = ({navigation}: any) => {
  const gogoleSignInMethod = new GoogleSignInMethod();
  const {googleSignIn, googleSignOut} = gogoleSignInMethod;

  const [signInInfo, setSignInInfo] = useState<GoogleUserInfo | null>(null);

  const {navigate}: any = navigation;

  useEffect(() => {
    if (signInInfo) {
      checkUser(signInInfo);
    }
  }, [signInInfo]);

  const {signInContainer, signInBlock, signOutText} = styles;

  return (
    <SafeAreaView style={signInContainer}>
      <View style={signInBlock}>
        {signInInfo && (
          <>
            <TouchableOpacity
              onPress={() => {
                navigate('ToDoList');
              }}>
              <Text style={signOutText}>Go ToDoList</Text>
            </TouchableOpacity>
            <TouchableOpacity
              onPress={() => {
                googleSignOut(setSignInInfo);
              }}>
              <Text style={signOutText}>Sign Out</Text>
            </TouchableOpacity>
          </>
        )}
        {!signInInfo && (
          <GoogleSigninButton
            size={GoogleSigninButton.Size.Wide}
            color={GoogleSigninButton.Color.Dark}
            onPress={() => {
              googleSignIn(setSignInInfo);
            }}
          />
        )}
      </View>
    </SafeAreaView>
  );
};

막상 보니 코드가 좀 길긴 하네요.

그래도 최소한의 기능과 로직만을 포함했다고 생각합니다.

다음엔 어딜 더 줄일지 고민해야겠습니다.

4.

생각보다 이것저것 한건 없는데 빨리 하루가 지나갔습니다.

로직을 재구성하기 위해 나름 그림(?)도 하루종일 그리고, 주말 사이에 읽었던 자료들을 떠올리며 어떻게 구성하는게 맞는지 고민하는데 시간을 많이 쓴 것 같습니다.

안타깝게도 프로젝트의 규모가 상당히 작아 주말 사이에 공부했던 개념을 적용시키는 것은 배보다 배꼽이 더 큰 느낌이기에 포기했습니다.

그래도 조금더 고민해보았던 것은 google 말고 다양한 방식의 social Auth를 적용하기 위해 하나의 SignIn class를 만들어 상속을 활용한 틀을 만들어둘까 했던 점입니다.

다음 프로젝트에는 꼭 반영해봐야겠습니다.

이상으로 ToDoList는 마치도록 하겠습니다.

내일은 RN의 다양한 기능, geolocation 등을 ToDoList에 집어넣어볼까 합니다.

혼종 예약입니다.

그럼 글은 이만 마치도록 하겠습니다. 읽어주셔서 감사합니다.