최근 팀 내에서 e2e 테스트를 도입하기 위해 초기 컨벤션을 적용하는 작업을 진행하였다. 대부분 테스트 도구에서 제시하는 문법이나 구조를 따르지만 이 외에 팀원들과 논의하여 적용한 부분들도 있어서 소개해보고자 한다. Cypress vs Playwright 처음에는 기존에 cypress로 작성된 e2e 코드가 있었기 때문에 이것을 정상화시키는 동시에 커버리지를 올린다는 생각으로 그대로 진행했었다. 그러나 생각보다 Cypress 실행속도가 느렸고, 다른 팀에서도 Playwright를 대부분 도입했다고 하여 재검토 요청을 받아 Playwright를 처음으로 사용해보았다. 솔직히 여기저기서 많이 언급하는 실행속도의 경우는 개인적으로 엄청 큰 차이는 못느꼈다. 그리고 여러 브라우저 지원의 경우도 우리는 기존에도 ..
Promise 객체가 가진 핸들러들 .then(), .catch(), .finally() 는 모두 비동기적으로 실행된다. console.log('Start!'); Promise.resolve('Promise!').then(res => console.log(res)); console.log('End!'); // 아래와 같이 출력 // Start! // End! // Promise! 위 코드를 보면 Promise를 바로 resolve 해주어도 then이 실행되는 것은 동기 코드보다 나중이다. 왜 그럴까? 마이크로태스크(Microtasks)와 매크로태스크(Macrotasks) 이 때 등장하는 것이 바로 마이크로태스크다. ECMA에선 위와 같은 비동기 처리를 위해 PromiseJobs라는 내부 큐를 명시하는데 ..
Promise에는 5가지 정적 메서드가 있다. Promise.all Promise.allSettled Promise.race Promise.resolve Promise.reject 이 중 가장 유용하고 많이 쓰이는 것은 Promise.all 일 것이다. 그래서 공부겸 직접 구현해보았다. Promise.all 직접 구현해보기 function all(iterable = []) { if (!iterable || !iterable.length) return Promise.resolve([]); return new Promise((resolve, reject) => { const result = iterable.map(() => ({ state: 'pending', value: undefined })); iter..
Promise ES6에서 등장한 Promise 객체는 자바스크립트에서의 비동기 처리를 획기적으로 변화시켜주었다. 기존에 '콜백 지옥'이라 불리던 것을 해결하며 더 명료한 코드를 작성할 수 있도록 해준다. Promise 객체 속성 Promise는 catch, finally, then 등의 메소드를 가지고 있고 state와 result라는 내부 프로퍼티를 가지고 있다. Promise는 3가지 state를 갖는다. pending - 비동기 처리가 아직 완료되지 않은 상태 fulfilled - 비동기 처리가 성공적으로 끝나 resolve가 호출된 상태 rejected - 비동기 처리 중 오류가 발생해 reject가 호출된 상태 위 상태에 따른 result는 아래와 같다. pending 상태 - undefined..
본 포스팅은 코어 자바스크립트 > 에러 핸들링 페이지를 참고하여 제 생각을 덧붙여 작성한 글입니다. # try...catch try...catch 문법은 대부분의 프로그래밍 언어에서 에러를 핸들링 하기 위해 쓰이고 있다. 자바스크립트도 예외는 아니다. 문법은 아래와 같다. try { // 에러 발생하면 코드 중단되고 catch 블록으로 넘어감. throw new Error('에러 발생'); alert('실행될 수 없어'); // 실행 안됨. } catch (err) { // 에러 핸들링 console.log(err); } 위 코드에서는 명시적으로 에러 객체를 생성해서 던져주었지만, 보통 에러가 발생하면 자바스크립트가 에러 상세내용이 담긴 객체를 생성하여 catch 블록에 인자로 넘겨준다. ## 선택적 c..
# 리덕스 import { createStore, actionCreator } from "./redux-middleware"; function reducer(state = {}, { type, payload }) { switch (type) { case "init": return { ...state, count: payload.count }; case "inc": return { ...state, count: state.count + 1 }; case "reset": return { ...state, count: 0 }; default: return { ...state }; } } const logger = (store) => (next) => (action) => { console.log("logger..
# 좋은 아키텍쳐란? 다른것들끼리 분리해라. 컴포넌트를 언제 어떻게 쪼갤지에 대해선 의견이 분분하지만, 강사님 개인적인 의견으로는 map으로 리스트 데이터를 뿌려주는 경우 별도의 컴포넌트로 감싸주는걸 선호한다. 한 눈에 보기 더 쉽기 때문! 쪼갤까 말까 싶을때가 쪼갤때다! 나중에 더 비대해질 경우 버그날까 쪼개기 더 어렵다. # 커뮤니케이션 이 부분은 아래 링크 작성자께서 정리를 잘해주셔서 발췌해왔습니다. https://github.com/soongyu/woowa-tech-learning-react-typescript/blob/master/week02-2.md soongyu/woowa-tech-learning-react-typescript 우아한테크러닝 3기 React&TypeScript 기록. Cont..
# 지난 시간 정리 리덕스는 전형적인 펍섭(pubsub) 모델을 구현한 것. 사실상 리액트와 연관성이 전혀 없다. publish - subscribe 구조. 상태 변경되면 그걸 알려주고 구독한 쪽에서 알람 받을 수 있는 구조. observer 패턴이랑은 다르다. # 리액트 만들기 좋은 아키텍처를 말할 때 대원칙 중에 하나는 같은 것끼리 묶고 다른 것끼리 분리하는 것에 있다. 여기서 지식 수준의 차이에 따라 어떤게 같은것이고, 어떤게 다른것인지 판단하는 기준이 달라진다. 그러나 보통 기본적인것(네이밍 잘 짓기 등)만 잘 지켜도 70%는 먹고 들어간다. ## 리액트 컨셉 리액트 컨셉은 완전히 새로운게 아니다. 브라우저의 경우 예를 들어보자. HTML코드의 문자열 구조를 직접 다루는 것은 어렵기 때문에 훨씬 ..
- Total
- Today
- Yesterday
- 우아한테크러닝
- ES6
- til
- vue-meta
- 리액트훅
- axios
- frontend
- chartjs
- 상태관리
- Docker
- 인프런
- Python
- JavaScript
- asyncawait
- prerender-spa-plugin
- typeScript
- vue
- EventLoop
- js
- ReactNative
- nodejs
- vue-router
- 프론트엔드
- Component
- REACT
- promise
- vue-cli
- jsconf
- vuejs
- Vuex
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 |