스택의 정의

스택과 큐가 데이터를 저장하는 방법은 배열과 같다.

스택은 리스트의 끝에서만 데이터가 들어오고 나가는 자료구조이다. Javascript에서는 Array에 push와 pop을 이용하여 구현할 수 있다. 스택은 마지막 리스트에서 자료를 넣거나 뺼 수 있는 선형 구조(Last in First Out)으로 되어있다. 스택이 비었으면 1을 반환하고, 그렇지 않다면 0을 반환한다.

스택의 연산

• top() : 스택의 가장 윗(마지막) 데이터를 반환한다.
• pop() : 스택의 가장 윗(마지막) 데이터를 삭제한다.
• push() : 스택의 가장 윗 데이터로 top이 가리키는 자리 위에(top = top + 1) 메모리를 생성,데이터를 넣는다.

Javascript 코드

class Stack {
    constructor() {
      this.arr = [];
    }
    push(x) {
      this.arr.push(x);
    }
    pop() {
      return this.arr.pop();
    }
    empty() {
      if(arr.length == 0) {
        return 1;
      } else {
        return 0;
      }
    }
}
  const stack = new Stack();
  stack.push(1);
  stack.push(2);
  stack.push(3);
  console.log(stack.pop()); //3
  console.log('stack', stack); //[1, 2]

큐(Queue)

큐의 정의

• 먼저 집어 넣은 데이터가 먼저 나오는 선입선출(FIFO - Frist In First Out)구조로 저장하는 형식이다.
• 프린터의 출력 처리나 윈도우 시스템의 메시지 처리기, 프로세스 관리 등 데이터가 입력된 시간 순서대로 처리해야 할 필요가 있는 상황에 이용한다.

큐의 연산

• shift() : 큐의 맨 앞의 데이터를 삭제한다.
• unshift() : 큐의 맨 앞의 데이터를 추가한다.

Javascript 코드

class Queue {
  constructor (){
    this.arr = [];
  }
  enqueue(item){
    this.arr.push(item);
  }
  dequeue(){
    return this.arr.shift();
  }
}
const queue = new Queue();
queue.enqueue(1);
queue.enqueue(2);
queue.enqueue(3);
queue.dequeue(); // 1
console.log(queue.arr) // [2,3]

출처 : http://paullab.co.kr

자바스크립트는 나에게 첫 언어이고 그렇기에 현재까지 자바스크립트를 기반으로 모든 프로젝트를 진행하였다.

그렇지만 자바스크립트 내부에서 어떻게 동작하는지 고민 해본 적이 있었던가...?

1편에서는 자바스크립트 엔진과 런타임, 콜스택으로 설명!

자바스크립트 엔진(V8)

V8이란 ?

: C++로 작성된 구글의 오픈소스, ECMAScript, WEbAssembly엔진 -> 즉 JS와 WASM을 실행할 수 있는 환경

V8이 수행하는 일

: JS, WASM 코드 컴파일, 실행 : 콜스택 처리(함수 실행) : 메모리 할당 : 가비지 컬렉션

V8의 실행 과정

V8엔진 구성

메모리힙(Memory Heap): 메모리할당이 이루어지는 곳 콜스택(Call Stack): 코드가 실행되면서 스택 프레임이 쌓이는 곳

런타임

브라우저에는 거의 모든 자바스크립트 개발자가 사용하는 API가 존재

콜스택

자바스크립트는 싱글 쓰레드(single-threaded) 프로그래밍 언어이다. 다시 말하면 콜스택이 하나라는 뜻. 따라서 한 번에 하나의 일만 할 수 있다.

특히 리팩토링시 클래스나 패키지 폴더의 이름 변경은 자주 발생하는 작업이므로 변경 내역을 잘 관리해야 하며 git 의 아래 명령어를 사용하면 된다.

git mvLink to git mv

파일 이동 명령어인 mv 사용하면 변경 사항을 추적할 수 있으며 다음과 같이 사용하면 된다.

