1. act: GitHub Actions를 로컬에서 실행하기

act는 GitHub Actions를 로컬에서 실행할 수 있도록 해주는 도구입니다. 이를 사용하면 GitHub의 실행 환경을 시뮬레이션하여 테스트할 수 있습니다.

1.1 act 설치

macOS

brew install act

Windows (Scoop 사용)

scoop install act

Linux (curl 사용)

curl -s https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash

또는, GitHub Releases에서 바이너리를 다운로드하여 사용할 수도 있습니다.

1.2 act 실행하기

설치가 완료되면, GitHub Actions을 실행할 디렉토리로 이동하여 다음 명령어를 실행합니다.

act

기본적으로 .github/workflows/ 폴더 내의 워크플로우를 찾아 실행합니다.

1.3 특정 이벤트 트리거로 실행하기

act push  # push 이벤트 실행
act pull_request  # pull_request 이벤트 실행
act -l  # 실행 가능한 이벤트 목록 확인

1.4 특정 워크플로우 실행하기

워크플로우 파일이 .github/workflows/eas-update.yml로 구성되어 있을 경우, 아래 명령어로 실행할 수 있습니다.

act workflow_dispatch -W .github/workflows/eas-update.yml \
  -s EXPO_TOKEN=mytoken \
  -P ubuntu-latest=catthehacker/ubuntu:act-latest \
  --container-architecture linux/amd64 

1.5 필요한 Docker 이미지 설정하기

act는 기본적으로 medium 사이즈의 Docker 이미지를 사용합니다. 더 가벼운 이미지를 사용하려면 -P 옵션을 이용하세요.

act -P ubuntu-latest=nektos/act-environments-ubuntu:18.04

2. act 사용 시 주의할 점

2.1 GitHub Secrets 처리

GitHub Actions에서 secrets.GITHUB_TOKEN과 같은 환경 변수를 사용하는 경우, 로컬에서 실행하려면 .secrets 파일을 만들어야 합니다.

echo "GITHUB_TOKEN=mytoken" > .secrets
act --secret-file .secrets

2.2 필요한 툴이 설치되어 있어야 함

act는 Docker 컨테이너 내에서 실행되므로, Docker가 반드시 설치되어 있어야 합니다. 또한, GitHub Actions에서 사용하는 도구(예: Node.js, Python 등)가 로컬 환경에도 있어야 합니다.

3. 마무리

act를 사용하면 GitHub Actions를 로컬에서 빠르게 테스트하고 디버깅할 수 있습니다. 이를 활용하면 불필요한 푸시를 줄이고, 빠른 피드백을 얻을 수 있습니다.

더 자세한 사항은 act 공식 문서를 참고하세요.

기본 동작

position: fixed는 화면을 기준으로 요소를 고정합니다. 스크롤을 하더라도 요소는 제자리에서 움직이지 않습니다. 다음은 기본적인 예제입니다.

.fixed-element {
    position: fixed;
    top: 10px;
    left: 10px;
}

위 코드를 적용하면, .fixed-element는 화면의 좌측 상단에서 항상 10px 떨어진 위치에 고정됩니다.

예외 상황

특정 CSS 속성이나 환경에서는 fixed가 화면(viewport)을 기준으로 동작하지 않을 수 있습니다.

1. transform, perspective, filter의 영향을 받을 때 fixed 요소가 transform, perspective, 또는 filter 속성이 적용된 부모 요소의 자식일 경우, 화면이 아닌 해당 부모 요소를 기준으로 동작합니다.

.parent {
    transform: translate(0, 0);
}

.child {
    position: fixed;
    top: 10px;
    left: 10px;
}

이 경우, .child는 부모 요소 .parent를 기준으로 위치가 고정됩니다. 이는 fixed가 viewport 대신 부모의 containing block에 영향을 받기 때문입니다.

2. 모바일 환경에서의 특수 동작 모바일 브라우저에서는 fixed가 예상과 다르게 동작하는 경우가 종종 있습니다. 예를 들어, 소프트 키보드가 나타나거나 화면 크기가 변경될 때 fixed 요소가 재배치되지 않는 문제가 발생할 수 있습니다.

마무리

position: fixed는 일반적으로 화면을 기준으로 동작하지만, transform, perspective, filter 속성의 영향을 받을 경우 부모 요소를 기준으로 동작할 수 있습니다. 이러한 특성을 이해하고 CSS를 작성하면 예상치 못한 동작을 방지할 수 있습니다.

웹 개발에서 작은 차이가 큰 문제를 초래할 수 있으므로, 레이아웃 설계 시 이러한 예외 상황을 고려하는 것이 중요합니다.

출처: https://developer.mozilla.org/ko/docs/Web/CSS/position#fixed

실시간 스트리밍 플랫폼에서 코덱 선택은 서비스 품질, 비용 효율성, 사용자 경험을 좌우하는 중요한 요소입니다. 이번 포스트에서는 VP8, VP9, 그리고 AV1 코덱을 비교하며, 특히 하드웨어 지원이 되는 디바이스만 사용할 경우 AV1의 장점과 한계를 중심으로 살펴보겠습니다.

1. 코덱별 특징

VP8

• 출시 시기: 2010년 (Google)
• 장점:
  • 간단한 구조로 인코딩 및 디코딩 속도가 빠름.
  • 다양한 기기에서 널리 지원됨.
  • 실시간 스트리밍에 적합 (낮은 지연 시간).
• 단점:
  • 최신 코덱에 비해 효율성이 낮음 (대역폭 소비가 큼).

VP9

• 출시 시기: 2013년 (Google)
• 장점:
  • VP8 대비 약 30%-50% 대역폭 절감.
  • 4K 콘텐츠를 위한 우수한 품질 제공.
  • 주요 플랫폼과 브라우저에서 폭넓게 지원됨.
  • 실시간 스트리밍에서도 적절한 성능 발휘.
• 단점:
  • 하드웨어 가속 지원이 제한적이었던 과거 디바이스에서 성능 저하.
  • AV1 대비 대역폭 효율성 부족.

AV1

• 출시 시기: 2018년 (Alliance for Open Media)
• 장점:
  • VP9 대비 약 30%, H.265 대비 약 50% 대역폭 절감.
  • 무료 라이선스 (운영 비용 절감).
  • 4K, 8K 콘텐츠를 위한 최고의 품질과 효율성.
• 단점:
  • 인코딩 속도가 느림 (특히 소프트웨어 기반).
  • 하드웨어 가속이 없는 기기에서는 성능 저하 및 높은 지연 발생.
  • 지원 디바이스 범위가 제한적.

2. 비용적인 측면

• VP8 & VP9:

  • 모두 무료 라이선스 제공.
  • VP8은 상대적으로 대역폭 효율성이 낮아 네트워크 비용이 증가할 수 있음.
  • VP9은 VP8 대비 대역폭 절감 효과로 비용 효율성 우수.

• AV1:

  • 무료 라이선스로 장기적인 네트워크 비용 절감 가능.
  • 높은 대역폭 효율성으로 대규모 트래픽이 발생하는 서비스에서 유리.
  • 초기 인코딩 인프라 투자 및 하드웨어 가속 필요.

3. 실시간 스트리밍 플랫폼에서의 비교

AV1의 강점

1. 최고의 대역폭 효율성:

   • 4K, 8K 해상도에서 낮은 대역폭으로 고품질 제공.
   • 장기적으로 네트워크 비용 절감.

2. 최신 디바이스에서 뛰어난 성능:

   • 하드웨어 가속 지원 기기에서는 낮은 지연 시간과 빠른 디코딩 가능.

3. 무료 라이선스:

   • H.265 등 유료 코덱 대비 비용 절감 효과.

AV1의 단점

1. 하드웨어 지원 제한:

   • 최신 디바이스에서만 원활하게 동작.
   • 구형 기기에서는 소프트웨어 디코딩으로 성능 저하.

2. 인코딩 속도 문제:

   • 실시간 스트리밍에서 지연(latency) 증가 가능.

3. 운영 복잡성 증가:

   • AV1을 지원하지 않는 기기를 위해 VP8 또는 VP9 같은 백업 코덱이 필요.

4. 하드웨어 지원 디바이스만 사용할 경우

AV1이 유리한 조건

1. 사용자 기반이 최신 디바이스 중심:

   • 최신 스마트폰, PC, 스트리밍 기기를 사용하는 경우 AV1의 장점 극대화.

2. 고품질 콘텐츠 제공:

   • 4K, 8K 콘텐츠를 낮은 대역폭으로 전송 가능.

3. 대규모 트래픽 비용 절감:

   • 대역폭이 중요한 스트리밍 서비스에서 비용 절감 효과.

AV1이 한계가 있는 조건

1. 저지연 실시간 스트리밍:

   • 인코딩 지연 문제로 실시간 서비스에 부적합할 수 있음.

2. 사용자 디바이스가 다양할 경우:

   • 하드웨어 지원이 부족한 구형 디바이스에서는 성능 문제가 발생.

