타임라인

• 팀빌딩 : ~2/15 (일)
• 주제 사전 발표 : 2/19 (목)
• 해커톤 당일 : 2/21 (토) 오후 3시 ~ 2/22 (일) (실제 개발 진행 : 2/21(토) 오후 4시 ~ 2/22 오전 8시)

주제

오프라인에서 완성되는 경험

프로덕트 소개

오고있니 AreUComing

• frontend repo

"기다림의 시간까지도 설렘으로"

• '위치 추적'이 아닌 상호 '위치 공유'로, 연인을 만나러 가는 경로를 실시간으로 시각화 🗺️
• 만나러 가는 길까지도 하나의 콘텐츠가 될 수 있게 💗
• 쌓인 만남의 기록들은 연인만의 새로운 이야기 ✍️

오프라인을 대체하지 않는, 오프라인에서의 만남을 오히려 촉진하는 서비스!

로그인 / 회원가입 / 파트너 연결 흐름

서비스를 이용하기 위해서는 로그인 및 회원가입이 필요하며, 회원가입 직후에는 자신이 초대 코드를 만들어 상대방에게 전달하거나, 상대방이 만든 초대 코드를 수락하는 식으로 _파트너 연결_을 하게 된다.

홈 화면

파트너 연결 이후에는 '위치 공유 시작' 버튼을 눌러 나의 위치 공유를 먼저 시작할 수 있다. 한 명이 위치 공유를 시작하면 타인에게 그 푸시 알람이 도착하여, 상호 위치 공유를 할지 말지 선택할 수 있다. (*푸시 알람 기능은 FCM-Firebase Cloud Messaging을 이용했으며 안드로이드에 PWA 형식으로 웹을 설치했을때, 그리고 데스크탑에서 작용하는 것 확인)

위치 공유

홈의 '위치 공유' 버튼을 누르면 websocket 연결이 확립되고, '실시간 위치 보기'를 클릭해서 지도가 있는 위치 공유 페이지로 이동하면 그때부터 websocket 기반 실시간 위치 공유를 시작한다.

(여담으로 지도를 확대해 보면, 해커톤의 장소인 '성수 엘리스랩' 근방에서 팀원들이 열심히 뛰어다녔다는 것을 확인할 수 있다 😅)

'만남 기록' 버튼을 누르면 두 사람의 만남이 성사된 것으로 간주되어, 내가 이동한 거리 + 상대방이 이동한 거리를 합산한 '만남 이동 거리'와 만날때까지 걸린 시간이 계산 및 기록된다. 이 데이터는 '만남 회고' 탭에서 연인 간의 하나의 이야기 겸 콘텐츠처럼 향유할 수 있다.

만남 회고

• 스토리 탭 : 각각의 만남의 평균 시간과 평균 거리를 계산해서 대시보드 형태로 보여주며, 이번 달에 몇 번 만났는지 / 만남까지 총 걸린 시간과 이동 거리, 그리고 만남까지 걸린 최단 시간을 이야기 형태로 보여준다.
• 목록 탭 : 모든 만남 목록을 피드 형식으로 보여준다.

• 지도 탭 : (지도 부분은 작동하는 것을 스크린샷 찍지 못해서, 아래에 피그마 스크린샷을 첨부했다.) 실제로는 시간 부족 이슈로, 모든 만남을 오버레이해서 하나의 지도로 보여주는 것까지만 구현했다.

KPT (Keep, Problem, Try)

Keep

사전 준비 워크플로우

약 이틀 간의 준비 시간을 알차게 활용할 수 있기 위해서는, 행사 이전 무엇을 어디까지 준비할 것인지에 대한 고민과 이에 따른 투두 정리가 필요할 것이라 생각했다. 따라서 다음과 같은 사전 준비 타임라인 설계를 했다.

첫 회의 :

• 회의 이전에 아이디에이션 및 _아이디어 투표_를 피그마의 FigJam을 이용해 미리 진행.

• 회의 때 아이디어 바탕으로 세부 기획서 작성.

  두 번째 회의 :

  • 회의 이전에 기획서를 바탕으로 UI 스케치 및 DB 스키마/엔드포인트 목록 작성

    • 두 번째 회의 때 서로 피드백 및 수정사항 반영 + 업무분배

  각 업무 간의 의존성을 고려한 효율적인 흐름이었기 때문에 만족한다.

  

styled-components의 도입

지금까지 계속 CSS Modules를 사용하다가, CSS 파일을 페이지별로 적용할 시간이 없을 것 같아서 · 반복되는 컴포넌트 스타일이 대부분이고, 페이지 레이아웃의 경우도 반복되는 경우가 많다고 여겨서 처음으로 styled-components를 사용해 보았다.

예상대로 초기 세팅 시간을 들이고 나니 빠르게 UI를 구현할 수 있어서, 효과적인 프레임워크 세팅이라고 느꼈다.

작은 규모의 서비스에 맞는 깔끔한 파일 구조

이 블로그 링크 를 참고해서, 중급 정도의 파일 구조를 적용했다.

• pages 폴더 : 안에 페이지 컴포넌트, 그리고 해당 페이지에만 사용되는 파일들 (컴포넌트 / 훅)을 넣음

• components 폴더 : 여러 페이지에 걸쳐 사용할 수 있는 컴포넌트들의 경우 여기에 넣음
• hooks : 컴포넌트 폴더와 마찬가지로, 여러 페이지에 걸쳐서 사용되는 전역 hook를 저장할 수 있음
• assets : 전역 css 스타일 /폰트 파일 / 사진들
• context : 전역 변수 관련 파일들
• data : 프로그램에서 사용되는 정보(전역 constant, 테마 정보 등)
• utils : 여러 페이지에 걸쳐 사용되는 포맷팅 함수 등의 함수 파일들

초기 설정에도 간편했고 address alias 설정과 함께 이용하니 파일 경로를 바꾸어도 import를 바꾸는 등의 문제가 없어서, 다음에도 프로젝트 규모가 너무 크지 않은 경우 이런 파일 구조를 차용할 예정이다.

서비스의 완성도

서비스의 및 유저 페르소나가 명확하고 스토리텔링이 구체적이라고 느꼈다. 또한 서비스 이용 시나리오에 따른 UX 흐름이 유기적이라고 느껴서, 기능 구현 정도를 포함하여 서비스의 전반적인 완성도가 높아 만족스러웠다.

Problem / Try:

• 기능 선택과 집중이 부족했다. 해커톤이 처음이라서 그런지 약 16시간 미만 동안 얼마나 개발할 수 있는지 감이 잘 오지 않았다. 또한 프로젝트 완성도를 추구하며 해커톤이 끝나갈 무렵 사소한 포인트 디버깅을 하느라 발표자료를 늦게 제출하게 된 탓에 (...) 프로덕트 완성도 및 기획력에 비해 등수가 낮아졌을 수도 있겠다고 생각했다. ➡ '하면 된다'는 마인드보단, 현실적으로 개발 기간동안 할 수 있는 것들을 evaluate하고, 완벽한 프로덕트가 아닌 MVP를 만든다는 생각을 더 가지는 것이 필요하다. 핵심적인 기능들을 선정하고 그것을 잘 showcasing하는 것이 중요하다.

• 프로젝트와 관련해서 혼자 고민해보고, 고민 결과로 도출된 진행 방향이나 계획을 팀원들에게 공유하고 의견을 구하는 진행 방식은 익숙한 것 같다. 그러나 0에서 1을 만들기 위해 팀원들과 논의가 필요한 경우, 논의에 더 효과적으로 참여할 수 있게 하기 위한 소통 방식 i.e, human querying / prompting이 아직 덜 익숙한 것 같다. 이후 프로젝트등을 진행할때 이를 염두에 두어야겠다고 느꼈다.

• PM뿐만이 아니라 다른 역할들도 맡았기 때문에, 특히 해커톤 진행 중은 프론트 개발 업무가 과중했기 때문에 각각의 팀원들의 프로젝트 진행 상황에 대해서 신경 쓰지 못했다. 그 과정에서 백엔드 개발자 분께서 본인의 업무 분담이 끝나서 프론트 쪽을 하고 있으셨는데, 그 부분이 프론트 개발자들에게 잘 전달되지 않는 등 더 효율적일 수 있던 부분이 아쉽게 느껴진다.
  ➡ 앞으로 여러 역할을 PM과 함께 병행해야 하는 상황이라면, 프로젝트 매니징 업무에 집중할 수 있도록 다른 역할들의 업무 부담을 조절하는 것이 필요하다.
  ➡ 프로젝트의 전체적인 흐름을 알지 못하면 비효율이 발생할 가능성이 높다. 효율적 진행을 위해 팀원 간 소통을 연결해주기 위해서는, 프로젝트가 전체적으로 어떻게 되어가는지 아는 것이 중요하다.

UI/UX 디자인

피그마로 UI 디자인을 처음 시도해보았다. 툴을 써본 적은 있지만, 피그마에 UI 스케치를 시도해보며 툴을 사용한 것은 처음이었기 때문에 사전 준비 과정에서 plugin, assets 사용, flexbox처럼 frame 사용하기 등 피그마 자체 사용법을 더 잘 알게 되었다.

Figma Make 이용: 디자인 경험이 있으신 다른 프론트엔드 담당 분께서 알려주신 덕에, Figma Make에 프로젝트에 대한 설명이 포함된 프롬프트를 넣으면 디자인과 함께 코드까지 통합적으로 나온다는 것을 알게 되었다. UI를 고민하고 레퍼런스를 찾아볼 시간이 사실 충분하지 않았기 때문에, 최대한의 효율으로 UI 디자인을 내기 위해, Figma Make에서 나온 AI의 UI를 다른 Figma 파일에 복사 & 붙여넣기하여 AI스럽거나 어색한 부분을 수정하는 식으로 진행했다.

이 과정에서 AI가 한 디자인을 그대로 쓸 경우, gradient 사용이나 과도한 그림자, 투박한 색상 선정과 'boxes in boxes' 등의 요소들이 'AI스러움'을 자아내어 서비스의 질을 더 떨어져보이게 한다고 느꼈다. AI 시대에서 프로덕트가 양산형이 되지 않을 수 있는 방법은, UI 디자인과 UX 라이팅에 고민을 들이는 것, 그럼으로써 authencity를 챙기는 방법이라고 생각한다.

로고 또한 gemini에 프롬프트를 넣어 나온 초안을 참고하여 직접 피그마로 만드는 방식으로 만들었다.

• ai 생성 로고 :
• 수정 후의 로고 :

ui와 로고들을 그려본 이후 디자인 전공을 하고 있는 팀원에게 검수를 받아서 완성도를 높였다.

사용 디자인 워크플로우 정리

• 기획서 작성 이후, Figma Make로 디자인 생성 - 레퍼런스로 활용
• 서비스 의도와 비슷한 UI 레퍼런스를 찾아보기
• 서비스의 컨셉이 무엇일지 고민하면서 primary color등 컨셉 포인트들을 잡기
• 1, 2, 3을 바탕으로 최종 UI를 만들기

파일을 주고 받을 서버를 연결하기 위해서는 File > Site manager 에 들어가서, 연결 Protocol, Host & Port, User id을 입력하면 되는데

이렇게 에러가 뜸

이유 : 연결 Port를 잘못 입력했기 때문 실제로 연결된 port를 서버와 연결된 터미널창에서 다음 커맨드로 확인해야 한다

