[TIL]오늘의 개발일지

 

빵댕이 덩실덩실 

오늘 드뎌 최종프로젝트 리팩토링을 하고 싶었던 근본적인 기능!!!!

게시글과 북마크를 supabase로 리팩토링해서 북마크 기능, 게시글이 삭제됐을때 북마크에서도 자동으로 사라지는 기능을 만들었다

 

 

아래는 bookmark 테이블 구조 

상황에 따라서 어떤 형식의 데이터 구조가 좋은지 박수 짝짝 치면서 느꼈던 과정 (SQL공부하고 시땅)

 

요게 북마크 구현한 부분 >_< 

1. 유저가 북마크 클릭시 저장이 됌 (해당하는 postId가 없는 경우만!)

2. 또 클릭했는데, 만약 db에 같은 postId가 있으면 걔를 삭제(한마디로 북마크 해제)

3. 게시글이 삭제되면 postId를 기준으로 다 날려벌여~~(그럼 북마크에 해당 포스트 데이터들이 다 사라짐)

  const addBookMark = async (itemId) => {
  	// uuid를 안에다 선언한 이유 : uuid가 마운트됐을때 한번만 실행되고 그 후에 안바뀌면 중복됭께
    const uuid = uuidv4();
    const bookMark = {
      bookmarkid: uuid,
      postid: itemId,
      userid: authService.currentUser.uid,
    };
    // 만약, 컬럼명에 userid가 뭐인 애중에 postid가 이미 있으면?
    // 걔는 삭제해라
    const { data, error: searchUserBookMarkError } = await supabase
      .from("bookmark")
      .select("*")
      .eq("userid", authService.currentUser.uid)
      .eq("postid", itemId);


    if (data?.length !== 0) {
      console.log("북마크가 있었고 삭제가 될거임");
      const { error } = await supabase
        .from("bookmark")
        .delete()
        .eq("postid", itemId);
      return;
    }

    if (data == [] || data.length == 0) {
      console.log("데이터가 없었고 새로 저장될거임");
      const { error } = await supabase
        .from("bookmark")
        .insert(bookMark);
      if (error) {
        console.log(error);
      }
      return;
    }
  };

 

캬캬 

해보고 싶었던 부분들 하나둘 해나가는 묘미가 너무 재미땅

 

맘마 먹고 한턴 쉬다가 부족한 부분들을 쫘악 보충하는 시간을 가져야징

내 이력서 너무 보완할 부분이 많아잉 

 

 

---

+) 오후 기록

 

내가 확실하게 알지 못하고 있었던 게 "전역 상태관리"의 근본적인 목적이었다.

 

전역 상태관리는 한 페이지에서는 당연히 각 컴포넌트들에서 전역으로 관리되고잇는 넘들이 다같이 바뀌지만,

다른 '페이지'의 경우는 엄연하게 다른 provider를 제공하고 있다는 것!!!!!

 

'다른 페이지'에서도 실시간으로 (잘못 생간한거) 변경이 될거라고 잠시 착각햇던거뉘!!!!!!!!!!!

 

사실 다른 페이지에서는 아예 다른 RecoilRoot가 그려진 것이었고 (생각해보면 리덕스 쓸때도 새로고침하면 값이 초기화되니 그렇게 안되는 방법을 튜터님이 만들어보라고 하셨어쨔나!!!!! 

 

보면 '한페이지' 안에서 컴포넌트들을 타고타고 내려가는 경우 (B컴포넌트 안에 A컴포넌트를 넣고 여기선 실시간으로 보이는지 해봤음)

// AComponent.tsx
import { useCountState } from "@/lib/recoil/atoms";
import React from "react";

const AComponent = () => {
  const { count, increment, decrement } = useCountState();

  return (
    <div>
      <h4>나는 A컴포넌트야</h4>
      A컴포넌트의 count야 : {count}
    </div>
  );
};

export default AComponent;

 

쨔잔 요렇게 잘 나오는 걸 볼수 이찌

 

 

 

결론 : 전역state관리를 하는 것은 한 페이지 안에서 컴포넌트 드릴링(사실 SPA을 쓰면서 리액트가 나왔고, 리액트의 특성상 컴포넌트 드릴링이 있어서 리덕스가 나왔던거자나!!!) 을 막기 위해 한다는 게 "목적"이고, 오늘 내가 하고싶었던 목적은 

"어느 페이지에서나 로그인한 User의 정보를 유지시키는 것"이므로 쿠키나 세션에 저장을 하는 것이 맞다는 생각이 들었다

어떤 식으로 저장을 해야할지 진짜 고민을 많이 했는데 내일 ㅈㅇ님이 알려주신 next-auth도 한번 써봐야지

(지금은 recoil-persist로 해놨는데 이거 자체가 세션스토리지에 저장하는거라, 로그인 유저 정보는 보안상 세션스토리지나 로컬스토리지에 저장하는것이 바람직하지 않다고 해서 내일 더 좋은 방법을 선택해서 리팩토링해야겠다)