3. 멀티코덱 운영 필요:

   • AV1과 함께 VP9/VP8을 병렬적으로 운영해야 하므로 관리 복잡도 증가.

5. 결론

AV1이 적합한 환경

• 최신 하드웨어 중심의 서비스:
  • 예: 최신 디바이스를 사용하는 프리미엄 구독 서비스.
• 고품질 콘텐츠 제공이 중요한 플랫폼:
  • 예: 4K, 8K 콘텐츠 중심의 OTT 서비스.
• 장기적인 대역폭 비용 절감이 목표:
  • 예: 대규모 글로벌 스트리밍 플랫폼.

VP9/VP8이 적합한 환경

• 저지연 실시간 스트리밍:
  • AV1의 인코딩 속도 문제를 해결할 수 없을 경우.
• 다양한 사용자 디바이스 지원이 필요한 플랫폼:
  • 구형 디바이스까지 아우르는 서비스.

추천 전략

1. 최신 디바이스에서 AV1을 우선 활용:
   • 고품질 콘텐츠에 AV1을 적용.
2. 백업 코덱으로 VP9 운영:
   • AV1을 지원하지 않는 기기에 대응.
3. 실시간 스트리밍은 VP9 중심:
   • 실시간성과 낮은 지연 시간을 요구하는 경우 VP9이 최적.

이 글이 실시간 스트리밍 플랫폼에서 코덱 선택에 도움이 되길 바랍니다! 서비스 환경에 맞는 최적의 코덱을 선택해 높은 품질과 비용 효율성을 모두 잡으세요.

트리 쉐이킹은 사용되지 않는 코드를 제거하여 최종 번들 크기를 줄이는 기법입니다. 주로 모듈 번들러(예: Webpack, Rollup)와 함께 사용되며, 특히 자바스크립트 환경에서 중요하게 여겨집니다. 이 문서에서는 트리 쉐이킹의 개념, 작동 방식, 이점, 주의 사항 등을 설명합니다.

1. 트리 쉐이킹의 개념

트리 쉐이킹은 프로그래밍에서 "트리" 구조를 비유적으로 사용하여, 사용되지 않는 코드를 마치 나무의 잎사귀처럼 제거하는 과정을 의미합니다. 이를 통해 애플리케이션의 번들 크기를 줄이고, 성능을 향상시킬 수 있습니다.

2. 작동 방식

트리 쉐이킹은 주로 정적 분석을 통해 이루어집니다. 모듈 번들러가 코드를 분석하여 사용되지 않는 코드의 종속성을 찾고 이를 제거합니다. 이 과정에서 중요한 요소는 다음과 같습니다:

• ES6 모듈: 트리 쉐이킹은 주로 ES6의 import와 export 구문을 사용하는 모듈에서 효과적으로 작동합니다. CommonJS 모듈 시스템에서는 트리 쉐이킹이 제한적일 수 있습니다.
• 정적 분석: 코드가 어떻게 사용되는지를 정적으로 분석하여 실제로 사용되지 않는 부분을 식별합니다.

예시

// utils.js
export function usedFunction() {
    console.log("I am used!");
}

export function unusedFunction() {
    console.log("I am unused!");
}

// main.js
import { usedFunction } from './utils';

usedFunction(); // "I am used!" 출력

위 예시에서 unusedFunction은 main.js에서 사용되지 않기 때문에, 트리 쉐이킹을 통해 최종 번들에서 제거될 수 있습니다.

3. 이점

• 번들 크기 감소: 사용되지 않는 코드를 제거하여 최종 번들의 크기를 줄입니다.
• 성능 향상: 로딩 시간이 단축되고, 페이지의 초기 렌더링 성능이 개선됩니다.
• 코드 가독성: 코드의 복잡성을 줄이고, 불필요한 부분을 제거하여 가독성을 높입니다.

4. 주의 사항

• 라이브러리 호환성: 모든 라이브러리나 프레임워크가 트리 쉐이킹을 지원하는 것은 아닙니다. ES6 모듈을 지원하는 라이브러리를 사용하는 것이 중요합니다.
• 동적 import: 동적으로 불러오는 코드의 경우 트리 쉐이킹이 어려울 수 있습니다. 사용 여부가 명확하지 않은 경우, 해당 코드가 번들에 남아있게 됩니다.
• enum과의 관계: TypeScript의 enum과 같이 런타임 객체로 변환되는 코드는 트리 쉐이킹이 효과적으로 작동하지 않을 수 있습니다.

결론

트리 쉐이킹은 애플리케이션의 성능을 최적화하는 중요한 기법입니다. ES6 모듈을 활용하고, 사용되지 않는 코드를 적극적으로 제거함으로써 최종 번들의 크기를 줄이고 성능을 향상시킬 수 있습니다. 트리 쉐이킹을 올바르게 활용하면, 효율적인 애플리케이션 개발에 큰 도움이 됩니다.

TypeScript의 enum은 코드의 가독성을 높이는 데 유용하지만, 성능 최적화 측면에서 몇 가지 단점을 가지고 있습니다. 특히 트리 쉐이킹(Tree Shaking)과 관련하여 enum 사용을 피해야 하는 이유에 대해 알아보겠습니다.

1. 트리 쉐이킹의 개념

트리 쉐이킹은 사용되지 않는 코드를 제거하여 최종 번들 크기를 줄이는 기법입니다. 주로 ES6 모듈을 사용하는 환경에서 효과적으로 작동하며, 모듈 번들러(예: Webpack, Rollup)가 이를 수행합니다. 사용되지 않는 코드가 번들에 포함되지 않도록 정적 분석을 통해 이루어집니다.

2. Enum의 구조와 동작 방식

TypeScript의 enum은 컴파일될 때 런타임 객체로 변환됩니다. 이로 인해 enum의 모든 값이 최종 번들에 포함됩니다. 예를 들어, 아래의 enum 예시를 살펴보겠습니다:

enum Status {
    Pending = "pending",
    Approved = "approved",
    Rejected = "rejected",
}

위의 코드에서 Status enum은 세 개의 문자열 값을 포함합니다. 코드에서 Status enum의 일부 값만 사용하더라도, 모든 값이 최종 번들에 포함될 수 있습니다.

3. 트리 쉐이킹과 Enum의 문제점

• 런타임 객체: enum은 런타임에 존재하는 객체이므로, 사용되지 않는 값이 코드에 남아있게 됩니다. 이는 트리 쉐이킹이 제대로 작동하지 않는 원인이 됩니다.
• 정적 분석의 한계: enum의 값들이 런타임에 필요하기 때문에, 사용되지 않는 값이 정적으로 분석되기 어렵습니다. 이로 인해 최종 번들에서 제거되지 않고 포함될 수 있습니다.

예시

function getStatusMessage(status: Status) {
    switch (status) {
        case Status.Pending:
            return "Your request is pending.";
        case Status.Approved:
            return "Your request has been approved.";
        case Status.Rejected:
            return "Your request has been rejected.";
        default:
            return "Unknown status.";
    }
}

위 코드에서 getStatusMessage 함수는 Status enum의 값 중 일부만 사용할 수 있지만, 모든 값이 번들에 포함됩니다.

4. 대안: 리터럴 타입 및 유니언 타입

트리 쉐이킹을 최적화하기 위해 enum 대신 리터럴 타입과 유니언 타입을 사용하는 것이 좋습니다. 이를 통해 사용되지 않는 코드의 포함을 방지할 수 있습니다.

type Status = "pending" | "approved" | "rejected";

function getStatusMessage(status: Status) {
    switch (status) {
        case "pending":
            return "Your request is pending.";
        case "approved":
            return "Your request has been approved.";
        case "rejected":
            return "Your request has been rejected.";
        default:
            return "Unknown status.";
    }
}

위와 같이 리터럴 타입을 사용하면, 코드의 가독성을 유지하면서도 트리 쉐이킹의 이점을 극대화할 수 있습니다.

결론

TypeScript의 enum은 편리하지만, 트리 쉐이킹과 같은 성능 최적화 측면에서 문제가 될 수 있습니다. 코드의 최적화를 위해서는 리터럴 타입과 유니언 타입을 사용하는 것이 좋습니다. 이를 통해 최종 번들의 크기를 줄이고, 성능을 향상시킬 수 있습니다.

자바스크립트는 프로토타입 기반의 객체 지향 언어로, 다른 객체지향 언어들처럼 명시적인 class 기반 다중 상속을 직접 지원하지는 않습니다. 하지만, 자바스크립트는 몇 가지 다른 방법으로 다중 상속을 시뮬레이션할 수 있습니다. 이번 글에서는 자바스크립트에서 다중 상속을 구현하는 일반적인 방법들에 대해 알아보겠습니다.

1. 믹스인(Mixin) 패턴

믹스인은 하나의 함수나 객체에서 다른 객체의 메서드나 속성을 "혼합"하여 사용하는 패턴입니다. 이는 자바스크립트에서 다중 상속을 구현하는 가장 일반적인 방법 중 하나입니다.

