Mapin

블로그 공지

Mapin — Sat, 6 Jul 2024 12:08:53 +0900

오랜만입니다.
FE와 JS를 한참 공부하고 제가 3학년때부터 약 1년정도 쓰기 시작했던 블로그였는데, 카카오 화제사건으로 인해 색인이 다 빠져버린 뒤로 블로그 쓸 맛이 안나서 velog로 이사를 갔습니다.

종종 제 글을 봐주시고, 또 저도 가끔 JS가 기억이 안날때 제 블로그를 뒤지기도 하는데요, 글을 하나 둘 씩 velog로 옮길 생각입니다.(JS ,TS를 다시 한번 보고싶거든요 !)

제 근황은 게임개발로 완전 돌아섰습니다. 여러가지 이유가 있지만, 제일 큰건 개인적으로 Web이 재미가 없어졌습니다. 웹을 하면서 프로그래밍을 잘한다라기 보단 점점 프레임워크의 고수가 되어가는(?) 그런느낌을 받았기 때문에... 점점 스프링이 없으면 코딩을 못할것 같은 느낌이 들고, 모든 사고 방식이 하나의 프레임워크에 의존적으로 변해가는 자신이 싫더라구요 .

제가 생각하는 엔지니어는 플랫폼이 변해도 적응해서 살아가는 그런 엔지니어라고 생각을 합니다. 하지만, 새로나오는 플랫폼은 기존 시장에서 엄청난 지분을 차지하는 것을 기반으로 나오기 때문에, 스프링을 하면서 저런 걱정을 한다는것 자체가 잘못됐다고 하실 수 있습니다. 저도 인정합니다.

게다가 하나의 프레임워크를 잘 다루고, 잘 이해하는것도 굉장히 어렵고 대단한 능력입니다. Spring은 20년동안 굳건하게 자리를 지켜왔기 때 문에 앞으로도 쭉 그 자리를 지켜나갈거라고 생각합니다. 하지만, 마음이 불편하니까 점점 흥미도 식고 , 이게 주위 사람들에 비해서 경쟁력도 떨어지게 되더라구요.

그래서, 4학년 2학기때 쯤에 뭘할까.. 여러분야를 생각해보다보니, 하나하나 로우 레벨부터 직접 만드는 재미는 게임만한게 없더라구요. 그리고, 지금까지는 진짜 재밌게 하고 있습니다!

[React/Optimize/Memo] Component를 분리하고, 마지막으로 React의 Memorization을 활용해보자!

Mapin — Thu, 10 Nov 2022 22:29:40 +0900

Component의 재사용성과 확장성을 갖기위해서 , 컴포넌트의 "합성"를 이용해서 , 좀 더 추상적인 컴포넌트를 만들고 혹은 재사용되는 컴포넌트를 만들고 구체화하는 방식으로 구현했습니다. 하지만, 그에 따른 부작용으로 컴포넌트간의 관계가 복잡해지고, 리렌더링 Issue가 생기기 시작했습니다.

현실적으로 FE 개발자에게 "생산성"은 빠질 수 없는 요소이기 때문에, 사실 이러한 이슈에 대해서 깊게 파고드는 것은 당장 필요한 사항은 아닐 수 있습니다. 세부적인 동작은 모두 React에 일임하고 , 우리는 그것을 사용하면 되니까요. 하지만,한번 깊이감있게 가져가보겠습니다. 재밌기도 하거든요!

Memo를 사용하기 전에, 독립적으로 나눌 수 있는 Component가 없는지 확인해보자 . (By 공식문서)

저보다 똑똑한 분들이 만든 React는 이미 훌륭한 라이브러리이고, 그 React만의 흐름을 잘 타서 활용하는것이 좋은 방법이지 , 이 React 만의 흐름을 깨는것은 바람직하지 못합니다. ~~(강아지가 뒤로가고 싶은데 제가 앞에서 목줄을 당긴다면, 힘이 많이 들겠죠!)~~

흐름을 거스르지 맙시다.

Memo가 "최적화"방법이라고 하지만, 최적화를 할 수 있는 상황에서 "최적화"이지 , 최적화를 하지 않아도 되는 상황에서 Memo를 사용하면 오히려, 얕은 비교를 실행하여 불필요한 추가연산이 필요해집니다. 생각해보면, Memo "동작이 모든 환경에서의 최적화 동작"을 했다면, 그냥 렌더링의 모든 과정을 memo로 구현하면 되지, 왜 그러지 않았을까요!

하지만, 저희는 컴퓨터공학도! 입증하려면, React의 코드를 직접 까봐야합니다. 직접 까보는것도 정말 좋겠지만, 우선 저의 시간을 아껴주실 선생님을 모시도록 하겠습니다.

https://blog.isquaredsoftware.com/2022/10/presentations-react-rendering-behavior/

React Advanced 2022 - A (Brief) Guide to React Rendering Behavior

A shorter look at how React rendering actually works

blog.isquaredsoftware.com

렌더링 Issue

React가 렌더링을 다시하는 경우는 4가지로 정해져 있습니다. "React"는 컴포넌트에 대한 전권을 갖고있습니다. 즉, React가 모든 상황을 통제합니다. React에서는 정확하게는 "렌더링에서 제외되는 조건"이 정해져있지만 , "렌더링이 제외되는 조건"보다는 렌더링이 되는 조건이 조금 더 직관적인것 같습니다.

1. State가 변경이 되었을 때

즉, setState가 실행되면 해당 State가 존재하는 컴포넌트는 리렌더링 되어집니다.

2."새로운" Props가 들어올 때

부모 컴포넌트로부터, 새 props가 들어오면, 자식 컴포넌트는 재렌더링 됩니다.

3. 기존 Props가 업데이트 되었을 때

부모 컴포넌트로 받은, props가 변경되면 props 값을 받은 자식 컴포넌트도 재렌더링 됩니다.

4. 부모 컴포넌트가 리렌더링 될 때

부모 컴포넌트가 재렌더링되면, 자식 컴포넌트도 모두 재렌더링 됩니다.

흔한 Counter 예시를 들어보겠습니다.

Counter .jsx

import React ,{useState} from "react"

function Inner(){
	console.log("Inner is Rendered!");
	return(
    	<div>
        	This is Inner!
        </div>
    )
}


function Counter(){
	const [count,setCount] = useState(0)
    console.log("Counter is Render"!)
    const handleCount = () =>{
    	setCount((prev)=>prev +1)
    }
	return(
    	<>
        	<button onClick={handleCount}></button>
        	<div>{count}</div>
            <Inner></Inner>
        </>
    )
}

버튼을 클릭하면 , 어떻게 될까요 ? 네 , 당연히 Counter가 리렌더링 되면서 , Inner가 리렌더링 됩니다.

왜냐하면, Counter 아래에 <Inner>이 있기 때문이죠! 그럼 , 이걸 어떻게 해결할 수 있을까요? 렌더링 되는 원인은 Inner가 Counter 속에 있기 때문입니다. 하지만, Rendering 위치는 변하면 안됩니다. Inner는 정확하게 {count} 아래에 있어야합니다.

우선, 가장 잘 알려진 Memo기능을 사용할 수 있겠네요!

Child Component는 매번 바뀌지 않기 때문에, Memo 해놓고, 렌더링 시켜주면 됩니다.

import React, { useState } from "react";

function _Child() {
  console.log("Child is Render!");
  return (
    <>
      <div>Hello!</div>
    </>
  );
}
const Child = React.memo(_Child);

function Parent() {
  const [count, setCount] = useState(0);
  const handleClick = () => {
    setCount((prev) => prev + 1);
  };
  console.log("Parent is Render!");
  return (
    <>
      <button onClick={handleClick}>+1</button>
      <div>{count}</div>
      <Child />
    </>
  );
}

export default Parent;

네 잘되네요!

하지만, 리엑트는 이렇게 권장하고 있습니다.

상위 컴포넌트에서 컴포넌트를 분리하고, Props로써 던져주라고요! 저도, 이게 더 좋은것 같습니다. 더 "리엑트"스럽네요!

Index.js

function Inner() {
  console.log("Inner is Rendered!");
  return <div>This is Inner!</div>;
}

root.render(
  <StrictMode>
    {/*<Parent lastChild={<Child />} />*/}
    <Counter props ={<Inner/>}/>
  </StrictMode>
);

의도했던대로, 하위 컴포넌트가 리렌더링 되지않습니다. 이건, 새로운 Props가 전달되지 않죠! 알아둡시다. 컴포넌트는 매번 새롭게 할당되지 않습니다.

컴포넌트 안에 컴포넌트를 생성하면 어떻게 될까요

function Parent(){
	function Child(){
    	return <div>Im Child!</div>
    }
    return <Child/>
}

