본문 바로가기

모두 보기

 (96)
react-spring으로 구현해본 애니메이션 정리 2021. 6. 29. 00:26 리액트에서 웹 UI 애니메이션을 구현하는데 유명한 라이브러리인 react-spring으로 구현해본 기능들을 정리한다. 1. Page Transition 참고 예시 SIMPLE TRANSITION peaceful-almeida-t7puq - CodeSandbox peaceful-almeida-t7puq by yujeongJeon using lodash, react, react-dom, react-router-dom, react-scripts, react-spring codesandbox.io history.location이 바뀔때마다 슬라이딩되어 넘어가는 애니메이션을 useTransition을 사용하여 구현하였다. 예시와 다른 점은 1 -> 2로 갈 때는 오른쪽으로, 2 -> 1로 backward될 때에는..
getEventListeners로 등록된 이벤트리스너 확인하기 2021. 6. 14. 18:23 웹 개발에서 이벤트 리스너가 잘 해제되고 있는지 확인해야 하는 경우가 있다. 그럴 때 getEventListener를 사용하여 확인할 수 있다. getEventListeners(window) getEventListeners(document) 결과 { error: Array(1), unhandledrejection: Array(1), pagehide: Array(1), popstate: Array(1) } 결과에서 볼 수 있듯이 [Event 종류]: Array으로 결과를 볼 수 있다. 예를 들어, React에서 visibilitychange 이벤트 리스너를 등록 후 지우지 않았다면 const Comp = ({children}) => { const onVisibilityChange = () => { /** ..
React 18에서 알아야 할 세가지(What You Need to Know About React 18) 2021. 6. 12. 23:46 Sheeraz Shaikh의 What You Need to Know About React 18을 번역하였습니다. > Going to see the original article { // Transition: Show the results setSearchQuery(input); }); React 18 Working Group Facebook에서 잘 알려진 라이브러리들의 author, maintainer들을 위한 working group을 생성했습니다. 그들은 이 특징들에 대해 사전 피드백을 주기 위해 논의하고 있습니다. 해당 논의들은 관심있는 누구든지 볼 수 있도록 열려 있습니다. 제가 팔로잉하는 링크를 공유합니다. https://github.com/reactwg/react-18/discussions/4..
제 5장. 예 2021. 6. 12. 20:35 제 4장. 수식과 명제보다 제 5장을 먼저 읽은 관계로 5장을 먼저 포스팅한다. 기본 1. 전형적인 예를 사용한다. 전형적인 예를 먼저 사용하고, 극단적인 예시를 사용한다. 글쓴이 사견 : 예시 코드를 작성할 때 일반적인 기능에 대한 구현을 예로 들면 더 효과적이겠다. 2. 들어맞는 예 -> 들어맞지 않는 예를 기술한다. 들어맞는 예와 들어맞지 않는 예는 비슷하지만 다른 성질을 갖는 예를 들면 좋다. 두 예가 아예 동떨어지면 본 개념에 대한 이해가 흐려질 수 있다. 3. 일반적인 예를 사용한다. 특수한 조건이 붙는 예를 활용하지 않는다. 4. 독자의 지식을 고려한 예를 사용한다. 글을 읽을 독자들이 알고 있는 배경 지식을 고려한다. 독자들에게 알기 쉬운 것, 익숙한 것, 알고 있는 것으로부터 예를 만든다..
제 3장. 순서와 계층 2021. 5. 31. 11:45 1. 순서는 글을 배열하는 것 독자가 글을 읽기 쉬운 순서로 나열한다. 작업 순서로 글을 나열할 때 번호를 추가하면 순서가 더 명확해진다. 번호 뿐만 아니라 글의 형식또한 통일한다. 아는 것에서 모르는 것으로 독자가 이미 알고 있는 것을 간결하게 쓴다. 알고 있는 것과 모르는 것이 섞인 내용을 쓴다. 모르는 것에 대해 자세히 쓴다. 2번의 알고 있는 것과 모르는 것이 섞인 내용을 쓸 때에는 예시를 제시하거나, 질문은 던져본다. 구체에서 추상으로 구체적인(특수한) 예시를 먼저 제시하고, 추상적인(일반적인) 경우를 설명한다. 또한 구체적으로 설명한 문단과 추상적인 문단은 병렬적인 형식을 취한다. (병렬법 참고) 특수 로그인 화면의 테스트 코드를 작성할 때 가장 먼저 화면의 입력란이 렌더링되었는지 확인하는 코..
cypress를 써보자! (2) 2021. 5. 23. 16:32 cypress를 써보자! (3) 목차 1. Webpack resolve.alias 2. Settig up CI 3. One intercept, multiple responses 1. Webpack resolve.alias 1주차에서 jsconfig.json에 alias 설정을 추가했다. 그러나 cypress:open 시 절대 경로를 못찾는 에러가 발생했다. cypress 웹팩 설정에서 resolve.alias를 해주지 않아 발생한 이슈였다. 따라서 cypress/plugins/index.js에 webpack resolve.alias 또한 추가했다. // ./cypress/plugins/index.js // ... 중략 ... module.exports = (on, ..
제 1장. 독자 ~ 제 2장. 기본 2021. 5. 22. 00:08 유키 히로시의 「이공계 x의 글쓰기책」 을 읽으면서 글쓴이가 기억하고 싶은 문장과 핵심 내용을 정리하였습니다. 매우 주관적인 정리입니다. 제 1장. 독자 글을 쓸 때, 독자의 입장을 생각하면서 글을 써야 한다. 독자의 입장을 생각하는 방법 1. 독자의 지식 독자는 글을 읽으면서 상황에 따라 변한다. 따라서 글의 순서를 의식하면서 글을 써야한다. 여기까지 읽은 독자는 무엇을 알고 있는가 2. 독자의 의욕 독자가 글에 흥미를 느끼고 글을 계속 읽을 수 있는 의욕을 향상하기 위해 글의 논조에 변화를 준다. 추상적인 이야기 ▶ 구체적인 예를 든다 구체적인 이야기 ▶ 요약 정리를 한다 글로 된 설명의 지속 ▶ 그림, 그래프, 표를 삽입한다. 의욕은 아하! 하고 무릎을 탁 치는 발견이 있을 때 매우 향상된다. 3...
cypress를 써보자! (1) 2021. 5. 16. 00:23 cypress를 써보자! (2) > cypress를 써보자! (3) > 프로젝트를 쭉 담당하면서 단위테스트만으로는 부족하다고 생각될 때가 왔다. 저번주에 운영환경을 체크하는 로직을 라우터 페이지에 넣어버리는 실수로 인해 리얼환경에서 잘 동작하는지 반드시 확인해야 할 필요가 생겼다. 또한 QA 과정(혹은 단위테스트)에서 발견이 어려웠던 이슈들이 속속들이 나오고 있었다. 따라서 새 서비스 개발에 착수하기 전에 작년부터 해보고 싶었던 cypress를 도입하여 통합 테스트를 작성하고자 했다. 이번주에는 cypress 첫 설치와 실행 그리고 간단한 테스트 코드 작성으로 사용하는 것까지 공부하면서 기록했다. 1. cypress 설치 글쓴이는 외부와 차단된 private 망에서 개발을 하고 있다. 따라서 외부 깃헙에..
오늘 배포하다가 식겁한 ssul 2021. 5. 6. 12:41 저번주에 A서비스를 출시했는데 진입하는 고객들이 단한분도 없었다.(cs도 없어서 안쓰시는건가 했다ㅠ) 일주일째되던 오늘....라우터 페이지에서 운영환경에서는 작동하지않게 해둔 코드를 발견했다.. 원래 B서비스와 출시일이 같아서 하나의 epic브랜치에서 checkout하여 병렬적으로 작업하고 있었는데, A서비스 출시일자가 미뤄지면서 방어로직을 추가했다는게 기억났다ㅠㅠ 알파,베타 환경에서는 당연히 작동하기때문에 QA도 통과되는 바람에 Real환경 이슈를 놓친것이다🥶 서비스 특성상, real환경에서는 QA를 못하는 제약사항이 이렇게 크리티컬한 버그를 낳다니ㅠㅠ 가급적 운영환경을 점검하는 로직은 넣지말아야겠다...
TDD로 서비스 개발하기 2021. 4. 18. 14:19 지금까지 내가 어떤 서비스 개발에 참여하고, 기획서와 디자인 시안을 받으면 가장 먼저했던 것이 있다. 바로 기획서와 전체 스펙을 보고 FE에서 개발해야 할 기능 리스트를 정리하고 각 기능에 대해 머릿속이나 간단한 코드로 설계를 해보는 것이다. 테스트 코드는 개발이 완료되면 리팩터링을 시작하기 전에 작성하고는 했다. 그러나 항상 결정과 피드백* 사이의 차이점을 인식하지 못하는 경우가 발생하는데 이는 주로 QA에서 기획서 스펙과 다른 사항을 피드백받고 나서야 해결하고는 했다. 결정과 피드백* '결정'은 개발자가 목표를 구현하기 위해 설계하는 과정을 말하고, '피드백'은 기능이 정상적으로 동작하는지에 대한 성공/실패를 말한다. TDD는 개발자가 기능을 설계하는 과정에서 목표를 잃어버리지 않게 도움을 준다. 그..
[MobX, mobx-react-lite] Observable 다양하게 활용하기 2021. 4. 13. 19:23 현재 다니고 있는 회사에서는 MobX와 mobx-react-lite*을 활용하여 상태를 관리하고 있다. 크게 아래 세 과정에 의해 스토어를 생성하고 사용한다. 과정 자세히보기 1. 'create~Store' 네이밍 룰로 옵저버블로 만들고자 하는 객체를 생성한다. const createAccountStore = () => { return { id: '', password: '', setId(value) { this.id = value } get isValidId() { return this.id.length > 5 } } } export {createAccountStore} 2. mobx-react-lite의 useLocalStore*로 만든 옵저버블을 컨텍스트에 등록한다. const rootContext..
/** IGNORE*/ 주석 2021. 4. 9. 12:20 팀원분께서 axios 코드를 뜯어보시다가 /** IGNORE*/ 주석을 소개해주셨다. 예를 들어 어떤 비동기 함수를 이렇게 작성하면 const asyncFunc = async () => { try { const res = await axios.get('/something') return res } catch { /** IGNORE*/ } } asyncFunc에서 에러가 발생해도 catch문에서는 어떠한 처리를 하지 않고 리턴할 것이다. 즉 /** IGNORE*/ 주석의 의미는 ‘내(여기서는 asyncFunc입장)가 낸 에러는 스스로 잡을게. 대신 다른 처리를 하진 않을게’ 라는 약속인 것이다. const asyncFunc = async ()=>{ try{ const res = await new Promi..

티스토리툴바