분류 전체보기 324

[Dayjs] 왜 api 응답은 잘 오는데 화면에서 시각을 다르게 보여주지? (utc, local)

상황 🥺 버그 제보를 받았다. 분명 서버에서는 날짜 데이터를 잘 보내주고 있는데, 화면에는 다르게 표시하고 있었다. A api와 B api에서 날짜를 받아온 후에 dayjs 라이브러리를 활용해서 화면에 표시하고 있었는데, 하나는 제대로 표시되고 하나는 제대로 나오지 않았다. 원인 🌟 자세히 보니 api 응답이 조금 달랐다. 1번 2번 1번은 T, Z 가 붙어있다. T는 날짜 뒤 시간이 오는 걸 표시해주는 것이고, Z는 UTC 기준시라는 뜻이다. UTC 기준시가 아니라 다른 시간대의 시간일 경우에는 +09:00 이런 식으로 UTC 기준시로부터 얼마나 떨어져있는지 나타낸다. 아무튼 1번은 UTC 기준시라는 뜻이다!! 2번은 T, Z가 없다. 나는 dayjs(시간).('DD MMM YYYY HH:mm') 이런..

23년 2월에 읽은 개발 아티클 🔖

소프트웨어 설계 20년 해보고 깨달은 '좋은 설계'의 조건 '모든 상황에서 모든 문제를 해결해주는 모범답안 같은 완벽한 해법은 없으며, 설계는 정교한 의사소통을 돕는 도구로 활용될 때만 의미가 있다고 믿습니다.' - 본문 중- '소통 없이는 완벽한 설계 문서란 없다.', '당장 개발을 위한 소통에 쓰이지 않는 문서나 그림 형태로 설계하는 일은 지양해야 헙나다.' - 본문 중- 완벽하고 철저한 설계는 있을 수 없고, 코딩 직전에 어떻게 해야 할지 정도만 설계하면 된다. 개발 전에 모든 것을 꼼꼼하게 설계하지 말고, 개발-리팩토링하면서 지속적으로 설계도 해나가야 한다!! (약간 애자일 개발방법과도 연결되는 것 같다 !) [Korean FE Article] 내가 작성한 Jest 테스트는 왜 이렇게 느릴까? 읽..

책꽃이 📔 2023.02.06

23년 1월에 읽은 개발 아티클 🔖

글을 읽으면서 정리하고 내 의견을 쓰면 더 집중도 잘 되고, 나중에 필요한 부분 찾기도 쉬워서 정리하고 있다. :) 파란색 글씨가 내 생각이다 ~ 2022.log (velopert) https://velog.io/@velopert/2022.log 2022.log 2022년, 정말 큰 변화가 있던 해였다. 5년 넘게 다닌 나의 첫 직장 라프텔을 퇴사했고, 창업을 결정했다. 왜 퇴사를 했는지.. 창업 라이프는 어땠는지 공유를 해보겠다. velog.io 벨로그를 만드신 벨로퍼트님의 2022년 회고 글이다. 퇴사를 하고 창업을 하신 이야기가 핵심이다. 개발자들을 채용하고, 사무실을 계약하고, 투자 받는 등등. 대표로서 살아가는 이야기가 있다. 나도 창업을 하는 게 재밌을 것 같다는 생각이 있는데(물론 힘들긴 하..

책꽃이 📔 2023.01.05

TypeScript 챌린지로 공부해야지!

오늘 TS의 as를 사용했다가 사용하지 않는 게 좋다는 코드 리뷰를 받았다..!! as를 종종 사용했는데.. 전혀 사용하지 않으려고 하니 밑줄이 자꾸 자꾸 생겼다. TS를 공부해야겠다는 생각이 들던 중에 전에 다른 분의 회고 글에서 봤던 https://github.com/type-challenges/type-challenges 가 떠올렸다. 도전~ 위 깃허브에 들어가면 아래와 같이 문제들이 나온다. 문제 태그를 클릭하면 문제 설명이 나온다. Take the Challenge를 클릭하면 문제를 바로 풀어볼 수 있게 playground로 이동한다. your code here 부분의 코드를 수정해서 아래 test case 코드의 에러를 없애면 된다! 다른 사람들의 풀이를 볼 수 있고, 본인의 풀이도 공유할 수..

프론트엔드💛 2023.01.03

신입 프론트엔드 개발자의 2022년 돌아보기 👍🥹🌈

2022년 안에 2022년 회고를 쓰려고 했는데, 어쩌다 보니 1월 2일이 됐다.. 그래도 오늘이 가장 2022년에 가까운 날이니까... 지금이라도 써본다 ㅎㅎ 회사 생활 👩‍💻 좋았던 점 👍 동료들과 어느 정도 레포가 쌓였고, 커뮤니케이션도 (전보다) 원활하게 하고 있다. 처음에는 코드 리뷰나 질문도 조심스러웠는데, 이제는 편하게 할 수 있다. 레크레이션, 마니또 등도 하면서 재밌게 지내고 있다~ 2주 스프린트 단위로 일하는 게 익숙해지고 있다. 처음 해보는 것도 아주 두렵지는 않아졌다. 입사 초기에는 처음 해보는 일을 하면 실수하거나 잘못할까봐, 기한을 못 맞출까봐, 남들이 내 코드를 보고 뭐라고 할까봐 걱정을 많이 했다. 그런데 동료들과 함께 하고, 경험이 쌓이면서 그런 상황도 괜찮게 받아들일 수 ..