$ echo ${SSH_CLIENT##* }

보통 FTP 연결, SFTP 연결이면 Port 22인데, 서버 아이디 신청 시 할당받는 port로 오해하고 있었다

1. 로그인 / 회원가입 구현 및 내비게이션 바에 인증 상태 반영
2. react-router-dom의 url parameter을 이용한 query로 서버에서 모집공고 가져오기 및 필터링, 정렬 기능 구현.
3. 마이페이지 내에서 프로필 등록 여부에 따른 조건부 렌더링, 프로필 작성 및 수정 기능 구현.

이번 글에서는 createContext, useContext 훅으로 사용자 정보 user 및 로그인 상태를 리액트에서 전역변수로 관리한 구조를 기록해보고자 한다.

Authentication context

React에서 다른 component들이 공통된 state를 두고 동시다발적으로 그 state에 접근할 수 있는 것이 context이다. 유저 정보와 로그인 유무는 여러 컴포넌트에서 글로벌하게 사용되기 때문에, 이러한 context를 사용하는 것이 더 유리하다. (상위 component에서 fetch를 하고 하위 component들에게 prop으로 전달해주는 것보다)

➡️ src/contexts/AuthContext.tsx에 AuthContext, ContextProvider(AuthProvider), 그리고 context를 불러올 수 있는 커스텀 훅 useAuth를 모두 정의해 두었다.

• AuthContext : 다른 컴포넌트들이 사용할 수 있는 global variable

• AuthContextProvider : AuthContext를 다른 컴포넌트들에게 전달해줌
• useAuth : 다른 컴포넌트가 AuthContext를 내부의 useContext를 통해 접근할 수 있게 하는 Hook.

파일 내부 정의된 type들

• AuthContextType : 전역변수 AuthContext의 type (i.e, 다른 컴포넌트로 전달되는 모든 정보의 목록.) ➝ fetch해오는 user 값뿐만이 아니라, context와 관련하여 user을 업데이트 할 수 있는 login, signUp, logout 함수들도 미리 정의해두고 전달해줄 수 있다.

  // 인증 상태(isLogined) 관리 위한 context의 type
  interface AuthContextType {
    user: User | null;
    isLoading: boolean; // api 응답이 왔는지의 여부
    /* signup, login api 요청들 : 
      SignupData or LoginData를 받아서 Promise 형태의 응답을 return. */
    signUp: (data: SignupData) => Promise<void>;
    login: (data: LoginData) => Promise<void>;
    logout: () => void;
  }

• User : GET /api/auth/me에서 반환되는 response type.

  interface User {
    id: string;
    name: string;
    email: string;
    userRole: string;
  }

  AuthContext ⬅️ createContext

  전역변수 역할을 하는 context는 미리 지정해둔 ContextType으로 명시해두고, React.createContext로 만들어두기만 하면 된다.

  const AuthContext = createContext<AuthContextType | undefined>(undefined);

AuthProvider (AuthContext.Provider)

ContextProvider에서는 ContextType에 있는, context에서 전달해주어야 하는 모든 property들을 관리하고 반환해준다.

setup

export const AuthProvider = ({ children }: { children: ReactNode }) => {
  const [user, setUser] = useState<User | null>(null);
  const [isLoading, setIsLoading] = useState(true);

• children: 이후 App.tsx에서 <AuthProvider />으로 하위 컴포넌트들을 모두 감싸주는데, 이 감싸진 컴포넌트들이 children으로 취급되어 AuthContext를 접근할 수 있다.
• state 관리 : context에서 api 호출의 response 값이나 로딩 여부 등의 객체 값들은 주로 ContextProvider안의 state로 관리된다. 위 코드에서는 유저 정보 user과 로딩 여부 isLoading이 state로 관리된다.

useEffect - 렌더 시의 로직

AuthContext에서는 context의 특성 상, 유저가 이미 로그인되어있는지의 여부를 렌더 시마다 확인하고, user 정보를 업데이트해야 한다. 무슨 context를 구현하는지에 따라 다르겠지만 이처럼 각 렌더마다 확인되어야 하는 정보들은 useEffect안에 넣어준다.

  // 앱 렌더 시 저장된 토큰 있는지 확인
  useEffect(() => {
    const checkLogined = async () => {
      // 저장된 인증 토큰 있는지 확인 (있으면 로그인 유지)
      const token = localStorage.getItem('authToken');

      if (token) {
        try {
          const response = await apiClient.get<User>('/api/auth/me');
          setUser(response.data);
        } catch (error) {
          console.error('토큰을 가진 유저 가져오기 실패', error);
          localStorage.removeItem('authToken');
        }
      }
      setIsLoading(false);
    }; // end of checkLogined()

    checkLogined();
  }, []);

• 로그인 여부는 서버에서 저장해주는 보안 토큰(authToken)이 localStorage에 저장되어있느냐 마냐로 결정된다.

• 이때, 유저 정보 설정(setUser)은 GET /api/auth/me 요청의 응답으로만 시행한다. ⇒ login / signup의 api 요청 응답도 유저 정보를 부분적으로 반환하지만, 이렇게 반환된 값은 User데이터타입 스키마와 일치하지 않는다.

• 따라서 User type state로 user 정보를 관리하기 위해, login/signup 이후에 자동 로그인 기능을 구현할 때에는, api 요청의 response 중 토큰만 이용하여 다시 /api/auth/me 요청을 보내고, 해당 값으로 따로 setUser을 한다.

회원가입 함수

• SignupData는 따로 types/index.ts에서 데이터타입을 정의해두었다. (LoginData도 마찬가지)

• 위에서 언급한 것처럼, api response 중 토큰만 받아와서 다시 User 정보를 fetch하는데 이용한다.

  /* 회원가입 함수 */
  const signUp = async (data: SignupData) => {
    // apiClient로 api call 보내기
    const response = await apiClient.post('/api/auth/user', {
      authType: 'APPLICANT', //고정
      info: {
        type: 'APPLICANT', // 고정
        name: data.name,
        email: data.email,
        password: data.password,
        successCode: 'success', // 값 변경 가능
      }, // end of info
    }); // end of apiClient.post();
  
    // 회원가입 response에서 token만 가져오기
    const { token } = response.data;
    // 인증 token : localStorage에 저장
    localStorage.setItem('authToken', token);
  
    // signup 후 자동 로그인
    const userResponse = await apiClient.get<User>('/api/auth/me');
    setUser(userResponse.data);
  };
  

### 로그인 함수

```typescript
  /* 로그인 함수 */
  const login = async (data: LoginData) => {
    const response = await apiClient.post('/api/auth/user/session', {
      email: data.email,
      password: data.password,
    });
    const { token } = response.data;

    // 로그인 상태
    localStorage.setItem('authToken', token);

    // 유저 정보
    const userResponse = await apiClient.get<User>('/api/auth/me');
    setUser(userResponse.data);
  };

로그아웃 함수

  /* 로그아웃 함수 */
  const logout = () => {
    // try {
    //   await apiClient.delete("/api/auth/user/session");
    // } catch (error) {
    //   console.error("로그아웃 실패 - 클라이언트 측 정보 지우기만 진행", error);
    // } finally {
    //   localStorage.removeItem("authToken");
    //   setUser(null);
    // }

    // 클라이언트 토큰 값만 삭제
    localStorage.removeItem('authToken');
    setUser(null);
  };

• 주석 처리된 부분은 원래 과제 명세에서 필요했던, api call을 통한 세션 제거 부분이다. 그러나 해당 부분 구현 과정에서 서버 세팅 오류로 인한 CORS 에러가 발생하여, 현재 구현에서는 클라이언트 토큰 값만 삭제하는 것으로 변경되었다.

AuthProvider의 return value

위와 같이 다른 컴포넌트들로 반환해줄 값들의 준비가 코드 상으로 완료되면, Context.Provider의 형태로 컴포넌트를 반환해주면 된다. 이때 컴포넌트 prop의 value에는 context(global variable)에서 전달해주는 모든 property들을 명시해주면 된다. (aka ContextType)

export const AuthProvider = ({ children }: { children: ReactNode }) => {

...

  return (
    <AuthContext.Provider value={{ user, isLoading, signUp, login, logout }}>
      {children}
    </AuthContext.Provider>
  );
  // end of AuthProvider
};

Custom Hook - useAuth

다른 컴포넌트들이 AuthProvider을 통해서 AuthContext에 접근하는 것을 보다 편리하게 하기 위해, useContext를 이용한 wrapper hook을 정의해준다.

// custom Hook -> 다른 컴포넌트들에서 사용
export const useAuth = () => {
  const context = useContext(AuthContext);
  if (context === undefined) {
    throw new Error('useAuth는 AuthProvider 안에서 사용되어야 함');
  }
  return context;
  // end of useAuth
};

매우 간단하다.

활용

App.tsx

가장 상위 컴포넌트인 App.tsx에서 AuthProvider로 나머지 컴포넌트들을 감싸주어야 한다. 다른 Context Provider들을 정의하더라도 비슷한 방식으로, 원래 있던 Provider을 감싸거나 그 안에 두는 식으로 작성하면 된다.

    <AuthProvider>
        <Topbar />
        <main>
          <Routes>
            <Route path="/" element={<Home />} />
            <Route path="/login" element={<Login />} />
            <Route path="/signup" element={<Signup />} />
            <Route path="/mypage" element={<MyPage />} />
            <Route path="/mypage/profile/new" element={<CreateProfile />} />
            <Route path="/mypage/profile/edit" element={<EditProfile />} />
          </Routes>
        </main>
    </AuthProvider>

Topbar.tsx

과제 스펙 중 하나인, 로그인 여부에 따라서 조건부 렌더링되게 하는 것을 구현하기 위해 AuthContext를 활용했다.

• 로그인 전 :

• 로그인 후 :

• 코드 : user값을 받아와서 user 값이 null인지 아닌지를 바탕으로 로그인 여부를 판단하고 렌더링을 다르게 함.

import { useAuth } from '../contexts/AuthContext';
import { useNavigate } from 'react-router-dom'

const Topbar = () => {
  const navigate = useNavigate();
  const { user, logout } = useAuth();
    // user = isLogined value와 같은 기능

  const handleLogout = async () => {
    await logout();
    navigate('/'); // 로그아웃 이후 홈으로 이동
  };

  return (
    <div className="topbar">
      ...
          {user ? (
          <>
            <span className="user-name">{user.name}님</span>
            <button onClick={handleLogout} className="nav-button">로그아웃</button>
          </>
        ) : (
          <>
            <Link to="/login" className="nav-link">로그인</Link>
            <Link to="/signup" className="nav-link">회원가입</Link>
          </>
        )}
  ...

Signup.tsx

const { signup } = useAuth();

• name, email, password : state로 저장해두기 → input의 onChange 에 setter 함수 설정 → form 제출 시 signup 함수에 바로 state 값 전달

• 회원가입 버튼을 눌렀을 때 form 요소에서 ‘제출’ 이벤트를 처리하기 위한 handleSubmit 함수 필요

  const handleSubmit = async (e: React.FormEvent) => {
    e.preventDefault();
    setError('');
    try {
      await signup({ name, email, password });
      navigate('/'); // Redirect to home on success
    } catch (err: any) {
      setError(err.response?.data?.message || '회원가입에 실패했습니다.');
    }
  };

Login.tsx

  const { login } = useAuth();
  const navigate = useNavigate();

  const handleSubmit = async (e: React.FormEvent) => {
    e.preventDefault();
    setError('');
    try {
      await login({ email, password });
      navigate('/'); // Redirect to home on success
    } catch (err: any) {
      setError(err.response?.data?.message || '로그인에 실패했습니다.');
    }

AuthContext 와 함께한 보안인증 끝! 서버에서 토큰을 받아서 저장하고 이런 로직을 처음 알게 되었다 context의 필요성도 체감한 뜻깊은 과제였다 〰️

1. 로그인 / 회원가입 구현 및 내비게이션 바에 인증 상태 반영
2. react-router-dom의 url parameter을 이용한 query로 서버에서 모집공고 가져오기 및 필터링, 정렬 기능 구현.
3. 마이페이지 내에서 프로필 등록 여부에 따른 조건부 렌더링, 프로필 작성 및 수정 기능 구현.

이 과정에서 배운 것들이 많아서 이후 다른 과목의 팀 프로젝트에서도 배운 내용을 유용하게 활용할 수 있었다.

axios를 이용한 API Client

이전 '천개의 레시피' 클론코딩에서는 사용해야 하는 api 함수들이 한정적이라서, 따로 라이브러리를 사용하지 않았다. 이번에는 조금 더 체계성을 갖추기 위해, 따로 src/api/index.ts 에 axios를 이용한 apiClient를 만들어두었다.

import axios from 'axios';

const apiClient = axios.create({
  baseURL: 'https://api-internhasha.wafflestudio.com',
  // withCredentials: true, // refresh_token 첨부
});
// 인증 토큰 필요 X인 endpoint들
const publicPaths = [
  '/api/auth/user', //회원가입
  '/api/auth/user/session', //로그인
];

// interceptor(API 요청을 intercept하는 아이) : 인증이 필요한 endpoint들에 인증 토큰 자동 부여
apiClient.interceptors.request.use(
  (config) => {
    const isPublicPath =
      config.url &&
      publicPaths.includes(config.url) &&
      config.method === 'post';

    if (!isPublicPath) {
      const token = localStorage.getItem('authToken');

      if (token) {
        config.headers.Authorization = `Bearer ${token}`;
      }
    }

    return config;
  },
  (error) => {
    return Promise.reject(error);
  }
);

export default apiClient;

• client : axios.create로 axios instance를 만들어 두고(apiClient), 다른 파일에서 api요청을 보내야 할때 import apiClient 하여 간편하게 클라이언트를 활용하여 api를 쓸 수 있다.

• interceptor : header 관리

  • 모든 api call을 'intercept'하는 아이로, 위에서는 모든 api 요청 헤더에 인증 토큰인 authToken을 넣는 역할을 하고 있다.
    • 위 코드에서는 publicPaths array에 로그인, 회원가입의 인증 토큰이 필요하지 않은 endpoint들을 넣어 두어, 해당 요청들에 한해서 토큰을 넣지 않게 설정되어 있다.

• request : 다른 파일에서 api요청을 보낼 때 apiClient.{HTTPmethod}('endpoint', {body});와 같은 형식으로 간편하게 활용할 수 있다.

• response : axios를 이용한 api call에서 응답을 받을 경우, axios client가 자동적으로 Content-type header을 확인한 후 json 형식일 경우 response.json()을 내부적으로 수행한 뒤에 json object를 반환해준다. ➡️ 즉, api 요청 결과 json object를 단순하게 response.data로 접근할 수 있다.

  • 공식 문서의 response schema :

        {
          // `data` is the response that was provided by the server
          data: {},
    
          // `status` is the HTTP status code from the server response
          status: 200,
    
          // `statusText` is the HTTP status message from the server response
          // As of HTTP/2 status text is blank or unsupported.
          // (HTTP/2 RFC: https://www.rfc-editor.org/rfc/rfc7540#section-8.1.2.4)
          statusText: 'OK',
    
          // `headers` the HTTP headers that the server responded with
          // All header names are lower cased and can be accessed using the bracket notation.
          // Example: `response.headers['content-type']`
          headers: {},
    
          // `config` is the config that was provided to `axios` for the request
          config: {},
    
          // `request` is the request that generated this response
          // It is the last ClientRequest instance in node.js (in redirects)
          // and an XMLHttpRequest instance in the browser
          request: {}
        }

  • 사용 예시 :

        axios.get('/user/12345')
      .then(function (response) {
        console.log(response.data);
        console.log(response.status);
        console.log(response.statusText);
        console.log(response.headers);
        console.log(response.config);
      });

axios 에러 핸들링 :

구현 과정 중 custom error code를 감지하고, 이에 따라 다른 handling을 하는 로직을 구현해야 했다. 유저의 프로필이 없을 때 반환되는 APPLICANT_002와 같은 에러 코드를 어떻게 확인할 수 있을지가 애매하여 조금 헤맸다.

만약 해당 API를 쏘았을 때 상세 에러코드가 “APPLICANT_002”인 경우, 아직 프로필이 등록되지 않은 상태입니다.

• axios 공식 문서 상 사용법 : Error 객체의 .response property 안, 즉 error.response 에 data, status, headers 등의 error에 대한 부가 정보가 존재한다.

    axios.get('/user/12345')
  .catch(function (error) {
    if (error.response) {
      // The request was made and the server responded with a status code
      // that falls out of the range of 2xx
      console.log(error.response.data);
      console.log(error.response.status);
      console.log(error.response.headers);
    } else if (error.request) {
      // The request was made but no response was received
      // `error.request` is an instance of XMLHttpRequest in the browser and an instance of
      // http.ClientRequest in node.js
      console.log(error.request);
    } else {
      // Something happened in setting up the request that triggered an Error
      console.log('Error', error.message);
    }
    console.log(error.config);
  });

• 활용 코드 :

  • try-catch block에서 try 의 안에서는 response.data로 응답 json string을 받아오고, catch(error) 의 안에서는 error.response.message, error.response.status 등을 이용하여 에러를 표시하는 등 에러 핸들링을 한다.

  • 이때 서버에서 명시한 에러 code는 error.response.data 안에 있기 때문에({ "code":"APPLICANT_002", "message": "Applicant not found" }와 같은 형식), typescript에게 error.response.data 안에 code 속성이 있다고 이야기해주는 type assertion 을 활용한다.

    // MyPage.tsx
    import { isAxiosError } from 'axios';
    
    ...
    catch (e) {
        if (isAxiosError(e) && e.response) {
            const status = e.response.status;
            const data = e.response.data as { code?:string };
            const code = data?.code;
    
            if (code==='APPLICANT_002') {
                setProfile(null);
                return;
            }
            console.error('API error', status, code, e.response.data);
        } else {
            console.error('Unknown Error', e);
        }

api 만으로도 분량이 길어져서 다음 글에서 본격적으로 context를 활용한 전역 변수 활용을 다룰 생각이다. 글을 올릴 때마다 내 글 밑에 있는 더욱 심화된 주제를 다루는 다른 글들이 추천으로 보여서 의기소침해지지만... 아무도 읽지 않아도 내가 다시 읽으면 된다! ^ . ^ 다른 달팽이들은 신경쓰지말자

1. react-dom-router을 이용해서 Multi-Page-App구현하기
2. 하나의 페이지 안에서 페이지 번호를 통해 이동하는 pagination 구현하기
3. fetch로 원하는 데이터를 asynchronous하게 가져오고 가져온 데이터 저장 및 활용하기

이 3가지가 쟁점이 되었던 과제였다. 2048 클론 코딩을 하면서 열심히 코딩을 하더라도 기록하지 않으면 남는 것이 많이 없는 것 같다고 느껴서, 과제 제출 이후 개발 과정 및 에러 로그를 기록했다.

개발 과정

1. 구조를 잡는다.

   

메인 페이지에서 각각의 레시피 카드를 클릭하면, 상세 레시피가 나타나는 별도 path의 페이지로 이동하는 방식이다.

따라서 `react-router-dom` 라이브러리를 이용하고, 각 path에 해당하는 페이지들을 `routes/` 폴더의 `Home.tsx`, `Detail.tsx`로 두었다.

Home에 있는 레시피마다의 카드는 따로 `components/` 폴더의 `Recipe.tsx` 로 분리했다. 페이지네이션 컴포넌트도 마찬가지로 따로 `Pagination.tsx`로 두었다.

```

├── src
│   ├── App.tsx
│   ├── components
│   │   ├── Pagination.tsx
│   │   └── Recipe.tsx
│   ├── main.tsx
│   ├── routes
│   │   ├── Detail.tsx
│   │   └── Home.tsx
│   ├── styles
│   │   ├── App.module.css
│   │   ├── Detail.module.css
│   │   ├── Home.module.css
│   │   ├── Pagination.module.css
│   │   └── Recipe.module.css
```

2. Pagination 컴포넌트

   React에서 pagination을 어떻게 구현할지 고민해보다가, pagination과 리액트 모두 익숙하지 않은 상황에서는 다른 사람의 코드를 검색해서 이해하는게 나을 것이라고 판단했다.

   따라서 검색 후에 정말 깔끔하고 범용성있는 컴포넌트 코드를 https://imdaxsz.tistory.com/37 에서 발견하고, 코드를 살펴보며 이해한 후에, 일부 수정 후 프로젝트에 적용했다.

3. API 확인

   사용할 api인 https://dummyjson.com/docs/recipes 의 설명을 확인해보았다.

   • 전체 데이터 가져오기 :

     한번에 전체 recipe data를 array로 가져오고 페이지에 맞게 slicing해서 이용하는 대신에, api의 limit 과 skip query를 이용해서 현재 페이지에 필요한 item들을 그때그때 가져오는 식으로 구현했다.

       // Home.tsx
        const response = await fetch(
       `https://dummyjson.com/recipes?limit=${itemCountPerPage}&skip=${(currentPage - 1) * itemCountPerPage}&select=name,image,difficulty,tags`
       );

     구현은 덜 귀찮았던 것 같지만, 그때그때 fetch를 해서 그런지 이미지 로드에 시간이 좀 걸렸다.

   ---

   • Detail에서 일부 데이터 가져오기 : Detail로 이동할때, 클릭된 레시피의 정보를 어떻게 전달해주어야 할까 고민했다. 모든 레시피를 가져오고 id와 같은 identifier 값을 바탕으로 찾는 레시피 데이터가 나올때까지 순회하는 것은 너무 비효율적인듯하였는데 공식 링크에서는 id 값만으로 item을 가져오는 설명이 따로 없었다.

     ⇒ 대충 전체를 가져오는 링크 https://dummyjson.com/recipes/ 를 바탕으로 url을 조금씩 변경해보면서 결국 https://dummyjson.com/recipes/2를 시도해보았는데, 정말로 id를 통해서 하나의 object를 가져오는 valid fetch url이었다 (? 시도의 중요성)

     ⇒ 따라서 Detail.tsx에서 해당 링크를 바탕으로 fetch를 하고, 필요한 id 파라미터 값을 url 파라미터의 형식으로 Recipe.tsx에서 전달받기로 결정했다.

   ---

4. 상위 App.tsx에서 Route 구조 잡기

    <Router>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/recipe/:id" element={<Detail />} />
      </Routes>
    </Router>

   → <Detail />에 이동 시 id 파라미터를 전달하기 위해 /recipe/:id명시 필요

5. Home.tsx 구현하기 & Recipe.tsx 구현하기

   typescript를 이용하는 만큼, Home에서 <Recipe /> 로 전달해줄 prop을 interface를 통해서 prop 제약을 걸어두었다.

    // Home.tsx
    export interface RecipeProps {
      id: number;
      name: string;
      image: string;
      difficulty: string;
      tags: Array<string>;
    }
    ...
      const [recipes, setRecipes] = useState<RecipeProps[]>();

   Home에서는 pagination에서 전달된 ?page={pagenum} 파라미터를 useSearchParams()로 받아오고, 이를 바탕으로 page에 맞는 데이터를 fetch해오는 로직이 메인이 된다.

    // Home.tsx
    ...
      useEffect(() => {
        setCurrentPage(parseInt(searchParams.get('page') || '1', 10));
      }, [searchParams]);
      ...      
      const response = await fetch(
      `https://dummyjson.com/recipes?limit=${itemCountPerPage}&skip=${(currentPage - 1) * itemCountPerPage}&select=name,image,difficulty,tags`);

   받아온 데이터는 recipes state에 저장해두고, .map을 통해서 각각의 데이터에 따라 <Recipe /> 컴포넌트를 만든다.

    // Home.tsx
    ...
    <div className={styles.recipeGrid}>
     {recipes?.map((recipe) => (
            <Recipe
              key={recipe.id}
              id={recipe.id}
              name={recipe.name}
              image={recipe.image}
              difficulty={recipe.difficulty}
              tags={recipe.tags}
            />
        ))}
    </div>

   Recipe에서는 받은 prop을 바탕으로 card 구조를 구현하는 것이 다이기 때문에 구조에는 css가 더 중요했다. 이외에는 Recipe 카드를 클릭했을때 Detail로 넘어갈 수 있도록, 전체 컴포넌트를 <Link>로 감싸주고, id 파라미터를 전달해주었다.

    //Recipe.tsx
    ...
        <Link to={`/recipe/${id}`} className={styles.recipeCard} key={id}>
            ...
        </Link>

   ---

6. Detail.tsx 구현하기

   Detail에서도 id를 바탕으로 fetch해올 개별 object의 구조의 type를 명시해두었다.

    interface RecipeDetail {
      id: number;
      name: string;
      ingredients: string[];
      instructions: string[];
      prepTimeMinutes: number;
      cookTimeMinutes: number;
      servings: number;
      difficulty: string;
      cuisine: string;
      caloriesPerServing: number;
      tags: string[];
      image: string;
      rating: number;
      reviewCount: number;
      mealType: string[];
    }
   
    ...
      const [recipe, setRecipe] = useState<RecipeDetail>();

   ingredients는 string[] 형식으로 받아서, 한 줄로 출력하기 위해 ingredients.join(' / ') 을 이용했다.

    const Detail = () => {
      const [loading, setLoading] = useState(true);
      const [recipe, setRecipe] = useState<RecipeDetail>();
      const { id } = useParams<{ id: string }>();
   
      useEffect(() => {
        const getRecipe = async () => {
          const response = await fetch(`https://dummyjson.com/recipes/${id}`);
          const data = await response.json();
          setRecipe(data);
          setLoading(false);
        };
        getRecipe();
      }, [id]);

   ---

7. component마다 styling 적용

   Movie clone, 2048 clone에서는 모듈별로 css를 적용해주지 않고 하나의 style sheet에서 모든 것을 해결했는데 이번에는 각각의 모듈별 style sheet을 만들었다. (ex. styles/Home.module.css )

   → 확실히 컴포넌트별 css 파일을 작성하는 것이 유지보수 및 수정이 더 간편하게 느껴지고, react의 장점을 더 살리는 방법이라고 느껴졌다.

   → 다음에는 row, col과 같은 공통되게 사용되는 class들을 공통된 style sheet나 상위의 style sheet에 두고 사용하는 보다 체계적인 방식을 사용할 예정이다.

   ---

8. 플로팅 바 만들기 :

   Home과 Detail 모두에 공통적으로 ‘천개의 레시피’ 상단 바가 있다. 따라서 이 바는 App.tsx 에 Router 안, Routes 의 밖에 따로 두어서 공통적으로 생기게 했다.

Troubleshooting

React

• 에러 메시지 : Uncaught Error: Too many re-renders. React limits the number of renders to prevent an infinite loop.

  • 원인 코드 :

    
      const Home = () => {
        // Page state
        const [currentPage, setCurrentPage] = useState<number>(1);
        const [loading, setLoading] = useState<boolean>(true);
        const [recipes, setRecipes] = useState<RecipeProps[]>();
        const [totalItems, setTotalItems] = useState<number>(0);
    
        // current page & other parameters
        const [searchParams] = useSearchParams();
        const ITEM_COUNT_PER_PAGE = 6;
        const PAGE_COUNT = 10;
    
        // 문제의 줄
        setCurrentPage(parseInt(searchParams.get('page') || '1', 10));
    

    → state의 setter 함수를 컴포넌트 body의 최상위 레벨에 직접적으로 호출하니, render 시 state가 바뀌고 바뀐 state 다시 render을 발생시키면서 앱이 무한히 render되게 됨.

⇒ **교훈 :**  ⭐ state setter 함수를 컴포넌트의 메인 body에 넣어서는 안된다.

⇒ **해결책  : `useEffect` 사용하기**

```tsx
  useEffect(() => {
    const pageFromURL = parseInt(searchParams.get('page') || '1', 10);
    setCurrentPage(pageFromURL);
  }, [searchParams])
```

• <Link> 이용 : <Link> 태그에 클릭가능하게 만들고자 하는 요소들을 감싸서 넣어주어야 한다는 사실을 인지하지 못하고, <Link ... > </Link>로 비어있는 <Link>를 사용해서 링크 태그가 잘 작동하지 않았다.

  → <Link>가 전체 element를 감싸게 하기

• Detail.tsx에서 useParams()로 id 가져오기 :

    const id = useParams();
    ...
    useEffect(() => {
    ...
        const response = await fetch(`https://dummyjson.com/recipes/${id}`);

  와 같이 실행했더니, 브라우저 콘솔에서 fetch link의 id 부분이 깨져있었다.

  → const {id} = useParams<{ id: string }>();로, 상단에서 정의한 RecipeDetail의 type를 이용해서 string을 받아오는 것을 명시해주었다. 그러니 문제가 해결되었다.

CSS

• classList="class-name"과 같은 형식이 아니라, 모듈별 css를 이용하며 classList={styles.className}과 같이 css class를 적용했기 때문에 class의 이름을 camelCase로 작성하지 않아서 style class가 제대로 적용되지 않았다.

  ⇒ css class를 애초에 camelCase로 명명하거나, bracket notation으로 classList={styles['class-name']}과 같이 이용하자.

• Detail의 css는 만들기 귀찮아서 gemini에게 외주맡겼다.

  그랬더니 recipe instructions와 menu info에 있는 <ul>과 <ol>의 <li> 요소들이 정상적으로 줄바꿈되지 않고, inline 형식으로 나열되었다.

  브라우저의 devtools에서 <li>의 computed styles를 확인해 보니, padding이 이상할 만큼 크게 설정되어 있고 float 속성이 있었다. 상위 css sheet에서 무언가

    ol, ul {
        display: block;
    }
    li {
        float: none;
        display: list-item;
    }

  위와 같이 초기화해주니 적용되었다.

{ key : item, …. , key: item } 형식의 데이터

⇒ API를 사용할때 주고받는 데이터의 형식은 대부분 JSON

• JSON ⊆ Javascript Object

  → 모든 JSON object는 Javascript object이다.

  • Javascript object이지만 JSON은 아닌 예시 : object 안에 function이 포함될 경우

      const user = {
           firstName: "Sam",
           lastName: "Green",
           getFullName: function() {
                return `${this.firstName} ${this.lastName}`
                }
      }

• JSON의 장점은 API가 무슨 프로그래밍 언어로 쓰였든 간에 JSON을 주고받을 수 있다면 다른 언어로도 API와 소통가능한 것이다.

• JSON Operations

  1. JSON string → Object : JSON.parse(string)

     주로 API에서 받은 JSON 문자열을 자바스크립트 객체로 변환할 때 사용.

      const string = '{"firstName":"Sam","lastName":"Green","age": 32}';
      const person = JSON.parse(string);
      console.log(person.firstName); // "Sam"

  2. JSON object → string : JSON.stringify(object)

     객체를 전송/저장에 적합한 문자열(JSON) 로 변환할 때 사용.

      const person = {
        firstName: "Sam",
        lastName: "Green",
        age: 32
      };
     
      const string = JSON.stringify(person);
      console.log(string);
     

API & HTTP methods

API : Application Programming Interface

→ 한 소프트웨어와 다른 소프트웨어가 서로 소통(데이터를 주거나 요구하는 등)하게 해주는 “통로” 같은 것.

“공공데이터 API”라고 하면, 공공데이터를 가지고 있는 기관이(서버) 다른 소프트웨어가 그 정보에 접근할 수 있도록 만든 인터페이스가 그 API라고 할 수 있다.

위 사진처럼, API는 앱과 서버 사이이 중계자라고 볼 수도 있다.

API를 통해 서버에게 무언가를 요구하는 것을 “API request”라고 하고, API에 요청한다고 하기도 한다.

요청의 결과 돌아오는 값 등을 API response라고 한다.

어떻게 요청을 해야 하고, 어떤 형식의 응답이 돌아오고 어떻게 활용해야할지는 주로 API 설명서 (기술 명세서)에서 확인할 수 있다.

⇒ 앱을 개발하면 기능 중에 오늘의 날씨를 표시하게 할 수도 있고, 환율을 보여줘야 할 수도 있는데 이런 개인이 마련하기 힘든 데이터 / 기능을 개발에 사용할 수 있도록 정부 혹은 기업에서 API를 제공하는 것이다.

chatGPT를 생각해보면, 원래 chatGPT는 따로 웹/앱에서 서비스가 존재하는데, 다른 앱에서도 chatGPT를 통한 AI 기능을 제공하는 경우가 많다. 이것도 openAI가 chatGPT API를 (유료로) 제공하기 때문이다.

HTTP protocol / method

• API에 규정된 소통 방식의 표준 중 하나가 HTTP protocol이다. :

  • 특정 서버에 API 요청을 보낼 때, 무엇을 요청하느냐에 따라 요청 URL 뒤의 endpoint(목적지)가 달라진다. 이러한 API 요청을 HTTP 표준(=http protocol)에서는 4가지로 분류하는데, 이를 HTTP method라고 한다.
    

• HTTP method

  • GET : 정보를 가져와달라는(”get”) 요청

    • POST : 특정 정보를 추가해달라는(”post”) 요청

  • PUT : 특정 정보를 어떻게 수정해달라는(”put” A in B) 요청

  • DELETE : 정보를 삭제해달라는 (”delete”) 요청

    → Get은 read 요청, 나머지 셋은 수정을 요하는 write 요청.

    ∴ POST, PUT, DELETE는 request URL과 별도로, “body”에 부가적인 data를 담아 요청해야 한다.

fetch(URL)

대표적인 asynchronous WebAPI 함수로, 브라우저에서 외부/내부 서버로 요청(request) 을 보낼 때 사용한다.

fetch()의 인자로 요청할 목적지 서버인 API endpoint(URL) 를 넣으면, 해당 URL로 요청을 보내고 응답(response) 을 받아온다. 응답의 본문은 보통 JSON 문자열(정보를 담은 텍스트)이다.

→ 기본적으로 GET request이며,

fetch(URL, {method: ..., headers: ..., body: ...}) 이렇게 추가적인 argument를 넣어줌으로써 POST, PUT, DELETE request가 가능하다.

Fetch (GET) 사용법

• fetch(URL)의 반환값은 Promise
  

  → 따라서 반환값을 활용하기 위해 chaining으로 .then(...), .catch(...), .finally(...)를 사용한다.
  

  ⇒ 서버에 요청을 보내고 응답을 받을 때까지 무작정 웹을 멈추고 기다리는 것을 막아준다.

    fetch(URL)
      .then((response) => {
        return response.json();      // JSON 본문을 파싱할 준비
      });

  Implicit Return 형식 :

    fetch(URL)
      .then((response) => response.json());

• response.json()

  • API response가 JSON 문자열일 때,

  • JSON.parse()처럼 JSON string → object 변환.

    다만 차이점은 JSON.parse()는 synchronous 함수이지만, .json()은 Asynchronous 함수로서 Promise를 반환한다.

    → 따라서 parse된 json object 활용을 위해 다음 단계에서 또 .then(...) 으로 결과를 받아야 한다.

형식

fetch(URL)
  .then((response) => response.json())  
  // 1. response → JSON parsing (Promise)
  .then((data) => {                     
  // 2. use parsed object
    console.log(data);
  });

⇒ Promise chaining : fetch와 response.json() 모두 Promise를 반환하므로, .then()을 두 번 사용해주어야 한다.

• 관습적인 명명들 :

  • response : fetch에서 처음 .then()으로 읽어오는 값, 진짜 데이터를 받기 전의 중간 과정

  • data : response.json()에서 .then()으로 받는 값이자 우리가 관심있는 데이터 (∴ 이름을 data로 할 것을 권장)

    API의 종류마다 데이터 타입이 다르므로 API 명세서 확인 후 (or console.log(data)로 확인) API에 맞게 데이터를 다루어야 한다.

URL & Endpoint :

하나의 서버는 base URL이 있고, 서버에 무슨 정보를 요청하는지에 따라 endpoint가 달라진다.

요청 보내는 URL = Base URL + endpoint

• e.g. 트위터 API의 base url : https://twitter.com/api/v1

  • endpoints :

       /users.json
       /notifications.json
       /tweets.json
       /account/password.json

  → 실제 fetch url

       https://twitter.com/api/v1/users.json
        https://twitter.com/api/v1/notifications.json
        https://twitter.com/api/v1/tweets.json
        https://twitter.com/api/v1/account/password.json

fetch 사용 예시 :

fetch(”https://jsdemo-3f387-default-rtdb.europe-west1.firebasedatabase.app/chapters/all.json")
.then(response ⇒ response.json())
.then(data ⇒ console.log(data));

→ 위 API에서 받은 데이터가 다음과 같이 array of object일때,

[
  { id: 1, isCompleted: true, title: "Basic Functions" },
  { id: 2, isCompleted: true, title: "Strings" },
  { id: 3, isCompleted: false, title: "Numbers" },
  { id: 4, isCompleted: true, title: "Variables" },
  { id: 5, isCompleted: false, title: "Conditions" },
];

completed chapter만으로 구성된 새로운 array를 만들어서 displayCompletedChapters()에 넣어주고 싶다면 :

const getChapters = () => {
  fetch(
    "https://jsdemo-3f387-default-rtdb.europe-west1.firebasedatabase.app/chapters/all.json"
  )
    .then((response) => response.json())
    .then((data) => {
      console.log(data);
      const completedChapters = data.filter((data) => {
        return data.isCompleted == true;
      });
      displayCompletedChapters(completedChapters);
    });
};

function displayCompletedChapters(chapters) {
  console.log("Received", chapters);
}

getChapters();

Handling fetch errors :

• response status code : API에 fetch request를 보낸 후 받은 응답에는 100~600의 범위의, authentiation status code가 함께 반환되어 응답이 정상적으로 반환되었는지 등의 상태를 알려준다. (i.e HTTP 상태 코드 표)

  • 1XX (100~199) : informational response - 정보 제공. 임시 응답으로, 계속 진행하라는 의미

  • 2XX (200~299) : 성공적인 응답! → 가장 흔히 볼 수 있는 숫자 범위 e.g. 200 + response text "OK" : 요청이 성공적으로 시행되었으므로 응답이 "OK"라는 뜻

  • 3XX (300~399) : redirect - 특정 url에서 다른 url로 이동한 후 추가 동작이 필요한 시 e.g. → 301 + response text "Moved Permanently" : 요청할 URL이 이동되었으니 그 주소로 다시 시도 → 302 + response text "Found"

  • 4XX (400~499) : client error - 에러의 이유가 클라이언트(나)에게 있다 e.g. → 401 + response text "Unauthorized" : 데이터가 인증(authentiation)을 필요로 하는 경우 → 404 : 존재하지 않는 url을 입력한 경우 (404 not found)

  • 5XX (500~599) : server error - 에러의 이유가 서버 측에 있다 e.g. → 500 + status text "Internal Server Error" : 서버 측 코드에 버그가 있음 → 504 + status text "Gateway Timeout" : 서버 트래픽 과다

    (추가 참고 : https://hongong.hanbit.co.kr/http-상태-코드-표-1xx-5xx-전체-요약-정리/)

• Error catch
  ↓ 무언가 부족한 코드 예시

    fetch(URL)
         .then(response => response.json())
         .then(data => {
              console.log(data);
         })
         .catch(error => {
              console.error(error);
    });

  위 코드에서, catch는 fetch()가 반환하는 promise가 rejected state가 될 때 실행 : client-server 연결 문제의 network error의 경우. 하지만 fetch()가 정상작동했지만 서버 측에서 에러 코드를 반환한 경우, catch가 에러를 잡지 못함.

  → 즉 fetch.then()안에서 별도로 에러를 다루어주어야 함.

  ⇒ 이 안에서의 구현, 즉 어떻게 에러를 다룰지는 API마다 다름.

  ---

  json으로 전환되기 전의 response object는 fetch 성공 여부를 확인할 수 있는 “ok” 필드를 가지고 있는데, 이는 에러코드(response status code)가 2xx 범위일때(i.e,클라이언트/서버 에러 모두 없는 성공적인 응답일때) “ok” 값을 가진다.

  → 이용해서 에러 다룰 수 있음.

완전한 형식

fetch(URL)
    .then(response => {
        if(!response.ok) {
            // 4xx or 5xx error
            throw new Error(“API issues.”);
        }
        /* catch로 잡히지 않는 API error을 다룬다.
        => throw문은 직접 promise를 reject
        */
        return response.json();
    })
    .then(data => {
        console.log(data);
    })
    .catch(error => {
    /* catch문에서는 network error을 다룬다. */
        console.error(error);
    });

Fetch POST, PUT, DELETE 사용법

앞서 말했듯 fetch()는 기본적으로 GET 요청이며, POST / PUT / DELETE 요청을 하기 위해서는 method, headers, body가 명시된 Javascript Object를 url 다음의 argument에 넣어주어야 한다.

• Headers : 주로 보내는 요청에 관한 meta-data를 첨부하여 넣는다. 대표적인 항목은 “Content-Type”으로, 어떤 형식의 데이터를 주고받는지에 대한 설명이다.

• Body : 요청에 대한 직접적인 data를 넣는다. (ex.수정할 데이터)

  • JSON object를 JSON.stringify를 통해 string으로 변환하여 넣어주어야 한다.

    → API에서 응답을 받을 때는 string → object 변환이 이루어졌던 것처럼, API에 요청 시 object를 바로 주지 않고 API가 활용할 수 있는 형식인 string으로 변환하는 것이 필요하다.

템플릿 :

fetch(URL, {
    method: "POST", // or PUT or DELETE
    headers: {
        "Content-Type": "application/json"
    },
    body: JSON.stringify({
        key1: 'value1', // replace with key/value based on documentation
        key2: 'value2', // same as above (if needed)
    })
})
.then(response => response.json())
.then(data => {
    console.log(data); // read server response
});

Fetch Wrapper 사용

• 웹을 만들다 보면 동일한 base url에다 endpoint만 다른 fetch 문을 많이 사용하게 됨

  → fetch wrapper을 구현해서 사용할 시 더 간결.

  response를 json으로 미리 바꾸어주고, header의 Content-Type가 json으로 미리 설정되어 있도록, FetchWrapper class를 구현하여 사용할 수 있다.

• e.g.

  • fetch wrapper 없이 fetch (GET, PUT)

      fetch(`fetchURL/notifications/new.json`)
      .then(response => response.json())
      .then(data => {
          console.log(data);
      });
    
      fetch(`fetchURL/write.json`, {
          method: "PUT",
          headers: {
              "Content-Type": "application/json"
          },
          body: JSON.stringify({
              grade: 18
          })
      })
      .then(response => response.json())
      .then(data => {
          console.log(data); // read server response
      });
    

  • fetch wrapper 사용 시 :

      const API = new FetchWrapper(“fetchURL/”);
    
      API.get(“notifications/new.json”).then(data => {
          console.log(data);
      });
    
      API.put(“write.json”, {
          grade: 18
      }).then(data => {
          console.log(data);
      });

    → 두번째 argument로 body만 넣어주고, body의 stringify도 fetch wrapper에서 처리하고 있는 구현.

Fetch Wrapper 구현

• 사용하는 API 및 사용자의 목적에 따라 customization이 가능하지만, 공통적으로는 base URL을 파라미터로 받는 constructor, 그리고 endpoint를 파라미터로 받는 get, put, post, delete 각각의 class method가 필요하다.

  → get, put, post, delete 메서드가 반환하는 결과에 .then을 이용하여 asynchronous하게 데이터를 활용할 수 있도록, 각 method는 Promise를 return해야 한다.

  추가적으로는 반환되는 응답을 method에서 미리 response.json()을 처리해주거나, 필요 시 특정 header을 디폴트로 보내게 하거나, 요청의 body를 알아서 stringify하게끔 구현할 수도 있다.

→ get 이외의 put, post, delete 메서드들은 작동 방식이 비슷하기 때문에, 공통적으로 사용할 수 있는 private helper method를 정의해두고 사용할 수 있다.

class FetchWrapper {
    constructor(baseURL) {
        this.baseURL = baseURL
    }
    **get**(endpoint) {
        return fetch(this.baseURL + endpoint, {
            headers: {
                "Content-Type": "application/json"
            }
        }).then(response => response.json());
    }

    **post**(endpoint, body) {
        return this.#send("post", endpoint, body);
    }

    **put**(endpoint, body) {
        return this.#send("put", endpoint, body);
    }

    **delete**(endpoint, body) {
        return this.#send("delete", endpoint, body);
    }


    #send(method, endpoint, body) {
        return fetch(this.baseURL + endpoint, {
            method: method,
            headers: {
                "Content-Type": "application/json"
            },
            body: JSON.stringify(body)
        }).then(response => response.json());
    }
}

→ 필요시 wrapper에서 수행하는 작업에 authentication, error catch 등 필요한 기능을 추가할 수도 있다.

코드 순서가 작업 순서와 마찬가지. 순차적으로 call stack(first in, last out)에 넣어지고, 넣어지자마자 바로바로 실행됨

Asynchronous Callback - 비동기 처리 함수

→ fetch, setTimeout 과 같은 Web API에서 제공되는 비동기 처리 함수를 이용할 수 있다.

ex.

setTimeOut(callback, milliseconds)

• setTimeOut : 실행될 callback function을 지정된 시간 후에 실행되도록 예약(queue)하는 함수.

  → 기존의 프로그램 흐름에서 벗어나 asynchronous하게 실행됨.

  task queue가 비어있는지 감지하고 callback을 call stack으로 이동하는 것은 javascript의 event loop의 역할.

⇒ fetch와 같은 API를 사용할 시, API request에 대한 response는 asynchronous할 것.

(서버에 요청을 보내면 요청이 올 때까지 시간이 좀 걸림 → 요청이 전부 수행될때까지 브라우저를 무작정 멈추어 둘 수는 없으므로, 서버의 요청이 도착하면 데이터 처리 코드를 실행하도록 aynchronous한 방식으로 코드를 작성해야 한다.)

callback pattern :

• callback : function의 파라미터로 다른 function definition을 넣는 것.

  → callback pattern : asynchronous한 코드를 작성하기 위해 callback을 이용할 수 있다.

• success callback : 함수 수행 성공 이후 실행되는 asynchronous callback

  • e.g. 아래 welcomeUser에서 두 번째 인자로 전달해주는 callback은 success callback이다.

      // usage
      welcomeUser("Sam", () => {
          console.log("Done welcoming user");
      });
    
      // definition
      const welcomeUser = (name, callback) => {
          setTimeOut(() => {
              console.log(`Welcome ${name}`);
              callback(); //success callback
              }, 1_000);
      }

• error callback : 함수 수행에 모종의 이유로 실패할 시 실행되는 asynchronous callback (e.g. reason => {console.error(reason);), 주로 success callback 다음 순서의 인자로 입력된다.

• e.g. success callback이 연산의 결과를 parameter로 받는 경우

    export const sumGrades = (grades, callback) => {
        // simulate expensive operation
        setTimeout(() => {
            const sum = grades.reduce((total, current) => total+current, 0);
            if (callback) {
                callback(sum); // call success callback with the sum
                }
            }, 1_000);
        }

    const calculateSum = (grades) => {
        sumGrades(grades, result => {
            console.log(`The sum is : ${result}`);
            });
        }
        calculateSum([18,10]);

Callback pattern vs Promise :

Promise: Promise의 결과에 따라 callback을 수행할 수 있게 하는 wrapper의 일종이라고 생각할 수 있음.

→ Promise를 이용하여 asynchronous code를 작성하는 것이 보다 직관적인 syntax

e.g.1. callback을 이용할 경우 생길 수 있는 callback hell ..

• 비교 예시
  

  callback pattern :

    sumTemperatures(temperatures, value => {
        console.log(value);
    }, reason => {
        console.error(reason);
    });

  → promise : .then과 .catch() 로 함수 실행 순서를 정해줄 수 있으므로 callback 인자 순서를 상관하지 않아줘도 됨, 보다 직관적.

    sumTemperatures(temperatures)
        .then(value => {
            console.log(value);
        })
        .catch(reason => {
            console.error(reason);
        });

그래서 promise가 뭔데?

Promises:

• 비유 : 키오스크에서 음식 주문 후 받는 번호표가 Promise object와 비슷하다고 볼 수 있다. (주문 후 아직 음식이 없지만, 음식이 될 수 있는 것.)

  주문이 그냥 배달될수도(resolve) 취소될수도(rejected) 있고, .then(), .catch() method로 배달과 취소 각각의 경우를 다룰 수 있다. (e.g. then() : 음식이 됨, catch() : 음식이 되지않음 ..)

• .then() , .catch() : Promise를 반환하는 함수에만 쓸 수 있는 method. fetch와 getUserMedia 등 여러 WebAPI가 promise를 활용하기 때문에 중요하다. → 각각 Promise 실행 성공/실패의 경우 무엇을 할지를 다룬다.

• e.g. 아래 wait() 함수 : 인자로 기다릴 시간을 받고, promise를 결과로 반환

    const wait = milliseconds => {
        return new Promise(resolve => {
                setTimeout(() => {
                        resolve();
                    }, milliseconds);
                }, reject => {
                    reject("function rejected");
                });
    }

  → 반환되는 Promise의 파라미터 :

  • resolve : success callback과 같은 역할, wait.then(resolve)와 같은 형식으로 전달됨.

    • reject : error callback과 같은 역할, wait.catch(reject)와 같은 형식으로 전달된다.

    ⇒ 이때 .then()과 .catch()는 wait이 반환하는 Promise에 불러져서 promise에 callback을 전달해주는 역할을 함.

    wait(1_000).then(() => {
     console.log("waited 1 second");
    })
    .catch(() => {
     console.log("rejected");
    });
    ;

• Promise의 state

  • pending : promise가 외부 함수에 의해 반환되었지만 아직 실행되지 않은 상태 (e.g. 성공/실패 결과가 정해지지 않음)

  • fulfilled : promise 실행이 성공하여 이에 따른 success callback의 실행까지 완료됨

    → promise가 fulfilled 상태가 되면 .then(callback)이 실행된다

  • rejected : promise가 성공적으로 실행되지 못했을 때의 state (ex. API 응답이 네트워크 이슈로 성공적으로 수령되지 못했을 때)

    → 이때 실행할 에러 처리용 callback을 .catch(callback)으로 전달해줌으로써 에러를 다루는 로직을 구현할 수 있음(에러메시지 띄우기 등)

e.g. :

```jsx
console.log(wait(1_000));
// console : Promise {<pending>}
```

```jsx
const result = wait(1_000);
console.log(result);
// console : Promise {<pending>}
```

→ Promise의 callback 실행을 위해서는 1초가 지나야 하기 때문에, 함수를 부르고 난 직후의 출력은 <pending> 상태를 보여준다.

```jsx
const result = wait(1_000);
console.log(result);
// Promise {<pending>}

result.then(() => {
    console.log(result);
    // Promise {<fulfilled: undefined>}
});
console.log(result);
// Promise {<pending>}
```

→ `wait()`이 반환하는 promise가 result에 담겨있으므로, result에 `.then`을 사용할 수 있다.

⇒ result.then() 안의 `console.log(result)`만 promise가 fulfilled 상태가 된 이후 실행되므로, 출력값은 아래와 같다

```jsx
Promise {<pending>}
Promise {<pending>}
Promise {<fulfilled: undefined>}
```

Promise 만들기

• promise를 사용하기 위해서는 Promise를 반환하는 함수를 정의해야 한다.
  
  

  → 일반적인 형식 :

    const function = (parameter) => {
                                            // Executor!
        return new Promise((resolve, reject) => {
            /* 함수에서 실행할 statement들 */
            resolve(); // promise가 성공적이면 실행될 .then(callback)
            reject(); // promise가 실패하면 실행될 .catch(callback)
        });
    }

  이때 Promise가 초기화될때 받는 argument를 executor(()⇒{})이라고 한다.
  

  Promise가 실행 완료되었을 때(i.e, fulfilled state가 되었을 때) 실행하는 callback인 resolve()함수는 executor의 첫번째 인자이다.
  

  Promise가 실행 실패했을 때(i.e, rejected state가 되었을 때) 실행하는 callback인 reject()함수는 executor의 두번째 인자이다.
  

  즉 Promise의 argument인 executor의 argument ()에 사용할 callback들(resolve, reject)이 들어가고, body {} 에는 그 callback들을 promise로 활용하는 function의 내용이 있다.

Resolving data

• Promise가 성공적으로 실행되어 ‘fulfilled’ state가 되었을 때, promise가 “resolve”(해결) 되었다고 한다.

  → ”*promises can resolve with data”* : promise는 외부 함수(자신을 반환하는 함수)가 다루는 data를 자신 내부에서 활용할 수 있다.

  → 즉, .then(resolve)으로 전달되는 resolve 함수는, argument로 외부에서 전달될 data를 넣어줌으로써 이를 활용할 수 있다. ⇒ resolve(data)

  e.g. 실제 구현의 경우 외부 API에서 반환되는 data를 활용하는 코드를 작성할 수 있다.

• 예시 : 사용자가 입력한 milliseconds 만큼 기다렸다가, 기다린 시간을 초 단위로 console에 보여주는 resolve callback을 실행하는 wait 함수의 구현

    const wait = milliseconds => {
        return new Promise(resolve => {
            setTimeout(() => {
            resolve(milliseconds / 1_000);
            }, milliseconds);
        });
    }
    wait(2_000).then((data) => {
        console.log(data); // 2
    });

Rejecting data

executor의 두번째 callback argument는 Promise가 rejected state일때 실행되는 .catch(callback)과 동일한 reject() 함수이다.

resolve()와 같이 reject()도 함수의 data를 전달받아 이용할 수 있다.

• e.g. 항상 reject되는 함수 :

    const alwaysFail = () => {
        return new Promise((resolve, reject) => {
            reject("Failed. That's the only thind I do.");
        });
    }
    alwaysFail()
        .then(() => {
            // never called
    }).catch(data => {
            console.error(data);
    });

Promise chaining

resolve, reject와 같이 promise에서 실행하는 callback들도 Promise를 반환할 수 있다. 이 경우 다음과 같은 promise chaining이 가능하다.

• fetch example

    fetch("some-url")
        .then(response => response.json())
        .then(data => {
            console.log(data);
        });

Promise.finally() :

• .then()은 promise가 성공적으로 실행돼서 fulfilled 상태가 되면 수행하고, .catch()는 promise 실행에 실패해서 rejected 상태가 되면 실행한다.
  

  ⇒ .finally()는 fulfilled든 rejected든 상관없이 pending 상태에서 벗어나면 callback을 실행한다.
  

  ⇒ .then()과 .catch()에서 공통적으로 실행하는 statement가 있으면, .finally()로 깔끔하게 넣어줄 수 있음. (e.g. console.log(”finished”); )
  

• ex. 로딩을 시작하고 끝내는 startLoader(); stopLoader() 함수를 가상의 API 함수 getWeatherIn()의 시작과 끝에 각각 두고 싶을 때 (기상정보가 반환됐을 때 loader을 안보이게 하는 등)

    startLoader();
    getWeatherIn("Amsterdam")
        .then(data => {
                console.log(data);
            })
        .catch(error => {
                console.error(error);
            })
        .finally(() => {
                stopLoader();
        });

Promise.all() & Promise.any()

Promise.all() :

• method .all()이 인자로 받는 모든 promise가 fulfilled일때, .all()을 부른 Promise 또한 fulfilled 상태가 되고, 그 외에는 reject 상태가 된다.
  

  → 여러 개의 promise를 동시에 실행하고 모든 promise가 성공할 때까지 기다릴 수 있다.

• e.g. Javascript file과 CSS file을 동시에 불러오는데, 두 파일 모두 불러오기 전까지 component를 render하기 싫을 때.

    Promise.all([promise1, promise2]).then(values => {
            console.log(values);
    }).catch(error => {
            console.error(error);
    });

Promise.any() :

• .all()과 사용법이 비슷하지만, 인자로 받은 모든 promise가 아니라 그 중 하나의 promise라도 성공하면 가장 처음 성공하는 promise의 data를 받아온다.

• e.g.

    Promise.any([promise1, promise2]).then(value => {
        console.log(value);
    }).catch(error => {
        console.error(error);
    });

➡️ 이제는 instance variable 이름 앞에 #을 부티면 private field로 취급된다.

• private class field는 constructor 안에서 선언될 수 없고, 밖에서 선언된 이후 constructor에서 값을 할당하는 식으로 진행되어야 한다.

  class User {
       #votingAge;
  
       constructor(){
            this.#votingAge = 18;
       }
  } 

• private class field의 유용한 점 : class 바깥에서 field의 값을 임의로 수정할 수 없다. 합법적인 수정 경로인 setter 함수를 정의해준다면 가능하다. 또한, setter 함수에서 값에 대한 제약을 걸어두기 용이하다.

   class User {
     #votingAge = 18;
  
     get votingAge(){ return this.#votingAge;}
  
     set votingAge(age) {
          if (age>= 18) this.#votingAge = age;
     }
      }
  
     const user = new User();
     user.votingAge = 10; // invalid
     console.log(user.votingAge); // still 18
     user.votingAge = 20; // meets check
     console.log(user.votingAge); // changed to 20
  

  ---

• Private class method* : => class instance method의 이름 앞에도 #를 붙이면 private class method가 되어서 class 정의 내부에서만 사용 가능하다.

javascript에서 모든 object는 (특정 class, 혹은 원래 존재하는 primitive type의 instance) 하나의 큰 상위 Object class의 prototype를 계승한다. 이때 Object class - parent class - child class 사이에서의 prototype에 대한 계승을 Prototype Chain이라 한다.

Prototype 정의 참고 : [JavaScript] Class == Function & Prototype Inheritance

Inheritance와 prototype chain :

  class Parent {
    parentMethod() {
        // 
    }
  }

  class Child extends Parent {
      childMethod() {
          //
      }
  }

  const child = new Child();

• Object.getPrototypeOf(child) -> 실행 결과 : Parent {}, Child class의 prototype는 Parent의 prototype를 '원형(=prototype)으로 한다.

• Object.getPrototypeOf(Object.getPrototypeOf(child)) -> 실행 결과 : {}, Parent class의 prototype는 기본적인 Object.prototype를 '원형'으로 한다.

• Object.getPrototypeOf(Object.getPrototypeOf(Object.getPrototypeOf(child))) -> 실행 결과 : [Object: null prototype] {}, Object보다 상위의 class, 즉 Object.prototype보다 prototype chain에서 상위에 있는 것은 null 뿐이다.

  ➡️ 이런 꼬리물기와 같은 inheritance 관계가 바로 prototype chain이다.

  
  ### **Takeaway** 이것 때문에 `Child` class에서 `Parent` class의 `parentMethod()`를 explicitly override하지 않고도 부를 수 있음. (`child.parentMethod()`) -> `extends`를 이용한 inheritance는 prototype의 모든 member function을 넘겨주는 식으로 작동하는 prototype inheritance라는 사실과도 연관이 있음.
  

• 예시:

  class Welcome
      sayHello() {
          return "Hello World!";
      }
  }
  const welcome = new Welcome();
  welcome.sayHello();

  위 코드에서 welcome 인스턴스는 class Welcome의 인스턴스이므로 Welcome.prototype에 있는 Welcome의 class method에 접근할 수 있는데, 이 class Welcome은 Object class를 계승하므로 인스턴스가Object.prototype에 있는 모든 것에 접근할 수 있다.

function 형식으로 표현한 class

• class 정의 : 마치 constructor을 정의하듯 class를 정의함

  function classname (instanceVariable) {
      // constructor contents
  }

• instance method : classname.prototype.methodname = ...의 형태로 따로 정의해준다. 예시 : width, height 두 개의 instance variable과 isSquare() 하나의 class method를 가지는 class Rectangle

  function Rectangle = (width, height) {
        this.width = width;
      this.height = height;
    }
  Rectangle.prototype.isSquare = function () {
        return this.width === this.height;
   }

  아래 class syntax 코드와 비교

  class Rectangle {
          constructor(width, height) {
              this.width = width;
              this.height = height;
          }
          isSquare() {
              return this.width === this.height;
          }
      }

prototype는?

특정 function (즉 class)의 모든 instance method를 포함하는 object. (최상위 class인 object에게서, 모든 하위 class instance들이 상속받는 property라 할 수 있다.)

• prototype로 classname class에 funcname 클래스 메서드 추가하기

  classname.prototype.funcname() = function(){...}

  위와 같이 classname.prototype에 funcname method를 추가하면, 모든 classname instance가 이 method를 공유하며 method에 접근할 수 있다. 또한 위의 Rectangle에서 보였듯, class의 prototype에 추가된 method 내부에서는 this.문법으로 class instance variable에 접근할 수 있다. (class method로 치부되므로)

• 예시 :
  String.prototype.trim() ➡️ String instance에 trim()을 부를 수 있다는 뜻 (즉 trim은 String에 대한 instance method임)

  
  

프로토타입 상속 - Prototypical Inheritance

• 일반적인 상속의 한계 : 한 클래스를 상속Inherit하면, 그 클래스가 가지고 있는 모든 member function(=instance method)가 함께 온다. 상속받을 parent class의 모든 member function이 필요하다면 괜찮지만, 일부만 필요한 경우에는 다소 쓸모없는 측면이 있다. (ex. 원치 않는 일정이 있는 패키지 여행의 비애) 이를 극복할 수 있는 것이 Javascript의 prototype inheritance이다.

  
  

• prototype inheritance : 원하는 instance method만 골라담아 class를 정의할 수 있는 상속.

  • 앞에서 class==function임을 이야기하면서, function 표현법으로 class에 instance method를 추가하기 위해선 그 class(=function) type의 prototype에 메서드를 추가하면 된다고 설명했다.
    ➡️ 비슷하게 새로운 class를 정의할 때, 다른 class(=parent class)에서 가져오고 싶은('상속'받고 싶은) instance method가 있다면,

      class1.prototype.func1 = class2.prototype.func2;

    와 같이 parent class prototype에서 메서드를 가져와서 child class prototype에 추가하는 방식으로 원하는 instance method만 선택적으로 상속받을 수 있다!
    ➡️ 이렇듯 일반적인 extends를 이용하는 상속과는 달리, 클래스 전체가 아닌 원하는 method들만 prototype를 통해 상속받는 것을 Prototype Inheritance이다.

    즉 prototype inheritance를 사용하면, 다른 class의 method를 원하는 대로 조합해서 새로운 class를 만들 수 있다.

• ex. prototype inheritance로 GorillaBanana 클래스 만들기

  • function syntax :

        function Gorilla() {
        }
        function Banana() {
        }
        function GorillaBanana() {
        }
    
        Gorilla.prototype.eat = function() {
            console.log("Gorilla eats");
        }
    
        Banana.prototype.peel = function() {
            console.log("Banana peeled");
        }
    
        // Extend our GorillaBanana with the Gorilla's eat() method
        GorillaBanana.prototype.eat = Gorilla.prototype.eat;
    
        // Extend our GorillaBanana with Banana's peel() method
        GorillaBanana.prototype.peel = Banana.prototype.peel

  • eat, peel 메서드만 상속할 수 있다. extends 를 사용하지 않고 class를 정의한 후 prototype를 이용하여 Gorilla class에서는 .eat만, Banana class에서는 .peel만 가져온다! ⇒ 고릴라를 만들고 싶다고 해서 전체 정글을 가져오는 대신, 바나나를 까서 먹는 고릴라만 가져올 수 있는 것

    • class 형식 :

           class Gorilla {
               eat() {
                   console.log("Gorilla eats");
               }
           }
      
           class Banana {
               peel() {
                   console.log("Banana peeled");
               }
           }
      
           class GorillaBanana {}
      
           // Selectively copy the methods
           GorillaBanana.prototype.eat = Gorilla.prototype.eat;
           GorillaBanana.prototype.peel = Banana.prototype.peel;
      
           const gb = new GorillaBanana();
           gb.eat();  // "Gorilla eats"
           gb.peel(); // "Banana peeled"

일반적인 extends를 이용한 상속 뒤에도 사실 prototypical inheritance가 작동한다.

⇨ parent class의 모든 member function을 가져오는 형태로! 즉, Javascript에서 inheritance의 기본 원리는 prototype inheritance라는 것.

코드 파일이 변경해 온 역사를 기록해둘 수 있는, 버전 관리 시스템.

• git init :

  로컬 폴더 위치를 git으로 관리할 수 있게끔 git에 경로를 등록하여, 해당 폴더를 git local repository로 만든다. 폴더 내에 .git 폴더가 생성되며, 폴더 내 모든 변경사항이 .git내에 기록된다. (새로 파일을 만들 때, 즉 첫 initialization 단계에서만 실행하면 된다.)
  

  (repository - 한 프로젝트의 파일과 버전 이력을 관리하는 공간으로, .git 폴더 등 로컬 환경에 있는 저장소를 local repository, github과 같이 온라인 서버에 있는 저장소를 remote repository라 한다.)

변경사항 git에 기록하기 (local)

• git add : git system이 파일 변경을 추적할 수 있게 파일을 ‘등록’한다.
• git commit : 파일 변경 사항을 기록해 둔다.
  • commit : 변경 사항을 저장할 수 있는 가장 작은 단위이다. 각 commit마다 구체적인 변경 사항이(어느 줄이 어떻게 바뀌었는지) 표시되어 쉽게 기록할 수 있다.
  • git commit -m “message” : message에 무엇을 바꾸었는지 간략하게 설명을 작성할 수 있다.

변경사항 git에 기록하기 (remote)

위의 git init, git add와 git commit이 로컬 git 저장소에 변경사항을 기록하는 방법이라면, Github과 같은 온라인 서버에 원격 저장소를 만들기 위해서는 git remote 와 git push 를 이용할 수 있다.

• git remote add origin [https://github.com/nickname/repository-name.git](https://github.com/nickname/repository-name.git) : 로컬 저장소 위치를 원격저장소인 github repository와 연결시킨다.

• git push {원격저장소} {branch} : 명시한 원격저장소의 branch에 commit 내역을 “push”, 즉 저장한다. (git add 및 git commit 이후 실행)

  • ex. git push -u origin master :

  • -u 옵션 : --set-upstream 과 같은 뜻으로, 앞서 명시해준 원격저장소(origin)의 master branch와 해당 로컬 저장소 사이에 연결관계를 형성함.
    

    → git push 만으로도 연결관계를 형성한 원격저장소에 push 가능.

(waffle studio 23.5 OT)

branch :

• ‘평행세계의 코드’라고 볼 수 있다. 원본 코드 파일들이 있는 main에서, 복사본인 branch들을 만들고 그곳에서 원본 코드에 영향을 주지 않으며 코드를 작성할 수 있다. 이후 main의 코드와 합칠 수 있다.

  → 코드의 원본 파일을 영향주지 않으면서 코드 작성을 하고 싶을때 이용할 수 있다.

  • branch 만들기 : git branch <branch-name>

  • branch로 이동 : git switch <branch-name>

  • branch의 코드를 main과 합침 : git merge <from-branch>

    또한 협업 시, 여러 사람이 서로 다른 작업을 할 때 하나의 공동 작업공간 (organization repository)에서 각각 branch를 만들어 독립적인 작업 영역을 만들고 이후 작업이 완료되면 main으로 merge한다.

    ⇒ 공동 repository에서 개인 branch를 복사하는 것을 repository를 ‘fork’한다고 하며, 그리고 merge 이전에 공동작업자들에게 코드 변경 사항에 대한 확인을 보내는 것을 ‘Pull Request’ 즉 PR이라 한다.

• fork repository : 외부 서버에 있는 repository를 내 repository로 복사해오는 것이라 볼 수 있다.

pull request 만들기:

• 오픈소스 프로젝트와 같이 외부 공개된 public repository에 있는 코드에 수정사항을 남기고 commit할 경우에는, 외부 repository를 내 repository로 fork해온 후 해당 repository를 로컬 저장소로 가져와준다. (clone , pull )

  (fork는 외부 repository에 대한 나만의 branch를 생성하는 거라 할 수 있다.)

  이후 해당 로컬 저장소에서 파일을 수정한 후, commit 및 push한 후 원본 repository에서 pull request를 생성할 수 있다.

• pull request, 즉 PR은 자신이 fork를 통해 만든 branch를 외부 repository에 merge(=수정, 즉 commit내역을 승인)하기 전에 이를 확인 받기 위한 과정이다. pull request 원본 repository의 소유자는 pull request를 확인하고 이를 승인/거절할 수 있다.

    cd file/location/
    git clone https://github.com/nickname/repo-name.git
    git pull

정리

    local repository 
    -- | commit, push | --> 내 git server 
    —- | pull request | --> 외부 git server

    외부 git server 
    -- | fork | --> 내 git repository
    --> | clone | --> 내 local repository

예시

• local 저장소에 있던 gift-card-maker을 local repository로, git에 경로 등록하기

         ~/projects                       
        ❯ cd gift-card-maker
        ❯ git init
        Initialized empty Git repository in /Users/seoyeonheo/projects/gift-card-maker/.git/

• ** git add, commit :**

        ❯ git add images
        ❯ git add index.html
        ❯ git add main.js
        ❯ git commit -m "initial commit"

• github repository 연결

        git remote add origin https://github.com/h-seo-n/card-maker.git
        git branch -M main
        git push -u origin main

변경사항 push & commit 과정

README.md 업데이트 등 원격저장소(github)에 수정이 있었을 때, 원격저장소의 데이터를 git pull로 로컬 저장소인 git에 최신화한 후 commit 해야 함.

→ 그렇지 않을 시 충돌 발생, pull 후 병합된 내용을 push하게 됨.

• 수정 사항을 git add 로 스테이지에 추가
  • 모든 파일 추가 : git add .
  • 특정 파일 추가 : git add main.js
• git 상태 확인 : git status
• 커밋하기 : git commit -m "changes saved"
• 로컬 저장소의 커밋을 원격 저장소로 올리기 : git push

reset : 실수로 한 add/commit/push취소하기

• add unstaging : commit 전, stage에 파일을 잘못 add 한 경우 git reset <파일 경로 or 파일명> 으로 해당 파일을 stage에서 제거할 수 있다.

• push 전 commit 취소 :

  • commit을 취소하지만 stage에는 남겨놓기 (add한 상태) : git reset --soft HEAD^
  • commit을 취소하고 stage에서도 제거 : git reset --mixed HEAD^ == git reset HEAD^
  • 여러 개의 commit 취소 : ex. git reset HEAD~{개수}
  • 원격 저장소 & 로컬 작업 공간 모두에서 commit 내역 삭제하기 : git reset --hard HEAD^

• push 취소 :

  • 가장 최근 커밋 취소 : ****git reset HEAD^

  • 특정 커밋 취소하기 : git reset {commit id}

    → reset 후 git commit -m "message" 입력 및 git push {repository} {branch} -f 로 강제 push를 해주면 원격저장소로 push된 커밋까지 취소할 수 있다.

Github repository에서 파일 삭제하기

깃헙에 개의치 않게 테스트 코드 등의 파일을 잘못 올렸을때 git rm을 이용해서 github에서만 파일을 삭제할 수 있다. (로컬 저장소에는 유지)

 git rm --cached filename.code 
 git commit -m "remove filename.code"

--cached를 지우고 커맨드 실행 시 로컬 저장소에서도 삭제된다.

(깃헙 공식 웹에서는 웹 gui에서 삭제하는 방법이 안내되어 있으나 현재는 그 방법이 없어진 것으로 보임)

기본 형식 :

src 속성으로 프레임에서 보여줄 html 파일을 명시하고, title 속성은 프레임의 제목 역할을 하여 스크린리더(Screen reader; 웹사이트 음성 지원)가 이를 읽을 수 있게 한다.

ex.`<iframe src="url" title="description"></iframe>`

스타일 관련 설정들 :

• 크기 : 프레임의 크기는 style 속성에서 css의 width와 height 속성으로 설정하거나, 따로 html의 width와 height 속성으로 설정해줄 수 있다.

• 윤곽선 : 기본적으로 iframe 요소는 옅은 윤곽선이 있다. 이를 지우거나 수정하기 위해서는 style 속성에서 css로 border 속성을 작성해주면 된다.
  

  ex. style=”border:none;” 혹은 style=”border:5px solid Green;”

• 링크 요소 <a>의 target 속성을 통해, 링크 요소를 누를 시 링크가 iframe 요소 안에서 열리도록 할 수 있다.
  

  ex.

    <!DOCTYPE html>
    <html>
    <body>
  
    <h1> ⬇️ iframe </h1>
    <iframe src="backgroundimg.htm" name="iframe_ex" title="iframe example"></iframe>
    <p><a href="blockinline.htm" target="iframe_ex">Show block inline example</a></p>
    <p><a href="backgroundimg.htm" target="iframe_ex">Show background image example</a></p>
  
    </body>
    </html>

  

<img src="https://velog.velcdn.com/images/h-seo-n/post/df40319a-92bf-4ad3-a8d2-6090803aea6b/image.png" width=40% style="float:right">
</div>

• <style> 내부에서 .classname { … } 의 형식으로, 온점 . 뒤에 클래스의 이름을 적음으로써 클래스를 형성하고 클래스와 이에 따른 css 스타일을 설정해줄 수 있다.

• 무슨 요소이든 class attribute(속성)으로 (class=”class1 class2”)특정 클래스에 속함을 밝힐 수 있고, 속하는 class의 속성들(style 등)을 부여받게 된다.

  이때 한 요소는 class 이름을 띄워 적음으로써 여러 개의 class에 속할 수 있고, 서로 다른 종류의 여러 요소가 같은 클래스에 속할 수도 있음.

• e.g.

  

   <head>
     <style>
     .pink_button {
             background-color:Pink;
             color:SeaShell;
             padding: 15px 25px;
             margin: 10px;
             inline-size:min-content;
             float:left;
             border-radius: 20px;
         }
  
      .rectangle {
             background-color:SeaShell;
             color:Pink;
             padding:15px 25px;
             margin:10px;
             float:left;
             inline-size:min-content;
         }
     </style>
   </head>
   <body>
       <h1 class="pink_button">Pink Button</h1>
       <h1 class="rectangle">Rectangle</h1>
   </body>
  
  

• 클래스와 자바스크립트 :
  • 자바스크립트의 getElementByClassName() 메서드로, 한 클래스에 속하는 모든 요소들을 선택하고 자바스크립트 코드로 특정 상호작용을 지정하는 등의 코드를 짤 수 있다 ➡️ 실제 활용에서는 document.querySelector(.classname)이 클래스로 요소를 선택하는 데에 많이 쓰인다.

아이디 :

• 클래스가 여러 html 요소를 그룹핑하는 역할이라면, 아이디는 각각의 html 요소를 구별하는 식별자 역할이라고 할 수 있다. 한 아이디는 하나의 요소에만 부여될 수 있다.

• <style> 내부에서 샵(#)과 함께, 특정 아이디에 대한 스타일을 css로 설정해줄 수 있다. 이를 적용하기 위해 각 요소의 id 속성에서 고유한 아이디를 부여해줄 수 있다.

  <!DOCTYPE html>
  <html>
  <head>
   <style>
     #green {color: SeaGreen;}
   </style>
  </head>
  <body>
   <h2>This has no id</h1>
   <h2 id="green">This has id "green"</h1>
  </body>
  </html>

  

• 아이디와 자바스크립트 :
  • getElementById() 를 통해 특정 아이디를 가진 요소를 선택함으로써 자바스크립트로 여러 구현을 할 수 있다. (or document.querySelector("#id"))

• 블록 요소 : 블록 요소는 요소가 페이지 좌우너비 전체를 차지하는 하나의 ‘블록’이라고 볼 수 있다.

  • ex. <p>, <h1>-<h6>, <ol>, <ul>, <li>, <blockquote>, <div> 등

• 인라인 요소 : 인라인 요소는 필요한 만큼의 너비만 차지하는 요소이다. in-line 말 그대로 행 자체이기보다는 행의 내부에 (다른 요소들과) 있다.

  • ex. <a>, 텍스트 포매팅 요소(<b>, <i> 등), <abbr>, <map>, <img>, <span> 등

• 블록 요소는 블록과 인라인 요소 모두를 담을 수 있지만, 인라인 요소 안에는 블록 요소가 담길 수 없다!

  ---

<div>와 <span>

• <div> 태그 : 페이지의 컨텐츠를 나누거나('div'ide) 그룹핑하는데 사용되는, 마치 컨테이너와 같은 역할을 하는 요소로 대표적인 블록 요소이다.

• <span> 태그 : 제목이나 본문 요소 등 안에서 텍스트의 일부를 선택하는 태그. 선택할 부분을 <span> 태그 안에 넣으면 된다. 대표적인 인라인 요소.

• ex.

  <div style="background-color:PaleGoldenRod">
  <h1>Div element</h1>
  <p>This is an div element. Div divides and groups these contents.</p>
  </div>
  
  <div>
  <h1> &lt;span&gt; inside div</h2>
  <p><p>I want to change only
  <span style="color:LightPink">
  This Part</span> of the code.</p></p>
  </div>

  

  ---

<div> 요소 스타일 활용하기

• margin:auto; : div 요소의 너비가 (스타일에 의해) 페이지 너비보다 좁다면, div 요소를 자동적으로 중앙으로 정렬해준다.

• display: inline-block; : 다른 요소의 위아래로 쌓이는 대신, 인라인 요소처럼 페이지의 여백을 채우는 식으로 작동한다.

• float : inline-block의 효과와 유사하게, float를 이용해서 여러 개의 div 요소가 양옆으로 서로 정렬되도록 할 수 있다.

  • ex :

    Div {
      width: 40%;
      float:left;
      margin: 10px;
     }

    

• 이외에도 CSS의 display:flex 혹은 display:grid 를 이용하여 더 간편하게 div를 이용한 레이아웃을 설정할 수 있다.

  (https://webdesignerdepot.com/when-pages-are-not-paper-the-designers-guide-to-layout-code/ 참고 시 div style을 웹 레이아웃에 활용하는 방법을 더 알 수 있음)

HTML 리스트

순서 없는 리스트 (Unordered List)

불렛 리스트처럼 나열식으로 된 리스트. <ul> (unordered list 이니셜) 요소 안에 <li>로 리스트의 각 항목을 작성한다.

순서 있는 리스트 (Ordered List)

1, 2, 3처럼 순서를 부여한 리스트. <ol> (ordered list 이니셜) 요소 안에 <li>로 리스트의 각 항목을 작성한다.

설명 리스트 (Description List)

리스트 항목마다 설명을 같이 작성할 수 있는 리스트.

<dl> (description list) 요소 안에 <dt> (d + term)으로 설명할 용어/개념, 그 다음 <dd> (d + description)로 설명을 작성한다.

(즉 <dt>와 <dd> 쌍이 하나의 리스트 항목을 구성한다.)

• 절대적인 url(Absolute URL) vs 상대적인 url(Relative URL)

  • 절대적인 url : https:// ~ 부터 시작하는 통상적인 웹 주소
  • 상대적인 url : 현재 html 웹(파일)의 주소를 기반으로 한 url (한 웹 주소가 여러 다른 하위 페이지를 가지고 있을 때, 혹은 html 파일이 위치한 폴더 안에 다른 리소스 파일들이 있을 때 이용)
    

• <a> 태그 안에 <img>태그를 넣음으로써 링크 미리보기로 이미지를 띄울 수 있다.

  
  

• 누군가에게 이메일을 바로 보내는 (유저의 이메일 프로그램을 여는) 링크 : mailto:someone@example.com e.g. <a href="mailto:best3487@snu.ac.kr">Mail Me!</a>

  

링크 색깔

• 방문 전(unvisited - 기본값) / 방문 후(visited) / 마우스를 위에 올려놓았을 때(hover) / 클릭 시(active) - 이 4개의 링크 상태에 따라 스타일을 다르게 지정할 수 있음.
• 링크 요소는 기본 스타일값이 밑줄이 쳐져 있는 형태이며, text-decoration=none이라고 css style에서 따로 명시하면 밑줄을 없앨 수 있다.

<style>
a:link {
    background-color: #20B2AA;
    color: PapayaWhip;
    font-size: 200%;
    text-decoration: none;
} 

a:visited {
    color:LightPink;
    text-decoration: none;
}

a:hover {
    color:Tomato;
    text-decoration: underLine;
}

a:active {
    color:Snow;
    text-decoration: underLine;
}
</style>

• link (기본 상태)

  

• hover (마우스 띄운 상태))

• visited (링크 방문 상태)

• active (링크 클릭하고 있는 상태)

링크 버튼

• CSS의 style (e.g.{padding: 15px 25px; display: inline-block})를 활용해서 링크 요소가 버튼처럼 보이도록 할 수 있음.
  (padding : 순서대로 요소의 세로 방향과 가로 방향에 적은 픽셀 만큼의 패딩을 넣는 스타일 속성)

  • 예시 :

    a:link {
       background-color: #20B2AA;
       color: PapayaWhip;
       padding: 15px 25px;
       display: inline-block;
       border-radius: 20px;
    } 

    

북마크 만들기 :

웹페이지가 너무 길 경우 페이지의 특정 요소로 이동하는 북마크 요소를 만들 수 있음.

→ 북마크를 설정해둘 요소에 id 속성을 설정해두고

→ 북마크는 링크 요소(<a>)로 만들고, href=”#(설정한id)” 속성을 설정해 두면 됨.

→ 이런 북마크는 다른 웹페이지에서도 링크 요소로 설정해줄 수 있음. (href=”링크#설정한id”)

• ex

  <body>
  <a id="top" href="#bottom">Move To Bottom</a>
  
  <br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
  <br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
  <br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
  
  <a id="bottom" href="#top">Move To Top</a>

  

HTML 이미지 세부사항

`src=”이미지 주소”`:

• 웹페이지는 열릴 때마다 <img> 태그의 src 속성 안에 있는 주소에서 이미지를 가져옴. 웹페이지 안에 고정된 것이 아니기 때문에, 웹페이지가 열릴 때 src에 명시한 주소 안에 이미지가 반드시 있어야 함.

  • 이미지 주소의 경우 절대적 url과 상대적 url 중, 로컬 html 파일이 위치한 폴더 기준으로 이미지 주소를 적는 상대적인 url(relative url)을 사용하는 것을 적극 권장.

    (절대적 url을 가진 이미지는 외부 웹사이트에 호스팅된 이미지이므로, 다른 사람의 웹사이트에서 이미지를 가져오는 것은 윤리적이지도 않으며(내 웹에서 이미지가 로딩될 때의 트래픽 비용을 외부 웹사이트가 부담하는 등) 해당 주소의 이미지가 나도 모르게 바뀔 수 있으므로 불안정함. 만약 내 소유 웹사이트에서 이미지를 가져온다고 하면 괜찮을 것)

• 즉, 상대적인 url을 사용하기 위해 로컬 html 파일이 위치한 폴더 안 어딘가 이미지 파일이 있어야 하고 그 위치를 임의로 바꾸면 안된다. (코드 상 이미지의 주소를 같이 바꾸지 않는 이상)

• src에 명시된 링크에 이미지가 없거나 네트워크 문제로 가져오는 것을 실패한 경우, 깨진 이미지 아이콘과 함께 alt 속성에 설정해둔 대체 텍스트가 표시된다.

  
  

width, height 속성 :

• 이미지의 크기 (가로 x 세로) 는 width, height 속성보다는 style 속성에서 css 문법으로 설정하는 것을 권장 :
  

  • 속성으로 크기를 정의할 경우, header에서 정의된 style element 등 CSS style sheet에서 전체적으로 정의해 준 이미지 크기가 속성으로 정의된 개별 이미지 크기를 무시하고 덮어쓸 수 있음.
    

  • 반면 개별 이미지의 크기를 따로 css로 정의해 주면 전체 css style 설정과 개별 요소들의 설정을 모두 유지할 수 있으므로, 그냥 css style로 이미지 크기를 정의하는 것에 익숙해지자.

    

      (w3schools의 예시) 

이미지 형식 :

이미지로 gif 애니메이팅 파일을 넣을 수도 있다.

이뿐만 아니라 APNG, GIF, ICO, JPEG, PNG, SVG 파일 모두를 지원함

이미지 “플로팅” :

문단 <p> 요소 안에 이미지 요소 <img>를 넣으면 문단 안에 이미지를 위치시킬 수 있다.

또한 css의 float 문(e.g. style=”float:right”)으로, 이미지가 다른 요소 위에 ‘떠 있도록’ 할 수 있는데, 이미지와 다른 요소를 나란히 정렬시키는 데 이용된다고 보면 된다.

floating 코드 예시 :

  <p>
  <img src="images/cafe.jpeg" alt="cafe that feels good"
  style="float:left;width:200px">
  느낌 좋은 카페. 느낌 좋은 카페. 느낌 좋은 카페. 느낌 좋은 카페. 느낌 좋은 카페. 느낌 좋은 카페. 느낌 좋은 카페. 느낌 좋은 카페. 느낌 좋은 카페. 느낌 좋은 카페. 느낌 좋은 카페. 느낌 좋은 카페. 
  </p>

이미지를 링크로 넣기 :

<a> 안에 <img>를 넣으면 된다.

• ex:

  <h1>고함항아리구경하기>>
  <a href="https://github.com/h-seo-n/Scream-Jar" style="float:right;">
  <img src="images/cloud.jpeg" style="width:200px">
  </a>
  </h1>

  

이미지 매핑 :

• 좌표를 이용해서 이미지의 특정 구역을 클릭하면 다른 링크로 이동하는 등, 이미지의 특정 구역과 사용자와의 상호작용을 구현할 수 있다.

• <map> 요소에서 설정해줄 구역을 shape와 coords 속성으로 정의해주고, <map>의 name 속성과 <img>의 usemap 속성이 일치하게 함으로써 연결해주면 된다.

• 예시 형식 :

  <img src="images/ex1.jpg, usemap=#ex1">
  
  <map name="ex1">
      <area shape="rect" coords="34,44,270,350" href="example1.htm"
  >

• <area> : <map> 요소 안에 구역을 설정해주는 <area> 요소가 있고, 추가적 속성으로 구역의 모양과 크기를 설정해줄 수 있다.

  • shape=”rect” : 가장 왼쪽 상단의 좌표와 가장 오른쪽 하단의 좌표, 총 두 쌍의 좌표를 coords에 적어 준다.
  • shape=”circle” : 원의 중심 좌표와 원의 반지름, 총 세 개의 숫자를 적어준다.
  • shape=”poly” : 여러 쌍의 좌표를 입력하면, 그 점들을 선으로 연결한 다각형 모양을 만든다. (사진 출처 : https://www.w3schools.com/html/html_images_imagemap.asp)

<img src="https://velog.velcdn.com/images/h-seo-n/post/b5d23f57-fc9e-4f5d-b710-2cf133180e1b/image.png"> | <img src="https://velog.velcdn.com/images/h-seo-n/post/21d61b68-dde5-440d-9236-40e30279a584/image.png">
---|---|

 <br>

• <area href = “…”> : 정의해준 구역을 클릭했을 때, href 속성에 적은 링크로 이동하도록 한다.

  • JavaScript : <area> 요소의 onclick 속성에 자바스크립트 함수 이름을 명시함으로써, 정의해준 이미지 구역(맵 요소)이 자바스크립트 함수에 정의된 대로 사용자와 상호작용하게 할 수 있다.

  ex.

  <area … onclick=”myfunction()”> …
  <script>
  function myFunction() { … }
  </script>

  
  

배경으로 이미지 넣기 :

• 전체 웹페이지에 배경 이미지 넣기:
  

  <style> 태그 혹은 css 시트 안에 background-image: url(’이미지 주소’); 를 설정해주면 된다.

  • ex:

    <style>
    body {
        background-image: url('images/landscape.jpeg');
        background-size: cover;
        background-attachment: fixed;
    }
    </style>

    

• 특정 HTML 요소에 배경 이미지 넣기 :

  개별 style 속성으로 설정해주면 된다.

• 배경 이미지 관련 스타일 설정들 :

  • background-size :

    • “cover”로 설정해둘 시, 이미지가 기존의 비율을 유지하면서 페이지(혹은 요소) 전체를 채운다.

      → 밑에 나오는 background-attachment 설정 없이 그냥 cover만 할 시 “100%”로 설정하는 것과 같음

    • “100%”로 설정하면 기존의 비율을 유지하면서 가로 길이만 페이지(혹은 요소)의 길이에 맞춘다.

    • “100% 100%”로 설정하면 비율을 유지하지 않고 페이지(혹은 요소) 전체를 덮어버린다.

  • background-attachment :

    • 현재 사용자가 브라우저를 통해 보고 있는 웹의 영역인 viewport에 배경이 고정되어 있는지, 혹은 페이지(혹은 요소)가 스크롤 될때 배경이 같이 스크롤 되는지의 여부.
      

      → background-size=cover; background-attachment=fixed; 이렇게 동시에 설정해두면 배경 이미지가 항상 페이지(혹은 요소) 전체를 가린다.

  • background-repeat :

    • 이미지의 원래 크기가 요소나 페이지보다 작으면, 페이지(혹은 요소)를 모두 덮을때까지 배경 이미지가 반복된다. 이게 싫으면 background-repeat: no-repeat;를 설정해주면 된다.

→ css background에 대해 더 검색해보면 더 잘 알 수 있는데 실제로 만들때 그때그때 검색하면서 해도 될 것 같다.

<picture> 요소

• 모바일, 태블릿, 데스크탑 등 웹사이트를 여는 기기에 따라 브라우저의 너비가 달라지면, 화면 크기에 따라 다른 이미지를 표시할 수 있게 하는 요소이다. 사용 기기에 따라 다른 디자인을 보여주는 반응형 디자인을 구현할 때 등에 사용할 수 있다.

• 형식 :

    <picture>
        <source media="(min-width: nnnpx)" srcset="ex1.jpg">
        <source media="(min-width: mmmpx)" srcset="ex2.jpg">
        <img src="default_img.jpg">
    </picture>

  <picture> 내부 <source> 요소가 있고, media 속성으로 어떤 조건 하에 해당하는 이미지를 표시할지 설정해준다. 이때 브라우저는 소스를 순서대로 보다가 조건을 만족하는 소스를 찾으면 더 보지 않고 바로 그 소스(이미지)를 표시한다.
  

  <source>요소들을 다 작성한 후 마지막에 <img> 요소를 넣어주면, 모든 조건이 만족하지 않을 때의 기본값 이미지가 된다.

• 화면 크기에 따라 HTML 코드는 다르게 표시될 수 있으며, 한 칸을 초과하는 여백(space, Enter)은 HTML 표시 시 무시된다. ⇒ 줄바꿈 요소인 <br>을 입력하지 않는 한 두 줄 이상 띄울 수 X

• Preformatted text(사용자 지정 형식의 텍스트)를 적을 수 있는 <pre> element를 이용하면 줄바꿈과 띄어쓰기가 보존됨.

• ex :

  <h2>reformatted text</h2>
  <pre>
  This Mode
  Should be g.  O.  O. O. D. 
  To write Poems
  
         Right?
  </pre>

  

HTML Style (요소 꾸미기) :

• HTML Style : HTML 요소의 style 속성을 통해 색, 폰트, 크기 등과 같은 스타일을 조정할 수 있다.

• 기본 형식 : <tagname style=”property:value;”>
  

  → 쌍따옴표 안의 property:value는 CSS 언어를 작성하는 거라 볼 수 있다.

• 종류 :

  • 배경색 - “background-color:colorname;”
  • 글자색 - “color:colorname;”
  • 폰트 - “font-family:fontname;”
  • 글자 크기 - “font-size:100%;”
  • 글자 정렬 - “text-align:center;”

HTML 색깔 :

• 미리 지정되어 있는 색깔 이름(140개의 색상 이름 지원), 혹은 RGB, HEX, HSL, RGBA, HSLA와 같은 색상 코드 값으로 표시할 수 있다.

• style 속성을 통해 요소의 배경 색, 텍스트의 색, 그리고 테두리 색(ex. ”border:2px solid Tomato;” )을 설정할 수 있다.

• RGB : rgb(red, green, blue) 의 형식으로, 삼원색이 각각 강한 정도를 0~255 범위의 숫자로 나타내면 됨.

  • RGBA: rgba(red, green, blue, alpha) alpha 필드가 추가되었는데 불투명도를 0.0~1.0 범위의 값으로 지정해주면 됨.

• HEX: hexadecimal의 줄임말으로 색을 16진수로 나타내는 형식. #rrggbb 빨강, 초록, 파랑 삼원색의 정도를 00ff 로 나타낸다.(십진수로는 0255로 rgb와 본질은 같음)

• HSL: hsl(hue, saturation, lightness)← 색, 채도, 밝기를 값으로 넣어주는 형식. 색은 색깔 종류로 0(빨강)에서 360 사이, 채도는 색의 강도로 퍼센티지 값. 밝기도 퍼센티지.

  (출처 : https://en.wikipedia.org/wiki/HSL_and_HSV)

• HSLA: rgb와 rgba와 마찬가지로, 투명도를 나타내는 alpha값이 추가된다.
  

⬇️ 색 사용 예시 :

  <h1 style="background-color:Tomato;">This is tomato color</h1>
  <p style="color:DarkOliveGreen; font-size:150%">Dark Olive Green is good</p>

  <h2 style="border:5px solid #0A400C; background-color:#819067;
  text-align:center;">
  <br>#819067<br><br>
  </h2>

HTML text formatting (글자 꾸미기) :

• HTML은 글.꾸(글자꾸미기)를 위한 여러 'formatting elements'가 존재한다. (style과 달리 속성_으로 설정하는게 아니라, 따로 _요소 안에 꾸밀 텍스트를 넣어주는 식으로 사용해야 한다.)

• 종류 :

  • <b> : bold text, 볼드체
  • <strong> : important text, 중요한 글(주로 볼드체랑 같음)
  • <i> : italic text, 이탤릭체
  • <em> : emphasized text, 강조되는 글(주로 이탤릭체랑 같음)
  • <mark> : 글씨에 형광펜 쳐줌
  • <small> : 글씨 작게 함
  • <del> : 글자에 취소선
  • <ins> : 삽입된inserted 글, 밑줄
  • <sub> : subscript text (글을 밑으로 내림 - 예시에서 확인)
  • <sup> : superscript text (글을 위로 올림 - 예시에서 확인)
    

• 사용 예시 :

  <h1><em>emphasis</em> is similar to <I>italics</I></h1>
  이건 중요하니까 <mark>밑줄쳐</mark> <br>
  근데 이건 안중요해서 <small>작게쓰자</small>
  <br> <del>취소선</del>
  <br> <ins>밑줄</ins>
  <br> 섭스크립트<sub>subscript</sub>
  <br> 수퍼스크립트<sup>superscript</sup> 

  

HTML 인용 요소들 :

• <blockquote> : 통으로 한 문단을 인용한다. 보통 인용하는 문단을 들여쓰기 하는 식으로 표시됨. 출처를 표시할 수 있는 cite 속성이 있는데, 스크린리더(청각 지원) 기능에서 주로 사용되고 따로 가시적으로 드러나지는 않는다.

```html
<p>책 블로그 홍보합니다:</p>
<blockquote
cite="[https://blog.naver.com/xersxe_y/223936326577](https://blog.naver.com/xersxe_y/223936326577)">
고통과 문제상황 자체를 들여다보고 그것의 속절없음을 직시하며 마음의 아픔을 내어주는 것이 바로 공감이라고 생각한다.
</blockquote>
```

<img src="https://velog.velcdn.com/images/h-seo-n/post/1c1cc7ba-9dd4-44e4-b883-f38b14fb2403/image.png" width=60%>

• <q> : 짧은 한 문장을 문단 내에서 인용한다. 보통 따옴표로 인용구를 둘러싸는 형식으로 표시된다.

• <cite> : 작품의 제목을 나타내는 요소로 보통 이탤릭체로 안의 텍스트를 표시함.

    <p>
    <cite>아프다는 것에 관하여 - 앓기, 읽기, 쓰기, 살기</cite>
    의 저자는 자신의 책에 대해 
    <q>이 책은 병condition이 삶에서 특정한 조건/상황/한계condition가 되었을 때 그 안에서 살아가며 배우고 생각한 것을 적은 책이다.
    </q>라고 이야기한다.
    </p>

  
  

• <abbr> : 긴 용어의 축약(abbreviation)을 표시해주는 요소로, title 속성에 원문을 작성하면 웹페이지에서 요소에 마우스를 갖다대면 원문이 표시되게 할 수 있다.

• <bdo> : 안의 텍스트 방향을 바꿀 수 있다. dir=”rtl” 속성과 함께 하면 좌→우 방향에서 뒤집어 우→좌 방향으로 입력되게 할 수 있다.

    <p>
    밴드 커버 곡으로 좋다고 생각하는 노래 중 하나는 아이들의 
    <abbr title="나는 아픈 건 딱 질색이니까">아딱질</abbr>
    이다. 제목을 반대로 하면 <bdo dir="rtl">나는 아픈 건 딱 질색이니까</bdo>이다.
    </p>

  
  

• <address> : 이메일 주소, 실제 장소 주소, 휴대폰 번호, sns 아이디 등의 연락처 정보를 표시하는 요소.

  요소 앞뒤로는 자동적으로 줄바꿈이 추가된다.

```html
<address>
허서연 작성 <br>
Take a look at my project: <br>
https://github.com/h-seo-n/Scream-Jar <br>
</address>
```

<img src="https://velog.velcdn.com/images/h-seo-n/post/1ab58e93-9f35-4273-bd05-37351c9edf1b/image.png" width=60%>

HTML 주석 (Comment) :

• 형식 : <!--how to write comments-->
  

  시작에 느낌표가 있지만 끝에는 없음, 적고자 하는 내용을 <!-- --> 로 감싸주어야 함.
  

  → 코드 설명 혹은 주의할 점을 주석으로 적을 때, 혹은 작성한 HTML 코드를 숨길 때 이용한다.

    <p>Gonna hide some elements</p>
    <!--
    <h1>Like this oversized title</h1>
    -->
    <p>You can't see it <!--or this--> now.</p>

  

HTML CSS

• cascading - 위에서 아래로 내려온다는 뜻, 즉 부모 요소(parent element)에 적용한 스타일이 자식 요소(child element)까지 적용되므로 더 편하게 스타일링 가능.

• 이용 방식 :

  • Inline : HTML 요소 안의 style 속성 사용 (위에서 본 대로)
  • Internal : HTML 파일 상단의 <head> 태그 안에 <style> 요소를 넣어줌
    • 하나의 html 페이지 전체에 적용되는 스타일을 정의.
  • External: <link>요소를 사용하여 외부 CSS 파일을 연결해줌

• 예시 :

  <!DOCTYPE html>
  <html>
  
  <head>
  **<style>**
  body {text-align: center;}
  h1 {background-color: SeaGreen; color: PapayaWhip;} 
  p {background-color: #FAFAD2; color: #20B2AA;}
  **</style>**
  </head>
  
  <body>
  <h1>This is heading style</h1>
  <p>This is a paragraph</p>
  </body>
  </html>

  

<!DOCTYPE html>
<html>
<head>
<title>Page Title</title>
</head>
<body>

<h1>My First Heading</h1>
<p>My first paragraph.</p>

</body>
</html>

• 모든 HTML 문서의 시작 - document type declaration(문서 형식 선언) : <!DOCTYPE html>

• 그 뒤에는 <html> 태그가 뒤따르며, 문서의 가장 마지막에는 </html> 태그로 문서의 끝을 표시

• 사용자에게 보이는 가시적인 부분을 담당하는 코드는 <body> … <!body> 사이에 있다. (그 안의 <h1>과 <p> 은 각각 제목과 본문을 보여주는 HTML 요소들.)

  
  

  ---

  ## **HTML elements (HTML 요소) :**

• 시작 태그부터 끝 태그까지의 전체를 HTML 요소라고 함. <tagname>content</tagname>

  (e.g. 위 코드에서 <h1>My First Heading</h1> 그리고 <p>My first paragraph.</p> 이 해당하며 사실상 <html>과 <head> <body>도 요소라고 볼 수 있음.)

  (HTML 요소의 끝 태그(end tag)를 생략해도 코드가 돌아갈 때도 있지만 … 가급적이면 쓰는 것을 잊지 말자!)

• 한 HTML 요소 안에 다른 HTML 요소가 중첩되어 있다. (HTML elements can be nested)

  ⇒ HTML 문서는 문서 형식 선언 뒤, 핵심 요소(root element)인 <html> 태그와 그 안의 <body> 안에 중첩된 여러 기타 HTML 요소로 구성되어있다고 볼 수 있음.

• 하나의 태그만으로 구성된 기타 HTML 요소 :

  • <br> : 줄바꿈을 하게 하는 요소
  • <hr> : 가로로 된 구분선을 표시하는 요소

기본적인 HTML 요소들

• HTML 제목 (Headings) :

  제목 크기에 따라 태그 <h1> ~ <h6> 까지 있음. ➡️ 서치엔진이 제목을 이용해 웹페이지 내용을 구조화하고, 웹페이지 유저도 제목으로 웹을 훑곤 하기에 제목은 중요! 단순 텍스트 크기를 크게 하려고 heading을 쓰는 것은 권장하지 X.
  

  • 제목 폰트 크기 수정 - <h1 style=“font-size:60px;”>Heading 1</h1>
    

• HTML 본문 (Paragraph) :

  본문은 <p> 태그로 정의됨, 본문은 항상 새로운 줄에서 시작함. : <p> content </p>

  
  

• HTML 링크(URL) : URL은 <a> 태그로 정의됨
  

  e.g. <a href=“[https://example.url](https://example.url/)”>attribute-url name</a>

  
  

• HTML Image :

  <img> 태그와 함께 소스 파일 src, 대체 텍스트 alt, 너비와 길이 width & height을 제공. : e.g. <img src=“name.jpg” alt=“text” width=“104” height=“142”>

  → 넣고자 하는 이미지가 html 코드 파일과 같은 위치에 있어야 함

  
  
  

• 종합 예시 코드 및 페이지

```html
<!DOCTYPE html>
<html>
<body>

<h1>The Biggest Header</h1>
<h2>The Smaller One</h2>
<p>now the paragraph</p>
<h6>The Smallest Header</h6>
<p>for the GitHub link: </p>
<a href="https://github.com/h-seo-n/Scream-Jar">Scream Jar URL</a>

</body>
</html>
```

![](https://velog.velcdn.com/images/h-seo-n/post/ff31af9d-7ec6-4fc5-a419-a003ad83c9b9/image.png)

실제 웹사이트에서 우클릭 후 검사(inspect)를 누름으로써 HTML 요소를 코드로 확인할 수 있다. 전체 소스 코드는 Ctrl + U 또는 우클릭을 하고 "페이지 소스 보기"를 누름으로써(view page source) 가능하다.

HTML Attributes (HTML 속성) :

• HTML 요소에 대해 추가적인 정보를 제공하는 코드로, HTML 요소의 시작 태그 안에 작성된다. 주로 name=“value” 의 형태로 작성됨.

예시 :

• url 링크 요소의 속성들

  • href : URL 요소에서 페이지의 주소를 명시함

    e.g. <a href=“[https://example.url](https://example.url/)”>url name</a>

  • target : url을 어디서 열지 명시하는 속성 (명시하지 않으면 현재 열린 브라우저에서 엶)

    • target=”_self” : 디폴트 값, 클릭된 브라우저 창에서 열림

    • _blank : 새 브라우저 창에서 링크가 열림

    • _parent : 현재 창이 프레임으로 구성되었을 때 부모 프레임(parent frame)에서 링크가 열림

    • _top : 현재 창이 프레임으로 구성되었을 때 모든 프레임이 사라지고 전체 화면에서 링크 페이지가 열림

      (참고: https://m.blog.naver.com/mathesis_time/222039284932)
      

• 이미지 요소의 속성들 :

  • src : 이미지의 주소를 명시(외부 웹에 있는 이미지의 경우 url을 입력하거나, 현재 웹 내부에 이미지를 두고 현재 웹의 주소에 대한 ‘상대적인 url(relative url / e.g. src=“/images/img_girl.jpg”)’를 입력)

  • width, height : 너비, 높이 / alt : 대체 텍스트(alternative text)

    e.g. <img src=“name.jpg” alt=“text” width=“104” height=“142”>

• lang : html 요소의 시작 태그 안에서 웹페이지의 언어가 무엇인지 알려줌. 첫 두 글자는 언어를, 뒤 두 글자는 국가를 명시.
  

  e.g. <html lang=“en-US”>
  

• title : html 요소의 이름을 지정한다고 할 수 있음. 웹페이지에서 요소에 마우스를 갖다댔을때 tooltip(설명 메시지)를 나타나게 함.
  

  <p title=“I’m a tooltip”>This is a paragraph.</p>

⇒ Attribute 작성 시 name="value"에서 이름을 소문자로 적기를 권장, 그리고 값을 따옴표로 감싸주기를 권장.

서울대학교 차세대데이터 여름학교 2025 단기 특강

Some History, Hardware Lottery

• AI winter for Neural Networks :

  • 원래 Neural Networks는 지금 hype 된 것보다 성능이 훨씬 별로였다

    • Marvin Minsky (1969) : “Nerual Networks” cannot learn the XOR relationship .. only linearly separable problems … and become too large for complex knowlege

      → 하지만 Single layer이 아닌 “Deep” neural network의 학습이 가능한 하드웨어적 기반이 마련되면서 NN의 성능 비약적 향상

• The Hardware Lottery :

  • Sara Hooker이 Communications of the ACM, 2021에 주장한 개념. GPU의 발달으로 DNN이 AI 핵심 기술로 거듭난 것에 대한 설명

    Some ideas win, not because they are better, but because they work better with existing hardware

  • Hardware Lottery Winners: General-Purpose CPU Threads

    • chip의 집적도가 증가한다는 Moore’s Law + chip 성능 향상에도 power density가 일정하게 유지된다는 Dennard Scaling = Dependable performance scaling

    • 위와 같이 Moore’s Law와 Dennard Scaling이 건재할 때에는 미래에 더 빠른 general-purpose hardware(cpu)가 등장할 것이므로, 굳이 (gpu와 같은) 특화된 specific-purpose hardware을 개발할 필요가 없었다.

      → Resources focused on making general purpose CPUs faster

    • 이러한 Von-Neumann general-purpose CPU는 :

      • not very good with parallel execution 병렬 계산 별로 X

        & not much emphasis on memory bandwidth 메모리 접근 속도도 별로 X

      • Thus, efficient with branch-heavy expert systems : favors symbolic approaches to AI (LISP, Prolog)

      • But inefficient with neural networks with massivel parallel matrix multiplication! → 즉 hardware lottery losers: nerual network

  • Hardward Lottery Losers: Nerual Nets and the AI Winter

    • general-purpose CPU 기반 연구에 집중하다 보니, 원래의 하드웨어가 잘 수행할 수 있는 symbolic approaches에만 집중. Neural net은 cpu로 학습시키기 너무 비효율적이었고 학습을 위한 cpu 여력이 부족하기도 했다.

    • Neural Network 이론 자체는 이미 등장했지만, lost the hardware lottery (cpu로 학습시키기 힘듦) → AI winter

    • NN을 위한 특화된 하드웨어를 개발하기 위한 벤처 기업들이 등장하긴 했지만(e.g. “connection machine”, 1985) 흐지부지됨

      → 그런데 어떻게 NN이 이렇게 승승장구 할 수 있었는가?

      바로 다른 것도 아닌 Video game 때문!

• 요약 : AI 흐름과 별개로 Video game 업체에서 3D 그래픽 게임에 대한 수요가 점점 높아지며, 이를 구현하기 위한 하드웨어 개발이 진행되며 3D Accelerator card, 그리고 gpu가 당연한 수순처럼 등장했다.

• Graphic Processing History

  • 1990’ : 게임을 위한 Real-time 3D rendering 보편화 (Doom, Quake, Descent, … ) + 3D 그래픽 처리가 점점 컴퓨팅 연산 많이 필요

    

    3D accelerator(gpu)가 도입되기 전에 cpu의 연산으로 감당할 수 있는 게임 그래픽을 구현할 수 있도록 하는 gimmick들이 있었다

    - Doom (1993) : “*Affine texture mapping*”

        → linearly maps textures to screen location (3D model → 2D space), disregarding depth;

        게임 내 비스듬한 평면이 없었던 이유는 이를 가리기 위해

    - Quake III arena (1999) : “*Fast inverse square root*”

        → 3d graphic에 필요한 연산을 우회적인 연산식으로 수행 (magic!)

        ![affine](https://velog.velcdn.com/images/h-seo-n/post/1078154a-2410-4a13-b525-3e7de4a17b0b/image.png)


- 그러다가 Starfox(1993)에서 처음으로 dedicated accelerator (전용 가속기 칩) 등장
    - 가정용 게임기에서 처음으로 3d 그래픽을 구현한 super Fx chip : 게임기 안에 cpu를 하나 더 넣은 것이라 생각할 수 있음 (16-bit RISC processor + some plotting commands, Dynamic Memory Access)

        ![](https://velog.velcdn.com/images/h-seo-n/post/d042f1e3-a408-4b58-a820-625615e0e2c0/image.png)


        - DMA; Dynamic Memory Access 가벼운 설명

            ![](https://velog.velcdn.com/images/h-seo-n/post/c6cdf995-184c-475b-8d21-eb00669a7a8e/image.png)


            Dynamic Memory Access; 즉 DMA unit이 CPU와 독립적이게 메모리 작업을 할 수 있게 하는 구조

            CPU는 DMAC, 즉 DMA control unit을 통해 메모리 작업 시작 명령을 내리고 다른 작업을 하다가 DMAC에서 작업 완료 신호를 받을 수 있음.

- Introduction of 3D Accelerator Cards :

    → 3D 게임에 대한 수요가 많아지며 3D Accelerator card가 당연한 수순처럼 등장

    3D 그래픽 처리는 많은 양의 데이터를 반복 처리하는 짧은 알고리즘 → 전용 가속기accelerator에서는 단순 연산을 빠르게 병렬적으로 계산해 줌.

    기본 원리 : 그래픽 카드에서 렌더링의 많은 연산을 대신 해준 후 모니터로 보내는 방식

→ 요컨대 AI를 빼어놓고 보아도 graphic card, gpu의 등장은 게임 측면의 marketing pressure에 의한 당연한 수순이었다!

• 단순 병렬 연산을 수행하는 core의 개수가 많아지고, 그에 비해 cache/control이 차지하는 비율은 ↓

  

• High-Performance Graphics Memory
  • 100K+ threads place enormous pressure on memory!

    → gpu의 많은 연산 thread를 위해 효과적으로 빠른 메모리 필요

- Modern GPUs empoy 3-D stacked memory via a silicon interposer

    → 이런 HBM (High-Bandwidth Memory) 구조는 더 넓은 data bus를 제공함으로써 이런 문제 방지

    ![](https://velog.velcdn.com/images/h-seo-n/post/5586bada-43c0-402f-aa5a-e0cd44e42bee/image.jpg)


    e.g. HBM2 in Volta, Ampere, etc

    → HBM2도 AI 이전 게임 때문에 등장

• Thus New Hardware Lottery Winners : GPUs

→ 이렇게 공교롭게 3D 게임을 위해 등장한 GPU가 nerual network를 가능하게 함

→ gpus originally designed for gaming; massively parallel; high memory bandwith; re-purposed for training.

• CNNs and GPUs → perfect match!

  ⇒ CNN은 동일한 matrix multiplication(multiply-add) 연산을 필요로 하므로 GPU로 병렬 연산하기 좋음

  • two papers using CNNs to identify cats :

    * “_Building high-level features using large scale unsupervised learning_”(2012) : 16000 cpu 사용

    * “*Deep learning with COTS HPC systems*”(2013) : two cpu cores + two gpus 사용

    → 둘의 결과가 맞먹을 정도로 gpu의 위력이 대단했다!

- “what other ideas are we missing due to the hardware lottery?”
    - 좋은 idea인데도 실현가능한 하드웨어가 없어서 놓치고 있을 수도 있음
    <br>

• Yet another lottery winners : specialized hardware

  • DNN에 더욱 최적화된 하드웨어 개발 진행 : tensore cores in GPUs, bfloat units in CPUs, TPUs …

    • Quantizied arithmetic, unstructured pruning 등 dnn 외에는 적용할 게 없는 매우 specific 것들도 하드웨어 개발에 적용

      → 이런 specialized hardware은 더욱 큰 AI 모델을 가능하게 함(더 많은 파라미터)

• Yet another lottery losers : Non-DNN Models

  • 하지만 DNN만큼 복잡한 대안 알고리즘이 TPU/GPU로 training 가능하지 않다면; 실현가능하지 않으므로 역사의 뒷전으로 빠짐 … (e.g. “capsule network”)

    • 다른 예시 graph nerual network : convolutions on graph-structure data, reasoning about non-euclidean data structure

      → graph data는 주로 매우 sparse하기 때문에 accelerator/gpu에 잘 맞지 않음

• Thus ; researchers will gravitate towards models/algorithms well-suited for GPU/TPU/Matrix multiplication since it is the most feasible

  → what great ideas are we missing because they lost the hardware lottery?