>```
git mv oldName newName

-n( --dry-run) 옵션을 사용하면 적용전에 어떻게 변경되는지 테스트가 가능하다.

mv 시 invalid argument 가 발생할 경우

mv 명령시 invalid argument 에러가 발생하는 경우가 있다. 제 경험상 파일이나 폴더 이름의 일부를 대소문자로 변경하는 경우에 발생한다.

예로 sprint 라는 폴더를 Sprint로 첫 글자를 대소문자로 변경하는 경우 위 에러를 접하게 된다.

이럴 경우 아래와 같이 임시 폴더 이름으로 rename 하고 임시 폴더 이름을 원래 바꾸려고 한 이름으로 rename 하는 2단계 절차를 거치면 된다.

git mv sprint tmpDir
git mv tmpDir Sprint

[Ref Link](https://stackoverflow.com/questions/11183788/in-a-git-repository-how-to-properly-rename-a-directory)

: React의 SSR(Server Side Rendering)을 쉽게 구현할 수 있게 도와주는 간단한 프레임워크

SSR vs CSR

: SSR은 서버에서 사용자에게 보여줄 페이지를 모두 구성하여 사용자에게 페이지를 보여주는 방식, SSR을 사용하면 모든 데이터가 매핑된 서비스 페이지를 클라이언트(브라우저)에게 바로 보여줄 수 있다. 서버를 이용해서 페이지를 구성하기 때문에 클라이언트에서 구성하는 CSR(client-side rendering)보다 페이지를 구성하는 속도는 늦어지지만 전체적으로 사용자에게 보여주는 콘텐츠 구성이 완료되는 시점은 빨라진다는 장점이 있다. 더불어 SEO(search engine optimization) 또한 쉽게 구성할 수 있다.

반면 CSR은 SSR보다 초기 전송되는 페이지의 속도는 빠르지만 서비스에서 필요한 데이터를 클라이언트(브라우저)에서 추가로 요청하여 재구성해야 하기 때문에 전제적인 페이지 완료 시점은 SSR보다 느려진다.

Next js 핵심기능

1. 기본적으로 서버사이드 렌더링을 제공함
2. 더욱 빠른 페이지 로드를 위한 코드 스플리팅 자동화
3. HMR을 지원하는 웹팩 기반 환경
4. Express나 Node.js와 같은 http 서버와 함께 구현 가능
5. Babel, Webpack 설정 커스터마이징 가능

얼마나 많은 기업들이 Next js를 채택하여 사용하는지 볼 수 있다👇
https://github.com/vercel/next.js/discussions/10640

store store는 말그대로 전역에서 상태를 관리해주는 공간이다.객체 형태로 되어 있다.

action action은 상태 변화를 일으키는 주체이다. 객체 형태이고 타입이라는 것이 필수로 들어간다. 액션 생성 함수로 발행한다.

reducer reducer는 액션을 실행시키는 순수함수이다. 순수함수란 동일한 임자가 들어오면 동일한 결과를 반환해야 하며 외부의 상태를 변경하지 않는 함수를 말한다. 즉, 함수 내 변수 외에 외부의 값을 참조, 의존하거나 변경하지 않아야 한다는 것을 의미한다. 그래서 reducer는 현재 상태와 들어온 액션을 파라미터로 입력받아 새로운 상태값을 만들어서 반환한다.

(prevProps,action) => newState

dispatch 스토어의 내장함수 중 하나이다. 이 함수가 호출되면 스토어는 리듀서 함수를 실행시켜서 새로운 함수를 만들어 준다.=> 하지만 "react-redux"를 사용하면 dispatch함수를 쓰지 않고 더 쉽게 액션을 발행시킬 수 있다.

provider 내가 사용하는 app이 스토어를 사용할 수 있게 래핑해주는 역할을 한다.props로 store를 전달한다.

The Gist!

앱의 상태 전부는 하나의 스토어(store)안에 있는 객체 트리에 저장됩니다. 상태 트리를 변경하는 유일한 방법은 무엇이 일어날지 서술하는 객체인 액션(action)을 보내는 것 뿐입니다. 액션이 상태 트리를 어떻게 변경할지 명시하기 위해 여러분은 리듀서(reducers)를 작성해야 합니다.

import { createStore } from 'redux'

/**

• 이것이 (state, action) => state 형태의 순수 함수인 리듀서입니다.
• 리듀서는 액션이 어떻게 상태를 다음 상태로 변경하는지 서술합니다.
• 상태의 모양은 당신 마음대로입니다: 기본형(primitive)일수도, 배열일수도, 객체일수도,
• 심지어 Immutable.js 자료구조일수도 있습니다. 오직 중요한 점은 상태 객체를 변경해서는 안되며,
• 상태가 바뀐다면 새로운 객체를 반환해야 한다는 것입니다.
• 이 예시에서 우리는 switch 구문과 문자열을 썼지만,
• 여러분의 프로젝트에 맞게
• (함수 맵 같은) 다른 컨벤션을 따르셔도 좋습니다.
• / function counter(state = 0, action) { switch (action.type) { case 'INCREMENT': return state + 1 case 'DECREMENT': return state - 1 default: return state } }
  // 앱의 상태를 보관하는 Redux 스토어를 만듭니다. // API로는 { subscribe, dispatch, getState }가 있습니다. let store = createStore(counter)
  // 업데이트를 직접 구독하거나 뷰 레이어에 바인딩할수 있습니다. // 보통은 subscribe()를 직접 사용하기보다는 뷰 바인딩 라이브러리(예를 들어 React Redux)를 사용합니다. // 하지만 현재 상태를 localStorage에 영속적으로 저장할 때도 편리합니다.
  store.subscribe(() => console.log(store.getState()) )
  // 내부 상태를 변경하는 유일한 방법은 액션을 보내는 것뿐입니다. // 액션은 직렬화될수도, 로깅할수도, 저장할수도 있으며 나중에 재실행할수도 있습니다. store.dispatch({ type: 'INCREMENT' }) // 1 store.dispatch({ type: 'INCREMENT' }) // 2 store.dispatch({ type: 'DECREMENT' }) // 1

그리고 오랜만에 내방 침대에서 잤는데...너무 푹신 ㅠ_ㅠ.. 그리웠어..(고시원에서도 엄청 잘잤음..^^)

보자 보자... 10월 19일 위코드 개강.. 12월 11일 2차 프로젝트 종료 약 2달간의 시간 어떻게 흘러간지 모를정도로 위코드 안의 생활에 둘러쌓여있었다. 사실 최근에서야 코로나 확산때문에 다시 뉴스를 찾아보곤 했지만 그동안은 코로나고 뭐고 only 코딩에만 집중!

이틀 전 2차 프로젝트가 끝나고 내일이면 기업협업이 시작된다.

기업협업 전 2차 프로젝트 정리를 하려고 한다.

1. 2차 프로젝트에서 느낀점
2. 2차 프로젝트에서 깨달은점
3. 수위의 서재
4. 앞으로의 방향

1. 2차 프로젝트에서 느낀점
2. 1차때 PM으로써 팀원을 이끌었다면 2차에서는 완전한 follower가 되었고 조금은 수동적인 자세로 임했던 것 같다. 이유는 모두가 그렇겠지만 체력적으로 조금 지침 + 이참에 잘 따르는 follower가 되어보자..

그래서 결과..

follower로써 자가 평가 : 수동적인 태도 반성 필요.. ^^ + 2차 또한 열심히 했지만 1차와 비교해서 살기위해.. 몸을 사렸던 것 같읍니다...

~~(핑계 : 체력적 한계 + react 함수형 + styled-components 조합.. 바로 바로 적용/응용시키기 어려움을 느낌 -> 진도 안나감) 멘토님들이 프론트의 고충을 아셨을까 '양 보다 질'이라고 기능 구현에만 급급하지 말고 기능 하나하나 올바르게 적용해보며 코드를 깔끔하게 작성하며 부끄러운 코드를 남기지 말라는 말씀!

2. 2차 프로젝트에서 깨달은점 결과적으로 무사히 프로젝트를 끝마쳤다 생각된다. 하지만 모두 바쁘고 열악한 환경에서 서로 도움을 주고 받으며 꽤 괜찮아 보이게 결과물이 나왔다. 중간 중간 git rebase 이슈로 시간을 꽤 잡아먹었고 git conflict 이슈로 진이 빠진 적도 있었지만 멘토님과 든든한 팀원들의 덕분에 금방 회복하고 다시 페이스를 찾을 수 있었던 것 같다. 하지만 조금 아쉬운 점이라면 내가 좀 더 나서서 프론트 간에 대화를 이끌었다면? 하는 이미 지나간 날에 대한 아쉬움이 든다. 마음 속으론 (사소하지만) 이런 이슈도 공유하면 좋을 것 같다, 이런 파일은 먼저 통일 시키고 시작하면 좋겠는데? 다른 분들은 어떤식으로 routes 경로명 설정하셨지? 등등 이런 생각들이.. '나중에 합쳐볼테니 어차피 알게 될거야'라고 자기 최면을 걸고 내파트에 집중한 것 같다.

Dear. 수위의 서재

수희님 - PM이자 수위의 서재 대표님! 갑작스런 코로나 확산과 환경적으로 급격한 변화에서도 침착하게 팀원들을 이끌어주셔서 너무 감사합니다. 그리고 잊을 수 없는 Suwee의 복지(선릉 산책도 시켜주시고 밥도, 간식도 마구마구 사주시고...)는 과히..최고였다..Suwee는 성과제인데..; 성과(목표량 구현)로 모두 보답하지 못한 것 같아 죄송하고 그럼에도 마지막까지 저희를 북돋아주신 부분 너무 감사합니다.

주민님 - 주민님! 제가 1차때 상세 페이지를 맡아서 도움드리고 싶은 부분이 있었을텐데 제 것 한다고 챙겨드리지 못해서 미안하게 생각하고 그럼에도 알차게 구현하셔서 괜한 염려를 했나 생각했어요! 함께해서 즐거웠습니다!

세원님 - 세원님..랜딩페이지 결과물은 정말 멋졌습니다! 소셜 로그인도 뚝딱! 결제 기능도 뚝딱! (당신 ..그만 잘 해...)그와중에 팀원들도 챙겨주시고..그리고 세원님께 질문하면 과정 하나하나 알려주셔서 이해가 잘되었습니다! 정말 최고였어요!

승진님 - 이전에 저의 첫 코드카타 짝궁이셨던 지니베어님! 제가 백엔드는 아니지만 지니베어님의 명성을 익히 들어서일까요? 서버와 통신할때 안되는 부분 말씀드리면 바로 잠시만요~ 하시고 해결 쏙쏙 ! 든든했습니다!

현석님 - 저의 마니또가 되셔서 1차 플젝때 간식과 커피를 챙겨주셨던 현석님! Suwee에서 저와의 접점은 없었지만 2주동안 동고동락! 즐거웠습니다!

4. 앞으로의 방향

(작성해야함)

(시간이 지날수록 미화는 무슨, 기억이 리셋되기 전에 다듬어지지 않은 글로 우선 업로드하겠습니다..)

오구오구를 한마디로 정리하자면

너 무 즐 거 웠 다 ! 그리고 정말 많이 웃었다!

중간 중간 시련이 있었지만 사랑스러운 조원들 덕분에

팀원 중 현지님을 제외한 혜수/성보/승제/민영님은 평소에 대화를 많이 해보지 않았던 분들이였는데 함께하니 우리의 조합은 최고🥰

우리 팀원들에게

나의 뽀야미 1호..2호.. 현지 & 혜수님

현지님 - 퀸현지.. 무슨 말이 더 필요할까... PM으로써 놓치는 부분이 있다면 챙겨주시고 멘토님이 계시지 않아 어려움을 겪을때 정확한 문제 파악 후 원포인트 레슨까지.. 오구오구가 막힘없이 프로젝트를 진행할 수 있게 힘써주신 현지님.

혜수님 - 1차 프로젝트의 로그인/회원가입 + 장바구니 끝판왕! 이렇게 잘 하면서 ! 못하는척 하기 있기없긔? 해수님께 공감도 많이 받고 서로 위로도 해주고 우리 좀 재밌었는데.. 이제 7층에 있어 ㅠ_ㅠ

든든한 백둥이

성보님 - 마지막날 아침까지 고생해주셨던 성보님..! 나와 상세페이지내 모든 데이터를 함께 했던..! 다른 이커머스와 달리 G9의 product 모델링으로 힘드셨을테도 먼저 맞춰주시려고 했던 성보좌.. 할말이 많았는데.. 지금은 11시 50분 ..신림 꼭 가겠습니다...🤗

승제님 - 나와 상세페이지 내 문의사항 CRUD 과정을 함께 한 승제님! 디테일한 논의 전에 이미 프론트의 flow까지 생각해주셔서 해당폴더의 props대공사를 시키지 않아도 되었다! 정말 아름다운 로직이였다! 내가 조금만 더 잘했다면 게시글 수정/업데이트 기능까지 붙여볼 수 있었을텐데! 나의 파트에 집중하고 있을때 기존의 목표를 클리어 하고 말을 하지않아도 민영님과 함께 이메일 인증번호 추가구현을 하신 건 정말 멋졌다.

민영님 - 민영님 덕분에 너무 든든했던 백엔드! 여전히 백엔드에 대해 모르는 부분이 많지만 오구오구때는 사실 감조차 잡히지 않았는데, 민영님께서 우리 백엔드 멤버들과 논의하시고 회의때마다 알아듣기 쉽게 정리하여 말씀해주셔서 너무 든든했다. 특히 현재 상황과 프론트와의 커뮤니케이션을 굉장히 잘해주셔서 프론트의 내 파트 이외에 서버 통신 상황에 대해 숙지하고 있을 수 있었다. 프로젝트 발표날 잠도 거의 못주무시고 아침 일찍 오셔서 함께 맞춰봐주셨던.

어떻게 표현해야 할지 모를정도로 함께 프로젝트를 진행한 다섯분께 너무 감사한 마음이 크다. 두고 두고 생각 날 것 같다. 어떻게 보면 첫 개발자로써의 프로젝트를 이 멤버들과 함께해서 너무 영광이고 앞으로도 좋은 인연으로 발전되기를 바라본다.

사진 첨부할 것 도 많은데.. 일단 이까지

업데이트 될 예정입니다..

O9O9(오구오구) 프로젝트 소개

1차 클론 프로젝트 아이디어공모에서 G9가 선정되어 PM으로써 G9를 모티브로 클로닝 프로젝트를 사랑스러운 팀원들과 12일간 진행하였다.

G9 : 이베이 코리아가 운영하고 있는 큐레이션 오픈마켓 사이트 모든 것이 깔끔한 G9, 초기 카피는 상술을 버리다, 상식을 채우다 (하나 하나 다 맘에 들었어...지구 너..)

프로젝트 진행기간 : 2020년 11월 16일 ~ 2020년 11월 27일

기술 스택

▪️** FrontEnd**

JavaScipt ES6

React (CRA 초기세팅)

Sass

▪️** BackEnd**

Python

Django

▪️ 공통

git

Slack

Trello

팀원 소개 👫

▪️ FrontEnd

🌸 류지혜 (PM) Product Detail Page

🌺 김현지 Main Page, Product List Page

🌼 안혜수 Signin Page, Signup Page, Cart Page

▪️ BackEnd

☘️ 박승제 Login, Signup, Q&A CRUD 구현

🌻 이민영 Cart CRUD, Email 인증 및 발송 기능 구현

🌹 이성보 Products Page, Category Page, Product feature 구현

우리 오구오구팀 멤버들 왜이리 다 귀엽나요? 왜죠!? G9폰트처럼 동글 동글 했던 우리. 의견 마찰없이(있었다면 DM Plz...🤗) 모두가 맡은 역할 이상으로 멋진 결과물을 만들어 냈다. 그리고 멋지고도 귀여운 O9O9가 탄생하게 된다.💙

O9O9의 목표 🔥

우리 프론트엔드와 백엔드 멤버 모두 React, Django를 이용한 첫 프로젝트이다. 외에도 각 파트 로드맵에 따라 다양한 기술과 지식을 쉼 없이 익히며 달려왔다. 이때문에 이커머스 사이트에서 구현할 수 있는 기본 핵심 기능을 구현하며 기초를 다지고 내 것으로 흡수시키는 방향으로 설정하고 기본에 집중하며 프로젝트에 임했다. (차후 이 부분은 나 포함 팀원들이 초기 부담을 덜게되어 능률이 더욱 올라갔고, 추가 기능까지 구현하며 좋은 성과를 낼 수 있었다 생각한다! )

마치... 내 성격과 같은 Agile하게... 👊

성격따라 개발 프로세스도 애자일로^^ ~(원래부터 애자일로 방법론으로 설정됨)~~, 대신에 끝없는 소통... 그때 그때 끝없는 소통이지만, 공식 소통시간을 오전・오후 하루 2번 진행하였다. 프론트/백은 이슈 발생시 그때 그때 공유하더라도 팀원 모두가 거의 수면시간을 제외하고 작업에 매진했기 때문에(그만큼 하루동안 변경사항과 결정사항을 논의해야 할 텀이 짧았다.), 사소한 점이라도 서로에게 공유를 하고 넘어가자는 의미에서 모든 회의는 길지않게 각자 진도, 오늘의 구현 목표, 각 파트 이슈 및 변경사항 정도로 간결하게 진행되었고, 저녁회의 마치고는 팀원들과 씐나는 탁구...^^ 너무나 재미있었다... refresh하고 다시 코딩모드

### 프로젝트 결과물

상품 디테일 페이지 보러가기

👩‍💻 상세 페이지

☑️ 담당 구현 기능

▸ 상품 상세 페이지 : REST Api를 사용해 서버를 통신하여 상품 리스트 렌더링 : 상세 페이지 내 메뉴 Tab 기능 생성 / 문의하기 탭 CRUD 및 출력 기능 구현 : State관리를 통한 찜하기 및 수량에 따른 가격 변경 기능구현 : 각 기능을 모두 개별의 컴포넌트로 구현 후 부모 컴포넌트에서의 상태관리

▸ 메인페이지 상단 nav바 , Footer 구현 : 로그인 실행 유무에 따른 상태 변경 기능 구현

특별할 것 없지만 머리속은 이미 long story..😶

처음에는 간단하게 쓰려고 했는데 내 이름에 대해 쓰고 있는 나를 발견.....

그래서 하나씩 짧게 나누어 작성하려 한다.

참고: 크롬에서 테스트한 결과로 디테일한 현상은 타 브라우저와 다를 수 있습니다. 그리고 테스트 코드는 typescript 기반으로 제작되었는데, 인자 값을 any 타입으로 정의한 것은 테스트 코드를 간소화하기 위한 것으로 실제로는 타입에 맞게 지정해 주어야합니다.

1. jsx 태그에 등록하는 이벤트 리스너는 네이티브 이벤트가 아니다.

jsx 태그에 onMouseDown, onClick, onChange 같은 이벤트 리스너를 등록할 수 있는데, 이 이벤트들은 네이티브 이벤트가 아니다. Mouse 이벤트의 경우 네이티브 마우스 이벤트 정보를 담고 있는 Class 객체로 들어오고, onChange 이벤트의 경우에는 네이티브 change 이벤트 정보를 담고 있는 SyntheticEvent 객체로 들어온다. 특히 change 이벤트 같은 경우 네이티브 이벤트와 동작이 다른데, 네이티브 이벤트는 포커스 아웃이 됐을 때 사용자 입력이 완료되었다고 인식하여 change 이벤트가 발생하는 반면 react의 change 이벤트는 인풋에 텍스트가 입력되어 변경이 생기면 발생한다. 크롬기준으로 봤을 때 input 이벤트와 비슷하다.

react 태그에 직접 이벤트 핸들러를 등록

네이티브 이벤트 등록

2. input 엘리먼트에 value 속성을 지정하면 인풋값이 변경되지 않는다.

아래처럼 value 속성을 지정해 두면 이 엘리먼트는 value 값에 의해서만 값이 변경된다는 전제가 생기기때문에 사용자가 값을 입력해도 input은 변경되지 않는다.

그래서 인풋창의 값을 업데이트하기 위해서는 props나 state 값을 바인딩하여 render 함수를 통해 업데이트 해야한다.

라우트의 경로에 특정 값을 넣어 해당 페이지로 이동할 수 있게 하는 것.(Dynamic Routing)

React Router에서는 두 가지 방법을 통해 유동 라이팅 기능을 구현할 수 있습니다.

1. Query parameters
2. URL parameters

라우트로 설정한 컴포넌트의 3가지 props

### 1. history 이 객체를 통해 다른 경로로 이동하거나 앞, 뒤페이지로 전환할 수 있습니다.

2. location 이 객체는 현재 경로에 대한 정보를 지니고 있고, URL 쿼리에 대한 정보도 가지고 있습니다.

3. match 이 객체에는 어떤 라우트에 매칭이 되어있는지에 대한 정보가 있고, params 정보를 가지고 있습니다.

Query parameters

location

this.props.location을 통해서 URL 주소의 정보를 가지고 올 수 있습니다.

해당 URL에서 필요한 key값을 추출하여, 백엔드와 데이터 통신을 하고, 백엔드와 통신한 데이터로 원하는 정보를 페이지에 담을 수 있습니다.

URL parameters

match

params 정보는 this.props.match.params를 통해 가지고 올 수 있습니다. params 데이터를 사용하기 위해서는 Route.js에서 라우트 설정을 조금 수정해야 합니다. Route exact path 뒤에 /:id를 붙여주면 해당 컴포넌트에서 this.props.match.params.id를 통해 해당 값을 가지고 올 수 있습니다.

String parameters VS Query parameters

String parameters

해당 페이지에서 여러 정보가 필요한 경우 Query parameters를 사용할 경우, routes.js를 수정해야 하기 때문에 유지 보수 측면에서 좋지 않다고 판단될 경우 필터링을 하고 싶은 경우 Query parameters

특정한 resource를 식별하고 싶은 경우. 즉, 하나만 딱 필요한 경우. /users // 사용자 전체의 목록을 가져온다. /users/123 // id 값이 123인 사용자를 가져온다. /users?job=programer // 필터링 >>> 직업이 프로그래머인 사용자 목록만 가져온다.

유치원 첫 등원 하는 기분으로 화창한 테헤란로 아침 햇볕을 받으며 던킨도나스 앞 횡단보도를 룰루랄라 건넜던 기억이 엊...엊그제 같은데...

얼굴을 외웠지만 이름과 매칭시키는 과정에서 이름이 기억안나 부르진 못하고 이름없이 자연스럽게 부르려고 했던 순간도, 라운지가 낯설어 강의실에서 눌어앉아 코드치던 시간도 순삭...😳

이젠 거의 주말까지 4주 내내 붙어서 얼굴을 마주보니 대부분 14기 동기들을 한 3개월 정도 알고 지낸 것 같은 느낌이 들만큼 익숙하다.. 그리고 영주님 말처럼 한 달 뒤에 헤어진다 생각하니 벌써 눈물 뚝(ㅠ_ㅠ.. 생각보다 정많은 스탈❄️)

대략 프론트앤드 기준 이번주 까지의 4주 루틴은 아래와 같다.

🌟 첫째주 : HTML/CSS/Javascript 문제를 풀며 친해지기 🌟 둘째주 : 하루에 하나씩 짝꿍과 알고리즘 문제를 풀고, HTML/CSS/Javascript로 인스타그램을 구현해본다. 쉽지 않지만 다 하게 되어있다. 🌟 셋째주 : HTML/CSS/Javascript를 사용해 만든 인스타그램을 SPA로 CRA환경으로 세팅해 react로 구현한다. + SCSS포함..^^ 이게 될까 싶지만 된다...^^ 갓 위코드와 위대한 동기들...! 🌟 넷째주 : 전 주에 react로 구현한 인스타그램을 조별 git repository에 PR하고 공용 컴포넌트와 mock데이터도 적용해보고 서로 리뷰도 주고 받았다. 내가 누구에게 리뷰를 남기다니... 그리고 멘토 리뷰도 받고 리팩토링 진행! 이후에 리뷰 반영 후 조끼리 readme작성 후 일단 한숨을 돌린다... 그리고 멘토님들이 merge까지 해주시면... 종료!

➕ 중간 중간 진행된 수업들

• 웹 서비스의 역 개발자 도구, HTTP, 리눅스 & 터미널 사용법, 데이터 베이스와 모델링, 인증 & 인가... 제목만 적어보았지만... 어떻게 이걸 다 소화했나..(우선은 다 소화했다 생각하고 싶다.^^)

리액트

리액트 특히 ...리액트 특징이 어렵다라는 거라는데...컴포넌트 나누는 것 부터 너무 낯설었다. State와 Props도 알듯 말듯.. 하지만 인스타그램 클론이 종료될때쯤 보인다 보여!! +_+!!! 천천히 느리지만 분명 하루하루 성장하며 나아가고 있으니 걱정은 하지 않을 것이다. 지금, 그리고 앞으로 더 몰입하여 리액트를 꼭 끝장낼 수 있도록... 하겠다...

눈 깜짝 할 사이에 한달이 흘렀다. 느끼는 점은 어렵고 어렵다.. 이해하려고 하는데 이해가 안되서 머리가 지끈지끈 아프고 우울한 날도 있었다. 하지만 너무 즐겁다! 될 것 같다! 아무 걱정없이 내가 하고싶은 공부를 하는 현재..얼마나 소중하고 행복한 시간인가.. 그렇지만 이 시간 조차 그냥 주어진게 아니기에 이 소중한 시간을 더욱 알차게 쓰도록! 다시 한 번 개발자의 길을 선택한 나에게 쓰담쓰담해주고 싶다... 그리고 응원해주는 엄마 아빠 오빠 사랑해🧡

분명 위코드 시작 전 사전 스터디 나의 홈페이지 만들기 과제에서

갈려질 만큼 하자 했는데... 과연 내가 갈려질 만큼 한걸까? 100을 쏟아 부었는가? 아니다. 체력은 매일 워워크 계단오르기로 유지(?) 하고 있고, 이제 1차 프로젝트 시작 때 갈릴거야...

1차 프로젝트를 앞두고 느끼는 점

원하는 클론 프로젝트 사이트를 발표할 때 나는 나의 애정하는 사이트 G9를 발표했다. 깔끔하면서도 귀욤귀욤한 UI, 고민하지 않아도 되는 제품 퀄러티, 모두 무료 배송 & 무료 반품, 그리고 동글동글 로고와 상큼한 테마컬러!!

그리고 감사하게도 G9가 클론 프로젝트 리스트에 선정이 되었다! (사실 될 줄 알았음. 왜냐면 이커머스 사이트중에 G9만큼 편안하고 직관적이고 심플한 곳이 있나 ^^ + 그리고 여유만 된다면 프론트와 백에서 구현해볼 것 천지인 이커머스!)

관건은 1차에 할 것인가 2차에 할 것인가.... 나의 감은 1차..응 당첨...^^ 그럴 것 같아..

급 포스팅 종료... (수정은 나중에)

마지막으로 미래의 함께할 팀멤버분들께, 미리 잘 부탁드립니다.. 우리 G9.. 최강의 조를 만들겝니다...

1. fetch()
2. fetch함수를 사용해 backend API붙이기

Ajax의 포스팅은 요기에서 🐙

두근두근 +_+ ! 오늘은 backend분들이 만든 데이터 모델을 fetch함수를 통해 내가 만든 위스타그램 로그인창에서 유효성 체크를 해보는 시간을 가졌다. 그리고 유효한 값을 넘기면 받을 수 있는 귀여운 토큰들도 받았다!

1. fetch() ??

1-1. fetch의 기능

• 서버가 응답할 때 까지 다른일을 할 수 있도록 도와주는 메서드
• fetch()안에 들어가는 인자값만 서버 응답이 끝난 후 실행되고, 나머지 요소들은 서버응답과 상관없이 실행한다.

• 그렇다! 비동기(Asynchronous)이다!

*기본 문법 *

let promise = fetch(url, [options])

```