Child는 Parent가 "렌더링"될 때, 새로운 컴포넌트가 생성이 되어지고, return ,즉 Render하는 부분에서 새로운 Component가 생성되어 넘어갑니다. 다른 말로하면 매번 새로운 Reference값이 넘어가는거죠. 이렇게되면, 아래에 있는 모든 DOM노드들은 새롭게 다시 그려지는 비효율이 발생합니다. HOC와 다릅니다 . HOC는 Component 객체를 넘기는거지, <Child>즉, 렌더를 하는게 아닙니다.

절대 Never , Ever 컴포넌트 안에 컴포넌트를 생성하는 일이 없어야 한다고 Mark아저씨는 이야기 합니다.

아래와 같이, 분리를 하는게 좋습니다.

function Child(){
	return<div>Hi</div>
}

function Parent(){
	return <Child/>
}

한가지 예시는 아쉬우니까, TodoList에 뭔가를 추가하게 될 때 최적화를 생각해볼까요! (댓글이라고 생각해도 재밌겠네요.)

TodoList가 간단하게 있다고 하고, 2초마다 지속적으로 TodoList가 하나씩 추가되는 Interval을 주었다고 해봅시다.

TodoList.jsx

import React from "react";
import TodoItem from "./Todoitem";

const Todos = [
  { id: 1, doing: "wash" },
  { id: 2, doing: "Coffee" },
  { id: 3, doing: "Yes" },
  { id: 4, doing: "No" },
  { id: 5, doing: "Swimming" }
];

function TodoList() {
  const [Todo, setTodo] = React.useState(Todos);
  
  React.useEffect(() => {
    const IntervalId = setInterval(() => {
      setTodo((prev) => [
        ...prev,
        { id: `${prev.length + 1}`, doing: "newJob" }
      ]);
    }, 2000);
    return () => clearInterval(IntervalId);
  }, []);
  
  return (
    <div>
      {Todo.map((items) => (
        <TodoItem key={items.id} props={items.doing} />
      ))}
    </div>
  );
}

export default TodoList;

TodoItem .jsx

function TodoItem({ props }) {
  console.log("TodoItem is Render!");
  return (
    <>
      <div>{props}</div>
    </>
  );
}

export default TodoItem;

TodoItem은 상위 TodoItem.jsx의 state가 바뀌기 때문에, 리렌더링이 되고, 그에 따라서 자식인 TodoItem 아래의 모든 자식들이 ReRendering 됩니다. 렌더링 되는 횟수를 보시면 어마무시합니다.

어떻게 최적화 시킬 수 있을까요 ? 이럴 때도, HOC를 설계해서 분리하고 해서 최적화를 해줄 수 있습니다만, 생각보다 쉬운듯 어렵습니다. 저는 솔직히 아이디어가 떠오르지 않습니다. 그래서, 저는 Memo를 써주겠습니다.

이때, props로써 , 함수가 오는 상황이 있을 수 있습니다.

import React from "react";
function TodoItem({ props }) {
  console.log("TodoItem is Render!");
  return (
    <>
      <div>{props}</div>
    </>
  );
}

export default React.memo(TodoItem);

함수는 매번 렌더링 될 때마다, 새로운 ref를 생성하므로, Memo가 올바르게 동작하지 않습니다. 따라서, useCallback이라는 또 다른 Hook을 사용해서, 최적화 시키면 됩니다!

[React/Composition] 리액트 컴포넌트의 확장(React Composition)

Mapin — Mon, 7 Nov 2022 12:17:48 +0900

React를 잘 사용하기 위해서는 , 컴포넌트 설계능력이 필수적이게 된다. 이건 경험적인 요소라 많이 쓸수록 자연스럽게 늘어나겠지만, 한번 의식적으로 확장을 해보자!

웹 환경에서의 재사용

웹에서는 생각보다 반복적인 작업이 많다. 예를들어, 아래와 같은 Modal 창을 구현한다고하자. Modal창은 구체화되서, "로그인창"이 될 수도 있고, "상세정보를 보여주는 Modal창"이 될 수도있다. 물론 , 각각 폴더로 분리해서 각각의 Component로 구현해도 무방하다. 하지만, 이번에는 "의도적"으로 Modal창을 추상화시키고, Login창과 Detail창을 구현해보도록 하겠습니다. 마치 "상속"과 비슷하지 않나요!

React에서는 상속대신 , Composition

https://reactjs.org/docs/composition-vs-inheritance.html

Composition vs Inheritance – React

A JavaScript library for building user interfaces

reactjs.org

React에서는 상속대신 , 컴포넌트끼리의 합성을 권장하고 있습니다. 저는 위의 예시처럼, Modal창을 이용해서 여러가지 Modal을 구체화시켜보겠습니다. Title과 Description을 갖고있는 Modal이라는 틀에 , 내가 구현한 JSX를 주입하는 식으로 구현해보겠습니다.

초기버전

Modal.jsx

export default function Modal(props) {
  return (
    <div className="modal">
      <div className="modal_wrapper">
        <div className="title">TEST</div>
        <div className="description">TEST</div>
        {props.children}
      </div>
    </div>
  )
}

Modal이라는 창안에 , props.children의 JSX를 그대로 던져주면서, 더 큰 "확장성"을 노려볼 수 있게 되었습니다. LoginModal창을 간단하게 만들어보겠습니다.

LoginModal.jsx

export default function Login(){
  return(
    <Modal>
      <form>
        <label htmlFor='id'>ID:</label>
        <input id="id"></input>
        <br></br>
        <label htmlFor='pw'>PW:</label>
        <input id="pw"></input>
      </form>
    </Modal>
  )
}

흠.. 뭔가 아쉽습니다. 제가 원한건 , Title과 Description도 , 서비스의 종류에 따라 바꾸고 싶습니다. modal을 더 확장시켜보겠습니다.

1차 확장시킨 Modal

Modal.jsx

export default function Modal(props) {
  return (
    <div className="modal">
      <div className="modal_wrapper">
        <div className="title">{props.title}</div>
        <div className="description">{props.description}</div>
        {props.children}
      </div>
    </div>
  )
}

Title과 description도 props.title,props.description으로 확장을 했습니다. 이제, Login Modal에서 Login을 줘볼까요!

Login.jsx

export default function Login(){
  return(
    <Modal title="Login" description="Login">
      <form>
        <label htmlFor='id'>ID:</label>
        <input id="id"></input>
        <br></br>
        <label htmlFor='pw'>PW:</label>
        <input id="pw"></input>
      </form>
    </Modal>
  )
}

이제, Detail 모달창을 만드려면 어떻게하면 될까요?

DetailModal.jsx

import React from 'react'
import Modal from './Modal'
export default function DetailModal() {
  return (
    <Modal title="Detail" description="디테일창">
      <div>디테일 창입니다~</div>
      <div>사진사진~!</div>
    </Modal>
  )
}

App.js에서 DetailModal을 부르기만하면 됩니다!

2차로 확장시켜보자

Modal 창은 보통, 버튼으로 구현이 됩니다. 각각의 버튼을 눌러서, Login -> Login Modal을 뜨게하고, Detail -> Detail을 뜨게만들면되겠죠! 간단하게 , App.jsx에서 State를 정해준 뒤에, Modal.jsx에 열려있는지 , 아닌지에 따라서, 화면을 바꿔주는 연습을 해보겠습니다.

Flow : 메인화면 -> 버튼클릭 -> Modal창들 보여주기 -> 취소시 원래화면으로 복귀

App.jsx

function Dimmed(){
  return (
    <div className="dimmed">
    </div>
  )
}
function App() {
  const [LoginOpen,setLoginOpen] = React.useState(false)
  const [DetailOpen,setDetailOpen] = React.useState(false)

  const handleDetailModal = () =>{
    setDetailOpen((prev)=>!prev)
  }
  const handleLoginModal = () =>{
    setLoginOpen((prev)=>!prev)
  }
  return (
    <div className="App">
      <button onClick={handleLoginModal}>로그인창</button>
      <button onClick={handleDetailModal}>상세창</button>
      {/*로그인창 클릭시*/}
      {LoginOpen ? <Login handler={handleLoginModal}/>:null}
      {/*상세창 클릭시*/}
      {DetailOpen? <DetailModal handler={handleDetailModal}/>:null}
      {/*Dimmed 처리*/}
      {LoginOpen || DetailOpen ? <Dimmed></Dimmed>: null}
    </div>
  );
}

Login.jsx

props가 점점 늘어나고 있네요! 흠.. 좋지않은 징조입니다. 태그가 Heavy하면 나중에 좋지 않거든요!

import React from 'react';
import Modal from './Modal';

export default function Login(props){
  return(
    <Modal title="Login" description="Login" handler={props.handler}>
      <form>
        <label htmlFor='id'>ID:</label>
        <input id="id"></input>
        <br></br>
        <label htmlFor='pw'>PW:</label>
        <input id="pw"></input>
      </form>
    </Modal>
  )
}

