0619
오사카 가기 전까지 D-4
호시노겐 보기 전까지 D-5

백준: 연구소
- 바이러스 있는 곳이랑 없는 곳 따로 따로 넣은 다음에
- 바이러스 없는 곳에다가 벽을 3개까지 세울 수 있으니
이 조합들을 구해서 0이 가장 많은 경우를 출력
그냥 bfs랑 combination 혼합 문제였다.
OSSCA 리팩토링
오후에 빌드 에러나서 오랜만에 코드를 다시 읽는데,
AppHeaderBottombar 컴포넌트가 현재 developers 페이지에서만 사용된다는 이유로
page 경로를 developers만 받아놓게 했는데 왜 이렇게 했었지.. ㅎㅎ
그래서 아래와 같이 route 경로 관련 프롭스도 추가해줬다.
'use client';
import { usePathname } from 'next/navigation';
interface AppHeaderBottomBarProps {
isItems?: { href: string }[];
isOpen?: boolean;
highlightRoutes?: string[];
}
export default function AppHeaderBottomBar({
isItems,
isOpen,
highlightRoutes,
}: AppHeaderBottomBarProps) {
const pathname = usePathname();
const shouldShowBottomBar =
isOpen || // 드롭다운이 열려 있을 때
highlightRoutes?.some((route) => pathname.startsWith(route)) || // 현재 경로가 하이라이트 경로와 같을 때
isItems?.some((item) => item.href === pathname); // 드롭다운 아이템 경로와 같을 때
그리고 현재 조직에서 레포를 사용 중이라 버셀 우회 배포중인데,
갑자기 github action log에 이런 오류가 났다.
./public/open_graph.png
Error: Could not load the "sharp" module using the linux-x64 runtime
보니까 GitHub Actions는 Linux 환경이고,
Next.js는 이미지 최적화를 위해 sharp 모듈을 사용하는데,
로컬에서 설치된 sharp의 바이너리가 Linux 환경과 호환되지 않아서 발생한 문제인 것 같았다.
그래서 Linux 환경에 맞는 sharp 바이너리를 아래의 명령어로 설치해서 해결했다.npm install --os=linux --cpu=x64 sharp
그리고 어디서 에러가 터진지 모르겠는데,
그전에 에러가 났던 로그가 쌓이고 쌓여서 그런지
오류를 수정해도 재배포할 때 수동으로 캐시를 초기화해주지 않는 이상
자동으로 push해서 배포한 사항에는 그 전 캐시가 남아있는 채로 빌드가 되는 것 같았다.
그래서 환경변수에다 VERCEL_FORCE_NO_BUILD_CACHE=1
을 설정해서
매번 캐시를 초기화해서 빌드하게 설정했다.
아무래도 우회 방법을 사용하고 있다보니
vercel이 자동으로 제공해주는 기능들을 편하게 사용하지 못하는 것 같아 아쉽다
RealWorld
포스팅은 내일 할 예정이고,
SWR이랑 tanstack query에 대해서 간단하게만 훑는겸? 알아봤다.
tanstack은 관련된 모든 쿼리가 자동으로 업데이트되기에
현재 로그인 한 사용자 정보는 지금처럼 swr로 갖고와도 충분할 것 같고
팔로우 상태나 좋아요에 사용하면 좋을 것 같다고 생각했다.
한꺼번에 swr을 다 tanstack으로 바꾸는 것 보단, 먼저 일부만 tanstack으로 바꿔보는게 좋을 것 같다.