response / request header부분은 별도로 다루지 않겠다.

함수 설명

• GET 이외의 요청을 보내려면 추가 옵션을 사용해야 한다.

• method : GET, POST, PATCH 등 http method를 입력한다.
• body : 문자열(예 : JSON)
• 통신을 할 때는 string 형태의 JSON으로 보내야 하기 때문에 JSON.stringify()라는 메서드를 활용해서 포맷을 기존의 Object에서 String으로 변환해준다.
• 통신은 다른 로직에 비해 오래 걸리기 때문에 비동기 처리돼서 then 메서드를 사용한다.

2. fetch함수를 사용해 backend API불러오기

backend에서 작업한 데이터 모델이 들어있는 서버 주소를 API라는 변수로 지정해두고😃, fetch함수를 사용해 통신을 시작한다.

아래 코드에서 첫 번째 then에서는 server에서 보내준 response를 Object 형태로 변환해주고 두 번째 then에서는 object로 변환한 response를 console.log로 확인한다. 여기서 원하는 로직을 구현하면 된다! fetch함수 내 body부분의 항목은 backend에서 지정한 key와 일치해야한다.(데이터 type확인 유의!!)

위의 Authorization은 상대 backend분의 key값과 일치하면 우선 나의 local storage에 담기게 되는데 미처 그것까지 확인하지 못하여 첫 토큰들을 다 캡쳐해버렸다...😄