Modal.jsx

button에 드디어 handler를 전달했습니다. 컴포넌트를 타고타고 들어가는게 너무 번거롭네요 .

import React from 'react';
import '../../css/modal.css';

export default function Modal(props) {
  //console.log(props)
  return (
    <div className="modal">
      <div className="modal_wrapper">
        <div className="title">{props.title}</div>
        <div className="description">{props.description}</div>
          {props.children}
          <button className="button" onClick={props.handler}>취소</button>
      </div>
    </div>
  )
}

잠깐잠깐! 뭔가, 더 번거롭고, 복잡해진 느낌이 들지 않나요 ?

저희는 재사용성을 위해서,Modal을 컴포넌트화 시키고, Login,Detail에 따라서 다른 view를 구현해줬습니다. 그리고, Modal은 어떤 버튼을 클릭한 후, 해당 Modal창을 띄우는게 일반적이라서, 버튼을 기반으로 onClick으로 이벤트를 구성했습니다.

하지만, "취소"버튼은 최하위인 Modal Component에서 해줘야했습니다. 그런데, 부모의 상태를 자식이 알려면, props를 drilling 해줘야합니다. 지금은 1~2depth정도 밖에 되지 않습니다만, 웹 페이지는 수많은 기능을 갖고있고, 수많은 wrapper와 component를 갖고있을 수 있습니다. 즉 , 6~7depth까지도 가능할 수 있다는 이야기죠.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

왜 Drilling이 생길 수 밖에 없을까 ?

데이터 흐름을 따라가보면 됩니다. App.js에서 해당 창을 띄울지 안띄울지 판단 -> 자식 컴포넌트에서 , 부모 컴포넌트 State를 조작해야함 -> State가 false가 되면, 원래 창으로 복귀

재사용성을 위해 컴포넌트를 분리한다는 이야기는 , Component -> Component 와 같이, 부모-자식관계가 끊임없이 생기는 것입니다. 즉 , 추상화를 시키니까 State 관리가 힘들어졌습니다. 그리고, React가 추구하는 단방향성 데이터 흐름이 깨졌습니다. 이래서, State를 관리하기 위한 Redux, Recoil 등의 상태관리가 생기게 된 것입니다! (Redux -> Flux 모델)

다음 글에서는 React Component의 상태관리 Redux, useReducer 등을 공부해보겠습니다.

[JS/비동기/프로미스] JavaScript Promise에 대해서

Mapin — Tue, 1 Nov 2022 12:39:55 +0900

오늘은 Front-End의 중요한 영역인 Data Fetching 에서 사용되는 Promise 문법에 대해서 알아보겠습니다.

Promise

프로미스는 비동기 작업의 최종 완료 또는 실패를 나타내는 객체입니다. - MDN

promise는 ES6에서 나온 새로운 기능으로, 어떤 "문제점"을 해결하기 위해서, 나온 기능입니다. 즉, 그 문제점이 뭐냐를 이해하면 Promise의 정체를 밝힐 수 있을 것 같습니다.

Promise의 등장배경

작은 규모의 웹에서는 비동기 요청이 많지 않아서, 각 비동기 요청간의 의존성이 크지 않았다고 합니다. 웹이 발전하고, 다양한 플랫폼으로 진출하면서 , 단순히 callback만으로는 모든 상태를 통제하기 어려웠다고 합니다. 예를들어, 로그인 과정에서 서버와 통신과정이 필요합니다. 세션 로그인방식이라고 생각해보겠습니다.

로그인 과정

[Client]

로그인 페이지에서, 아이디, 비밀번호를 서버로 POST 합니다.

[Server]

서버는 기존에 회원가입을 한 사람이면, 서버에서 세션아이디를 만들어줍니다.
세션 아이디를 담을 변수와 DB공간을 마련해서, 거기에 저장합니다.
쿠키 안에 Portion해서, Request한 브라우저에 쿠키를 Push해줍니다.

[Client]

mypage(로그인 해야만 들어갈 수 있는, 회원페이지)를 요청합니다.

[Server]

서버는 해당 요청을 받으면 일단 로그인 했는지 여부를 확인해야 함
쿠키에 세션 아이디가 포함되어 있는지 검사
만약, 있으면 통과시켜주고 그 과정에서 회원의 이름, 나이, 성별 등의 DB정보가 필요하면 꺼내옴

이때, Client의 동작은 연속적으로 일어나야하는걸 알 수 있습니다. 즉, client ->아이디, 비밀번호를 Post 한 뒤 쿠기가 Push되면 mypage를 요청합니다. 이때, 브라우저가 멈추면 안되기 때문에, 서버와의 통신은 비동기적으로 일어나게 됩니다. 즉, 비동기가 연속적으로 일어나야 합니다.

연속적인 비동기의 문제점(Callback Chain)

비동기가 연속적으로 일어난다는 이야기는 , callback을 연속적으로 던져줘야했다는 이야기입니다. 그리고 callback함수로 구현되어지는 비동기 함수는 JS의 실행흐름에 의해서, 따로 분리가 될 수 없습니다. 왜냐하면, 결과값을 받는 순간을 예측할 수 없기 때문입니다. 즉 , 아래와 같이 코드를 짜야한다는 이야기입니다.

UserLogin(()=>{
	//로그인을 한 뒤에, 연속적으로 mypage를 요청해야한다.
    UserLogin(()=>{
    
	})
},1000)

위와 같이 중첩에 중첩에 중첩을 계속하게되면, 유명한 "콜백지옥"이 완성됩니다.

가독성도 물론 엄청 떨어지지만, 근본적인 원인은 비동기 안에 연속적으로 일어나는 ,또 다른 비동기 로직들을 분리할 수 없던게 문제였습니다. 그래서, 비동기를 요청한 뒤 , 결괏값을 기억하고 있는 방식으로 구현하기로 했습니다.

즉 비동기 함수 안에 연속적으로 일어나는 로직들을 분리할 수 있는 방식이 바로 Promise입니다. 그래서, promise는 비동기 요청을 해놓고, 나중에 then()을 통해서, 결과값을 받을 수 있게 됩니다. 이 말을 다르게 해볼까요 . "미래의 어떤 시점에 결과를 제공하는 약속을 하겠다" ==> 그래서, Promise 입니다.

유명한 callbackHell을 Promise로 바꾸어보기

로그인하는 예제입니다. 서버가 없기 때문에,setTimeout을 이용
아래와 같이, UserStorage 객체가 준비되어있습니다.

class UserStorage{
  loginUser(id,password,onSuccess,onError){
      setTimeout(()=>{
        if(id==="admin" && password ==="root"){
          onSuccess(id)
        }else{
          onError(new Error("not Found!"))
        }
      },2000);
  }
  getRoles(user,onSuccess,onError){
    setTimeout(()=>{
      if (user ==="admin"){
        onSuccess({name:"admin",role:"admin"});
      }else{
        onError(new Error('no Access'));
      }
    },1000)
  }
}

로그인 과정 분석

login했을 때, 성공시에 해당 유저의 권한을 부여해야합니다. 따라서, onSuccess라는 callback을 던져주는 과정이 필요합니다.
가독성을 높이기 위해서 , 주석을 달아놨습니다. 하지만, 콜백안에 또 콜백이 있고, 또 콜백이 있고 .. 가독성이 떨어지며 , 프로그래머도 헷갈리기 시작합니다.
프로그래머가 "헷갈리기 시작"한다 => 기본적으로 에러날 확률이 높다. 뿐만 아니라, "유지보수"하기가 매우 힘들고, 확장성을 갖기가 힘들다. => 현재와 같은 고도화된 서비스를 넣기에 충분하지 않다. => 돈이 되지 않는다. => "확장성"을 확보하지 않은 코드는 필요가 없다.=> ~~이런 코드를 짜는 사람은 필요가 없다(극단적이지만)~~
즉, 안티 패턴인거죠!

const userStorage = new UserStorage()

const id = prompt("아이디 입력")
const password = prompt("비밀번호 입력")


userStorage.loginUser(
	id,
    password,
    //성공 callback
    (user)=>{
    	userStorage.getRoles(
        user,
        //로그인 성공 한뒤, 유저 권한 획득 callback
        (Userdata)=>{
        	alert(`${Userdata.name}님 안녕하세요. ${Userdata.role}권한으로 입장했습니다.`)
        },
        //로그인 한뒤, 유저 권한 획득 실패 callback 
        (error)=>{
        	console.log("로그인 한뒤, 유저 권한 획득 실패 callback ")
        },
        )
    },
    //error callback
    (error)=>{
    	console.log("로그인 실패")
    },
)