function mixin(target, ...sources) {
  Object.assign(target, ...sources);
}

const canEat = {
  eat() {
    console.log('Eating');
  }
};

const canWalk = {
  walk() {
    console.log('Walking');
  }
};

const canSwim = {
  swim() {
    console.log('Swimming');
  }
};

class Person {
  constructor(name) {
    this.name = name;
  }
}

mixin(Person.prototype, canEat, canWalk, canSwim);

const person = new Person('John');
person.eat(); // Eating
person.walk(); // Walking
person.swim(); // Swimming

이 방법을 통해 Person 객체는 canEat, canWalk, canSwim의 기능을 모두 상속받아 사용할 수 있습니다.

2. 프로토타입 체인을 통한 복합 상속

다른 방법으로는 프로토타입 체인을 사용하여 기능을 상속받을 수도 있습니다. 이 방법은 믹스인과 유사하지만, 객체의 프로토타입 체인을 직접 조작하여 상속을 설정합니다.

function inherit(target, ...sources) {
  sources.forEach(source => {
    Object.getOwnPropertyNames(source).forEach(name => {
      target[name] = source[name];
    });
  });
  return target;
}

class Animal {
  breathe() {
    console.log('Breathing');
  }
}

const swimmer = {
  swim() {
    console.log('Swimming');
  }
};

class Fish {
  constructor() {
    inherit(this, new Animal());
  }
}

inherit(Fish.prototype, swimmer);

const fish = new Fish();
fish.breathe(); // Breathing
fish.swim(); // Swimming

3. 결론

자바스크립트에서는 다른 객체지향 언어처럼 다중 상속을 직접적으로 지원하지 않지만, 믹스인이나 프로토타입 조작과 같은 방법을 통해 다중 상속을 간접적으로 구현할 수 있습니다. 이러한 패턴들을 활용하면 재사용 가능한 코드를 작성하고 객체 간에 기능을 공유하는 것이 가능해집니다. 다만, 구체적인 구현 방식을 선택할 때에는 코드의 가독성과 유지보수성을 고려해야 합니다.

공달이 - 공유 달력 | GongDal2

일정 관리, 일정 공유 앱

소그룹, 동아리, 회사, 학교 등 다양한 그룹 모임이 많아지는 시대에 맞춰 개인 일정뿐 아니라 그룹 일정을 한 눈에 관리할 수 있는 캘린더를 만들고자 이 아이디어를 시작하게 되었습니다.

기능 설명

📌 내가 속한 그룹과 개인일정을 달력 형태로 볼 수 있습니다

🗓️ 일별 일정들도 리스트로 확인할 수 있습니다

👥 내가 속한 그룹의 모임을 리스트로 확인할 수 있습니다

🔍 특정 그룹만 필터링하여 일정을 확인할 수 있습니다.

🧑‍💻 기술적 도전

달력

• 좋은 사용자 경험을 주기 위해 달력의 성능, 기능 들을 비교해보고, 선택한 과정을 담았습니다.
  • 캘린더 컴포넌트 인터페이스 개발
  • 초기 로딩 속도가 오래걸려 컴포넌트를 캐싱하는 방법으로 로딩 시간을 62% 단축시키기
  • 일정 컴포넌트 인터페이스 개발
  • 깊이 우선 탐색(DFS)을 활용한 일정 프로세스 성능 개선

기타

• React Native Quick Action을 사용해서 UX 향상시키기
• React Naitve SNS 공유와 딥링크로 사용자 경험 향상시키기

기술 스택

팀원

소개

Next.js는 서버 사이드 렌더링과 정적 사이트 생성과 같은 기능을 제공하여 오랫동안 인기 있는 React 애플리케이션 프레임워크였습니다. Next.js 13에서는 더 유연하고 확장 가능한 라우팅 시스템을 제공하기 위해 새로운 App Router가 도입되었습니다. 이를 기존의 Page Router와 비교해 보겠습니다.

기존 Page Router

이전 버전의 Next.js에서는 라우팅이 파일 기반이었습니다. pages 디렉토리 내부의 파일 구조가 라우트를 정의했습니다. 예를 들어:

pages/
  ├── index.js  // 라우트: /
  ├── about.js  // 라우트: /about
  └── blog/
      └── [id].js  // 동적 라우트: /blog/:id

장점

• 간단함: 이해하고 설정하기 쉬움.
• 관습 우선 구성: 최소한의 설정만 필요.

  단점

• 확장성 문제: 애플리케이션이 커짐에 따라 단일 pages 디렉토리에서 라우트를 관리하는 것이 번거로울 수 있음.
• 제한된 커스터마이징: 고급 라우팅 시나리오에 대한 유연성이 부족함.

Next.js 13의 App Router

App Router는 더 모듈화된 방식으로 라우트를 정의할 수 있게 하여, 더 많은 커스터마이징을 허용합니다.

예제 구성

App Router를 사용하면 파일 구조에서 라우트 정의를 분리하여 구성 파일에 라우트를 정의할 수 있습니다:

// app/routes.js
export default [
  {
    path: '/',
    component: HomePage,
  },
  {
    path: '/about',
    component: AboutPage,
  },
  {
    path: '/blog/:id',
    component: BlogPost,
  },
];

장점

• 모듈성: 여러 파일에 라우트를 정의하여 조직화가 향상됨.
• 유연성: 중첩 라우트와 가드를 포함한 고급 라우팅 논리에 대한 더 큰 제어 가능.
• 향상된 성능: 대규모 애플리케이션에서도 더 나은 성능을 위해 최적화됨.

  단점

• 학습 곡선: 기존 Page Router에 비해 설정이 더 복잡함.
• 구성 오버헤드: 초기 구성에 더 많은 노력이 필요.

사용 사례

기존 Page Router를 사용할 때

소규모에서 중규모 프로젝트: 작은 프로젝트에는 Page Router의 간단함이 유리함. 빠른 프로토타이핑: 쉬운 설정으로 빠른 개발 가능.

App Router를 사용할 때

대규모 애플리케이션: 복잡한 라우팅 요구 사항을 가진 애플리케이션에 더 적합. 고급 라우팅 필요: 중첩 라우트, 가드, 더 유연한 라우팅 논리가 필요한 경우.

결론

Next.js 13의 App Router는 기존 Page Router의 한계를 해결하는 더 강력하고 유연한 라우팅 접근 방식을 제공합니다. 그러나 둘 사이의 선택은 프로젝트의 특정 요구 사항에 따라 달라집니다. 소규모 애플리케이션에는 기존 Page Router가 여전히 좋은 선택이며, 더 크고 복잡한 애플리케이션은 App Router의 고급 기능을 활용할 수 있습니다.

문제

만약 일정을 삭제할 때 단순히 그 데이터만 삭제를 하는게 아니라 일정이 겹쳐져 있는 Day 컴포넌트들도 리렌더링을 해주어야합니다.

*쉽게 말해 무슨 말이냐면 *

예를 들어 아래 이미지처럼 일정들이 있을때 "일정1"을 삭제한다면

아래 이미지 처럼 "일정1"과 같은 단계에 있는 데이터들을 삭제해줘야한다

그렇지 않으면 아래처럼 됩니다

아래 이미지처럼 계단식으로 쭉 연결되어있다면 연결된 모든 일정들을 렌더링 해주어야한다.

해결 1

계단식으로 쭉 연결되어있는게 어디까지인지를 몰랐기때문에 처음부터 끝까지 모든 일정을 다 부르는 방식으로 했었습니다. 물론 원하는 방식으로 동작을 하긴했지만 시간, 비용적인 측면에서 너무 낭비가 있다는 것을 느꼈고 개선의 여지가 필요했습니다. 아래는 모니터링으로 확인한 결과입니다.

모니터링을 확인하면 일정 한개가 삭제가 되었을때 4.3초가 걸렸습니다. 일정 한개가 삭제 되었을 뿐인데 모든 데이터를 호출하고 모든 데이터를 가공하는 형태입니다. 지금은 일정이 몇개 없어서 이정도 걸렸지만 관련이 있든 없든 일정이 많아질수록 시간은 더 증가할것입니다.

해결 2

꼭 필요한 데이터만 렌더링하자라는 생각이 들었습니다. 그래서 해당 날짜가 삭제가 되면 DFS 알고리즘을 통해 타고 타고 들어가서 시작날짜와 끝날짜를 찾자라는 계획입니다.

삭제한 일정의 시작, 종료 날짜로부터 시작해서 해당 날짜를 순회해서 계속 해서 탐색해 나갑니다. startingDay, endingDay를 통해 마지막 날짜를 찾을 수 있습니다. 해당 함수를 사용하면 연결되어있는 일정중 시작날짜와 끝날짜를 알 수 있어 모든 일정을 부르지 않고 필요한 데이터만 요청 할 수 있습니다.

const firstDate = getScheduleStartDate(삭제한 일정의 시작 날짜);
const lastDate = getScheduleLastDate(삭제한 일정의 종료 날짜);

