날씨와 동기 유형

aydennote·2023년 4월 9일
0

Project

목록 보기
6/8
post-thumbnail

1. firebase

에러 :
Firebase: Firebase App named '[DEFAULT]' already exists with different options or config (app/duplicate-app).

해결 :
에러를 해석하자면 Firebase에서 '[DEFAULT]'라는 이름의 앱이 이미 존재합니다. 라는 뜻이다.

// 기존
const app = initializeApp(firebaseConfig)
// 변경
const app = !getApps().length ? initializeApp(firebaseConfig) : getApp();

기존 에러 코드에서 변경 코드로 입력 후 정상적으로 해결되었다.

2. RTK State와 서버 데이터 동기화

어느 시점에 서버(Cloud Firestore)와 RTK State 데이터를 동기화시켜 활용하는 게 좋을지 고민했는데 여러 방법을 시도해봤다.
app.tsx 컴포넌트에 useEffect로 데이터를 받아 state에 저장시키려는 바보 같은 방법도 시도해보고 일정 생성, 완료, 삭제 등 모든 작업 하나하나 서버와 state를 같이 업데이트시켜 서버 호출 작업이 어마어마하게 늘어난 코드를 작성해버린 경험도 있다.
결론은 아래 처럼 기능으로 나눠 서버, state 데이터를 관리했다.


최초 로그인 시 : 서버에 데이터 생성.
일정 생성, 완료, 삭제 : RTK state로 데이터 관리.
일정 저장 : 서버에 데이터 업데이트.
새로고침 : 서버 데이터 불러와 RTK state에 저장.
완료 일정 전체 삭제 : 서버, RTK state 모두 변경.

3. RTK persist

에러 :
A non-serializable value was detected in an action, in th e path" 'register'.
리덕스 툴킷 persist 적용 후 에러 메시지가 출력되었다.

export default configureStore({
  reducer: persistedReducer,
  middleware: getDefaultMiddleware => getDefaultMiddleware().concat(logger),
});

위 코드는 에러가 발생한 기존 코드로 아래 코드로 변경 후 정상 해결되었다.

해결 :

export default configureStore({
  reducer: persistedReducer,
  middleware: [logger],
});

동작은 정상적으로 되는 것 같은에 로그에 에러가 계속 올라왔고 원인은 잘 못 작성한 미들웨어 정도로 추측된다.

4. 새로고침 데이터 관리

처음에는 RTK와 Cloud Firestore를 이용해 일정과 날씨에 대한 데이터를 관리하려고 했다. 개발 진행 중 새로고침 시 state 초기화되는 문제를 로컬스토리지에 state를 저장하는 persist 라이브러리로 해결했다.
persist 도입에도 문제가 있었는데 로그인하지 않아도 로컬스토리지에 데이터가 있어 저장된 일정을 볼 수 있었고 서버와 데이터 동기화에 있어서 중복으로 데이터를 저장하고 있다는 느낌을 받았다.
Cloud Firestore를 사용하면서 로컬스토리지를 사용해야 하는 이유를 새로고침 문제 외에는 찾지 못했고 결국, useEffect를 사용해 렌더링 시 서버 데이터를 불러와 RTK state에 저장하는 방식으로 새로고침 시 state 초기화 문제를 해결했다.


useEffect 해결 방법에도 아래 처럼 문제가 있다.
페이지 새로고침 ➡ state 초기화 ➡ 초기화 데이터 화면에 보여짐 ➡ 서버로부터 데이터를 받아 state 변경 ➡ 변경된 데이터 화면에 보여짐.
즉, 새로고침 시 페이지 렌더링이 두 번씩 되는 문제다.
이 부분은 개선 방법을 찾게 된다면 어제든 수정할 생각이다.🔥🔥🔥


useEffect 리렌더링의 근본적인 해결책은 아니지만 사용자 입장에서 데이터 깜빡임 없이 보이도록 수정했다. 해당 페이지에 useState 를 추가하여 data fetch가 이루어지면 true 로 변경해 false 일 때는 화면에 보이지 않도록 렌더링을 제어하여 개선했다. 다만, 아직도 state 가 두 번 변하기 때문에 성능적인 측면에서는 유의미한 해결책은 아닌 것 같다.


Vercel로 배포 후 logger로 봤을 때는 1회 state가 변해 렌더링에 문제가 없는 것으로 확인되었다. Vercel과 같은 호스팅 서비스에서는 브라우저와 서버가 분리되어 있기 때문에 새로고침 요청을 보낼 때마다 서버에서 새로운 상태를 응답하고, 브라우저는 이를 받아와서 새로운 상태로 렌더링하기 때문인 것 같은데 다음에는 프로젝트 도중 배포를 먼저 해놓고 로컬, 배포 모두 확인하면서 개발하는 방법을 시도해보려고 한다.

5. firebase 도메인, 규칙 추가 실패

프로젝트를 만든지 약 1개월 후 위 사진과 같이 구글 메일에 알림이 왔다. 다급하게 구글, chat GPT 등을 통해 찾아보고 최초 데이터베이스 생성시 규칙은 "1개월 DB 요청 허용" 이라는 것을 알았다.
규칙 수정 방법은 규칙탭에서 request.time < timestamp.date(날짜); 날짜 부분의 기간을 늘려주면 된다.

그런데, 수정 실패 오류가 지속적으로 발생되면서 수정되지 않았다.
권한/인증 같은 설정을 잘 못 수정한 것으로 추측되어 firestore에서 해당 프로젝트를 삭제하고 다시 만들었다.
요청 허용 기간이 오늘부터 +30일로 만들어졌지만 문제는 또 다른 곳에서 발생했다.

배포된 주소를 승인된 도메인에 등록해야 배포된 주소에서 DB 접근이 가능하게 된다. 규칙 탭에서 발생한 문제가 동일하게 발생되면서 도메인 추가, 삭제가 되지 않았다. 검색을 통해 CORS 키워드를 보고 아차 싶었다. 지난 기업 구현 과제 수행 중 CORS 문제를 개발단에서 해결하기 위해 크롬 확장프로그램을 설치했는데 해당 확장프로그램을 켜두고 있었던 것이다.😂
확장 프로그램을 끄고 도메인, 규칙을 정상 수정, 추가할 수 있었다...

profile
기록하는 개발자 Ayden 입니다.

0개의 댓글