※ React-create-app으로 생성한 프로젝트 내에서 사용가능
✏️ 목적
□ 하나의 svg 파일을 디자인 파일에 맞게 크기 및 색상을 커스텀해서 사용
□ ReactCompoent를 import하여 svg파일을 하나의 Component처럼 사용
✏️ 방법
□ import 하기 전, webpack을 설치하고, webpack을 설정해준다.
webpack설정의 경우 보편적으로 알려져있는 매우 기본적인 설정으로 만들어줌
□ custom.d.ts파일을 만들어 해당 파일 안에 svg에 대한 ReactComponent를 import 하기 위해 대한 코드를 작성해준다.
// custom.d.ts
// .svg 확장자의 파일에대해 ReactComponent의 존재를 인식
declare module "*.svg" {
import React = require("react");
export const ReactComponent: React.FC<React.SVGProps<SVGElement>>;
const src: string;
export default src;
}
위와 같이 custom 파일에 declare해주고, tsconfig.json 내부에 "include": ["src", "custom.d.ts"] 와 같이 custom.d.ts 포함시켜준다.
그러면 다음과 같이 선언하여 사용가능하다.
import { ReactComponent as MainLogo } from "../assets/CustomSvg/main_text_logo.svg";
...
<MainTextLogo />
...
const MainTextLogo = tw(MainLogo)`
fill-primary-YellowGreen
h-10 w-10
`;
styled-componets 또는 tailwind를 사용해 위와 같이 커스텀해서 사용 가능하다.
일정으로 인해 며칠간 동작하지않다 실행시키니 “Component auth has not been registered yet”라는 에러와 함께 firebase의 export const auth = getAuth(app); 구문에서 에러 발생
⭐️ SOLVE?
1. 공식문서를 확인하니 11/9에 10.6.0 으로 version update 되어서 firebase@latest 로 package 업데이트
2. import 구문에서 from에서 "@firebase/app"나 "@firebase/firestore"와 달리 auth의 경우만 "firebase/auth"을 발견 후 "@firebase/auth"으로 수정하니 오류 없이 진행됨
🤷♀️ WHY?
chatgpt에게 차이점을 물어보니 @firebase/auth
****의 경우 모듈식 SDK, firebase/auth
의 경우 기본(전통적인)SDK 방식이라고 하며, 내가 사용하던 getAuth의 경우 모듈식이었으므로@firebase/auth
가 맞는 from 출처이다. 확실하지는 않으나 버전이 업데이트 되면서 구분이 명확해져 생긴 오류로 보인다.
Modal Component 내에서 useState Hook을 사용하고자 호출하였으나 호출에러 발생
⭐️ SOLVE?
if (!isOpen) return null; 구문을 시작으로 Modal Component가 호출되고 있음을 발견
이후 호출 순서 변경
**기존 코드**
export default function Artwork_Modal({
isOpen,
closeModal,
artworkInfo,
currentUser,
}: ModalProps) {
if (!isOpen) return null;
const [isSaved, setIsSaved] = useState<boolean>(false);
...
}
**변경 코드**
export default function Artwork_Modal({
isOpen,
closeModal,
artworkInfo,
currentUser,
}: ModalProps) {
const [isSaved, setIsSaved] = useState<boolean>(false);
if (!isOpen) return null;
...
}
🤷♀️ WHY?
useState
훅이 함수 컴포넌트 내에서 조건에 따라 호출되고 있기 때문에 React Hooks의 호출 조건을 무시했기 때문에 발생한 오류이다. 호출 조건은 다음과 같다.
기본적인 규칙이지만 너무 익숙해서 잊고 진행함에서 발생한 오류라고 생각한다.
회원탈퇴를 실행할 경우 Firebase의 Authentication에서는 유저의 정보가 삭제되나, 별도 저장했던 Cloud Firestore내의 유저 정보 문서가 제대로 삭제되지 않는 상황 발생
🔎 TRY
A. 기존의 문서 삭제 방식인 deleteDoc이 아니라 필드를 삭제하는 방식을 이용
import { doc, updateDoc, deleteField } from "firebase/firestore";
const cityRef = doc(db, 'cities', 'BJ');
// Remove the 'capital' field from the document
await updateDoc(cityRef, {
capital: deleteField()
});
→ 필드의 경우 하위단계이고 이전 단계인 유저의 문서를 삭제해야하므로 Fail
A-1. A와 비슷한 맥락으로 updateDoc을 이용해 문서를 수정하듯 삭제하는 방식을 이용
→ 애초에 deleteDoc이 동작하지 않던 상황이므로 updateDoc도 제대로 동작하지않음
⭐️ SOLVE?
하위 문서가 삭제되고 난 후에야 상위 문서가 삭제됨을 발견.
**기존 코드**
await deleteDoc(doc(db, `userInfo/`, `${user.uid}`))
**변경 코드**
await deleteDoc(
doc(db, `userInfo/`, `${user.uid}/UserInfo/${user.email}`)
)
.then(() => {
deleteDoc(doc(db, `userInfo/`, `${user.uid}`));
console.log("success");
})
.catch((err) => console.error(err));
🤷♀️ WHY?
하위 문서인 userInfo/${user.uid}/UserInfo/${user.email}
의 문서를 선 삭제 후 .then 안에 성공했을 경우 상위문서인 유저의 전체 정보를 삭제하는 쪽으로 코드를 변경하였다.
공식문서 상에서 이유를 찾지는 못했지만, 스스로 생각해보자면 문서삭제 함수인 deleteDoc이 상위문서와 하위문서가 있어 동작을 실행하는데 있어 에러를 발생시킨것이 아닌가 생각된다.
그래도 updateDoc
을 실행해 firebase의 함수에 문제가 없음을 파악하고,deleteDoc
을 전체가 아닌 부분으로 실행해보며 삭제순서를 파악했기때문에 해결가능한 문제였다고 생각된다.
includes를 사용해 filter component 구성 중 filtering 된 array가 출력되지않음.
⭐️ SOLVE?
**기존 코드**
const filteredResults = response.filter(
res.map((i: any) => i.includes(tags))
);
**변경 코드**
const newArr = response.filter((item: any) =>
item.DP_ART_PART.includes(tags)
);
if (onFilterChange) {
onFilterChange(newArr.map((item: any) => item.DP_ART_PART));
}
🤷♀️ WHY?
includes 함수의 결과가 BOOLEAN이라는 기본적인 결과에 대해 잊고 코드를 구성한 것이 문제였다. 다른 filter가능 함수를 알아보다 결과값이 boolean이라는 것을 깨닫게 되었다.
그래서 공식문서를 통해 arr.includes(valueToFind[, fromIndex])
의 꼴을 다시한번 공부한 후, Filter 하위 Component상에 Props로 걸어두었던 onFilterChange를 활용해 Modal상에 결과를 보일 수 있도록 수정하였다.
🔥 회고
filtering을 할 수 있는 많은 함수 중 string과 연결짓기 가장 단순했던 includes 함수를 사용한 것 까지는 좋았으나 결과에 대한 학습이 부족한 탓에 시간낭비를 했던 문제라고 생각된다.
어렵지않은 문제였으나, 잊지말고 기억하자는 의미에서 trouble shooting에 포함한다.
++ 오픈 API가 http로 배포되어있으나 배포 단계에서 아예 error를 발생시킬꺼라 생각하지 못함. 하지만 error 발생 및 데이터 get 오류로 인해 기존에 api로 끌어다 쓰던 데이터를 json파일로 받아 firebase에 업로드 및 get해오는 방식으로 변경
작년 겨울에 혼자 진행하던 프로젝트를 배포 및 수정 단계 전에 중단하고, 재진행 및 마무리하며 오랜만에 적는 WIL 회고록
디자인 파일에 맞추어 모바일 앱이었지만 우선 웹 앱으로 모바일 사이즈에 맞게 진행하고, 지금까지 사용한 기술들을 익히고 한번 더 사용하자는 의미로 혼자 진행하게 되었는데, 혼자 진행하다보니 속도가 더뎌지고 문제 해결에 있어 시간이 조금 더 걸리게 되며 팀플의 소중함을 정말 크게 느끼게 됨
올해부터는 오로지 공부에만 몰두하며 진행한게 아니다보니 생각보다 꽤 오랜기간 진행되었던 점이 너무 아쉽게 느껴지는 부분.
기간을 오래 끌고 가다보니 개념적인 부분을 다시 같이 공부하면서 해야겠다는 생각이 듬.