const getScheduleStartDate = (startDate: string) => {
  let firstDate = format(new Date(startDate), 'yyyy-MM-dd');

  const DFS = (date: string) => {
    schedule.scheduleByDate[date]?.forEach((event) => {
      if (event) {
        const _fDate = fDate(event?.startDate);
        if (!event.startingDay) {
          DFS(_fDate);
        } else {
          if (isBefore(_fDate, firstDate)) {
            firstDate = _fDate;
          }
        }
      }
    });
  };

  DFS(firstDate);
  return firstDate;
};

const getScheduleLastDate = (endDate: string) => {
  let lastDate = format(new Date(endDate), 'yyyy-MM-dd');

  const DFS = (date: string) => {
    schedule.scheduleByDate[date]?.forEach((event) => {
      if (event) {
        const _fDate = fDate(event?.endDate);

        if (!event.endingDay) {
          DFS(_fDate);
        } else {
          if (isAfter(_fDate, lastDate)) {
            lastDate = _fDate;
            }
        }
      }
    });
  };

  DFS(lastDate);
  return lastDate;
};

DFS알고리즘을 통해 연결된 일정의 시작과 종료날짜를 찾고 그 부분만 호출해 렌더링하기때문에 시간이 4.3초에서 2.7초로 단축되었다. 하지만 탐색 경로를 보면 한번 들렸던 부분도 또 들리는 부분을 캐치했다. check 방식을 통해 들렸던 부분은 다시 들리지않는 방식을 하면 더 단축할 수 있을것같다.

해결3

해결2 방법으로도 많은 시간을 단축했지만 더 단축 할 수 있는 여지가 있습니다. check 방식을 통해 들렸던 곳은 다시 들리지 않게 해보겠습니다.

아래 코드를 추가하고 조건문에 방문여부를 확인하는 로직을 추가하겠습니다.

const check: Record<string, boolean> = {};

if(!check[_fDate])

const getScheduleStartDate = (startDate: string) => {
  const check: Record<string, boolean> = {}; // 추가
  let firstDate = format(new Date(startDate), 'yyyy-MM-dd');

  const DFS = (date: string) => {
    schedule.scheduleByDate[date]?.forEach((event) => {
      if (event) {
        const _fDate = fDate(event?.startDate);
        if (!event.startingDay && !check[_fDate]) { // 방문여부 체크
          DFS(_fDate);
        } else {
        // 훨씬 단축됨
          check[_fDate] = true; // 방문함
          if (isBefore(_fDate, firstDate)) {
            firstDate = _fDate;
          }
        }
      }
    });
  };

  DFS(firstDate);
  return firstDate;
};

const getScheduleLastDate = (endDate: string) => {
  const check: Record<string, boolean> = {}; //추가
  let lastDate = format(new Date(endDate), 'yyyy-MM-dd');

  const DFS = (date: string) => {
    schedule.scheduleByDate[date]?.forEach((event) => {
      if (event) {
        const _fDate = fDate(event?.endDate);

        if (!event.endingDay && !check[_fDate]) { // 방문여부 체크
          DFS(_fDate);
        } else {
          // 훨씬 단축됨
          check[_fDate] = true; // 방문함

          if (isAfter(_fDate, lastDate)) {
            lastDate = _fDate;
            }
        }
      }
    });
  };

  DFS(lastDate);
  return lastDate;
};

check 방식을 통해 탐색의 횟수를 줄였고 당연히 렌더링 걸리는 시간도 단축했다.

마무리

코딩 테스트를 준비하면서 공부한 알고리즘을 이렇게 사용해 볼 줄은 몰랐다. 솔직히 프론트엔드가 알고리즘을 그렇게까지 알아야하나라는 생각이 있었는데 이번 계기로 생각이 완전히 바뀌었다. 알고리즘이 중요하다고 많이들 들어왔지만 직접 체감을 해보니 느낌이 달랐다. 알고리즘을 적용했을뿐인데 4.3초에서 2.4초 약 44%의 성능 개선을 얻었다. 알고리즘 공부를 더 열심히 해야겠다는 욕구가 생긴 계기가 되었다.

분석

1. 일정은 몇 시간 단위거나 며칠 단위입니다. 같은 날 일정이라면 "일정1"과 같이 하루 안에 UI를 그리면 되지만 "일정2"처럼 며칠인 경우 가로로 길게 이어진 UI를 가집니다.

2. 컴포넌트의 순서도 시간이 빠른 일정이 먼저 렌더링 됩니다.

설계

1. 시작하는 시간이 제일 빠른 일정을 먼저 그리고 그 다음 먼저 끝나는 일정을 그리도록 정렬해야합니다.

2. 단순히 그 날짜에 일정 컴포넌트를 렌더링하는게 아니라 21일에 "일정2"처럼 한칸을 띄우고 단계를 맞추어 주어야합니다.

저는 null값을 넣어서 한칸을 띄우는 방식을 채택했습니다.

3. 만약 20일 컴포넌트를 렌더링할 순서라면 20일 컴포넌트를 그리고 그 날짜에 일정이 있으면 일정 컴포넌트를 렌더링하는 방식입니다. 이 과정을 반복하면서 그리게 됩니다. 해당하는 데이터만 있으면 되기때문에 데이터 검색 속도를 위해 Map 자료형으로 가공하여 사용합니다.

구현

먼저 일정 데이터를 API 조회를 하면 일정이 배열 형태로 응답받습니다.

[
    {
        "scheduleId":114,
        "name":"미용실",
        "startDate":"2024-05-24T03:35:34.385Z",
        "endDate":"2024-05-24T03:35:34.385Z",
        ...
    }
    ...
]

로직 순서

1. 데이터가 없으면 빈배열로 초기화
2. 시작 날짜와 종료 날짜가 동일하면 한개의 데이터만 저장후 바로 종료
3. 시작 날짜의 배열 Length와 종료 날짜의 배열 Length를 비교해서 큰 숫자와 동일하게 null값을 추가하여 높이를 맞춥니다
4. 시작 날짜의 startingDay와 종료 날짜의 endingDay를 true로 표시해줍니다.
5. 시작 날짜와 종료 날짜사이에 배열들도 3번과 같은 의미로 null값을 추가하여 높이를 맞춰줍니다.

const periodsData : { [date: string]: (ISchedule | null)[] } = {}

events.forEach((event) => {
      const startDate = format(event.startDate, 'yyyy-MM-dd');
      const endDate = format(event.endDate, 'yyyy-MM-dd');

      //1. 시작 날짜가 periodsData에 없으면 생성
      if (!periodsData[startDate]) {
        periodsData[startDate] = [];
      }
      //1. 종료 날짜가 periodsData에 없으면 생성
      if (!periodsData[endDate]) {
        periodsData[endDate] = [];
      }

      //2. 시작 날짜와 종료 날짜가 동일한 경우
      if (startDate === endDate) {
        periodsData[startDate].push({
          ...event,
          startingDay: true, // 일정의 시작
          endingDay: true, // 일정의 종료
        });
      } else {
        const startLength = periodsData[startDate].length;
        const endLength = periodsData[endDate].length;

        //3. 시작 날짜와 종료 날짜를 비교해서 같은 높이로 맞추기
        if (startLength > endLength) {
          while (periodsData[endDate].length < startLength) {
            periodsData[endDate].push(null);
          }
        } else if (endLength > startLength) {
          while (periodsData[startDate].length < endLength) {
            periodsData[startDate].push(null);
          }
        }

        //4. 시작 날짜에 시작 표시
        periodsData[startDate].push({
          ...event,
          startingDay: true,
          endingDay: false,
        });
        //4. 종료 날짜에 끝 표시
        periodsData[endDate].push({
          ...event,
          startingDay: false,
          endingDay: true,
        });

        //5. 시작 날짜와 종료 날짜 사이의 날짜들에 대한 표시
        let currentDate = new Date(startDate);
        currentDate.setDate(currentDate.getDate() + 1);
        while (currentDate < new Date(endDate)) {
          const middleDate = format(currentDate, 'yyyy-MM-dd');
          if (!periodsData[middleDate]) {
            periodsData[middleDate] = [];
          }

          const middleLength = periodsData[middleDate].length;

          // 시작 날짜와 중간 날짜를 비교해서 같은 높이로 맞추기
          if (startLength > middleLength) {
            while (periodsData[middleDate].length < startLength) {
              periodsData[middleDate].push(null);
            }
          }

          periodsData[middleDate].push({
            ...event,
            startingDay: false,
            endingDay: false,
          });
          currentDate.setDate(currentDate.getDate() + 1);
        }
      }
    });

결과

{
"2024-06-22":[
    null,
    {
    "scheduleId":122,
    "name":"일정2",
    "startDate":"2024-06-20T07:36:29.196Z",
    "endDate":"2024-06-22T07:36:29Z",
    "startingDay":false,
    "endingDay":true
    },
    ],
    ...
}

