React Query를 사용하면서 문제가 발생했을 때 디버깅 시간을 절약해주는 React Query Devtools에 대해 알아보았다.먼저 React Query Devtools를 활성화하기 위해서는 해당 모듈을 불러와야한다.이후 그것을 가져오려면 다음 QueryClie

Dj-playlist는 youtube api를 활용해서 음악목록을 가져오는 어플리케이션으로 해당 api에 요청하기 위해서는 key값이 필요했다. 지금까지는 가상서버호스팅 (VPS)인 vultr를 사용하여 해당 가상환경에서 .env파일을 사용하는 방식으로 환경변수를 불러

이번 자판기 미션에서 조금 까다로웠던 부분은 잔돈 계산 모듈 부분으로 잔돈 계산 묘듈의 요구사항은 다음과 같다.현재 보유한 최소 개수의 동전으로 잔돈을 돌려줘야하고 일반적인 자판기와 다르게 잔돈을 반환할 수 없는 경우 잔돈으로 반환할 수 있는 금액만 반환한다는 특징이

다음과 같이 자판기의 구매하기 버튼을 클릭하면 해당하는 아이템의 수량을 관리하기 위해 클릭한 아이템의 정보가 필요하다. 보통은 아이템을 구별할 수 있는 unique id를 넘겨주면 해결할 수 있지만 이번 미션에서는 dataset을 활용하라고 했기 때문에 직접 datas

다음은 자판기에 상품을 더하는 로직으로 어떤 아이템이 모델에 의해서 추가되고 나면 반환되는 값의 유무에 따라 다음 동작을 할 수 있도록 구현하였는데 false 값을 반환하는 것은 의도가 불분명한 것 같아 undefined 또는 null값을 반환하고자 한다.ECMAScr

View 내부에서 화면으로부터 사용자의 동작을 Controller로 전달해주는 로직, 사용자에게 보여줄 화면들을 그려주는 로직들이 비대해지면서 markUp에 해당하는 template 부분들을 분리하기로 했다.바꾼 후에 느꼈던 점은 View는 화면을 그리고 사용자의 동작

3차 토이 프로젝트 자판기어떤 아이템을 추가하는 경우에 input에 입력된 값들이 없을 수도 있는 상황에서 arguments로 넘겨줘야하는 경우 타입체크는? Partial 타입을 활용한다면 모든 요소를 옵셔널로 지정한 타입을 새로 생성할 수 있다.휴식

이번 3차 자판기미션에서는 표현해야 할 UI와 비즈니스 로직이 많아졌기 때문에 이를 잘 분리하여 코드의 가독성을 높이고 유지보수를 용이하게 하고자 프로젝트를 시작하기 전에 구조적인 부분에서 고민을 많이 했다.우선, 자판기미션에서는 크게 3가지 탭으로 구분되고 탭의 클릭

다음의 그림과 같이 탭을 클릭할 때 선택한 탭에 맞는 화면을 그려주는 역할을 컨트롤러에서 하고 싶어 방법을 찾아보다가 CustomEvent와 Dispatch()메서드를 활용하게 되었다.CustomEvent를 활용하면 일반적인 내장이벤트말고 탭변경에 대한 이벤트를 구분할

코인과 아이템은 클래스로 분리시켜 관리비교적 복잡하지 않은 코인과 아이템을 추상화 할 필요성을 느끼지 못해 객체로 관리. (위의 그림과는 다름)컨트롤러의 역할은?컨트롤러는 모델을 사용하여 적절한 비즈니스 로직을 수행하는 역할을 하려고 한다.자판기모델을 뷰에게 전달해주는

const로 선언한 객체타입의 경우에는 메모리 공간상에서 값을 변경할 수 있기 때문에 다음과 같이 수정할 수 있다. 하지만 상수라는 것은 변경되지 말아야 할 값을 변경하는 개발자의 실수를 방지하려는 의도로 작성하는 것이지만 위에서의 상황은 그렇지 못한다는 것이다. 그래

이번 3차 미션의 난이도가 저번주에 비해 많이 어려워졌다. 그래서 요구사항을 정확히 이해해서 구현목록부터 꼼꼼히 작성하고 이후에도 계속해서 수정해야하는 방향으로 가야할 것 같다.

지금까지 이터러블, 값으로 다룰 수 있는 프로미스를 활용한 지연평가, 동시성 프로그래밍 등에 대해서 알 수 있었던 시간이였고 오늘로서 개념적으로 설명해주는 부분들이 끝이 나면서 간략하게 회고를 작성해보았다.내가 함수형 프로그래밍에 관심을 가지게 된 것은 인생의 첫 화상

3차 토이 프로젝트 - 자판기, 개발환경 세팅 휴식

이전 포스팅에서는 비동기적인 실행들이 순차적으로 진행되어 아래와 같은 상황에서 매우 비효율적인 코드가 되었었다. 그 뿐만 아니라 데이터베이스에 날리는 쿼리, 이미지 처리등등에서도 지금까지 배웠던 함수들을 활용할 수가 있는데 여러개의 요청을 동시에 날리는 경우에는 효율적

오늘 보았던 강의는 이전 포스팅에 이어서 기존의 유틸함수를 Promise가 적용될 수 있도록 변경하는 과정들을 보여주는 내용이였다. 기존의 유틸함수에 프로미스를 적용하는 부분부터 조금씩 어려워지기 시작했는데 아무래도 여러번 봐야지 적용해볼 수 있을 것 같다...기존의

과거에는 callback만을 사용하여 비동기처리를 했지만 연속적인 비동기처리를 하다보면 가독성이 좋지 못하고 서드파티라이브러리인 경우 제어의 역전문제로 믿음에 대한 문제가 있었다.그래서 Promise라는 것이 나오게 된 것이고 오늘 강의에서 프로미스가 1급 객체이기 때

이전 포스팅에서의 reduce, take함수는 iterator에서 값을 하나씩 꺼내 결과를 만들어내는 함수로 생각하고 코드를 작성하면 유용하다. 그리고 그런 함수들을 이용한다면 조금 더 다형성이 높은 코드를 작성할 수 있다. reduce함수를 활용한다면 array일때만

지연평가는 계산의 결과 값이 필요할 때까지 계산을 늦추는 기법으로 필요한 경우에 도달할 때까지 계산을 늦추기 때문에 불필요한 계산을 줄일 수 있다는 장점이 있다.해당 부분을 학습하면서 take함수로 인해 지연평가가 주는 장점이 확 와닿았기 때문에 그 부분을 작성해보았다

문서 내의 특정 element를 찾기 위해서 주로 document.querySelector()를 사용하고 있었다. 하지만 문서 구조가 커진다면 root부터 시작하여 DOM 탐색을 하기때문에 탐색에 대한 불필요한 비용이 증가된다는 단점이 있다. 또한 클래스의 경우에는 언