[MZO-48] toast 공용 모듈 및 UI 구현#34
Conversation
| opacity: opacity, | ||
| transition: 'all 0.35s ease-in-out', | ||
| transform: `translateY(${opacity === 0 ? '-10px' : '0'})`, | ||
| }} |
There was a problem hiding this comment.
컴포넌트 변수를 style에 적용해야 해서 따로 css를 빼지 않고 바로 작성하였습니다.
RookieAND
left a comment
There was a problem hiding this comment.
고생하셨습니다 하랭.
작업과 관련하여 몇 가지 의견을 작성했으니 참고 부탁드립니다.
궁금한 점이 있다면 언제든 코멘트로 부탁드려요!
|
|
||
| export const useToastAtom = atom( | ||
| (get) => get(toasterAtom), | ||
| (get, set, type: 'success' | 'error' | 'info') => |
There was a problem hiding this comment.
여기서도 아까 정의했던 Type (ToastStateType) 을 사용하면 더 좋을 것 같습니다.
There was a problem hiding this comment.
엇 이거 ToastType으로 수정해놨었는데 왜 이렇게 보이는거죠..?!
| @@ -0,0 +1,8 @@ | |||
| export type Type = 'success' | 'info' | 'error'; | |||
There was a problem hiding this comment.
단순히 Type이라는 명칭보다는 Toast의 상태를 나타내는 것이니 ToastStateType 으로 표기하는 게 혼선이 덜할 것 같아요.
| <div | ||
| style={{ | ||
| opacity: opacity, | ||
| transition: 'all 0.35s ease-in-out', |
There was a problem hiding this comment.
animation time 의 경우에는 커스텀하지 않아도 괜찮으려나요? 불필요하다면 상수로 관리하게 좋겠네요.
There was a problem hiding this comment.
저희가 animation이 어디까지 들어갈지 아직 미정이고 각 animation마다 써야하는게 좀 달라질수도 있지 않을까요?? 상수로 관리해야할지 의문이 들어서요!
There was a problem hiding this comment.
하기야 그렇겠네요. 지금은 그냥 넣어도 좋아 보여요
| return ( | ||
| <AppPortal.Provider portalName="toast-portal"> | ||
| <div className="fixed space-y-2 -translate-x-1/2 left-1/2 top-4"> | ||
| {toasts.map((toast) => { |
There was a problem hiding this comment.
return 키워드를 사용하지 않고 곧바로 컴포넌트를 반환하면 더 코드가 간결해질 것 같아요.
{toasts.map((toast) => (
<Toast key={toast.id} {...toast} />;
))}| import Toast from '@/components/toast/Toast'; | ||
| import { useToastAtom } from '@/stores/toast'; | ||
|
|
||
| const Toaster = () => { |
There was a problem hiding this comment.
Toaster 컴포넌트의 역할은 Toast 컴포넌트가 렌더링되는 포탈을 제공하는 Provider의 역할이기 때문에
개인적으로는 ToastProvider 로 네이밍을 적는 게 좋아 보이는데 어떻게 생각하시나요?
There was a problem hiding this comment.
다른 라이브러리에서 Toaster라고 해서 참고한건데 ToastProvider도 괜찮아보이네요!
There was a problem hiding this comment.
오 그래요? 다른 라이브러리에서는 Toaster라고 하는 군요.. 하랭이 조율하셔도 괜찮아 보입니다.
There was a problem hiding this comment.
루키가 제안주신 네이밍이 더 좋은거 같아서 수정했습니닷 ㅎㅎ
| const Toaster = () => { | ||
| const toasts = useAtomValue(useToastAtom); | ||
| return ( | ||
| <AppPortal.Provider portalName="toast-portal"> |
There was a problem hiding this comment.
[NIT]
Provider는 Portal을 생성하기 위한 HTMLDivElement 를 제공하는 역할이긴 한데,
약간 고민이 되는게 해당 DOM에 className을 넘겨줄 수 있게 할지가 좀 고민이네요.
하랭의 경우 Provider 하단에 바로 toast 를 띄우는 Div를 만들었는데, 이럴 필요 없이 Portal의 parent가 되는 DOM에 classNames를 인계할 수 있게 하는 건 조금 그러려나요? 하랭의 의견이 궁금하네요.
There was a problem hiding this comment.
아 요부분 제가 Wrapper로 하려던걸 provider로 했네요.. 저도 루키 의견에 동의합니다!
| @@ -0,0 +1,29 @@ | |||
| import { atom } from 'jotai'; | |||
| import { v4 as uid } from 'uuid'; | |||
There was a problem hiding this comment.
toast 별로 uuid를 부여해서 고유한 key를 부여하는 방식이군요. 정말 좋은 아이디어라고 생각합니다.
다만 저는 아래와 같은 방식도 나쁘지 않다고 생각했습니다.
- toasterAtom 에서 현재 "몇 개의" toast를 생성했는지를 체크하는 속성인
sequence를 생성한다. - toast가 한 개 추가될 때마다 sequence 값을 1 증가시키고, 해당 toast 객체의 uuid 처럼 부여한다.
- toast가 삭제되더라도 sequence는 그대로 유지된다. 오직 "새로운 toast가 생성될 때만" 1 증가한다.
이렇게 되면 uuid를 사용하지 않더라도 고유함이 유지될 것이라 생각했습니다.
물론 고유한 값이라는 명목 하에는 uuid가 가장 절대적이긴 하지만 toast 에서까지 써야 하나? 라는 생각이 들어서요.
위와 같은 이유로 저는 Atom 에서 자체적으로 sequence 를 가지는 건 어떨까 싶네요. 하랭의 의견을 들려주세요.
There was a problem hiding this comment.
저도 이부분을 고민했었는데.. react-hot-toast에서 루키가 말한 방식으로 하고 있더라구요. 그런데 또 한편으로는 uuid를 안쓸 이유도 없다고 생각해서 사용했습니다.
toast에서 사용하는 id는 일시적인 값이라 루키가 그렇게 생각했을수도 있을것 같아요. 그러면 요건 루키가 말한 방식으로 수정해볼게요!
There was a problem hiding this comment.
맞아요 사실 일시적으로 잠깐 쓰이다가 말 값이라 굳이 UUID로 하지 않아도 된다는 게 제 의견이긴 했습니다.
Jira Issue 번호
#48
작업 내용
To Reviewers
Checklist