Day 컴포넌트에서 해당하는 날짜를 검색하고 null일 경우 한칸 띄우는 View를 구성하는 것으로 해결했습니다.

마무리

"공달이" 프로젝트를 하면서 가장 어려웠던 부분이라 생각합니다. 최대한 단순하게 구현을 해야 성능이라든지 유지 비용에 효율성을 높일 수 있다고 생각했습니다. 초반에 분석하고 설계를 잘 해놓으면 개발하는데 속도가 붙는다고 느끼게 되었습니다.

Deep Link란?

간단하게 설명하자면 웹 브라우저 환경에서 DNS가 존재하는 것처럼 모바일 환경에서도 특정 앱을 실행 시킬 수 있습니다. 방식에는 크게 세가지가 있습니다. 저는 여기서 1번 URI 스킴 방식으로 개발했습니다.

1. URI 스킴 방식: 앱에 URI 스킴(scheme) 등록해서 사용
2. 앱 링크(App Link): 도메인 주소를 등록해서 사용 (Android only)
3. 유니버셜 링크(Universal Link): 도메인 주소를 등록해서 사용 (iOS only)

URI 스킴 방식

URI 스킴 방식은 현재까지 가장 많이 사용하고 있고, 가장 초기에 나온 방식입니다. 앱에 scheme을 등록하여 각 앱을 구분짓습니다. 방식은 Scheme://Path 형태이고 경우에 따라 query(?name=millo)가 붙기도 한다.

• Scheme: 앱을 특정 (twitter)
• Path: 앱 내 페이지를 특정 (트위터 내 특정 페이지)
• query: 해당 페이지로 넘겨줄 값 (선택)

카카오톡 공유하기

1. react-native-kakao-share-link 설치

카카오톡 공유하기는 공식문서에 따라 설정하시면 됩니다.

2. 코드작성

아래 코드처럼 작성하시면 카카오톡 앱이 깔려있을 경우 정상으로 공유가 가능합니다.

KakaoShareLink.sendText({
        text: `안녕하세요! 공달이 앱에 초대합니다.
함께 일정을 공유하고 소통할 수 있는 새로운 캘린더 [${params.name}]가 생성되었어요. 
아래 링크를 클릭하면 바로 참여할 수 있습니다. 📅✨`,
        link: {
          webUrl: 'https://developers.kakao.com/',
          mobileWebUrl: 'https://developers.kakao.com/',
        },
        buttons: [
          {
            title: '앱에서 보기',
            link: {
              androidExecutionParams: [{ key: 'groupKey', value: params.key }],
              iosExecutionParams: [{ key: 'groupKey', value: params.key }],
              webUrl: 'https://developers.kakao.com/',
              mobileWebUrl: 'https://developers.kakao.com/',
            },
          },
        ],
      })

공유하기가 정상적으로 동작하는 모습을 확인 할 수 있습니다. "앱에서 보기" 버튼을 누르면 아직 아무일도 일어나지 않습니다. 추가적인 설정이 필요합니다.

Deep Link 설정

1. 안드로이드 설정

안드로이드는 AndroidManifest.xml에서 스킴을 추가해줘야합니다. kakao{카카오 네이티브 앱키}가 Scheme이 되고, kakaolink가 Path가 됩니다.

## ./android/app/src/main/AndroidManifest.xml

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
  package="com.example">
+   <uses-permission android:name="android.permission.INTERNET" />
    <application>
      <activity>
        <intent-filter>
            <action android:name="android.intent.action.MAIN" />
            <category android:name="android.intent.category.LAUNCHER" />
        </intent-filter>
+       <intent-filter>
+           <action android:name="android.intent.action.VIEW" />
+           <category android:name="android.intent.category.DEFAULT" />
+           <category android:name="android.intent.category.BROWSABLE" />
+           <data android:host="kakaolink" android:scheme="kakao{카카오 네이티브 앱키}" />
+        </intent-filter>
      </activity>
    </application>
</manifest>

2. IOS 설정

IOS도 마찬가지로 Info.plist에서 설정해주시면됩니다.

## ./ios/{your-project-name}/Info.plist

  <key>CFBundleURLTypes</key>
  <array>
+   <dict>
+     <key>CFBundleTypeRole</key>
+     <string>Editor</string>
+     <key>CFBundleURLSchemes</key>
+     <array>
+       <string>kakao{카카오 네이티브 앱키}</string>
+     </array>
+   </dict>
  </array>
  <key>CFBundleVersion</key>
  <string>1</string>
+ <key>KAKAO_APP_KEY</key>
+ <string>{카카오 네이티브 앱키}</string>
+ <key>LSApplicationQueriesSchemes</key>
+ <array>
+     <!-- 카카오링크 -->
+     <string>kakaolink</string>
+ </array>

3. React Native 코드 작성

아래와 같이 입력하면 딥링크의 요청이 handleDeepLink로 들어오게 됩니다. 해당 함수에서 로직에 맞게 처리하시면 됩니다.

  const handleDeepLink = (url: string | null) => {
    console.log('Deep Link: ', url);
    ... 해당 로직 작성
  };

  useEffect(() => {
    const linkingListener = Linking.addEventListener('url', (e) => {
      handleDeepLink(e.url);
    });

    return () => {
      linkingListener.remove();
    };
  }, []);

결과

마무리

카카오톡 공유하기를 쉽게 이용 할 수 있었고 딥링크에 알게된 계기였습니다. 딥링크의 활용도는 무궁무진하다고 생각이 듭니다. 딥링크를 이용 할 수 있는 웹도 만들어서 연결하면 지금 기능뿐 아니라 다양한 방면으로 활용 할 수 있을 것 같다.

문제 인식

원했던 화면이 그려지기는 했지만 로딩 되는데에 매우 오래걸리는 문제가 있었습니다. 성능 모니터링 툴로 확인을 해보니 3.3s가 걸리는 것을 확인할 수 있었습니다.

구글 리서치 자료에 따르면 모바일 웹 사이트의 로딩 시간이 3초 이상일 때 32%, 5초 이상은 90%, 6초 이상은 106% 마지막으로 10초가 넘으면 123%의 이탈률이 발생한다고 합니다.

우리는 아무것도 안했는데 벌써 유저 32%를 잃었습니다!! 지금은 빈 달력뿐이지만 나중에 일정, 애니메이션 등등 추가가 된다면 렌더링 시간은 더 늘어날 것입니다.

개선 방법

React Native에는 List를 표현하는 방법으로 ScrollView / FlatList / SectionList 를 이용하여 구현할 수 있습니다. 보통은 FlatList를 이용하여 작업을 많이 하게 됩니다.

React Natvie에서 List 최적화 방법이 많은데, 공식문서에서도 FlatList의 최적화 방법을 소개하고 있습니다.

하지만, 성능이 좋지 못한 폰에서는 리스트가 버벅거리는 현상이 있었습니다. 그렇게 해서 레퍼런스를 찾다가 발견한 List가 recyclerListView입니다.

recyclerListView는 성능의 이점은 있지만 사용법이 복잡하고 제대로 갱신이 되지 않는 버그를 가지고 있습니다.

그렇게 찾아보다 알게된 라이브러리가 FlashList입니다. FlashList는 내부적으로 recyclerListView를 가지고 있지만, 사용법이 FlatList와 같아 React Native의 FlatList를 사용해본 사람이라면 쉽게 구현할 수 있는 구조를 가지고 있습니다.

  return (
    <SafeAreaView style={{ flex: 1 }}>
      <FlashList // 변경
        ... 기존 코드
        estimatedItemSize={width} // 추가
      />
    </SafeAreaView>
  );
};

개선 결과

기존 3.3초였던 렌더링 속도가 1.2초로 단축된 것을 확인 할 수 있습니다. 약 63% 단축 된 결과를 얻었습니다!

이런 접근 방식을 통해 표시 성능을 최적화하면서도 보기 좋은 캘린더를 만들 수 있습니다.

마무리

성능 모니터링 툴을 이용해 성능개선을 해보니 도구나 기법에 더더욱 관심이 생기게 되었습니다. 도구를 더 잘쓰게 된다면 얻는 이점이 많다는 것을 알 수 있었습니다. 관심갖고 학습하여 더 나은 프로젝트를 만드는데 큰 도움이 되었습니다.

스마트폰을 사용하다가 앱을 길게 누르면 아래와 같은 액션 창을 본 적이 있을 겁니다. 옛날에는 앱 제거와 앱 위치 이동밖에 없었지만, 이제는 다양한 기능들로 사용자 경험을 향상시킬 수 있습니다.

Quick Actions 설정하기

먼저, react-native-quick-actions 라이브러리를 사용하여 Quick Actions를 설정합니다. Quick Actions를 통해 앱을 실행하면 특정 작업을 바로 수행할 수 있습니다.

설치

라이브러리를 설치합니다. 이 단계는 쉽기 때문에 따로 설명하지 않겠습니다. 설치가 완료되면 다음과 같이 코드를 작성합니다.