위와 같은 문제점을 해결하기 위해서 Promise가 등장했습니다. Promise는 비동기처리를 미리 약속해놓고, 결과값은 "나중에 then을 통해서 너가 원할 때 써라" 입니다.

Promise의 WorkFlow

Promise는 객체입니다. 따라서, new 연산자를 통해서 호출이 됩니다. 내부에 executor이라는 callback함수를 갖고있습니다. executor또한, resolve,reject라는 callback을 갖고있습니다. "콜백 지옥을 해결한다면서 또 콜백을 중첩시키면어쩌자는거야!"라고 할 수 있지만, 진정하고 들어주세요

const p1 = new Promise((resolve,reject)=>{})

Promise의 Executor은 선언되자마자 실행됩니다. 왜냐하면, Promise또한 객체니까요! new Promise()는 생성자입니다.

위의 로그인 코드를 Promise로 바꾸는 연습을 해보겠습니다.

loginUser

 loginUser(id, password) {
 	//callback이 아닌, promise를 리턴해준다.
    return new Promise((resolve, reject) => {
      setTimeout(() => {
        if (id === "admin" && password === "root") {
          resolve(id);
        } else {
          reject(new Error("error!"));
        }
      }, 2000);
    });
  }

getRoles

  getRoles(user) {
    return new Promise((resolve, reject) => {
      setTimeout(() => {
        if (user === "admin") {
          resolve({ name: "admin", role: "admin" });
        } else {
          reject(new Error("no Access"));
        }
      }, 1000);
    });
  }

실행

const userStorage = new UserStorage();

const id = prompt("Eneter your id ");
const password = prompt("Enter your pw ! ");

//then으로 chainning 가능!!
userStorage
  .loginUser(id, password)
  .then(userStorage.getRoles)
  .then((data) =>
    alert(`${data.name}님 환영합니다.${data.role}권한으로 접속했습니다.`)
  )
  .catch(console.log);

하지만, Promise 또한, 작성을 하다보면, then chainning도 엄청 길게 생길 수 있고, promise가 promise를 반환하는 또 ,Promise 지옥이 생길 수 있습니다. Then에서도 Promise를 넘겨주면, 다음 then에서 resolve된 값을 받을 수 있거든요!

Async Function의 등장

Promise를 반환해주는 Producer 역할을 하는 함수를 흔하게 작성합니다. 이와 같은 함수들은 async function으로 작성이 가능합니다. 즉, async 함수 => Promise를 Return 해주는 함수입니다.
await은 async 함수 내에서 사용할 수 있는 키워드로, Promise의 then역할을 하게 됩니다. 코드의 실행 순서가 오른쪽에서 왼쪽으로 바뀐다고 이야기도 하는데, "delay(3000)이 실행될 때 까지 기다려라!"라는 이야기 입니다.

// 실행을 ms 만큼 지연시키는 delay
function delay(ms){
	return new Promise((resolve,reject)=>{
    	setTimeout(resolve,ms)
    })
}

async getApple(){
	await delay(3000)
	return "Apple"
}
/* Promise 
function getApple(){
	return delay(3000).then(()=>"Apple");
}
*/
async getBanana(){
	await delay(3000)
    return "banana"
}
/* Promise 
function getbanana(){
	return delay(3000).then(()=>"Banana");
}
*/

pickFruits().then(console.log);

Async Function의 편리함

위와같은 Promise(Async 함수)들이 있을 때, 모든 Promise를 논리적으로 한 동작으로 묶어야할 필요가 있을 수 있습니다.

예를들어, "사과를 딴 뒤에, 바나나를 따고, 그 둘을 출력한다" 와 같이, 이전 Promise의 scope가 필요할 때, 유용하게 쓸 수 있습니다.

async function AsyncpickFruits(){
	const apple = await getApple()
    const banana = await getBanana()
    return `Fruits: ${apple} , ${banana}`
	
}
/* Promise 
function pickFruits (){
	return getApple()
    .then((apple)=>{
    	return getBanana().then(banana=>`Fruits: ${apple} , ${banana}`)
    })
}
*/

병렬적으로 처리하기

흠..근데, 굳이 사과를 따고나서, 바나나를 따야할까요? 아니죠! 사과와 바나나는 동시에 딸 수 있습니다. promise.all 혹은 ,promise.allSettled와 같은 메소드를 이용해서, promise들을 한꺼번에 처리할 수 있습니다!

function pickAllFruits(){
	return new Promise.allsettled([getApple(),getBanana()])
	.then((fruits)=>fruits.join(','))
}
pickAllFruits().then(console.log)

3줄 정리

Promise는 비동기 상태를 "값"으로 다룰 수 있게 한다는 점이 제일 큰 장점이다.
"값"으로 다룬 다는 이야기는 변수에 담고, 매개변수에도 넣을 수 있는 1급 객체로 다룬다는 이야기고, 이건 내가 원할 때, 비동기 상태의 값들을 쓸 수 있다이야기 입니다.
여러개의 Promise를 묶어서, 병렬적으로 처리할 수도 있고, Async/await를 써서, Promise의 then chain지옥을 빠져나갈 수도 있다.

다음 글은, Promise의 장점을 활용하여 비동기 상태를 여러 함수를 합성하는 걸 보겠습니다. 그리고, 그걸 가능하게 하는 Monad의 개념에 대해서 간단하게 알아보겠습니다!

refer

제로초님 JS고급강의

엘리님 JS 비동기 강의

[Python/Django/Framework] Django , WebFramwork에 대해서

Mapin — Thu, 27 Oct 2022 23:24:40 +0900

Airbnb 클론코딩을 진행하면서, 다양한 개념에 대해서 알게되는것 같습니다! 오늘은 WebFrameWork 장고에 대해서, 배운걸 기록해보겠습니다.

WebFramWork

FrameWork는 "모든 레고가 준비되어 있는 큰 레고상자"라고 생각하면 저는 더 와닿았습니다. 특히, "조립법"까지 모두 정해져있는 레고상자입니다. "FrameWork"는 정해진 사용법이 있다는게 라이브러리와 큰 차이점인 것 같습니다.

코드 내에서의 차이점을 보자면, 라이브러리는 프로그래머가 가져와서 쓰고 , FrameWork는 프로그래머가 작성한 코드를 가져갑니다.~~(이게 무슨말이야)~~

즉, 라이브러리는 라이브러리 내의 일종의 함수를 내가 import해서 활용하는 측면이 강하다면, FrameWork는 이미 활용법이 정해져 있는 함수와 필드값내에서, 그 함수에 프로그래머가 직접 코드를 작성하고, 그 코드를 기반으로 동작한다는 이야기 입니다. 프레임워크를 직접 수정할 수 있지만, 절대 권장되지 않습니다. 왜냐하면, 장고 프로젝트를 실행하기 위해서는 Django가 필요한데 , 프레임워크를 수정한 상태라면, 설치되는 PC의 Django 또한 Custom되어야하기 때문입니다.

Django

Django는 Python으로 이루어진 FrameWork입니다. Django는 다양한 기능들을 프로그래머가 직접 구현할 필요없이 , 이미 내제되어 있는 기능들이 많습니다. Django는 객체지향을 기본으로 하는 FrameWork입니다.

Django Project의 구성

Django는 Project 1개에 여러가지 App들이 결합되는 형태로 구성이 됩니다. App은 Data와 Logic이 묶인 하나의 모듈이라고 생각하면 됩니다. 그리고, Django는 Setting.py를 통해서 , App들을 서로 연결하고 하나의 서비스로 만들어줍니다.

manage.py는 Terminal에서 "Django 명령어가 실행될 수 있게끔" 해주는 파일입니다.

명령어

django-admin startproject [name] [directory]

Django App의 구성

App을 생성하면, model, Admin, Migration,view 등이 생성되게 됩니다. Data는 Model에서 담당합니다. DB와 연동을 위해서 Migration을 생성하고, Migrate 작업이 필요합니다. 이때, 생성되는 Migration은 Model에 정의된 코드를 기반으로 생성되게 됩니다. Admin은 장고에서 기본적으로 제공해주는 Admin page를 커스텀할 수 있게 해줍니다. View는 저희가 아는 그 View(화면)입니다.

* Migration

Application을 개발하다보면, DataBase의 스키마를 변경할 일이 빈번하게 발생합니다. 예를들어, 새로운 서비스를 추가하기 위해서, 테이블의 컬럼(Atrribute)를 추가하거나, 다른 테이블을 생성하거나, 심지어 데이터가 현재의 도메인 구조와 다르다면, 모든 데이터 값을 수정해야 할 수도 있습니다. (기존에 있던 데이터들은 새로운 Column이 생기는 경우) 이러한 과정을 Migration이라고 합니다. 즉, 서버에서 DB로 접근하여 DB를 Control하는 과정이라고 볼 수 있습니다. 장고에서는 모델수정(Data) -> make migration -> migrate -> DB 적용의 순서입니다.