React Compound 패턴 끄적끄적...

올해 첫 업무 분담을 했는데 일부 컴포넌트에 컴파운드 패턴 적용하는 걸 하기로 했다! 리액트도 두 달 정도 만에 사용하고, 컴파운드 패턴을 적용해본 적은 없어서 리액트 컴파운드 패턴을 알아봤다. 그리고 끄적끄적.. 메모를 남긴다. '요구되는 기능을 수행하기 위해 두 개 이상의 컴포넌트가 협력하는 형태' (https://so-so.dev/react/design-system-decision-record/ 중 ) 만약 같은 기능을 하나의 컴포넌트로 해결한다면? 그 한 컴포넌트에 prop을 모두 넘겨야 하고, 복잡해질 수 있다. 이 패턴을 사용하면? 실제 prop이 사용되는 컴포넌트에 전달해서 동작을 예측하기 쉽고, 코드도 이해하기 쉽다. select 안에 option을 사용하는 예시를 생각하면 된다. UI 프..

프론트엔드💛 2023.01.02

다른 개발자 분들의 2022 회고 글을 읽다.

이제 2022년이 일주일도 채 남지 않았다. 회고 글들이 많이 올라오고 있다~~ 다른 분들의 회고 글을 읽으면서 다양한 분들이 계셔서 재미있고, 공감도 되고, 배우는 점도 많다 ㅎㅎ 읽은 2022 개발자 회고글 중에 인상 깊은 것들을 모았다. 신입 백엔드 개발자 2022년 회고 (redjen 님) https://velog.io/@redjen/%EC%8B%A0%EC%9E%85-%EB%B0%B1%EC%97%94%EB%93%9C-%EA%B0%9C%EB%B0%9C%EC%9E%90-2022%EB%85%84-%ED%9A%8C%EA%B3%A0 신입 백엔드 개발자 2022년 회고 나는 한 해 좋은 동료 개발자, 좋은 선후배, 좋은 친구, 좋은 가족, 좋은 인간이었는가? velog.io 10월 말부터 신입 백엔드 개발자..

책꽃이 📔 2022.12.28

click, drag 구분하기(with vue) 😯😊

며칠 전, 마우스 클릭과 드래그를 구분해야 했다. 리스트가 있는데, 클릭했을 때는 상세 정보로 이동하고 드래그해서 텍스트를 복사하고 싶은 상황이었다. 기존에는 click event가 있으면 상세 페이지로 이동하게 해서, 드래그를 하고 싶어서 상세 페이지로 이동했다. 마우스 이벤트를 찾아보니 click 이벤트만 있는 게 아니라 다른 것도 있었다. 그것들을 활용하니 클릭과 드래그를 구분할 수 있었다. (아래 링크들은 MDN 사이트) mousedown event : 요소 안에서 포인터가 눌렸을(press) 때 발생 mousemove event : 요소 안에서 포인터가 움직일 때 발생 mouseup event : 요소 안에서 포인터가 release 될 때 발생 click event와 차이점 : 클릭 이벤트는 f..

프론트엔드💛 2022.12.16

우리 팀의 코드

오늘 아~주 잠깐 짜증나는 일이 있었다. 버그가 생겨서 퇴근을 약간 늦게 한 것이다. 백엔드 api가 수정되었는데, 프론트엔드에는 반영이 안돼서 생긴 버그였다.. "이거 수정 된거죠? 이 api 언제 수정된 거죠??? 왜 수정된 거예요?ㅠㅠ" 옆자리 백엔드 분께 묻기도 했다. 말투는 친절(?)했지만, 그 원인이 된 사람을 탓하려는 마음이 있었다. 'api가 수정됐으면 공유해주지....!' (* 하지만 짜증은 아주 아주 아주 잠깐이었다. 1분 미만..!! ) 버그를 해결하면서 생각했다. '원인이 누구인지 알면 뭐하나?? 있던 버그가 없어지는 것도 아니고.. 우리 팀의 코드니까 빨리 버그를 없애는 게 중요하지.. ' 생각해보니 오전에 있었던 일도 떠올랐다. 다른 분의 코드 리뷰를 하는데 a, k 와 같이 약..

"그때 가서 고치면 돼요~"

며칠 전에 이미 있는 컴포넌트를 다른 식으로 바꾸는 작업을 해야 했다. 그때 맡은 일을 완벽하게 하려고 하다 보니, 부담이 되고 잘 일이 안됐다.ㅠ 어떻게 하는 게 좋은 방법일지 여러 동료와 이야기를 나눴지만 최고의 방법이 무엇일지 계속 고민이 됐다. 그때 한 분이 말씀해주셨다. "너무 부담 가지지 말아요~ 어차피 또 수정할 건데요~ 문제 있거나 더 좋은 걸 찾으면 그때 가서 고치면 돼요~" 그 말을 들으니 마음이 편해졌다 ! 코드는 작성하는 순간에 리팩토링의 대상이 된다는 말도 있으니까..! 그 순간 최선의 코드를 작성하고, 또 다음에 수정하면 된다 :)

728x90