import React, { useEffect } from 'react';
import { DeviceEventEmitter } from 'react-native';
import QuickActions from 'react-native-quick-actions';

QuickActions.setShortcutItems([
  {
    type: '새로운 일정',
    title: '새로운 일정',
    icon: 'Compose',
    userInfo: {
      url: 'schedule',
    },
  }
]);

const App = () => {
  const handleQuickAction = (data) => {
    if (data.type === '새로운 일정') {
      // 원하는 작업 수행: 예를 들어 화면 이동
      console.log('Quick Action Triggered: 새로운 일정');
      // 네비게이션을 사용하여 특정 화면으로 이동
      // navigation.navigate('ScheduleScreen');
    }
  };

  useEffect(() => {
    const quickActionListener = DeviceEventEmitter.addListener(
      'quickActionShortcut',
      handleQuickAction
    );

    return () => {
      quickActionListener.remove();
    };
  }, []);

  return (
    // 앱의 루트 컴포넌트
  );
};

export default App;

코드를 간단히 설명하겠습니다

1. QuickActions.setShortcutItems: Quick Actions를 설정합니다. type, title, icon, userInfo 등을 정의하여 사용자가 앱을 길게 눌렀을 때 나타날 항목을 지정합니다.

2. DeviceEventEmitter.addListener: Quick Action이 발생하면 handleQuickAction 함수가 호출됩니다. 이 함수에서 원하는 작업을 수행할 수 있습니다. 예를 들어, 화면을 이동시키거나 특정 작업을 바로 수행할 수 있습니다.

퀵액션을 통해 앱을 실행하면 handleQuickAction에 데이터가 들어옵니다. 이 데이터를 바탕으로 화면을 이동시키거나 원하는 작업을 수행할 수 있습니다.

마무리

간단한 기능 추가만으로도 사용자의 경험을 향상 시킬 수 있었습니다. 작은 기능들이 모여 큰 비지니스가 되는 것을 느끼게 되었습니다. 작은 기능이라 하더라도 꼼꼼하게 개발하는 개발자가 되어야겠다가 느꼈습니다.

라이브러리 탐색

우선 저는 프로젝트를 빠르게 시작하고 싶어서 이미 존재하는 라이브러리를 사용하는 것이 좋겠다고 생각했습니다. 아래는 제가 찾아본 몇 가지 인기 있는 캘린더 라이브러리들입니다.

1. react-native-calendars

가장 먼저 찾아본 라이브러리는 react-native-calendars입니다. 이 라이브러리는 React Native에서 가장 널리 사용되는 캘린더 라이브러리 중 하나입니다. 다양한 뷰(월간, 주간, 일간 포함)를 제공하며, 커스터마이징이 용이합니다.

특징:

• 다양한 캘린더 뷰 제공
• 커스터마이즈 가능한 날짜 표시
• 이벤트, 마커 추가 기능

2. react-native-calendar-events

또 다른 유망한 라이브러리는 react-native-calendar-events입니다. 이 라이브러리는 Native 모듈로서 기기의 기본 캘린더와 상호작용 할 수 있게 해줍니다. 즉, Google Calendar나 Apple Calendar와의 동기화가 가능합니다.

특징:

• Native Calendar API와 연동
• 일정 추가, 삭제, 검색 기능

3. react-native-big-calendar

react-native-big-calendar는 좀 더 심플하고 직관적인 UI를 제공하는 캘린더 라이브러리입니다. 대규모의 이벤트들을 한눈에 보기 좋게 표현할 수 있으며, 사용자 친화적인 인터페이스를 제공합니다.

특징:

• 월간, 주간, 일간 캘린더 뷰
• 드래그 앤 드롭 이벤트 기능
• 터치 인터랙션 지원

많고 좋은 라이브러리가 많았고 실제로 써봤지만 아무리 커스터마이징하여 필요한 기능을 만든다 하더라도 한계가 있었습니다. 그래서 직접 구현하기로 결정했습니다! 그냥 네이티브로 만들걸..!

기본 UI 설계

const PAST_SCROLL_RANGE = 12;
const FUTURE_SCROLL_RANGE = 12;

const Calendar = () => {
  const { width } = useWindowDimensions();

  const items: Date[] = useMemo(() => {
    const months: Date[] = [];
    for (let i = 0; i <= PAST_SCROLL_RANGE + FUTURE_SCROLL_RANGE; i++) {
      const rangeDate = addMonths(new Date(), i - PAST_SCROLL_RANGE);
      months.push(rangeDate);
    }

    return months;
  }, []);

  const renderItem = useCallback(({ item }: { item: Date }) => {
    const monthStart = startOfMonth(item);
    const monthEnd = endOfMonth(monthStart);
    const startDate = startOfWeek(monthStart);
    const endDate = endOfWeek(monthEnd);

    const rows = [];

    let days = [];
    let day = startDate;

    while (day <= endDate) {
      for (let i = 0; i < 7; i++) {
        const formattedDate = fDate(day);
        days.push(
          <View key={formattedDate} style={{ padding: 8, flex: 1 }}>
            <Text>{formattedDate}</Text>
          </View>,
        );
        day = addDays(day, 1);
      }
      rows.push(
        <View
          style={{
            flexDirection: 'row',
            flex: 1,
          }}
          key={day.toString()}
        >
          {days}
        </View>,
      );
      days = [];
    }

    return (
      <View
        style={{
          width: width,
          height: '100%',
        }}
      >
        <View style={{ flex: 1 }}>{rows}</View>
      </View>
    );
  }, []);


  return (
    <SafeAreaView style={{ flex: 1 }}>
      <FlatList
        data={items}
        keyExtractor={(item) => JSON.stringify(item)}
        renderItem={renderItem}
        horizontal
        pagingEnabled
      />
    </SafeAreaView>
  );
};
export default Calendar;

실행 결과

추가 기능

여기서 캘린더 기능을 확장하여 다양한 기능을 추가할 수 있습니다. 다음은 몇 가지 추가할 수 있는 기능들입니다:

1. 일정 추가 및 관리: 각 날짜 셀을 클릭하면 일정 추가, 수정, 삭제가 가능한 팝업을 띄울 수 있습니다.
2. 알림 기능: react-native-push-notification 같은 라이브러리를 사용하여 일정 전에 사용자가 알림을 받을 수 있도록 합니다.
3. 다채로운 뷰 제공: 월간 뷰 외에도 주간 뷰, 일간 뷰 등을 추가하여 다양한 인터페이스를 제공합니다.
4. 확장 가능한 상태 관리: 상태관리 라이브러리를 사용하여 복잡한 상태 관리를 효율적으로 처리할 수 있습니다.

마무리

React Native로 캘린더 앱을 만드는 과정에서 이미 좋은 라이브러리들이 많다는 점을 알 수 있었습니다. 하지만 커스터마이징의 한계를 느꼈고, 직접 구현함으로써 프로젝트에 대한 완벽한 제어권을 확보하겠다는 결정을 하게 되었습니다. 무언가를 처음부터 구현하려는 결정은 언제나 쉽지 않지만, 프로젝트를 더 나아가게 만드는 큰 발걸음이 될 수 있습니다.

인스턴스

const instance = axios.create({
  // 상대적인 URL을 인스턴스 메서드에 전달하려면 baseURL을 설정하는 것은 편리하다.
  // URL(서버 주소) 예시 - http://127.0.0.1:5500
  baseURL: URL,
  // 요청이 timeout보다 오래 걸리면 요청이 중단된다.
  timeout: 1000,
  // 헤더값
  headers: {
    'Content-Type': 'application/json',
  },
});

• 인스턴스는 위와같이 서버주소라던지 타임아웃, 기본 헤더값을 미리 설정하고 재사용 할 수 있다! 벌써 편함
  

요청 인터셉터

instance.interceptors.request.use(
  (config) => {
    // getToken() - 클라이언트에 저장되어 있는 액세스 토큰을 가져오는 함수
    const accessToken = getToken();

    config.headers['Content-Type'] = 'application/json';
    config.headers['Authorization'] = `Bearer ${accessToken}`;

    return config;
  },
  (error) => {
    console.log(error);
    return Promise.reject(error);
  }
);

• request를 사용하면 요청이 전달되기 전에 개입 할 수 있다.
• 예시와같이 accesstoken이나 헤더 토큰을 추가하면 원래 요청에 해당 내용이 추가가 되어 실행된다
  

응답 인터셉터

instance.interceptors.response.use(
  (response) => {
    return response;
  },
  async (error) => {
    if (error.response?.status === 401) {
      // isTokenExpired() - 토큰 만료 여부를 확인하는 함수
      // tokenRefresh() - 토큰을 갱신해주는 함수
      if (isTokenExpired()) await tokenRefresh();

      const accessToken = getToken();

      error.config.headers = {
        'Content-Type': 'application/json',
        Authorization: `Bearer ${accessToken}`,
      };

      // 중단된 요청을(에러난 요청)을 토큰 갱신 후 재요청
      const response = await axios.request(error.config);
      return response;
    }
    return Promise.reject(error);
  }
);