콘솔창에 찍힌 값들이 뭐라고.. 왜이렇게 귀엽니!! 너희들🥲   앞으로 안전하게 보관해줄게💛

전달받은 토큰들을 안전하게 관리할 수 있도록 JWT(존맛탱 아님)에 대해서도 학습할 예정이다!

1. mock data란?

• mock: 거짓된, 가짜의

• 이름에서 알 수 있듯이 mock data 는 가짜 데이터, 샘플 데이터
• 즉, 실제 API 에서 받아온 데이터가 아닌 프론트앤드 개발자가 필요에 의해 샘플용으로 만든 데이터

2. mock data가 필요한 이유

• API 가 아직 준비중인 경우

  :: 프로젝트 진행 시 API가 나오기 이전에 페이지 레이아웃이 먼저 나오는 경우가 많다. 이러한 경우에는 백엔드에서 API가 나올 때까지 무작정 기다리는 게 아니라, mock data를 만들어 데이터가 들어오는 상황을 미리 대비하고 UI가 기획에 맞게 구현되는지 먼저 확인해야 한다.

• Backend 와의 원활한 의사소통을 위함
  :: 주고 받는 데이터가 어떤 형태인지, key-value 값을 미리 맞춰볼 수 있다.

2. mock data 관리 방법

data.js & data.json