좋은 아키텍쳐, 좋은 설계가 왜 중요한지 점점 더 알게되는 것 같습니다. 데이터의 무결성, 데이터의 중복방지 등, 데이터베이스 설계에 대한 공부도 꾸준히 해야할 것 같습니다.

[python/poetry/Django] Python Webproject 셋팅하기 -1

Mapin — Mon, 24 Oct 2022 14:32:50 +0900

클론코딩을 진행하면서, ToyProject들을 진행해보려고 합니다.큰 마음을 먹고, 백엔드부터, 프론트까지 다 해볼 수 있는 노마드코더님의 Airbnb클론코딩을 질렀습니다!

기본적인 강의 내용을 자세하게 포스팅 하기보단, 제가 부딪혔던 문제들을 위주로 ,기록해보려고 합니다!

Python Project 설정

Poetry 다운로드

패키징 시스템 중 하나입니다. 각각의 프로젝트에 대해서, 독립적인 개발환경을 만들어줍니다.
프로젝트에 따라서, 필요한 환경이 다르기 때문에, 독립적인 개발환경이 필요하게 됩니다.

Poetry를 다운로드하면, 환경변수를 등록해주어야 합니다. 설치를 확인하기 위해, poetry --version을 입력하면, 실행할 수 없는 명령어라고 나올 수 있습니다.

환경변수 설정하기

[STEP1] 윈도우키를 눌러, 고급 시스템 설정보기를 검색합니다.

[STEP2] 고급 탭을 선택한 후, 환경 변수를 선택합니다.

[STEP3] 환경변수(N).. 클릭 후, 시스템 변수에 Path를 클릭한 후, 편집을 누릅니다.\

[STEP4] 새로 만들기(N)를 클릭 한 후, Poetry Docs에서 안내하고 있는 경로를 등록해줍니다.

경로가 2개가 있는데, 하나씩 등록해보고, poetry --version을 쳐보시면 됩니다.

%APPDATA%\Python\Scripts
%APPDATA%\pypoetry\venv\Scripts\poetry

다 완료되면, 아래와 같이 version이 뜨게 됩니다.

가상환경(개발환경)에 필요한 패키지 다운받기

poetry 연결이 되었으면, poetry도 init(초기화)를 통해서, .toml 파일을 만들어줘야합니다.

poetry init

poetry init하면 설정들을 할 겁니다. 본인의 필요에 맞게 설정하면 됩니다. toml이 생성이 성공적으로 되었으면, django를 다운받아줍니다.

poetry add django

poetry shell로 접속하기

poetry는 가상환경이기 때문에, poetry안에 접속해서 django를 실행해야 합니다. 따라서, poetry shell이라는 명령어를 실행한 뒤, django를 실행해야합니다.

poetry shell

poetry shell로 접속이 되었으면, django-admin으로 django가 성공적으로 동작하는지 Test합니다.

* Error

여기서, 권한이 없다고 오류가 날 수 있습니다. powershell에서 ExcutionPolicy가 Restricted로 설정되어 있어서 그렇습니다. (Restricted가 기본값입니다) 권한은 바꿔주면 되겠죠? 저희는 admin이니까요!

Policy는 아래와 같이 준비되어 있습니다. 원하는걸로 하면 되지만, 저는 RemoteSigned를 하겠습니다.

Restricted : PowerShell의 실행 권한 정책 중 기본적으로 적용되어있는 옵션. ps1 스크립트 파일을 로드하여 실행할 수 없는 정책
AllSigned : 신뢰된 배포자에 의해 서명된 스크립트만 실행 할 수 있는 정책
RemoteSigned : 로컬 컴튜퍼에서 본인이 생성한 스크립트만 실행 가능 또는 인터넷에서 다운로드 받은 스크립트는 신뢰된 배포자에 의해 서명된 것만 실행 가능한 정책
Unrestricted : 제한 없이 모든 스크립트 실행 가능한 정책
ByPass : 어떤 것도 차단하지 않고 경고 없이 실행 가능한 정책
Undefined : 정책 적용 안함

Set-ExecutionPolicy RemoteSigned

[git/git-hub] 개발한 결과물을 관리해보자(Git)

Mapin — Mon, 24 Oct 2022 11:48:11 +0900

Github을 지속적으로 썻지만, git을 CLI로 쓴적은 없습니다. 항상 github 홈페이지에 들어가서 페이지가 완성이 되면, 업로드하는 방식으로 개발을 자주 했다. 혹은 UI tool(Github Desktop)을 이용해서 그냥 commit을 하는 형태로 했다.

나의 스킬을 늘리기 위해서, Cli 환경으로 git을 이용해보는 연습을 해보려고 한다. Git hub에 흔적을 남기면서, 이제 프로젝트를 위한 준비단계라고 생각하면 좋을 듯합니다.

Git

Git은 분산버전관리 시스템입니다. 여러 대의 컴퓨터(여러 명의 프로그래머)에서 하나의 프로젝트에 대해서 "협업"을 위해 유용하게 사용할 수 있는 tool입니다. 그림으로 이해를 해보자면, 아래와 같습니다.

컴퓨터 A,B,C가 모두 같은 작업물에 접근하여, 업데이트 할 수 있게끔 해주는 Tool입니다.

Git 설치하기

설치 자체는 간단하다. git 공식홈페이지에 접속해서, OS에 맞게 다운로드하면 됩니다.

Git Cli 환경으로 다루기

Git을 사용하는 방법에는 2가지 방식이 있습니다. Cli(Command Line)을 이용하는 방법 , UI Tool(SourceTree와 같은)을 이용하는 방법이 있습니다. VScode의 Terminal을 이용할 거기 때문에, Cli 환경을 이용하도록 하겠습니다.

* Tips

Mac OS를 이용하신다면, Mac에 내장되어있는 Terminal을 그대로 쓰시면 됩니다. Window유저시라면, cmder를 다운로드해서 사용하시는걸 추천드립니다. 하지만 , 기본 powershell , cmd를 쓰셔도 무방합니다.

Git 초기설정

1. git에 연결할 디렉토리에 .git 파일을 만들어줍니다.

git init

git파일을 초기화 해주는 명령어입니다. 해당 경로에서 위의 명령어를 실행하면, git파일이 생성됩니다. powershell보다는 저는 cmder이 편해서, 이제 Cmder을 쓰도록 하겠습니다.

powershell에서 입력

Cmder에서 git 생성 확인

2. 각 OS에 맞게 , 문자열 처리에 대한 옵션을 설정해줍니다.

Windows

git config --global core.autocrlf true

위 명령어는, 문자열 처리 방식에서 OS마다 약간의 차이가 있기 때문에, Mac에서 업로드한 내용, Window에서 업로드한 내용이 각각의 다른 운영체제에서 볼 때는 달라질 수 있기 때문에, 자동으로 처리해주는 옵션입니다.

혹시, git 파일을 Editor로 열어서, 수정하고 싶다면 아래와 같은 방법이 있을 수 있습니다. (command line으로는 여러가지 설정을 하기는 힘들고 , 여러가지 설정을 한꺼번에 하고 싶은 경우)

git config --global -e

[core] , [user],[filter] 등등의 값이 있습니다. 예를들어, 위처럼 autocrlf 속성을 true로 하고 싶다면, core 옵션에 autocrlf 속성을 넣고, true로 해주면됩니다.

3. git 파일 자체를 삭제하기

rm -rf .git

rm -rf는 터미널 명령어 입니다.

Git의 WorkFlow

git은 일정 WorkFlow에 따라서 , Version Control을 합니다. 따라서, 이 WorkFlow를 제대로 이해해야, Git을 활용할 수 있습니다.

git 상태 확인 명령어

git의 workFlow에 따라, 각각의 파일들이 어떻게 진행되고 있는지 알고싶을 수 있습니다. 그럴 때 이용할 수 있는 명령어입니다.

git status

option으로 -s를 이용하면, 짧게 볼 수 있습니다. A(Add) M(Modified)등 여러 정보가 함축적으로 나타납니다.

내 컴퓨터의 저장공간 (Local 저장공간)

Working Directory

내 컴퓨터의 작업공간 입니다. git이 tracking 하거나 tracking하지 못한 파일들이 있는 공간입니다. tracking은 이미 git이 관리하고 있는 파일들이고, untracked는 새로 생긴 파일 또는, git이 관리를 하지 않고 있는 파일을 이야기 합니다.
git add 명령어를 통해서, tracked 할 수 있습니다.

git add [파일명]

이때, Git에 포함하고 싶지 않은 파일들이 있을 수 있습니다. (module 파일이라던지, log 파일이라던지, 등등)