• response를 사용하여 요청의 응답의 적용 할 수 있다
• 예시처럼 토큰만료 코드인 401을 응답 받았을때 토큰 재발행하는 함수를 실행하고 기존 요청에 새로운 토큰을 넣어 다시 시도하는 방법으로 많이 사용한다.

몇줄 안되지만 위처럼 모듈화를 해놓고 사용하면 개발할때 수고스러움을 많이 덜어준다. 개꿀

현업에서 간편 송금앱을 개발중인데 채팅 서비스도 포함이 되어있다. 개발하다보니 많은 문제점이 발생했다.

문제점

1. 생각보다 Api조회가 너무 많다

기존의 프로세스는 다음과 같다

• 채팅방에 입장하면 방 정보와 채팅내용을 조회하여 렌더링한다
• 백그라운드에서 포그라운드 전환한 경우 데이터를 갱신한다. 채팅을 하다가 인스타하거나 유튜브 보거나

앱에 접속해있는 상태에서는 websocket을 사용하기때문에 전혀 문제가 없었다. 하지만 백그라운드 전환한 경우에는 api통신을 통해 메시지 내역을 불러와야했다. 백그라운드 상태일때 받은 메시지가 많으면 많을수록 데이터 통신양이나 성능에 문제가 보였고 무엇보다 채팅방에 들어올때마다 사용자에게 좋지 않은 UX를 주는게 별로였다. 사용자 입장에서 느리고 좋지않은 경험이다

2. 채팅방 처음 입장할때 대기시간이 생긴다.

처음 입장할때 메시지 내역을 조회한다. 아무리 페이징처리해서 소규모의 데이터만 가져온다해도 대기시간이 존재한다. 카카오톡을 비교해보면 채팅방에 들어가기 전부터 채팅내역이 있고 부드러운 경험을 주고 있는데 우리 앱은 방에들어면 몇초간 하얀 스크린을 보고있다.

3. 추가기능인 메시지 검색 기능 구현이 어렵다.

카카오톡 기능중 아래 이미지와같이 메시지 검색기능이 있다

이슈 해결

위에 1번문제를 생각해봤을때 데이터를 프론트가 가지고있어서 api호출을 최소화하자는 생각이 들었다. 그러려면 데이터를 프론트에 저장을 해놔야한다 생각했고 로컬디비를 비교해 보았다.

1. Firebase

• 데이터 타입이 단순,명료.
• 소규모 앱
• 온라인 동기화까지 고려
• 트래픽이 적으면 사용
• 배우기 쉬움
• NoSQL

2. Realm

• Local DB 목적으로는 최적. (Cloud platform은 무조건 돈 받는다.)
• 빠른 속도
• 배우기 쉬움
• NoSQL

3. SQLite

• 관계형 DB
• 완전 무료, 오픈 소스
• ORM DB에 익숙한 사람 (SQL문)

각각의 장단점이 있고 상황에 맞게 쓰면 된다. 필자는 SQLite 골랐다 왜냐하면 그때는 구조가 복잡해질거같았고 스키마를 명확히 해야 할거 같았다 또, sql문이 더 익숙해서 골랐다 . 하지만 지금와서는 잘못된거 같다. Realm으로 속도도 더 빠르고 생각보다 디비구조가 복잡하지않아서 오히려 더 무거워진 느낌이다. 일정을 보고 조만간 Realm으로 마이그레이션을 진행해볼까한다

과정

1. 앱을 런칭하면 모든 로컬디비를 조회하여 아래와 같은 타입으로 가공해놓는다.

데이터 검색 효율때문에 Record타입으로 정의했다. 일반 배열을 검색하는거보다 빠른속도를 보장한다.

messagesByRoomKey: Record<string, IMessage[]>;

export interface IMessage {
    ...
}

2. 채팅방에 들어오면 로컬디비에 마지막으로 저장된 값을 불러와서 그 값을 기준으로 이후의 메시지들을 조회하는 api를 사용한다.

3. 조회된값을 로컬디비에 저장하면 다음에는 api 조회없이 로컬디비만으로 충분하다.

결과

• 최소한의 api 조회만으로 구성했다.
• 메시지를 로컬 디비에 저장하고 미리 불러오는 과정으로 딜레이없이 렌더링을 향상했다.

보완해야할 점

• 처음부터 설계가 완벽하지못했던 점이 아쉽다. 그러다 보니 코드의 구조가 난잡하다. 혼자 개발하는게 아닌 이상 협업을 하기때문에 가독성을 보완해야 할 숙제가 생겼다

그래서 찾아보니 원인은 자동백업 때문이었다

Android API 23(또는 Android "6.0" 또는 Android "Marshmellow")이후 BackupManager는 공유 환경 설정을 포함한 앱의 모든 데이터를 클라우드에 저장한다.

이는 안드로이드 6.0부터는 AndroidManifest.xml 파일에서 application 요소의 android:allowBackup 속성을 명시하지 않으면 자동으로 true로 설정하기 때문인데 이로 인해 사용자도 모르게 데이터가 구글 클라우드에 자동으로 백업된다.

결국 재설치를 하면 자료가 자동으로 백업이 되다보니 환경설정 데이터도 복원되는 것이다.

해결방법

아래처럼 AndroidManifest.xml의 파일에 application요소에 allowBackup, fullBackupContent 요소를 false로 설정하면된다.

// AndroidManifest.xml

 <application
        ...
        android:allowBackup="false"
        android:fullBackupContent="false"
        ...
        >

참고

https://stackoverflow.com/questions/33169618/an-android-app-remembers-its-data-after-uninstall-and-reinstall

우선 환경은 React Native + SwiftUi 입니다

우선 React-Native 폴더에서 react-native-watch-connectivity 을 설치해줍니다.

npm install react-native-watch-connectivity --save
# or
yarn add react-native-watch-connectivity

후에
cd ios
pod install

App.tsx

import React, {useEffect, useState} from 'react';
import {
  Alert,
  SafeAreaView,
  Text,
  TextInput,
  TouchableOpacity,
} from 'react-native';
import {sendMessage, watchEvents} from 'react-native-watch-connectivity';

const App = () => {
  const [messageFromWatch, setMessageFromWatch] = useState('Waiting...');
  const [message, setMessage] = useState('');

  const messageListener = () =>
    //여기로 메시지 들어옴 
    watchEvents.on('message', (message: any) => {
      setMessageFromWatch(message.watchMessage);
    });

  useEffect(() => {
    messageListener();
  }, []);

  return (
    <SafeAreaView>
      <Text>Received from Watch App!</Text>
      <Text>{messageFromWatch}</Text>
      <Text>Send to Watch App!</Text>
      <TextInput placeholder="Message" onChangeText={setMessage}>
        {message}
      </TextInput>

      <TouchableOpacity
        onPress={() =>
          sendMessage(
            {messageFromApp: message},
            reply => {
              console.log(reply);
            },
            error => {
              if (error) {
                Alert.alert(
                  "메시지 전송 실패 🤔",
                );
              }
            },
          )
        }>
        <Text>SEND!</Text>
      </TouchableOpacity>
    </SafeAreaView>
  );
};

export default App;

messageListener를 통해 워치로부터 메시지를 수신받고 sendMessage를 통해 워치로 메시지를 전달합니다. 간단하죠?

그리고 이제 스위프트 코드를 작성해야하는데 여기서 삽질 오지게함

잘따라오십시요

1. 루트프로젝트에서 new > target 클릭

2. watchOS 탭에 App 클릭

옛 버전에서는 watch app for ios 등등 여러개였었는데 통합된듯

3. 와치앱 이름과 Identifier을 잘 입력해주시고 Watch App for Existing iOS App으로 기존 iOS앱이랑 연결해주세요.

이게 2번에서 말한 통합된 내용인듯합니다.

저는 WatchApp이라는 이름으로 진행하겠습니다

4. 여기까지 진행하면 폴더가 다음처럼 구성될거에요

WachApp Watch App이 새로 생김, 이름뒤에 자동으로 뭐가 붙는데 거슬리기는 하나 튜토리얼이기에 넘어갑시다

5. PhoneConnector.swift 파일 생성합니다.

폴더보면 PhoneConnector이라는 파일이있는데, 저는 미리 만들어놨기때문에 존재하는거지 원래 없습니다.

watchApp 폴더에서 new watchOS > swift 파일 선택 PhoneConnector 생성

6. PhoneConnector 코드 입력

import SwiftUI
import WatchKit
import WatchConnectivity


final class PhoneConnector: NSObject ,ObservableObject{
  @Published var receivedMessage = "Waiting..."

  var session: WCSession
  init(session: WCSession  = .default) {
    self.session = session
    super.init()
    if WCSession.isSupported() {
      session.delegate = self
      session.activate()
    }
  }
}

extension PhoneConnector: WCSessionDelegate {
  func session(_ session: WCSession, activationDidCompleteWith activationState: WCSessionActivationState, error: Error?) {

  }