📂 data.js

🧷 data.js 위치 해당 컴포넌트 바로 옆에 만들어서, 바로 접근하기 쉽게!

const SlickData = [
  {
    id: 1,
    skills: "HTML"
  },
  {
    id: 2,
    skills: "CSS"
  },
  {
    id: 3,
    skills: "JavaScript"
  },
  {
    id: 4,
    skills: "React"
  },
  {
    id: 5,
    skills: "React Native"
  },
  {
    id: 6,
    skills: "Angular"
  },
  {
    id: 7,
    skills: "Vue"
  },
  {
    id: 8,
    skills: "Redux"
  },
  {
    id: 9,
    skills: "TypeScript"
  }
];

export default SlickData;

**_🧷 app.js_**
>```jsx
import React from 'react';
import DATA from 'data.js';

📂 data.json

🧷 data.json 위치

• public 폴더 > data 폴더 > data.json

🧷 data.json

{
  "data": [
    {
      "id": 1,
      "name": "yang",
      "age": 30
    },
    {
      "id": 2,
      "name": "kim",
      "age": 29
    }
  ]
}

**_🧷 app.js_**

> ```javascript
import React, { Component } from 'react'
>
export class Main extends Component {
  constructor(){
    super();
    this.state = {
      data: []
    };
  }
>
  componentDidMount = () => {
    fetch('http://localhost:3002/data/data.json')
      .then(res => res.json())
      .then(res => {
        console.log("firstly: ", res.data)
        this.setState({
          data: res.data
        }, () => {
          console.log("secondly: ", this.state.data)
        })
  })
}
>
  render() {
    console.log("thirdly: " , this.state.data)
    return (
      <div>
        hello
      </div>
    )
  }
}
>
export default Main