eslint,prettier에도 ignore파일이 있듯이, git에서도 .gitignore파일을 준비해놨습니다. 등록하지 않고 싶은 파일을 gitignore파일에 등록해놓으면됩니다.

예를들어, 나는 module폴더는 제외하고 싶으면, gitignore파일에 /module을 등록해놓으면 됩니다.

echo /module >.gitignore

staging Area

Commit할 파일들을 모아놓는 공간입니다. 즉, Commit할 준비가 된 공간입니다.
여러개의 파일들을 add해서, commit하기 위해, 예약된 공간입니다.
Add를 한 순간의 그 파일 상태를 저장합니다. 즉, add한 뒤, 수정을 하면 , 또 add를 해주어야 합니다.

수정된 파일내용 확인하기

staging에 올렸다가, Modify가 되어서, 어떤 내용을 수정했는지 확인하고 싶은 경우가 있다.

git diff

하지만, 위와 같은 명령어를 이용하면, 보기가 까다롭다. (읽는 방법이 따로 존재한다)

쉽게 볼려면, Editor에 있는 기능을 이용하면 훨씬 더 쉽게 볼 수 있다. 아래와 같이 config를 설정해주자.

Commit하기

Staging Area에 파일이 자신이 의도한 대로 되었다면, git commit으로 git directory에 넣어줘야한다.이때, git commit은 단순히 git commit으로 하기 보다는, 어떤 내용에 대한 Commit인지 메세지를 남기는게 좋다.

git commit -m [메세지]

예를들어, 내 이번 commit이 Login Validation에 대한 내용이면, 아래와 같이 작성할 수 있다.

git commit -m "Add Login Validation"

원격저장소 (GitHub 연결하기)

Local에서의 설정이 끝났으면, 이제 github에 해당 폴더를 연결시켜주는 작업을 하는게 좋습니다.우선, 깃허브에 들어가서, test용 repository를 하나 만들어줍니다.

git remote add origin [깃허브주소]

git remote가 되어있는지 확인하기

git remote -v

연결이 성공하면, 아래와 같이 뜹니다.

연결이 되었다면, 이제 몇가지 작업을 좀 해줘야한다.

1. branch 이름 맞춰주기 .

master -slave의 이름을 이제, main으로 바꾸는 운동을 시작했다. 그래서 ,branch를 main으로 바꾸어주면 된다. 물론, 다른 branch로 내가 분기를 낼거면, 사실 필요없긴하다.

git branch -M main

2. git push 해주기

이제, 원격저장소에 push할 명령어를 입력해준다.

git push -u origin(내가 add때 등록한 이름) main(등록할 branch이름)

* error 발생

reject되는 경우

위와같은 오류사항이 발생할 수 있다. 위 오류사항은, github에 있는 현재 파일과, 내 local에 있는 파일이 달라서 그걸 check 해달라는 내용이다. 보통, github에서 readme파일을 생성해서, 생기는 오류이다.

안전한 방법은 Pull을 이용하는 방법이 있다.

git pull origin main

여기서 "refusing to merge unrelated histories"라는 멘트를 뱉어내며, 에러를 발생시킬 수 있다. 이건, 전혀 관련없는 두개의 프로젝트들이 지금 하나로 합쳐지는 경우이기 때문에, 뱉어내는 오류인데, 아래의 옵션을 주면 해결할 수 있다.

git pull origin 브렌치명 --allow-unrelated-histories

강제로 Push하기. (local에 있는 파일을 강제로 프로젝트에 덮어쓰기)

개인프로젝트인 경우에는, 강제로 push하는 방법이 더 좋을 수 있다. 왜냐하면, 초기셋팅일 확률이 크고, 뭐 자기자신의 파일과 github에 파일의 차이가 크게없을 수 있기 때문이다. 하지만, 만약 중간에 project에 합류한다거나, 어떤 프로젝트를 여러명이서 하고 있을 때는 무적권 pull을 이용하자.

git push origin +main

Tip

git 명령어를 단축키로 등록할 수 있습니다.

git config --global alias.단축키 기능

예를들어, git status가 너무 길어서, st로 줄이고 싶다면, 아래와 같이 명령어를 칠 수 있습니다.

git config --global alias.st status

refer

엘리님의 git강의

[JS/객체/프로토타입] JS의 프로토타입

Mapin — Sun, 23 Oct 2022 13:00:02 +0900

JavaScript는 프로토타입형 객체지향 언어이기도 하고, 함수형으로 쓸 수도 있고, 뭐 다양한 측면을 가진 언어입니다.

~~(non-blocking , single-Thread,concurrency ,asynchronized 언어~~이기도 하죠) 자바스크립트의 빼놓을 수 없는 특징 중 하나인, 프토로타입에 대해서 적어봅시다!

프로토타입

현실에서 "프로토타입" 이라는 말 많이 쓸 일이 없지만 , 프로토타입에 대해서 먼저 알아봅시다. 종종 영화같은데나 게임버전 같은데서는 Prototype이라는 용어를 씁니다. 아이언맨에서 "프로토타입"이라는 말이 나오는데요 , 구글링을 해보겠습니다.

검색결과

아이언맨 1에 나오는 초기 슈트입니다! 감은 잡힙니다. "프로토타입"이라고 하면, 뭔가 초기버전 , 근본이 되는 1.0ver같은 그런 느낌이 들긴합니다. 하지만, Iron man의 가장 매력적인 점은 따뜻한 마음도 있지만, 다양한 슈트가 있다는 점입니다.

즉, 프로토타입에서 다른 버전으로 업그레이드 하면서, 다른 특성들을 가지게 되지만 , 우리가 생각하는 "아이언맨"의 원형은 크게 바뀌지 않죠. 즉, 누구나 생각하면 딱 떠오르는 "아이언맨"이라는 원형은 크게 변하지 않습니다.(머리에 씌워져있고, 눈은 빛나면서 가슴 중간에는 토니의 상징인 아크 원자로가 있고, 손과 발에 있는 부스터를 이용해 비행을 하는 등)

프로토타입은 바로 이겁니다. 누구나 생각하는 "이상적인 원형" ,"이상적인 형태"라고 할 수 있습니다. 예를 더 들어볼게요. 대부분 물고기를 그려보라고 하면, 아가미에 , 꼬리는 v자 형태에, 유선형으로 그립니다. 새를 그려보라고 하면, 날개가 있고, 다리가 2개고, 발가락이 3개인 형태를 그립니다.

TMI (글쓴이의 주접)

이 점에서, JAVA의 class와 다른점이 드러나게 되죠. JAVA는 "특징"들을 정의해놓고(class선언), 틀에서 찍어내게 객체를 정의합니다. 그래서 , JAVA에서는 완벽한 Class를 설계하는 것은 정말 어렵습니다. 이와 다르게, JS에서 객체를 바라보는 시선은 , 이상적인 형태인 각각의 Prototype이 있으며, 그걸 확장시키는 개념인거죠.

사실 이 개념은 언어 설계자가 어떤 철학을 가지고 개발했냐에 달렸는것이기 때문에, 객체에 대한 시선은 충분히 사람마다 각자 해석하는 것이 다를 수 있습니다. 단지 , JS의 개발 철학은 Prototype에 기반을 두고 있다는 이야기를 하는 것입니다! 프로토타입에 대한 더 정확한 의미는 "Eleanor Rosch"의 "프로토 타입이론"에서 프로토타입에 대한 정의가 나옵니다.

JS에서 프로토타입

JS는 내부적으로 객체,함수,배열 등의 Prototype(Function.Prototype,Object.Prototype와 같은)을 갖고 있습니다. 그리고, 프로그래머가 사용하는 객체들에게 Prototype에 정의되어있는 constructor로 생성하게한 뒤, 자신의 정보를 [[Prototype]]객체로 묶어서 넣어주게 됩니다. 코드로 봅시다.

const arr= [1,2,3,4,5]
const obj = {
	name:"hello",
}

console.dir(arr)
console.dir(obj)

정리하면, 이렇게 말을 할 수 있습니다.결국, 쉽게 이야기하면 아래처럼 이야기할 수 있습니다.

JS에서 Prototype은 객체(함수든, array든,object든)를 생성할 때, 부모객체를 프로토 타입이라고 합니다.

ECMA Scrip Spec(공식문서)에서는 자바스크립트의 모든 객체는 [[Prototype]]이라는 인터널 슬롯 (interal slot)을 가지고, [[Prototype]]의 값은 null 또는 객체이며 , 상속을 구현하는데 사용된다고 안내하고 있습니다.

Prototype은 특정 객체를 생성할 때, 부모객체를 "Prototype"이라고 할 수 있다. (O)
[[Prototype]]를 부모를 통해 받기 때문에, "상속"이라는 개념을 구현 할 수 있다. (O)