  func session(_ session: WCSession, didReceiveMessage message: [String : Any], replyHandler: @escaping ([String : Any]) -> Void) {

    guard let messageFromApp = message["messageFromApp"] as? String else { return }


    DispatchQueue.main.async {
      self.receivedMessage = messageFromApp
    }
  }
}

라이브러리가 제공하는 기본 형태입니다. 대강 읽어보시면 세션만들어서 메시지받고 receivedMessage라는 메시지를 퍼블릭하게 공유한다 정도로 이해하면 됩니다.

7. ContentView 코드작성

import SwiftUI

struct ContentView: View {
  @ObservedObject var phoneConnector = PhoneConnector()

  var body: some View {
    VStack(alignment: .leading, spacing: 20) {
      VStack(alignment: .leading, spacing: 5) {
        Text("Send to Watch")
        Button {
          self.sendMessage()
        } label: {
          Text("Send")
        }
      }
      VStack(alignment: .leading, spacing: 5) {
        Text("Message from App")
        Text(self.phoneConnector.receivedMessage)
      }
    }
  }

  private func sendMessage() {
    let randomNumber = String(Int.random(in: 0..<1000))
    let message: [String: Any] = ["watchMessage": randomNumber]
    self.phoneConnector.session.sendMessage(message, replyHandler: nil) { (error) in
      print(error.localizedDescription)
    }
  }
}

struct ContentView_Previews: PreviewProvider {
  static var previews: some View {
    ContentView()
  }
}

phoneConnector를 연결해서 수신하고 랜덤 문자열을 송신하는 UI를 구성했습니다

8. 실행

watchApp을 타겟으로 실행해야합니다. 실행하면 메트로가 켜지고 ios랑 워치 시뮬레이터가 켜집니다.

여기까지 오면 끝났습니다

테스트

1. 워치 시뮬레이터에서 Send를 클릭합니다.
2. ios 시뮬레이터를 확인하면 수신이 확인됩니다. 355라는 숫자가 새로 생겼죠? 워치앱 send를 누를때마다 갱신합니다.

반대로도 테스트를 해보죠

1. ios 시뮬레이터에서 input을 입력하고 SEND! 클릭
2. 워치 시뮬레이터를 확인하면 수신이 확인됩니다. 잘가냐라는 메시지가 새로 생겼습니다.

마무리

송수신 모두 잘되는거 확인했습니다.

해당 코드는 깃허브에서 확인 할 수 있습니다.

다음에는 백그라운드도 올려볼게유

Realtime database

1. 비관계형 클라우드 데이터베이스

• 기존의 관계형 데이터베이스와 다른 접근 방식을 갖는다.
• 관계형에서 table의 역할은 비관계형에서는 Collection이 담당. Record(관계형)는 Document(비관계형)이 담당한다.

2. 실시간이 가능하다.

• 필요할 때 마다, HTTP 요청을 전송하고 응답 받아 데이터에 접근하는 방식이 아닌 동기화 방식을 사용한다.

3. 오프라인 상태에서도 데이터를 유지할 수 있다.

• 오프라인 상태인 경우, App 로컬에 저장하고 있다가 네트워크가 연결되면 로컬에 저장했던 데이터를 동기화시킨다.

2. 서버 없이 앱 만으로도 동작할 수 있다.

• 앱에서 직접 Firebase Realtime Database에 접근할 수 있기 때문에 별도의 서버 없이 동작할 수 있다.

Firestore

Firebase에서 제공하는 또 다른 데이터베이스로, 비교적 최근에 나온 기능이다.

위에서 언급한 4가지의 기능(비관계형 데이터베이스, 실시간, 오프라인 가능, 서버 없이 동작 가능)은 똑같이 제공된다.

홈페이지에서 제공하는 주요 기능 리스트이다. 유연성, 표현형 쿼리, 실시간 업데이트, 오프라인 지원, 확장형 설계

Realtime Database vs Cloud Firestore :: 차이점

그렇다면 나는 어떤 데이터베이스를 써야할까?

앱의 특성에 따라 권장하는 데이터베이스가 다르다. 각 데이터베이스별로 적합한 앱의 특성은 아래와 같다.

1. Realtime Database

• 기본적인 데이터 동기화
• 적은 양의 데이터가 자주 변경
• 간단한 json 트리
• 많은 데이터베이스

2. Cloud Firestore

• 고급 쿼리, 정렬, 트랜젝션

• 대용량 데이터가 자주 읽힘

• 구조화된 컬렉션

• 단일 데이터베이스

  권장 데이터베이스의 체크리스트를 통해서 확인 할 수 있다.

2. Browser에 캐싱된 DNS 기록들을 확인, www.google.com 에 대응하는 IP주소가 있는지 확인한다.

DNS의 목적은 편의성 제공이며 캐싱은 네트워크 트래픽을 조절하고 데이터 전송 시간을 줄인다.

• 가장 먼저 브라우저 캐시를 확인한다. 브라우저는 일정기간 동안의 DNS 기록들을 저장하고 있다. DNS Query가 이 곳에서 가장 먼저 실행이 된다.
• 그 다음에는 OS 캐시를 확인한다. 브라우저 캐시에 웹사이트 이름의 IP 주소가 발견되지 않으면, 브라우저는 systemcall을 통해 OS가 저장하고 있는 DNS 기록들의 캐시에 접근한다.
• 그 다음에는 Router 캐시를 확인한다. 컴퓨터에 DNS 기록들을 찾지 못하면 브라우저는 DNS 기록을 캐싱하고 있는 Router와 통신을 해서 찾으려고 한다.
• 그래도 못 찾는다면 마지막으로, ISP 캐시를 확인한다. ISP는 DNS 서버를 구축하고 있고 브라우저가 마지막으로 DNS 기록이 있기를 바라며 접근한다.

3. 요청한 URL이 캐시에 없으면, ISP의 DNS 서버가 www.google.com을 호스팅하고 있는 서버의 IP주소를 찾기 위해 DNS Query를 날린다.

DNS Query의 목적은 여러 다른 DNS 서버들을 검색해서 해당 사이트의 IP주소를 찾는 것이다. 이러한 검색을 Recursive Search라고 부른다. IP주소를 찾을 때 까지 DNS서버에서 다른 DNS서버를 오가면서 반복적으로 검색한다. 이 상황에서, ISP의 DNS 서버를 DNS recursor라고 부르고 인터넷을 통해 다른 DNS 서버들에게 물어 물어 도메인의 이름의 올바른 IP 주소를 찾는데 책임을 갖고 있다.

4. Browser가 서버와 TCP 연결을 한다.

브라우저가 올바른 IP 주소를 받게 되면 서버와 연결을 한다. 브라우저는 인터넷 프로토콜을 사용해서 서버와 연결이 된다. 웹사이트의 HTTP 요청의 경우 일반적으로 TCP를 사용한다. 클라이언트와 서버간 데이터 패킷들이 오가려면 TCP 연결이 되어야한다. TCP/IP three-way handshak 프로세스를 통해 연결이 이루어진다.

TCP/IP three-way handshak란?

• 클라이언트 머신이 SYN 패킷을 서버에 보내고 연결을 열어달라고 물어본다.
• 서버가 새로운 연결을 시작할 수 있는 포트가 있다면 SYN/ACK 패킷으로 대답은 한다.
• 클라이언트는 SYN/ACK 패킷을 서버로부터 받으면 서버에게 ACK 패킷을 보낸다 이 과정이 끝나면 TCP 연결이 완성된다.

5. Browser가 웹 서버에 HTTP 요청을 한다.

TCP 연결이 되어있다면, 데이터를 전송하면 된다. 클라이언트의 브라우저는 GET 요청을 통해 서버에게 www.google.com 웹페이지(html)을 요구한다. 요청을 할 때 쿠키나 헤더 정보와 같은 자료들을 포함 할 수 있다.

6. 서버가 요청을 처리하고 response를 생성한다.

서버는 웹서버를 가지고 있다. 이들은 브라우저로부터 요청을 받고 request handler한테 요청을 전달해서 요청을 읽고 response를 생성하게 된다. 이 request handler는 요청과 요청의 헤더, 쿠키를 읽어서 요청이 무엇인지 파악하고 필요하다면 서버에 정보를 업데이트 한다.

7. 서버가 HTTP response를 보낸다.

서버의 response에는 요청한 웹페이지, status code, compression type, 어떻게 인코딩 되어있는지, 어떻게 페이지를 캐싱할지 등이 포함된다.

8. Browser가 HTML content를 보여준다.

브라우저는 HTML content를 단계적으로 보여준다. 처음에는 HTML 스켈레톤을 렌더링하고 그 후에 HTML tag들을 체크해서 추가적으로 필요한 리소스등을 요청한다. 이 정적 우베페이지는 브라우저에 의해 캐싱이 되서 나중에 해당 페이지를 방문 할때 다시 서버로부터 요청하지 않는다. 드디어 원했던 www.google.com의 모습이 보여지게 된다.