모든 리액트 컴포넌트에는 라이프사이클(수명 주기)이 존재한다. 컴포넌트의 수명은 페이지가 렌더링되기 전인 준비 과정에서 시작하여 페이지에서 사라질 때 끝난다.

프로젝트 진행 시 가끔 컴포넌트를 처음 랜더링할 때 어떤 작업을 처리해야하거나 컴포넌트를 업데이트하기 전후로 어떤 작업을 처리해야 할 수도 있고, 또 불필요한 업데이트를 방지해야 할 수도 있다.

이떄 컴포넌트의 라이프사이클 메서드를 사용한다.

참고로 라이프사이클 메서드는 클래스형 컴포넌트에서만 사용할 수 있다. 함수형 컴포넌트에서는 사용할 수 없고 그 대신에 Hooks 기능을 사용하여 비슷한 작업을 처리한다.

라이프 사이클 멧서드의 종류는 아래와 같이 총 아홉가지이다.

Will접두사가 붙은 메서드는 어떤 작업을 작동하기 전에 실행되는 메서드 이고, Did접두사가 붙은 메서드는 어떤 작업을 작동하기 후에 실행되는 메서드 이다.

이 메서드들을 우리가 컴포넌트 클래스에서 덮어 써 선언함으로써 사용할 수 있다.