여러분 , 조금 만 더 깊게 들어가봅시다. 이거 재밌더라구요! 앞으로, 함수,배열, 객체들을 모두 지칭할 때는 큰 Object, 자바스크립트에서 리터럴로 생성하는 객체를 말할 때는 작은 object라고 쓸겁니다!.

JS 객체 생성방법

JS에서 객체를 생성하는 방법은 여러가지가 있습니다. 객체 리터럴, 생성자 함수이용,Object.create가 있습니다. 이 3가지가 묘하게 다른거 아시나요! 왜 이렇게 다양하게 있을까요. 한가지만 있으면 될텐데 말이죠.

함수도 Object 이고 , object도 Object이고, 배열도 Object 입니다. 그럼, 특별한 친구가 있죠. "생성자"라는 친구입니다. 생성자라는 친구는 함수이면서, 어떠한 객체(object)를 "생성"하는 친구입니다. 즉, Function.Prototype을 갖고 있으면서, 특정 객체(object)를 생성될 객체(object)한테 가르쳐 줘야합니다. 그래서,함수 타입에는 prototype이라는 property가 있습니다. 이걸 설명하는 이유는 , prototype property와 ~~.prototype이 무지무지 헷갈리기 때문입니다.

function a(){
}
console.dir(a)

prototype

객체 리터럴로 객체 생성하기

JS로 객체를 생성할 때, 가장 흔하게 쓰는 방법 중 하나인 객체 리터럴입니다. 객체 리터럴의 생성과정을 prototype을 적용해서 생각을 해보도록 하겠습니다.

const obj= {
	name:"Mapin",
    say:"hello!",

}

프로토 타입관점에서 위의 객체 리터럴을 이용하는 생성과정은 아래와 같은 Prototype Chain이 형성됩니다.

생성된 객체의 prototype이 Object.prototype으로, "객체 프로토타입"이 자신의 부모가 되죠.

생성자를 이용하는 방법은 어떻게 될까요?

function Obj(name,say){
	this.name=name;
    this.say=say;
    this.sayHello = function(){
    	console.log(`Hello! Im ${this.name} ${this.say}`)
    }
}

const ob = new Obj("mapin","Yob");

프로토 타입관점에서 위의 생성자 함수를 이용하는 생성과정은 아래와 같은 Prototype Chain이 형성됩니다.

생성된 객체의 prototype이 Obj.prototype으로, 자신을 생성한 부모가 자신의 프로토 타입이 되는것이죠.

3줄요약

JS에서 객체를 바라보는 관점은 Prototype이다.
Prototype은 객체가 생성 되었을 때, 자신의 부모객체를 가리킨다. [[prototype]]객체를 주입받아, "상속"이라는 개념을 이용할 수 있게 된다.
객체를 생성하는 방법에 따라서, prototype chain이 바뀐다.

refer

프로토타입 deepdive

[JS/호이스팅/실행 컨텍스트/이벤트 루프] JS 코드의 흐름

Mapin — Wed, 19 Oct 2022 23:36:39 +0900

저는 var을 한번도 써본적이 없지만, JS는 오래동안 써왔던 언어이므로 ,var를 마주칠 가능성이 높습니다.

(var은 호이스팅을 하기 때문에, 선언하지 않아도 접근이 가능해지며 재할당을 해도 아무런 상관이 없는 문제가 있었습니다)

JS의 코드의 흐름중에 하나인, 호이스팅부터 짚고 넘어가볼까요!

호이스팅(Hoisting)

아래의 코드를 보시죠! 어떤 문제가 있어보이나요?

var a=5
console.log(a)

아뇨, 없습니다! a=5 라는 결과가 나올겁니다. 아래의 코드를 보시죠 . 문제가 있을것 같나요?

console.log(b)
var b=5

놀랍게도, 아래의 코드도 "실행"은 됩니다. 의도치 않은 결과인 "undefined"를 뱉을 뿐, 에러는 발생하지 않습니다.

C언어,Java와 같은 정적인 언어를 자주 접해왔던 저는 처음에는 "뭐지 , 이 무근본은 ..?"이라고 생각했습니다.

선언을 하지도 않았는데, 이걸 에러를 안뱉어..? 그리고, 더 놀라웠던건, 같은 이름의 변수를 또 "선언"할 수 있었다.

var a =5
console.log(a)
var a=7
console.log(a)

하지만, 이러한 로직이 가능한건 , 분명한 이유가 있을거고, 바로 그 개념이 "호이스팅"의 개념입니다.

호이스팅은 이렇게 동작합니다. 코드를 실행하기 전에, V8엔진 형님이 먼저 코드를 한번와서 쓱 훑고 , "선언"된 변수들을 미리 적어갑니다. 코드 상의 동작으로 따지면, 아래와 같이 움직입니다. a를 최상단으로 옮기는거죠.

따라서, console.log(a)에 undefined가 나오게 되는겁니다. 아직 "값"자체는 할당되지 않았으니까요!

console.log(a)

var a=5 

//======== this code convert to below =====

var a 
console.log(a)
a=5

새로나온 let, const도 호이스팅을 안할까요? 아닙니다. 합니다! 단 , 값이 "할당"되기전에 접근하는걸 막는겁니다.

console.log(b)
let b =5

// convert code to below 

let b 
console.log(b)
//TDZ , 할당되기 전까지 b로의 접근을 막는다. b에 접근하면 error!
b=5

Summary

호이스팅 문제로 인해서, var은 더 이상 쓰지않는다. 하지만, 원시코드 형태로 만나볼 수 있으니 알고는 있자.
호이스팅은 V8엔진이 변수를 미리 기억하는 과정이다. 이 현상 때문에, 코드의 흐름상 제일 위로 끌어올리는 것과 같은 현상이 되는거다. 이때, var은 undefined로 되고, let,const는 TDZ를 만들어 할당이 되지 않았다면 접근을 막게된다.

Scope

C언어/Java와 같은 정적인 언어를 사용해봤다면, 혹은 Python을 다루어 보았다면 프로그래밍 언어는 "실행블록"이라는 개념이 있습니다. 예를들어, C언어,java는 중괄호 , python은 콜론(:) + 스페이스바 4칸(Tab)으로 구분을 합니다.

1개의 실행블록은, 독립적인 공간처럼 사용할 수 있어서, 외부에서 내부로 접근을 못합니다. 아래와 같이 말입니다.

void printNumber(){
	int num=5
    printf("%d",num)
}

printf("%d",num) //error!

실행블록과 같은 논리적인 범위, 변수값들의 유효범위를 JS에서는 Scope라고합니다. var은 이 scope가 애매합니다.

즉 , 지역변수와 전역변수가 애매해진다는거죠. 정확히는 var은 함수내부에서는 , 지역변수입니다만, if,for문과 같은 곳에서는 전역변수처럼 동작하게 됩니다. 이걸 JS에서는 "함수스코프를 가졌다"고 합니다.

for(var i=0;i<5;i++){
	console.log("inner",i)
	
// 1,2,3,4,
}
console.log("outer",i)
// boom! 5

function sayHi(){
	var say="hello"
}
console.log(say)
//error!

let,const에서 오면서 이걸 고쳤죠! 다른 언어와 마찬가지로 , blockScope로요!

정리하자면, Scope란 , 변수 이름, 함수 이름, 클래스 이름과 같은 "식별자(Identifier)"가 본인이 선언된 위치에 따라, 다른 코드에서 자신이 참조 될 수 있을지 없을지 결정 되는걸 이야기 합니다. 식별자의 유효범위인 셈이죠.

이벤트 루프

Chrome을 간소화 시키면 아래와 같은 구조를 띄게 됩니다. 실행 컨텍스트는 간단하게 이야기하면, "call stack에 쌓이는 로직들에 대한 모든 내용" 입니다. 우리가 실행하는 함수나 로직들은 call stack에 순차적으로 하나씩 쌓이게 됩니다. (즉, 들어온대로 처리가 된다는거죠!)

자세하게 들어가면, 전역 컨텍스트 , 함수 컨텍스트 , 지역 컨텍스트 등등 다양하게 있고, lexical scope chain ,this 등이 context마다 있습니다만, Event Loop에서는 "callstack에 쌓이는 로직" 이정도로 이해해도 큰 문제는 없을겁니다.

아래의 코드가 JS에서 실행된다고 생각해보죠.

console.log("welcome"!);
function func1(){
	console.log("Hello!");
}

setTimeout(func1,5000)

0. 메모리 영역에 func1을 등록해놓습니다.

1. console.log()가 callstack에 쌓입니다.

2. console.log() 실행이 끝나고, setTimeout이 실행됩니다. setTimeout은 실행됬다가, 비동기함수이므로 WebAPI에게 callback을 던집니다. 여기서는 func1을 던지겠네요!

3.Timer는 setTimeout이 요청했던대로, 5초뒤에 Task Queue에 callback을 던집니다.

