18. Invalid Date 버그처리

 

먼저 메세지를 입력했을 때, Invalid Date가 나오는 버그를 고쳐보겠다.

이게 Invalid Date가 표시되는 이유는 메세지를 넣어줄 때,

1. DB에 인서트 할 객체를 만들어 DB에 추가를 해주고

2. Optimistic Update를 해주는데, 

이 1과 2사이에서 넣어주는 객체가 각각 다르다. 

// components/ChatInput.tsx
const newMessage = {
      id: uuidv4(),
      text,
      // user_id: user?.id,
      is_edit: false,
      // created_at: new Date().toISOString(),
    };

    const { data, error, status } = await supabase
      .from("messages")
      .insert(newMessage);

    // optimistic update에 사용될 newMessage객체
    const newMessageForOpt = {
      ...newMessage,
      users: {
        id: user?.id,
        avatar_url: user?.user_metadata.avatar_url,
        created_at: new Date().toISOString(),
        display_name: user?.user_metadata.user_name,
      },
      created_at: new Date().toISOString(),
    };

    // console.log("newMessage.createdAt :  : ", newMessage.created);

    addMessage(newMessageForOpt as IMessage); // 불러온 addMessage 펑션 사용하기
    setOptimisticIDs(newMessageForOpt.id);

이게 이렇게 다른 이유는, 먼저 DB에 인서트 할때는 메세지 테이블에 인서트 하기 때문에, users객체를 빼고 인서트 해줘야 한다.

그럼 왜 user_id와 created_at은 주석처리를 해놨냐고 한다면, 이전에 message 테이블의 RLS Policy를 만들 때,

이렇게 만들어줬었다.

그래서 user_id와 created_at은 policy로 자동으로 들어가게 되는데, 또 Insert를 해주려고 하면 충돌이 일어난다. 그래서 빼준거다. 물론 둘다 policy에서 빼고, 직접 만들어 넣어주면 충돌은 안난다. 하지만 일단 user_id는 이렇게 넣어주는게 확실히 더 안전하고, 틀릴 가능성이 적어지고, created_at은 음,,, 유저의 기기마다 타임존이 다르다면 이렇게 서버에서 넣어주는 편이 더 정확할 것이다. 아무래도 디비에 저장되는 정보는 정확해야 하니깐. 그래서 디비에 이렇게 저장을 해준다. 

 

이제 메세지늘 Optimistic Update해줘야 하는데, newMessage 객체에 있는 정보들 만으로는 Message에 표시해주기에는 빠진 정보가 너무 많다. 그래서 추가로 유저정보와 created_at을 넣어주는 것이다. 그런데 저번에 넣을 때, created_at을 빠뜨렸다. 

그래서 이번에 새로 넣어주니

짠! 잘나온다.