라이프사이클은 총 세가지 즉 마운트, 업데이트, 언마운트 카테고리로 나눈다.

📍 마운트

DOM이 생성되고 웹 브라우저상에 나타나는 것이 마운트(mount)

Method	Description
constructor	컴포넌트를 새로 만들 때마다 호출되는 클래스 생성자 메서드 초기 state를 정할 수 있다.
getDerivedStateFromProps	props에 있는 값을 state에 넣을 때 사용하는 메서드 props로 받아온 값을 state에 동기화시키는 용도로 사용
render	우리가 준비한 UI를 랜더링하는 메서드
componentDidMount	컴포넌트가 웹 브라우저상에 나타난 후 호출하는 메서드 컴포넌트를 만들고 첫 헨더링을 다 마친 후 실행 최초 한 번 실행 이 안에서 다른 JS라이브러리 또는 프레임워크의 함수를 호출하거나 이벤트 등록, setTimeout, setInterval, 네트워크 요청 같은 비동기 작업을 처리하면 된다.

📍 업데이트

컴포넌트가 다음의 경우에 업데이트한다.

• props가 바뀔 때
• state가 바뀔 때
• 부모 컴포넌트가 리렌더링될 때
• This.forceUpdate로 강제로 렌더링을 트리거할 때

Method	Description
getDerivedStateFromProps	이 메서드는 마운트 과정에서도 호출되며, 업데이트가 시작되기 전에도 호출된다. props의 변화에 따라 state값에도 변화를 주고 싶을 때 사용한다.
shouldComponentUpdate	컴포넌트가 리렌더링을 해야 할지 말아야 할지를 결정하는 메서드 이 메서드는 true또는 false값을 반환해야 하며, true를 반환하면 다음 라이프사이클이 계속 실행되고, false를 반환하면 작업을 중지한다. 즉 컴포넌트가 리렌더링 되지않는다. 만약 특정함수에서 This.forceUpdate()함수를 호출한다면 이 과정을 생략하고 바로 render함수를 호출한다.
render	컴포넌트를 리렌더링한다. 라이프사이클 중 유일한 필수 메서드
getSnapshotBeforeUpdate	컴포넌트 변화를 DOM에 반영하기 바로 직전에 호출하는 메서드
componentDidUpdate	컴포넌트의 업데이트 작업이 끝난 후 호출하는 메서드

📍 언마운트

마운트의 반대 과정, 즉 컴포넌트를 DOM에서 제거하는 것이 언마운트(unmount)

Method	Description
componentWillUnmount	컴포넌트가 웹 브라우저상에서 사라지기 전에 호출하는 메서드

라이프사이클 메서드는 컴포넌트 상태에 변화가 있을 때마다 실행하는 메서드입니다.이 메서드들은 서드파이 라이브러리를 사용하거나 DOM을 직접 건드려야 하는 상황에서 유용하다. 추가로 컴포넌트 업데이트의 성능을 개선할 때는 shouldComponentdate가 중요하게 사용된다.

각 메서드 설명은 추가적으로 하겠다.

: Single Page Application : 말 그대로 한 개의 페이지로 이루어진 애플리케이션을 의미

기존에는 사용자가 다른 페이지로 이동할 때마다 새로운 html을 받아 오고, 페이지를 로딩할 때 마다 서버에서 리소스를 전달받아 해석한 뒤 화면에 보여주었다. 이렇게 사용자에게 보이는 화면은 서버 측에서 준비했다.

현재 웹에서 제공되는 정보가 무수히 많이 때문에 새로운 화면마다 서버 측에서 모든 뷰를준비한다면 성능상 문제가 발생할 수 있다.트래픽이 너무 많이 나오거나 불필요한 로딩이 많이 생기거 등등

그래서 리액트 같은 라이브러리 혹은 프레임워크를 사용하여 뷰 렌더링을 사용자의 브라우저가 담당하도록 하고, 우선 애플리케이션을 브라우저에 불러와서 실행시킨 후에 사용자와의 인터렉션이 발생하면 필요한 부분만 자바스크립트를 사용하여 업데이트해준다. 새로운 데이터가 필요하다면 서버 API를 호출하여 필요한 데이터만 새로 불러와 애플리케이션에서 사용할 수 있다.

SPA의 단점