4. 이제 더 이상 실행할게 없으므로, call stack에서 annoymous(전역객체)가 마지막으로 나갑니다. event loop는 callstack이 완전이 비어질 때까지 기다립니다.

5. Event loop는 call stack이 완전히 비어있고, Task Queue에 작업이 남아있다면, 그 작업을 call stack으로 올려줍니다.

6. callstack에서 callback 함수가 실행되고, 이제 끗! 입니다.

Eventloop는 , call stack을 항상 지켜보다가 , task queue에 남은 작업이 있다면, call stack으로 올려주는 역할을 하게됩니다. 예를들어, 아래의 코드는 bar을 즉시 반환할까요? 아닙니다. 콘솔에는 foo bar이 찍힙니다. 이게 자바스크립트의 코드 흐름 때문에 그렇습니다!

function func1(){
	console.log("bar")
}
setTimeout(func1,0)
console.log("foo")

다음시간에는 실행컨텍스트를 자세하게 들여다보면서, scope chain을 따라서 "this"가 결정되는 과정을 보고, closure패턴을 한번 봅시다! 왜 "this"가 함수 호출시에 결정되는지를 알려면, 실행컨텍스트를 보면됩니다!

실행 컨텍스트를 이해하려면, 오늘 적은 스코프,호이스팅,이벤트루프 ,call stack에 대한 개념을 조금 아셔야합니다.

실행 컨텍스트가 끝나면 , promise를 포스팅해서 ! 드디어, AJAX 즉 , 웹서버와 통신을 비동기적으로 하는걸 봅시다!

refer

JSconf - EventLoop

제로초님 블로그

[JS/EventLoop/CS] JS의 코드의 실행을 이해기 위한 CS

Mapin — Wed, 19 Oct 2022 01:25:49 +0900

JavaScript는 다른 언어들과 다르게, 특이한 흐름이 있습니다. JS는 "싱글 쓰레드"언어이지만, 동시성을 갖고 있는 언어이기도 합니다. 이게 무슨말인지 잘 와닿지 않을 수 있습니다. 여기서는 CS지식이 들어갈 수 밖에 없고, 저는 다행히 전공을 했기 때문에 이해가 가지만, 어려운 개념에는 틀림이 없습니다! 천천히 가보죠!

동시성(Concurrency)

프로그램 처리 관점에서 Concurrency는 "동시에 수행하는 것 처럼 동작시키는 것"을 이야기합니다. 아래의 예시를 보시죠. 어떤 작업 Task1,Task2가 듀얼코어의 CPU 시스템에서 처리된다고 생각해봅시다. cpu는 1개의 task밖에 처리를 못한다고 가정하겠습니다.

이런상황에서 , task 3,task 4를 진행시키고 싶은겁니다. 다른 말로 더 와닿게 말씀드리면, 브라우저 키고, 노래 듣고, 카톡도 하면서 , VScode도 하고 싶은겁니다.

어떻게 할 수 있을까요? 수십장의 그림을 빠르게 넘기면, 우리 눈에는 움직이는것처럼 보입니다. 즉, 끊기지 않고, 연결된 것처럼 보인다는 이야기죠. 마찬가지로, 작업도 인간이 인지할 수 있는 속도보다 빠르게, 바꿔치기 하면서 조금씩 작업하면, 마치 끊기지 않는것처럼 느껴지지 않을까요? 아래와 같이 말이죠! 이게 ,"동시성" 입니다. 대표적으로 , 시분할 방식을 쓰는데, OS정리할 때 다시 다루도록 하겠습니다.

병렬성(Parallelism)

병렬성은 말 그대로, 다른 CPU에서 처리하는걸 이야기합니다. 동시성은 Task를 바꿔주는데 비용이 발생합니다. 병렬성은 이런 과정이 필요없습니다. 진짜 물리적으로 분리되어 있는 공간에서 실행시켜주는 거입니다. CPU1,CPU2에서 task (1,3) (2,4)는 병렬적으로 처리되는걸 병렬성이라고 합니다.

스레드와 프로세스 , 컨텍스트 스위칭 (Context Switching)

프로세스는 운영체제로부터, 자원(메모리)을 할당받는 작업 단위입니다.

스레드는 할당받은 자원을 이용하는 "실행의 단위"라고 할 수 있습니다. 프로세스 내에 여러개의 스레드가 실행되는거죠.

Multi Process

하나의 프로그램을 여러개의 프로세스로 구성해서, 각 프로세스가 하나의 작업을 처리합니다. 즉, 메모리 공간을 추가적으로 OS에서 할당받아서 실행하는 방법입니다. 이때, 각 프로세스를 번갈아 가면서 실행(동시성)하게 되는데, 이 작업을 Context Switching이라고합니다. 프로세스는 독립적인 메모리 공간이므로, cache hit율도 낮습니다. 즉, 캐시메모리 초기화 작업을 해야합니다. 또, 메모리 영역을 할당받는다는 건 "System Call" 즉, OS를 통해서 커널모드로 바꿨다가, 사용자 모드로 전환하는 추가작업도 필요합니다. 하지만, 안정적입니다.

Multi Thread

멀티 쓰레드는 , 하나의 프로세스 안에서 여러개의 스레드로 자원을 공유하며 작업을 나누어 수행합니다. 즉, context switching 이 매우 빠르겠죠. 쓰레드는 기본적으로 "Function Call"이기 때문에, 시스템 콜이 줄어들어 빠르고, 한 프로세스 내에 있기 때문에, cache의 hit율도 높습니다.

하지만, 프로세스를 하나의 컨테이너처럼 사용해서, 여러개의 자원을 공유해서 사용한다는 말은 곧, 여러 쓰레드에서 동시에 접근 할 수 있다는 이야기 입니다. 공유자원을 보호하기 위해서, 동기화(Mutex,spinlock,Semaphore 등의 개념)를 잘 해줘야하고 , 그리고, 구현하기도 까다롭습니다(실수할 확률이 높다 , 사람마다 구현하는 결과물이 천차만별이다).

* JS는 Single Thread입니다. 즉, 1개의 스레드만 돌아간다는거죠! 1번에 1개의 작업만 가능!

들어가기 전에, 블로킹과 논블로킹, 동기와 비동기는 완전히 다른 관점에서 보는겁니다. 둘을 혼동하면 안됩니다!

블로킹 & 논 블로킹

블로킹은 말 그대로 , "blocking" 실행이 막히느냐 안막히느냐의 관점으로 해석을 한겁니다.

Blocking은 하나의 작업이 끝날 때 까지, 다른 작업을 하지 않습니다. 즉 , 제어권을 B에게 넘긴다음, B가 다시 제어권을 넘길때 까지 아무런 작업을 못합니다. 만약, JS가 Blocking이라면, Ajax요청을 보내면 , 요청이 끝날 때 까지 아무런 화면 클릭도 못할겁니다.

논 블로킹은 반대로, 제어권을 그대로 가지고 있는 상태로, 다른 함수를 "실행"만 시키는 형태입니다. 다른함수가 실행될 동안, 나는 내 할일을 하게됩니다.

Synchronous & Asynchronous

동기와 비동기는 프로세스의 수행 순서가 보장되느냐 관점입니다. 동기이면, 내가 지정한 순서대로 프로세스가 돌아가는걸 이야기합니다. Code로 따지면, Top-down으로 코드의 흐름이 생성되냐/안되냐에 따라서 나누는거죠!

함수로 따지면, 호출하는 함수 A가 호출되는 함수 B의 작업이 "언제"완료되는지 계속 물어봅니다.

비동기는 함수A가 함수 B를 호출할 때, 함수 B의 실행 순서를 신경쓰지 않습니다. 언제 실행되는지 모르고, 알 필요도 없고, 그냥 관심이 없습니다. 주로 Callback으로 구현합니다. code로 따지면, Top-down으로 코드의 흐름이 생성되지 않습니다.

* JS에서 EventListener, SetTimeout등이 비동기라고 불리는 이유는, 코드 상에서 Top-down으로 실행되지도 않고, 단지 Web API를 통해서 callback으로 등록하고 있을 뿐입니다.

보통 비동기 & non -blocking , 동기 & blocking을 조합하여 씁니다. 그리고, 간혹가다가 동기&non-blocking도 있습니다.

동기&non-blocking은, A의 함수 자신을 계속 실행하면서, B의 함수의 리턴값이 필요할 때 사용되어집니다. 즉, 중간중간에 계속 함수실행이 완료되었는지 물어보는 상태를 이야기합니다. 로딩창이 보통 그렇습니다. 자신은 계속 실행하면서, 상대방에게 끝났냐 ,끝낫냐 계속 체크를 하니까요.

JS는 비동기 ,non-blocking입니다. 왜 그런지는 다음 글에 담도록하죠!