앱의 규모가 커지면 자바스크립트 파일이 너무 커진다는 것 (페이지 로딩 시 사용자가 실제로 방문하지 않을 수도 있는 스크립트도 불러오기 때문) but 앞으로 배울 코드 스플리팅(code spliting)을 사용하면 라우트별로 파일들을 나누어 트래픽과 로딩 속도를 개선할 수 있다!

• ~~blabla 이해해야하는 부분. 서버 사이드 렌더링(server-side-rendering)를 통해 모두 해결할 수 있다.

Router

: 다른 주소에 다른 화면을 보여 주는 것을 라우팅이라고 한다. : 어떤 주소에 어떤 UI를 보여줄지 규칙을 정하는 작업 : 과거에는 서버에서 관리하는 로직이였지만 이제는 클라이언트 사이드에서 아주 간단하게 구현할 수 있다. : 한개의 웹페이지(html)안에서 여러 개의 페이지를 보여주는 방법이 Routing

리액트 라이브러리 자체에는 이 기능이 내장되어 있지는 않다. 그 대신 브라우저의 API를 직접 사용하여 이를 관리하거나, 라이브러리를 사용하여 이 작업을 더욱 쉽게 구현할 수 있다.

리액트 라우팅 라이브러리는 리액트 라우터(react-router), 리치 라우터(reach-router), Next.js등이 있다.

• props : properties(속성)
• 단어 뜻 그대로 컴포넌트의 속성값을 의미.
• props는 부모 컴포넌트로부터 전달 받은 데이터를 지니고 있는 객체
• props값은 해당 컴포넌트를 불러와 사용하는 부모 컴포넌트에서 설정할 수 있다.
• props를 통해 부모 컴포넌트로부터 자식 컴포넌트에게 state의 상태값, event handler를 넘겨줄 수 있다.

2. Props 객체

• 클래스형 컴포넌트에서 props, 즉 컴포넌트의 속성을 어떻게 정의할까?

// Parent.js

import React from 'react'; import Child from '../pages/Child/Child';

class Parent extends React.Component { constructor() { super(); this.state = { color: 'red' }; }

render() { return (

export default State;

- `Parent.js` 부모 컴포넌트이다.(기본적으로  app.js가 부모 컴포넌트이다.)
- 부모 컴포넌트 안에서 `<Child/>` 컴포넌트를 import 후 `<h1>` 태그 아래에 위치해주었다.
- 부모의 state에 있는 데이터를 `<Child />` 컴포넌트에게 props를 통해 넘겨보겠다.

>```jsx
// Parent.js
>
import React from 'react';
import Child from '../pages/Children/Children';
>
class Parent extends React.Component {
  constructor() {
    super();
    this.state = {
      color: 'red'
    };
  }
>
  render() {
    return (
      <div>
        <h1>Parent Component</h1>
                <Child titleColor={this.state.color}/>
      </div>
    );
  }
}
>
export default State;

• 자식 컴포넌트의 props 로 titleColor 속성을 생성했다.
• titleColor의 값으로 this.state.color, 즉 부모 컴포넌트의 state 객체 중 color 값을 전달해주었다.
• 이러한 방식으로 props를 통해 부모 컴포넌트 내부의 state 값을 자식 컴포넌트에게 전달할 수 있다.
• 그렇다면 <Child /> 컴포넌트 내부에서 전달 받은 props 데이터를 어떻게 사용하는지 확인해보자.

props 객체

• state 와 마찬가지로 컴포넌트의 props는 객체이다.
• 자식 컴포넌트인 Child.js 내부에서 props 객체는 어떻게 구성되어 있울까?

// Child.js

import React from 'react';

class Child extends React.Component { render() { // console.log(this.props);

return (
  <div>
    <h1 style={{color : this.props.titleColor}}>Child Component</h1>
  </div>
);

} }

export default State;

• <Child /> 컴포넌트 내부에 <h1> 태그가 있고 해당 태그의 글자 색상을 부모 컴포넌트의 state 로부터 전달 받은 데이터를 지정해주도록 한다.
• render 함수와 return 함수 사이에서 this.props 값을 console.log로 확인!
• 결과 확인 시 props 객체 안에 부모로 부터 전달받은 데이터가 key-value 형태로 담겨 있는 것을 확인할 수 있다.

Child Component

• 컴포넌트 내부에서 부모 컴포넌트로부터 전달받은 props 데이터를 사용하기 위해서는 state 객체에 접근하는 것과 마찬가지로 props 객체의 특정 키값, 즉 this.props.titleColor 이렇게 작성하면 된다!

3. Props & event

props를 통한 event handler 전달

// Parent.js

import React from 'react'; import Child from '../pages/Children/Children';

class Parent extends React.Component { constructor() { super(); this.state = { color: 'red' }; }

handleColor = () => { this.setState({ color: 'blue' }) }

render() { return (

- props 객체를 통해 state 데이터 뿐만 아니라 부모에서 정의한 event handler 함수도 넘겨줄 수 있다.
- props의 `changeColor` 값으로 Parent 함수에서 정의한 `handleColor` 함수 자체를 넘겨주고 있다.
- `<Child />` 컴포넌트에서 어떻게 props로 전달받은 `handleColor` 함수를 활용하는지 살펴보자.

>```jsx
// Child.js
>
import React from 'react';
>
class Child extends React.Component {
  render() {
        // console.log(this.props);
>
    return (
      <div>
        <h1 style={{color : this.props.titleColor}}>Child Component</h1>
                <button onClick={this.props.changeColor}>Click</button>
      </div>
    );
  }
}
>
export default State;

• <Child /> 컴포넌트 내부에 <button> 태그가 있다.
• 다음의 순서에 따라서 코드가 실행된다.
  • <button> 요소에서 onClick 이벤트 발생
  • 이벤트 발생 시 this.props.changeColor 실행
  • props 객체의 changeColor, 즉 부모 컴포넌트로부터 전달받은 handleColor 함수 실행
  • handleColor 함수 실행 시 setState 함수 호출 - state의 color 값을 'blue' 로 변경
  • render 함수 호출
  • <Child /> 컴포넌트에 변경된 state 데이터(this.state.color) 전달
  • this.props.titleColor 를 글자 색상으로 지정하는 <h1> 타이틀 색상 변경