• 설정
• 미들웨어 설치
• 반복되는 코드
• 불변성 유지 ==> 이런 불편한 것들을 해소

$ npm install @reduxjs/toolkit

createSlice

• reducer 함수의 객체, 슬라이스 이름, 초기 상태 값을 받아들여서 해당 액션 생성자와 액션 유형으로 slice reducer를 자동으로 생성함

• createSlice()는 다음과 같은 파라미터로 구성되어 있다.

  • name : 해당 모듈의 이름을 작성
  • initialState : 해당 모듈의 초기값을 세팅한다.
  • reducer : 리듀서를 작성한다. 이때 해당 리듀서의 키값으로 액션 함수가 자동으로 생성

export const postsSlice = createSlice({
  name: 'posts', // 이름
  initialState, // 초기값
  reducers: { // posts.actions
    setPosts: (state, { payload }) => { // action.payload
      state.selPosts = payload;
    },
  },
  // extraReducers는 createSlice가 생성한 액션 타입 외 다른 액션 타입에 응답할 수 있도록 합니다.
  // 아래처럼 슬라이스 외부에서 액션 타입을 참조하여 상태를 변화시킬 수 있습니다.
  extraReducers: (builder) => {
    builder
      .addCase(getAllPosts.fulfilled, (state, { payload }) => {
        state.allPosts = payload; // fulfilled 성공
      })
      .addCase(getAllPosts.rejected, (state, { payload }) => {
        console.log('rejected', payload); // rejected 실패
      });
  },
});

export const { setPosts } = postsSlice.actions;
// actions 는 내보내줘야 함(외부 컴포넌트에서 접근 가능하도록)
export default postsSlice.reducer;

• createSlice에서는 state값을 mutate하는 것이 가능

1. 원본에 추가,삭제,수정 등 mutate 하는 방식
2. 이전과 같은 방식으로 새로운 배열 혹은 객체로 대체하는 방식

createAsyncThunk

• 액션 타입 문자열, 프로미스를 반환하는 비동기 함수, 추가 옵션 순서대로 인자를 받는 함수다. 입력받은 액션 타입 문자열을 기반으로 프로미스 라이프사이클 액션 타입을 생성하고, thunk action creator를 반환한다.

• thunk action creator: 프로미스 콜백을 실행하고 프로미스를 기반으로 라이프사이클 액션을 디스패치한다.

• 리듀서를 생성해주는 기능은 없기 때문에 액션들을 처리할 로직을 직접 작성해야 한다.

import { createAsyncThunk, createSlice } from '@reduxjs/toolkit'
import { userAPI } from './userAPI'

const fetchUserById = createAsyncThunk(
  // string action type value: 이 값에 따라 pending, fulfilled, rejected가 붙은 액션 타입이 생성된다.
  'users/fetchByIdStatus',
  // payloadCreator callback: 비동기 로직의 결과를 포함하고 있는 프로미스를 반환하는 비동기 함수
  async (userId, thunkAPI) => {
    const response = await userAPI.fetchById(userId);
    return response.data;
  },
  // 세 번째 파라미터로 추가 옵션을 설정할 수 있다.
  // condition(arg, { getState, extra } ): boolean (비동기 로직 실행 전에 취소하거나, 실행 도중에 취소할 수 있다.)
  // dispatchConditionRejection: boolean (true면, condition()이 false를 반환할 때 액션 자체를 디스패치하지 않도록 한다.)
  // idGenerator(): string (requestId를 만들어준다. 같은 requestId일 경우 요청하지 않는 등의 기능을 사용할 수 있게 된다.)
);

createAsyncThunk는 thunk action creator를 반환한다. 위의 경우를 예로 들면, 다음 세 가지 thunk action creator가 반환된다. fetchUserById.pending: 'users/fetchByIdStatus/pending' 액션을 디스패치하는 thunk action creator fetchUserById.fulfilled: 'users/fetchByIdStatus/fulfilled' 액션을 디스패치하는 thunk action creator fetchUserById.rejected: 'users/fetchByIdStatus/rejected' 액션을 디스패치하는 thunk action creator 이 액션들이 디스패치되면, thunk는 아래 과정을 실행한다. pending 액션을 디스패치한다. payloadCreator 콜백을 호출하고 프로미스가 반환되기를 기다린다. 프로미스가 반환되면, 프로미스의 상태에 따라 다음 행동을 실행한다. 프로미스가 이행된 상태라면, action.payload를 fulfilled 액션에 담아 디스패치한다. 프로미스가 거부된 상태라면, rejected 액션을 디스패치하되 rejectedValue(value) 함수의 반환값에 따라 액션에 어떤 값이 넘어올지 결정된다. rejectedValue가 값을 반환하면, action.payload를 reject 액션에 담는다. rejectedValue가 없거나 값을 반환하지 않았다면, action.error 값처럼 오류의 직렬화된 버전을 reject 액션에 담는다. 디스패치된 액션이 어떤 액션인지에 상관없이, 항상 최종적으로 디스패치된 액션을 담고 있는 이행된 프로미스를 반환한다.

pnpm add -D vite

• package.json

$ pnpm create vite@latest

@ 뒤에 버전 입력! latest ==> 최신버전

$ pnpm i 

ESlint setting

$ pnpm create @eslint/config

To check syntax and find problems 선택

JavaScript modules (import/export) 선택

React 선택

TypeScript = no

code run? a 눌러서 browser,node 둘다 선택

config file format ==> JavaScript 선택

eslint-plugin-react ==> Yes

package manager ==> pnpm

VScode ESlint install 필수

$ pnpm add -D eslint-plugin-jsx-a11y

https://www.npmjs.com/package/eslint-plugin-jsx-a11y

.eslintrc.cjs 파일 내부 plugin & extends에 위와 같이 추가

$ pnpm add -D eslint-plugin-react-hooks

이건 빌드하면 install 되어는 있음 아래 변경 사항만 추가해주면 될 듯

https://www.npmjs.com/package/eslint-plugin-react-hooks

$ pnpm add -D eslint-plugin-react-refresh eslint-plugin-import

react refresh는 install 되어있음 plugin-import는 없음 install 필요

https://www.npmjs.com/package/react-refresh

• 파일 내 추가 사항은 final check 파일들 참조

$ pnpm add -D @types/node

final check

• pnpm list

• .eslintrc.cjs

• package.json

$ npx create-react-app

node.js 가 설치되어 있어야 함!

$ npm start

react sample application

$ npm serve -s build

배포

[React란?]

React ==> 사용자 정의 태그(컴포넌트)를 만드는 것

function을 이용해 사용자 정의 태그 만듬 반드시 대문자로 시작할 것 !

↪️

↳

↪

written by yoon

★★★★★

Authentication - 인증, 입증

• 자신이라고 주장하는 사용자가 누구인지 확인하는 행위
• 모든 보안 프로세스의 첫 번째 단계(가장 기본 요소)
• 즉, 내가 누구인지를 확인하는 과정
• 401 Unauthorized
  • 비록 HTTP 표준에서는 "미승인(unauthorized)"을 명확히 하고 있지만, 의미상 이 응답은 "비인증(unauthenticated)"을 의미

Authorization - 권한 부여, 허가

• 사용자에게 특정 리소스 또는 기능에 대한 액세스 권한을 부여하는 과정(절차)
• 보안 환경에서 권한 부여는 항상 인증이 먼저 필요함
  • 사용자는 조직에 대한 액세스 권한을 부여받기 전에 먼저 자신의 ID가 진짜인지 먼저 확인해야 함
• 서류의 등급, 웹페이지에서 글을 조회 & 삭제 & 수정 할 수 있는 방법, 제한 구역
  • 인증이 되었어도 모든 권한을 부여 받는 것은 아님
• 403 Forbidden
  • 401과 다른 점은 서버는 클라이언트가 누구인지 알고 있음

Authentication and Authorization work together

• 회원가입 후, 로그인 시 서비스를 이용할 수 있는 권한 생성
  • 인증 이후에 권한이 따라오는 경우가 많음
• 단 모든 인증을 거쳐도 권한이 동일하게 부여되는 것은 아님
  • Django에서 로그인을 했더라도 다른 사람의 글까지 수정/삭제가 가능하진 않음
• 세션, 토큰, 제 3자를 활용하는 등의 다양한 인증 방식이 존재

[Authentication determined]

다양한 인증 방식

• BasicAuthentication

  • 가장 기본적인 수준의 인증 방식
  • 테스트에 적합

• SessionAuthentication

  • Django에서 사용하였던 session 기반의 인증 시스템
  • DRF와 Django의 session 인증 방식은 보안적 측면을 구성하는 방법에 차이가 있음

• RemoteUserAuthentication

  • Django의 Remote user 방식을 사용할 때 활용하는 인증 방식

• TokenAuthentication

  • 매우 간단하게 구현할 수 있음
  • 기본적인 보안 기능 제공
  • 다양한 외부 패키지가 있음

[중요!] settings.py에서 DEFAULT_AUTHENTICATION_CLASSES를 정의

• TokenAuthentication 인증 방식을 사용할 것임을 명시

[TokenAuthentication 사용 방법]

• settings.py > INSTALLED_APPS에 rest_framework.authtoken 등록

• 각 User 마다 고유 Token 생성

• 생성한 Token을 각 User에게 발급
  • User는 발급 받은 Token을 요청과 함께 전송
  • Token을 통해 User 인증 및 권한 확인
• Token 발급 방법

• User는 발급 받은 Token을 headers에 담아 요청과 함께 전송
  • 단, 반드시 Token 문자열 함께 삽입
  • 삽입해야할 문자열은 각 인증 방식마다 다름(ex. Bearer, Auth, JWT 등)
  • Token 문자열과 발급받은 실제 token 사이를 ' '(공백)으로 구분
• Authorization HTTP headers 작성 방법

토큰 생성 및 관리 문제점

• 기본 제공 방식에서 고려하여야 할 사항들

1. Token 생성 시점
2. 생성한 Token 관리 방법
3. User와 관련된 각종 기능 관리 방법
   • 회원가입, 로그인, 회원 정보 수정, 비밀번호 변경 등..

[dj-rest-auth]

• 회원가입, 인증(소셜미디어 인증 포함), 비밀번호 재설정, 사용자 세부 정보 검색, 회원 정보 수정 등을 위한 REST API end point 제공
• django-rest-auth는 더 이상 업데이트를 지원하지 않음 ==> dj-rest-auth 사용

**[dj-rest-auth] 사용 방법 **

1. 패키지 설치

   $ pip install 'dj-rest-auth[with_social]'

2.App 등록

• settings.py > INSTALLED_APPS에 'dj-rest-auth' 등록

3. url 등록

[before start]

• 시작하기 전 auth.User를 accounts.User로 변경 필요
  • settings.py > AUTH_USER_MODEL = 'accounts.User'
• auth.User로 설정된 DB제거
• dq.sqlite3 삭제
• migrations의 파일들 삭제

• my_api/settings.py에 추가
• App 등록 및 SITE_ID 설정

[SITE_ID]

• Django는 하나의 컨텐츠를 기반으로 여러 도메인에 컨텐츠를 게시 가능하도록 설계됨
• 다수의 도메인이 하나의 데이터베이스에 등록
• 현재 프로젝트가 첫번째 사이트임을 나타냄

• Vue의 공식 라우터
• SPA 상에서 라우팅을 쉽게 개발할 수 있는 기능을 제공
• 라우트(routes)에 컴포넌트를 매핑한 후, 어떤 URL에서 렌더링 할지 알려줌
  • 즉, SPA를 MPA처럼 URL을 이동하면서 사용 가능
  • SPA의 단점 중 하나인 "URL이 변경되지 않는다"를 해결

$ vue create vue-router-app

$ cd vue-router-app

$ vue add router 

• 기존에 프로젝트를 진행하고 있던 도중에 router를 추가하게 되면 App.vue를 덮어쓰므로 필요한 경우 명령을 실행하기 전에 파일을 백업해두어야 함

[History mode]

• 브라우저의 History API를 활용한 방식
  • 새로고침 없이 URL 이동 기록을 남길 수 있음
• 우리에게 익숙한 URL 구조로 사용 가능
  • ex) http://localhost:8000/index
• History mode를 사용하지 않으면 Default 값인 hash mode로 설정('#'을 통해 URL을 구분하는 방식)
  • ex) http://localhost:8080#index

[App.vue]

• router/index.js
• views 폴더 생성

[router-link]

• a태그와 비슷한 기능 ==> URL을 이동시킴
  • routes에 등록된 컴포넌트와 매핑
  • 히스토리 모드에서 router-link는 클릭 이벤트로 차단하여 a태그와 달리 브라우저가 페이지를 다시 로드 하지 않도록 함
• 목표 경로는 'to' 속성으로 지정됨
• 기능에 맞게 HTML에서 a태그로 rendering 되지만, 필요에 따라 다른 태그로 바꿀 수 있음

[router-view]

• 주어진 URL에 대해 일치하는 컴포넌트를 렌더링 하는 컴포넌트
• 실제 component가 DOM에 부착되어 보이는 자리를 의미
• router-link를 클릭하면 routes에 매핑된 컴포넌트를 렌더링
• django에서의 block tag와 비슷함
  • App.vue == base.html
  • router-view == block 태그로 감싼 부분

[src/router/index.js]

• 라우터에 관련된 정보 및 설정이 작성되는 곳
• Django에서의 urls.py에 해당
• routes에 URL과 컴포넌트를 매핑

[src/Views]

• router-view에 들어갈 component 작성
• 기존에 컴포넌트를 작성하던 곳은 components 폴더 뿐이었지만 이제 두 폴더로 나뉘어짐
• 각 폴더 안의 .vue 파일들이 기능적으로 다른 것은 아님
• 폴더별 컴포넌트 배치는 다음과 같이 진행
• views/
  • routes에 매핑되는 컴포넌트, 즉 router-view 태그의 위치에 렌더링되는 컴포넌트를 모아두는 폴더
  • 다른 컴포넌트와 구분하기 위해 View로 끝나도록 파일이름 만드는 것 권장
• components/
  • routes에 매핑된 컴포넌트의 하위 컴포넌트를 모아두는 폴더

Vue Router 주소 이동

1. 선언적 방식 네비게이션
2. 프로그래밍 방식 네비게이션

[1.선언적 방식 네비게이션]

파일 경로 ==> App.vue

• router-link의 'to' 속성으로 주소 전달
  • routes에 등록된 주소와 매핑된 컴포넌트로 이동

• Named Routes
  • 이름을 가지는 routes
  • Django에서 path 함수의 name 인자의 활용과 같은 방식

• 동적인 값을 사용하기때문에 v-bind를 사용해야 정상적으로 작동

[2.프로그래밍 방식 네비게이션]

• Vue 인스턴스 내부에서 라우터 인스턴스에 $router 로 접근할 수 있음
• 다른 URL로 이동하려면 this.$router.push 를 사용
  • history stack에 이동할 URL을 넣는 방식
  • history stack에 기록이 남기 때문에 사용자가 브라우저의 뒤로가기 버튼을 클릭하면 이전 URL로 이동할 수 있음
• 결국 router-link :to="..." 를 클릭하는 것과 $router.push(...)를 호출하는 것은 같은 동작

[Dynamic Route Matching]

파일 경로 ==> router/index.js

파일 경로 ==> HellowView.vue

• HelloView.vue 작성 및 route를 추가
• route를 추가할 때 동적 인자를 명시

• $route.params 로 변수에 접근 가능
• HTML에서 직접 사용하기보다는 data에 넣어서 사용하는 것을 권장

[선언적 방식 네비게이션]

• params를 이용하여 동적 인자 전달 가능

[프로그래밍 방식 네비게이션]

• AboutView에서 데이터를 입력 받아 HelloView로 이동하여 입력받은 데이터에게 인사하기

[route에 컴포넌트를 등록하는 또다른 방법]

• route/index.js에 컴포넌트를 등록하는 또 다른 방식이 주어지고 있음(about)
• lazy loading
  • 모든 파일을 한번에 로드하려고 하면 모든 걸 다 읽는 시간이 매우 오래 걸림
  • 미리 로드를 하지 않고 특정 라우트에 방문할 때 매핑된 컴포넌트의 코드를 로드하는 방식을 활용할 수 있음
  • 모든 파일을 한 번에 로드하지 않아도 되기 때문에 최초에 로드하는 시간이 빨라짐
  • 당장 사용하지 않을 컴포넌트는 먼저 로드하지 않는 것이 핵심

• 상태(state) : 현재에 대한 정보(data)

• Web Application에서의 상태 ==> 현재 App이 가지고 있는 Data로 표현 가능

• 여러개의 component를 조합해서 하나의 App을 만들고 있음

• 각 component는 독립적이기 때문에 각각의 상태를 가짐

• 하지만 결국 이러한 component들이 모여서 하나의 App을 구성할 예정 ==> 즉, 여러개의 component가 같은 상태(data)를 유지할 필요가 있음(상태 관리)

[Pass Props & Emit Event]

• 이전까지 props와 event를 이용해 상태 관리를 하고 있음
• 각 컴포넌트는 독립적으로 데이터를 관리
• 같은 데이터를 공유하고 있으므로, 각 컴포넌트가 동일한 상태를 유지하고 있음
• 데이터의 흐름을 직관적으로 파악 가능
• But, component의 중첩이 깊어지면 데이터 전달이 쉽지 않음
• 공통의 상태를 유지해야하는 component가 많아지면 데이터 전달 구조가 복잡해짐

Vuex(Centralized Store)

• 중앙 저장소(store)에 데이터를 모아서 상태 관리
• 각 component는 중앙 저장소의 데이터를 사용
• component의 계층에 상관없이 중앙 저장소에 접근해서 데이터를 얻거나 변경할 수 있음
• 중앙 저장소의 데이터가 변경되면 각각의 component는 해당 데이터의 변화에 반응하여 새로 변경된 데이터를 반영
• 규모가 크거나 컴포넌트 중첩이 깊은 프로젝트의 관리가 매우 편리

==> 위와 같은 중앙 저장소를 통한 상태관리를 도와주는 것이 Vuex / 데이터가 예측 가능한 방식으로만 변경될 수 있도록하는 규칙을 설정하며, Vue의 반응성을 효율적으로 사용하는 상태 관리 기능을 제공

[Vuex]

$ vue create vuex-app

• vue project 생성

  $ cd vuex-app

• 디렉토리 이동

  $ vue add vuex 

• Vue CLI를 통해 vuex plugin 적용
• src / store / index.js 가 생성

• vuex의 핵심 컨셉 4가지

1. state
2. getters
3. mutations
4. actions

1. State

• vue instance의 data에 해당
• 중앙에서 관리하는 모든 상태 정보
• 개별 component는 state에서 데이터를 가져와서 사용
  • 개별 component가 관리하던 data를 중앙 저장소(Vuex Store의 state)에서 관리하게 됨
• state의 데이터가 변화하면 해당 데이터를 사용(공유)하는 component도 자동으로 다시 렌더링
• $store.state로 state 데이터에 접근

2. Mutations

• 실제로 state를 변경하는 유일한 방법
• vue instance의 methods에 해당하지만 Mutation에서 호출되는 핸들러 함수는 반드시 동기적이어야 함
  • 비동기 로직으로 mutations를 사용해서 state를 변경하는 경우, state의 변화의 시기를 특정할 수 없기 때문
• 첫번째 인자로 state를 받으며, component 혹은 Actions에서 commit() 메서드로 호출됨

3. Actions

• mutations와 비슷하지만 비동기 작업을 포함할 수 있다는 차이가 있음
• state를 직접 변경하지 않고 commit() 메서드로 mutations를 호출해서 state를 변경함
• context 객체를 인자로 받으며, 이 객체를 통해 store.js의 모든 요소와 메서드에 접근할 수 있음( == 즉 state를 직접 변경할 수 있지만 하지 않아야 함)
• component에서 dispatch() 메서드에 의해 호출됨

[Mutations & Actions]

• Vue component의 methods 역할이 vuex에서는 아래와 같이 분화됨
• Mutations : state를 변경
• Actions : state 변경을 제외한 나머지 로직

4. Getters

• vue instance의 computed에 해당
• state를 활용하여 계산된 값을 얻고자 할 때 사용
• state의 원본 데이터를 건들지 않고 계산된 값을 얻을 수 있음
• computed와 마찬가지로 getters의 결과는 캐시(cache)되며, 종속된 값이 변경된 경우에만 재계산됨
• getters에서 계산된 값은 state에 영향을 미치지 않음
• 첫번째 인자로 state, 두번째 인자로 getter를 받음

[모든 데이터를 Vuex에서 관리해야 하는가?]

• Vuex를 사용한다고 해서 모든 데이터를 state에 넣어야 하는 것은 아님
• Vuex에서도 여전히 pass props, emit event를 사용하여 상태를 관리할 수 있음
• 개발 환경에 따라 적절하게 사용하는 것이 필요함

[summary]

• state : 중앙에서 관리하는 모든 상태 정보
• mutations : state를 변경하기 위한 methods
• actions : 비동기 작업이 포함될 수 있는(외부 API와의 소통 등) methods / state를 변경하는 것 외의 모든 로직 진행
• getters: state를 활용해 계산한 새로운 변수 값

component에서 데이터를 사용하기 위한 데이터의 흐름

• component ==> (actions) ==> mutations ==> state

component에서 데이터를 사용하기 위한 데이터의 흐름

• state ==> (getters) ==> component

[Vuex example]

[Data in components]

• 우리는 정적인 웹페이지가 아닌 동적 웹을 만든다.

• 다루어야 할 데이터들은 한 페이지 내에서 같은 데이터를 공유하기도 하는데 페이지들은 각각의 component로 구분이 되어있음

• 완전히 동일한 데이터를 서로 다른 component에서 보여주려면 어떻게 해야할까?

  • 필요한 컴포넌트끼리 데이터를 주고받기 ( X )
    • 데이터 흐름을 파악하기 힘들다
    • 개발 속도 저하
    • 유지보수 난이도 증가
  • 컴포넌트의 부모 - 자식 관계만 데이터를 주고 받도록 ( O )
    • 데이터 흐름 파악 용이
    • 유지 보수 용이
    • 부모 ==> 자식 으로의 데이터 흐름(pass props)
    • 자식 ==> 부모로의 데이터 흐름 (emit event)

[Pass Props]

• 요소의 속성을 사용하여 데이터 전달
• props는 부모(상위) 컴포넌트의 정보를 전달하기 위한 사용자 지정 특성
• 자식(하위) 컴포넌트는 props 옵션을 사용하여 수신하는 props를 명시적으로 선언해야 함
• 정적인 데이터를 전달하는 경우 static props라고 명시하기도 함
• 요소에 속성을 작성하듯이 사용 가능하여, prop-data-name = "value"의 형태로 데이터를 전달(이때 속성의 키 값은 kebab-case를 사용)

• prop 명시
• 데이터를 받는 쪽, 즉 하위 컴포넌트에서도 props에 대해 명시적으로 작성해주어야 함
• 전달받은 props를 type과 함께 명시
• 컴포넌트를 문서화할 뿐만 아니라, 잘못된 타입이 전달하는 경우 브라우저의 자바스크립트 콘솔에서 사용자에게 경고

[Pass Props convention]

• 부모에서 넘겨주는 props
  • kebab-case(HTML 속성명은 대소문자를 구분하지 않기 때문)
• 자식에서 받는 props
  • camelCase
• 부모 템플릿(html)에서 kebab-case로 넘긴 변수를 자식의 스크립트(vue)에서 자동으로 camelCase로 변환하여 인식함

[Dynamic props]

• 변수를 props로 전달할 수 있음

• v-bind directive를 사용해 데이터를 동적으로 바인딩

• 부모 컴포넌트의 데이터가 업데이트되면 자식 컴포넌트로 전달되는 데이터 또한 업데이트 됨

• :dynamic-props="dynamicProps"는 앞의 key값(dynamic-props)이란 이름으로 뒤의 " "안에 오는 데이터(dynamicProps)를 전달하겠다는 뜻

• 즉, :my-props="dynamicProps"로 데이터를 넘긴다면, 자식 컴포넌트에서 myProps로 데이터를 받아야 함

• v-bind로 묶여있는 " " 안의 구문은 JS의 구문으로 볼 수 있음 (따라서 dynamicProps라고 하는 변수에 대한 data를 전달할 수 있는 것)

[단방향 데이터 흐름]

• 모든 props는 부모에서 자식으로 즉 아래로 단방향 바인딩을 형성
• 부모 속성이 업데이트 되면 자식으로 흐르지만 반대 방향은 아님
  • 부모 컴포넌트가 업데이트 될 때마다 자식 컴포넌트의 모든 prop들이 최신값으로 새로고침 됨
  • 하위 컴포넌트가 실수로 상위 컴포넌트 상태를 변경하여 앱의 데이터 흐름을 이해하기 힘들게 만드는 것을 방지
  • 하위 컴포넌트에서 prop을 변경하려고 시도해서는 안되며 그렇게 하면 Vue는 콘솔에서 경고를 출력함

[Emit Event]

• 부모 컴포넌트에서 자식 컴포넌트로 데이터를 전달할 때는 이벤트를 발생시킴
• 이벤트를 발생시킴으로 어떻게 데이터를 전달?
  • 데이터를 이벤트 리스너의 콜백함수의 인자로 전달
  • 상위 컴포넌트는 *해당 이벤트를 통해 데이터를 받음 *

[$emit]

• $emit 메서드를 통해 부모 컴포넌트에 이벤트를 발생
  • $emit('event-name') 형식으로 사용하며 부모 컴포넌트에 event-name이라는 이벤트가 발생했다는 것을 알림
  • 마치 사용자가 마우스 클릭을 하면 click event가 발생하는 것처럼 $emit('event-name')가 실행되면 event-name 이벤트가 발생하는 것

[Emit Event]

1. 자식 컴포넌트에 버튼을 만들고 클릭 이벤트를 추가
2. $emit을 통해 부모 컴포넌트에게 child-to-parent 이벤트를 트리거

3. emit된 이벤트를 상위 컴포넌트에서 청취 후 핸들러 함수 실행

• 자식 컴포넌트에 있는 버튼 클릭 이벤트를 청취하여 연결된 핸들러 함수 호출
• 호출된 함수에서 $emit을 통해 상위 컴포넌트에 이벤트 발생
• 상위 컴포넌트는 자식 컴포넌트가 발생시킨 이벤트를 청취하여 연결된 핸들러 함수 호출

[emit with data]

• 이벤트 발생 시 인자로 데이터를 전달 가능

• 이렇게 전달한 데이터는 이벤트와 연결된 부모 컴포넌트의 핸들러 함수의 인자로 사용 가능

1. 자식 컴포넌트에 있는 버튼 클릭 이벤트를 청취하여 연결된 핸들러 함수 호출
2. 호출된 함수에서 $emit을 통해 부모 컴포넌트에 이벤트를 발생(이벤트에 데이터를 함께 전달)
3. 부모 컴포넌트는 자식 컴포넌트의 이벤트를 청취하여 연결된 핸들러 함수 호출, 함수의 인자로 전달된 데이터가 포함되어 있음

[emit with dynamic data]

[pass props / emit event 컨벤션]

• HTML 요소에서 사용할 때는 kebab-case
• JS에서 사용할 때는 camelCase
• props
  • 상위 ==> 하위 흐름에서 HTML 요소로 내려줌 : kebab-case
  • 하위에서 받을 때 JS에서 받음 camelCase
• emit
  • emit 이벤트를 발생시키면 HTMl요소가 이벤트를 청취 : kebab-case
  • 메서드, 변수명 등은 JS에서 사용함 : camelCase

• ** 유지/보수 용이, 재사용성, 확장 가능, 캡슐화, 독립적**
• UI를 독립적이고 재사용 가능한 조각들로 나눈 것(기능별로 분화한 코드 조각)
• CS에서는 다시 사용할 수 있는 범용성을 위해 개발된 소프트웨어 구성 요소를 의미
• 하나의 app을 구성할 때 중첩된 컴포넌트들의 tree로 구성하는 것이 보편적임
  • src/App.vue를 root node로 하는 tree의 구조를 가짐
• 컴포넌트는 유지보수를 쉽게 만들어 줄 뿐만 아니라 재사용성의 측면에서도 매우 강력한 기능을 제공
• 우리가 사용하는 웹 서비스는 여러개의 컴포넌트로 이루어져 있음
• 하나의 컴포넌트를 만들어두면 반복되는 UI를 쉽게 처리할 수 있음

[SFC]

• component in Vue
  • 이름이 있는 재사용 가능한 Vue instance
  • new Vue()로 만든 인스턴스

[SFC(Single File Component)]

• 하나의 .vue 파일이 하나의 Vue instance이고, 하나의 컴포넌트이다.
• Vue instance에서는 HTML,CSS,JavaScript 코드를 한번에 관리
• 컴포넌트 기반 개발의 핵심 기능
• Vue CLI가 Vue를 Component based하게 사용가능하게 함

[Vue Component]

• 템플릿(HTML)
  • HTML의 body 부분
  • 눈으로 보여지는 요소 작성
  • 다른 컴포넌트를 HTML 요소처럼 추가 가능
• 스크립트(JavaScript)
  • JS 코드가 작성되는 곳
  • 컴포넌트 정보, 데이터, 메서드 등 Vue instance를 구성하는 대부분이 작성 됨
• 스타일(CSS)
  • CSS가 작성되며 컴포넌트의 스타일을 담당

• 컴포넌트들이 tree 구조를 이루어 하나의 페이지를 만듦
• root에 해당하는 최상단의 component가 App.vue
• 이 App.vue를 index.html 과 연결
• 결국 index.html 파일 하나만을 rendering(SPA)

[Vue CLI install]

• Vue 개발을 위한 표준 도구
• 프로젝트의 구성을 도와주는 역할
• 확장 플러그인, GUI, Babel 등 다양한 tool 제공

[설치]

$ npm install -g @vue/cli

[프로젝트 생성]

$ vue create vue-cli

• vscode terminal에서 진행

[Vue 버전 선택]

> Default ([Vue 2] babel,eslint)

[설치 시 출력되는 명령어 실행]

$ cd vue-cli

$ npm run serve 

[Vue CLI 프로젝트 구조]

[node-modules]

• node.js 환경의 여러 의존성 모듈
• python의 venv와 비슷한 역할을 함
  • 따라서 .gitignore에 넣어줘야 하며, Vue 프로젝트를 생성하면 자동으로 추가 됨

[Babel]

• JS Compiler
• JS의 ES6+ 코드를 구버전으로 번역/변환 해주는 도구
• JS의 파편화, 표준화의 영향으로 작성된 코드의 스펙트럼이 매우 다양
  • 최신 문법을 사용해도 브라우저의 버전 별로 동작하지 않는 상황이 발생
  • 버전에 따른 같은 의미의 다른 코드를 작성하는 등의 대응이 필요해졌고, 이러한 문제를 해결하기 위한 도구
  • 원시 코드(최신 버전)를 목적 코드(구 버전)으로 옮기는 번역기가 등장하면서 더 이상 코드가 특정 브라우저에서 동작하지 않는 상황에 대해 크게 고민하지 않을 수 있음

[Webpack]

• static module bundler
• 모듈 간의 의존성 문제를 해결하기 위한 도구
• 프로젝트에 필요한 모든 모듈을 매핑하고, 내부적으로 종속성 그래프를 빌드함

[Module]

• 개발하는 어플리케이션의 크기가 커지고 복잡해지면, 파일 하나에 모든 기능을 담기가 어려워짐
• 따라서 자연스럽게 파일을 여러 개로 분리하여 관리를 하게 되었고, 이때 분리된 파일 각각이 모듈 즉, JS파일 하나가 하나의 모듈
• 모듈은 대개 기능 단위로 분리하며, 클래스 하나 혹은 특정한 목적을 가진 복수의 함수로 구성된 라이브러리 하나로 구성됨
• ** Module 의존성 문제** : 모듈의 수가 많아지고 라이브러리 혹은 모듈 간의 의존성이 깊어지면서 특정한 곳에서 발생한 문제가 어떤 모듈 간의 문제인지 파악하기 어려움 ==> Webpack은 이 모듈 간의 의존성 문제를 해결하기 위해 등장

[Bundler]

• 모듈 의존성 문제를 해결해주는 작업이 Bundling
• 이러한 일을 해주는 도구가 Bundler이고, Webpack은 다양한 Bundler 중 하나
• 모듈들을 하나로 묶어주고 묶인 파일은 하나(혹은 여러개)로 만들어짐
• Bundling된 결과물은 개별 모듈의 실행 순서에 영향을 받지않고 동작하게 됨
• Vue CLI는 이러한 Babel,Webpack에 대한 초기 설정이 자동으로 되어있음

[package.json]

• 프로젝트의 종속성 목록과 지원되는 브라우저에 대한 구성 옵션을 포함

[package-lock.json]

• node_modules에 설치되는 모듈과 관련된 모든 의존성을 설정 및 관리
• 협업 및 배포 환경에서 정확히 동일한 종속성을 설치하도록 보장하는 표현
• 사용할 패키지의 버전을 고정
• 개발 과정 간의 의존성 패키지 충돌 방지
• python의 requirement.txt 역할

[public/index.html]

• Vue 앱의 뼈대가 되는 html파일
• Vue 앱과 연결될 요소가 있음

[src/]

• src/assets
  • 정적 파일을 저장하는 디렉토리
• src/components -하위 컴포넌트들이 위치
• src/App.vue
  • 최상위 컴포넌트
  • public/index.html과 연결됨
• src/main.js
  • webpack이 빌드를 시작할 때 가장 먼저 불러오는 entry point
  • public/index.html과 src/App.vue를 연결시키는 작업이 이루어지는 곳
  • Vue 전역에서 활용 할 모듈을 등록할 수 있는 파일

Template Syntax

• 렌더링 된 DOM을 기본 Vue instance의 data에 선언적으로 바인딩할 수 있는 HTMl 기반 template syntax를 사용

  • 렌더링된 DOM : 브라우저에 의해 보기 좋게 그려질 HTML 코드
  • HTML 기반 template syntax : HTML 코드에 직접 작성할 수 있는 문법 제공
  • 선언적으로 바인딩: Vue instance와 DOM을 연결

Text Interpolation

• 가장 기본적인 바인딩(연결) 방법
• 중괄호 2개로 표기
• DTL과 동일한 형태로 작성
• Text interpolation 방법은 모두 일반 텍스트로 표현

Raw HTML

• v-html directive를 사용하여 data와 바인딩
• directive - HTML 기반 template syntax
• HTML의 기본속성이 아닌 Vue가 제공하는 특수 속성의 값으로 data를 작성

[Directives]

• v-접두사가 있는 특수 속성에는 값을 할당 할 수 있음(값에는 JS 표현식을 작성할 수 있음)
• directive의 역할은 표현식의 값이 변경될 때 반응적으로 Dom에 적용하는 것

Directives 기본 구성

[월요일 vue 교재 10p 사진 추가]

• ' : ' 을 통해 전달 인자를 받을 수 있음
• ' . ' 으로 표시되는 특수 접미사 - directive를 특별한 방법으로 바인딩 해야 함

[v-text]

• Template Interpolation과 함께 가장 기본적인 바인딩 방법
• {{ }} 와 동일한 역할(정확히 동일한 역할인 것은 아님)

[v-html]

• RAW HTML을 표현할 수 있는 방법
• 단, 사용자가 입력하거나 제공하는 컨텐츠에는 절대 사용 금지(XSS 공격 참고)

[v-show]

• 표현식에 작성된 값에 따라 element를 보여줄 것인지 결정
• boolean 값이 변경될 때 마다 반응
• 대상 element의 display 속성을 기본 속성과 none으로 toggle
• 요소 자체는 항상 DOM에 렌더링 됨
• false값이 되어도 화면에서만 사라졌을 뿐, DOM에는 존재한다. (display 속성만 변경된 것)

[v-if]

• v-show와 사용 방법은 동일
• isActive의 값이 변경 될 때 반응
• 단, 값이 false인 경우 DOM에서 사라짐
• v-if, v-else-id, v-else 형태로 사용

v-show VS v-if

• v-show(Expensive initial load, cheap toggle)

  • 표현식 결과와 관계없이 렌더링 되므로 초기 렌더링에 필요한 비용은 v-if보다 높을 수 있음
  • display 속성 변경으로 표현 여부를 판단하므로 렌더린 후 toggle 비용은 적음

• v-if (Cheap initial load, expensive toggle)

  • 표현식 결과가 false인 경우 렌더링조차 되지 않으므로 초기 렌더링 비용은 v-show 보다 낮을 수 있음
  • 단, 표현식 값이 자주 변경되는 경우 잦은 재 렌더링 비용이 증가할 수 있음

[v-for]

[string]

• for .. in .. 형식으로 작성
• 반복한 데이터 타입에 모두 사용 가능
• index를 함께 출력하고자 한다면 (char,index) 형태로 사용 가능

[Array]

• 배열 역시 문자열과 동일하게 사용 가능
• 각 요소가 객체라면 dot notation으로 접근할 수 있음

[참고] 특수 속성 key

• "v-for 사용 시 반드시 key 속성을 각 요소에 작성"
• 주로 v-for directive 작성 시 사용
• vue 화면 구성 시 이전과 달라진 점을 확인하는 용도로 활용(따라서 key가 중복되어서는 안됨)
• 각 요소가 고유한 값을 가지고 있다면 생략할 수 있음

[Object]

• 객체 순회 시 value가 할당되어 출력
• 두번째 변수 할당 시 key 출력 가능

[v-on]

• ' : ' 을 통해 전달받은 인자를 확인
• 값으로 JS 표현식 작성
• addEventListener의 첫 번째 인자와 동일한 값들로 구성
• 대기하고 있던 이벤트가 발생하면 할당된 표현식 실행
• methodfmf 통한 data 조작도 가능
• method에 인자를 넘기는 방법은 일반 함수를 호출할 때와 동일한 방식
• ':'을 통해 전달된 인자에 따라 특별한 modifiers(수식어)가 있을 수 있음
  • ex) v-on:keyup.enter 등
• '@' shortcut 제공
  • ex) @keyup.click

[v-if]

• HTML 기본 속성에 Vue data를 연결

• class의 경우 다양한 형태로 연결 가능

  • 조건부 바인딩
    • {'class Name': '조건 표현식'}
    • 삼항 연산자도 가능
  • 다중 바인딩
    • ['JS표현식','JS표현식'...]

• Vue data의 변화에 반응하여 DOM에 반영하므로 상황에 따라 유동적 할당 가능

• ' : ' shortcut 제공

  • ex) :class 등
  • v-for에서 사용하였던 :key는 v-bind의 숏컷을 활용한 것

[v-model]

• Vue instance와 DOM의 양방향 바인딩
• Vue data 변경 시 v-model로 연결된 사용자 입력 element에도 적용

[Vue advanced]

computed

• vue instance가 가진 options 중 하나
• computed 객체에 정의한 함수를 페이지가 최초로 렌더링될 때 호출하여 계산
• 계산 결과가 변하기 전까지 함수를 재호출하는 것이 아닌 계산된 값을 반환

methods VS computed

• methods
  • 호출될 때마다 함수를 실행
  • 같은 결과여도 매번 새롭게 계산
• computed
  • 함수의 종속 대상의 변화에 따라 계산 여부가 결정 됨
  • 종속 대상이 변하지 않으면 항상 저장(캐싱)된 값을 변환

watch

• 특정데이터의 변화를 감지하는 기능
  1. watch 객체를 정의
  2. 감시할 대상 data를 지정
  3. data가 변할 시 실행 할 함수를 정의
• 첫 번째 인자는 변동 후 data
• 두 번째 인자는 변동 전 data
• 실행 함수를 Vue method로 대체 가능
  1. 감시대상 data의 이름으로 객체 생성
  2. 실행하고자 하는 method를 handler에 문자열 형태로 할당
• Array,Object 내부 요소 변경 감지를 위해서는 deep 속성필요

filter

• 텍스트 형식화를 적용할 수 있는 필터
• interpolation 혹은 v-bind를 이용할 때 사용 가능
• 필터는 자바스트립트 표현식 마지막에 ' | ' (파이프)와 함께 추가 되어야 함
• 이어서 사용(chaining) 가능

• 소프트웨어 아키텍처 패턴의 일종

• 마크업 언어로 구현하는 그래픽 사용자 인터페이스(view)의 개발을 Back-end(model)로부터 분리시켜 view가 어느 특정한 모델 플랫폼에 종속되지 않도록 함

• View : 우리 눈에 보이는 부분 = DOM

• Model : 실제 데이터 = JSON

• Veiw Model(vue)

  • View를 위한 Model
  • View와 연결(binding)되어 Action을 주고 받음
  • Model이 변경되면 View Model도 변경되고 바인딩된 View도 변경됨
  • View Model의 데이터가 변경되고 바인딩 된 다른 View도 변경됨

View instance

• Vue instance === 1개의 객체
• 아주 많은 속성과 메서드를 이미 가지고 있고, 이러한 기능들을 사용하는 것

el (element)

• Vue instance 와 DOM을 연결(mount)하는 옵션
  • HTML id 혹은 class와 마운트 역할
  • View와 Model을 연결하는 역할
• Vue instance와 연결되지 않은 DOM 외부는 Vue의 영향을 받지 않음(Vue 속성 및 메서드 사용 불가)

• 새로운 Vue instance 생성
• 생성자 함수 첫번째 인자로 Object 작성
• el 옵션에 #app 작성 = DOM 연결

data

• Vue instance의 데이터 객체 혹은 인스턴스 속성
• 데이터 객체는 반드시 기본 객체 {} (Object)여야 함
• 객체 내부의 아이템들은 value로 모든 타입의 객체를 가질 수 있음
• 정의된 속성은 interpolation {{}} 을 통해 view에 렌더링 가능함

• Vue instance에 data 객체 추가
• data 객체에 message 값 추가
• 추가된 객체의 각 값들은 this.message 형태로 접근 가능

methods

• Vue instance의 method들을 정의하는 곳
• methods 객체 정의

[주의] methods with Arrow Function

• 메서드를 정의할 때, Arrow Function을 사용하면 안됨
• Arrow Function의 this는 함수가 선언될 때 상위 스코프를 가리킴
• 즉 this가 상위 객체 window를 가리킴
• 호출은 문제없이 가능하나 this로 Vue의 data를 변경하지 못함

[N:1 참조 조회]

[실습 사전 준비]

파일 경로 ➡️ articles/models.py

$ python manage.py makemigrations 

$ python manage.py migrate

• Comment 모델 작성 및 데이터베이스 초기화 & migration

GET - LIST

• 댓글 데이터 목록 조회하기

파일 경로 ➡️ articles/serializers.py

파일 경로 ➡️ articles/urls.py

파일 경로 ➡️ articles/views.py

GET = DETAIL

• 단일 댓글 데이터 조회하기
• Article과 달리 같은 serializer 사용하기

파일 경로 ➡️ articles/urls.py

파일 경로 ➡️ articles/views.py

POST

• 단일 댓글 데이터 생성

파일 경로 ➡️ articles/urls.py

파일 경로 ➡️ articles/views.py

• line 6
• save() 메서드는 특정 Serializer 인스턴스를 저장하는 과정에서 추가적인 데이터를 받을 수 있음
• CommentSerializer를 통해 Serialize 되는 과정에서 parameter로 넘어온 article_pk에 해당하는 article 객체를 추가적인 데이터를 넘겨 저장

파일 경로 ➡️ articles/serializers.py

• CommentSerializer에서 article field 데이터 또한 사용자로부터 입력받도록 설정되어있어 에러가 발생
• read_only_fields를 사용해 외래 키 필드를 읽기전용 필드로 설정
• 읽기전용 필드는 데이터를 전송하는 시점에 '해당필드를 유효성 검사에서 제외시키고 데이터 조회시에는 출력' 하도록 함

DELETE & PUT

파일 경로 ➡️ articles/views.py

[N:1 역참조 데이터 조회]

1. 특정 게시글에 작성된 댓글 목록 출력하기

• 기존 필드 override

2. 특정 게시글에 작성된 댓글의 개수 출력하기

• 새로운 필드 추가

[특정 게시글에 작성된 댓글 목록 출력하기]

• 기존 필드 override - Article Detail
  • 게시글 조회 시 해당 게시글의 댓글 목록까지 함께 출력하기
  • Serializer는 기존 필드를 override 하거나 추가적인 필드를 구성할 수 있음

1. PrimaryKeyRelatedFields

파일 경로 ➡️ articles/serializers.py

• POSTMAN 댓글있는 게시글 조회 결과

• models.py에서 related_name을 이용하여 이름 변경 가능
• 역참조 시 생성되는 comment_set을 override 할 수 있음

2. Nested relationships

• 모델 관계 상으로 참조 된 대상은 참조하는 대상의 표현에 포함되거나 중첩될 수 있음
• 이러한 중첩된 관계는 serializers를 필드로 사용하여 표현할 수 있음
• 두 클래스의 상/하 위치를 변경해야함

파일 경로 ➡️ articles/serializers.py

[특정 게시글에 작성된 댓글의 개수 출력하기]

• 새로운 필드 추가 - Article Detail
  • 게시글 조회 시 해당 게시글 댓글 개수까지 함게 출력하기

파일 경로 ➡️ articles/serializers.py

• line 3 : source
• serializes field's argument
• 필드를 채우는 데 사용할 속성의 이름
• 점 표기법을 사용하여 속성을 탐색할 수 있음

[Django shortcuts function]

• django.shortcut 패키지는 개발에 도움 될 수 있는 여러 함수와 클래스를 제공
• 제공되는 shortcuts 목록
  • render(), redirect(), get_object_or_404(), get_list_or_404()

1. get_object_or_404()

• 모델 manager objects에서 get()을 호출하지만, 해당 객체가 없을 땐 기존 DoesNotExist 예외 대신 Http404를 raise함

2. get_list_or_404()

• 모델 manager objects에서 filter() 결과를 반환하고 해당 객체 목록이 없을 땐 Http404를 raise함

왜 사용해야 할까?

• 클라이언트 입장에서 "서버에 오류가 발생하여 요청을 수행할 수 없다(500)"라는 원인이 정확하지 않은 에러를 마주하기 보다는, 서버가 적절한 예외처리를 하고 클라이언트에게 올바른 에러를 전달하는 것 또한 중요한 요소이기 때문

• Django REST framework 는 django에서 Restful API 서버를 쉽게 구축할 수 있도록 도와주는 오픈소스 라이브러리

• Web API 구축을 위한 강력한 toolkit을 제공

• DRF의 serializer는 django의 Form 및 ModelForm 클래스와 매우 유사하게 작동

[실습 사전 준비]

• 가상환경 생성 및 실행
• pip install

  $ pip install django==3.2.18 djangorestframework django-seed psycopg2

• 프로젝트 생성, articles 앱 생성, urls 등록

파일 경로 ==> settings.py

파일 경로 ==> myapi/urls.py

파일 경로 ==> articles/urls.py

• view 임시 작성

• Articles 모델 작성 및 migration

파일 경로 ==> articles/models.py

$ python manage.py makemigrations

$ python manage.py migrate

5. django-seed 이용해 임의 데이터 생성

$ python manage.py seed articles --number 20

[ModelSerializer]

• serializers.py 생성
• ModelSerializer 작성

파일 경로 ==> articles/serializers.py

ModelSerializer

• ModelSerializer 클래스는 모델 필드에 해당하는 필드가 있는 Serializer 클래스를 자동으로 만들 수 있는 shortcut을 제공

1. Model 정보에 맞춰 자동으로 필드를 생성
2. serializer에 대한 유효성 검사기를 자동으로 생성
3. .create() 및 .update()의 간단한 기본 구현이 포함됨
4. 단일 객체 인스턴스 대신 QuerySet 또는 객체 목록을 serialize하려면 many=True를 작성해야함(ex. serializer = ArticleListSerializer(articles,many=True) )

[Build RESTful API - Article]

GET - LIST

• 게시글 데이터 목록 조회하기
• DRF에서 api_view 데코레이터 작성은 필수

파일 경로 ==> articles/views.py

GET - DETAIL

• 단일 게시글 데이터 조회하기
• 각 데이터의 상세정보를 제공하는 ArticleSerializer 정의

파일 경로 ==> articles/serializers.py

파일 경로 ==> articles/urls.py

파일 경로 ==> articles/views.py

POST

• 게시글 데이터 생성하기
• 요청에 대한 데이터 생성이 성공했을 경우는 201 Created 상태 코드를 응답하고 실패 했을 경우는 400 Bad request를 응답

파일 경로 ==> articles/views.py

• POSTMAN 결과 예시

Raising an exception on invalid data

• 유효하지 않은 데이터에 대해 예외 발생시키기
• is_valid()는 유효성 검사 오류가 있는 경우 ValidationError 예외를 발생시키는 선택적 raise-exception 인자를 사용할 수 있음
• DRF에서 제공하는 기본 예외 처리기에 의해 자동으로 처리되며 기본적으로 HTTP 400 응답을 반환

파일 경로 ==> articles/views.py

DELETE

• 게시글 데이터 삭제하기
• 요청에 대한 데이터 삭제가 성공하였을 경우는 204 No Content 상태 코드 응답(명령을 수행했고 더 이상 제공할 정보가 없는 경우)

파일 경로 ==> articles/views.py

PUT

• 게시글 데이터 수정하기
• 요청에 대한 데이터 수정이 성공했을 경우는 200 OK 상태 코드 응답

파일 경로 ==> articles/views.py

[Profile]

• 자연스러운 follow 흐름을 위해 Profile page 먼저 생성

파일 경로 ➡️ accounts/urls.py

파일 경로 ➡️ accounts/views.py

파일 경로 ➡️ accounts/profile.html

파일 경로 ➡️ templates/base.html

파일 경로 ➡️ articles/index.html

[Follow]

[모델 관계 설정]

파일 경로 ➡️ accounts/models.py

$ python manage.py makemigrations

$ python manage.py migrate

[Follow 구현]

파일 경로 ➡️ accounts/urls.py

파일 경로 ➡️ accounts/views.py

파일 경로 ➡️ accounts/profile.html

• 다대다(M:N) 관계 설정 시 사용하는 모델 필드
• 하나의 필수 위치인자(M:N관계로 설정할 모델 클래스)가 필요
• 모델 필드의 Related Manager를 사용하여 관련 개체를 추가, 제거 또는 만들 수 있음
  • ex. add(), remove(), create(), clear() etc.

• django는 다대다 관계를 나타내는 중개 테이블을 만듦
• 테이블 이름은 ManyToManyField 이름과 이를 포함하는 모델의 테이블 이름을 조합하여 생성됨
• 'db_table' arguments를 사용하여 중개 테이블의 이름을 변경할 수도 있음

[ManyToManyField's Arguments]

*1. related_name *

• target model이 source model을 참조할 때 사용할 manager name
• ForeignKey의 related_name과 동일

2. through

• 중개 테이블을 직접 작성하는 경우, through 옵션을 사용하여 중개 테이블을 나타내는 django 모델을 지정
• 일반적으로 중개 테이블에 추가 데이터를 사용하는 다대다 관계와 연결하려는 경우에 사용됨

3. symmetrical

• default : True
• ManyToManyField가 동일한 모델(on self)를 가리키는 정의에서만 사용
• True인 경우
  • _set매니저를 추가하지 않음
  • source 모델의 인스턴스가 target 모델의 인스턴스를 참조하면 자동으로 target 모델 인스턴스도 source 모델 인스턴스를 자동으로 참조하도록 함(대칭)
• 대칭을 원하지 않는 경우 False로 설정

[Related Manager]

• 같은 이름의 메서드여도 각 관계(N:1, M:N)에 따라 다르게 사용 및 동작됨

  • N:1에서는 target 모델 객체만 사용 가능
  • M:N 관계에서는 관련된 객체에서 모두 사용 가능

• 메소드 종류

  • add(), remove(), create(), clear(), set() 등

add()

• "지정된 객체를 관련 객체 집합에 추가"
• 이미 존재하는 관계에 사용하면 관계가 복제되지 않음
• 모델 인스턴스, 필드 값(PK)을 인자로 허용

remove()

• "관련 객체 집합에서 지정된 모델 개체를 제거"
• 내부적으로 QuerySet.delete()를 사용하여 관계가 삭제됨
• 모델 인스턴스, 필드 값(PK)을 인자로 허용

LIKE(좋아요 기능)

• Article과 User의 M:N 관계 설정을 통한 좋아요 기능 구현하기

[모델 관계 설정]

파일 경로 ➡️ artiles/models.py

• ManyToManyField 작성

모델 변경 후 migration 작업 진행

$ python manage.py makemigrations

➡️ like_user 필드 생성 시 자동으로 역참조에는 .article_set 매니저가 생성됨

• 그러나 이전 N:1(Article-User)관계에서 이미 해당 매니저를 사용 중
• user.article_set.all() : 해당 유저가 작성한 모든 게시글 조회
• user가 작성한 글들(user.article_set)과 user가 좋아요를 누른 글(user.article_set)을 구분할 수 없게 됨

• user와 관계된 ForeignKey 혹은 ManyToManyField 중 하나에 related_name 을 작성해야함

파일 경로 ➡️ artiles/models.py

$ python manage.py makemigrations

$ python manage.py migrate

• ManyToManyField에 related_name 을 작성후 migration

LIKE 구현

파일 경로 ➡️ articles/urls.py

파일 경로 ➡️ articles/views.py

파일 경로 ➡️ articles/index.html

• line 16-25 추가 : 좋아요 버튼 출력

Referencing the User model

1. setting.AUTH_USER_MODEL

• 반환 값 : 'accounts.User'(문자열)
• User 모델에 대한 외래 키 또는 M:N관계를 정의할 때 사용
• *models.py의 모델 필드에서 User 모델을 참조할 때 사용 *

2. get_user_model()

• 반환 값 : User Object (객체)
• 현재 활성화된 User모델을 반환
• 커스터마이징한 User모델이 있을 경우는 CustomUser모델, 그렇지 않으면 User를 반환
• *models.py가 아닌 다른 모든 곳에서 유저모델을 참조할 때 사용 *

Article - User CRUD

[모델 관계 설정]

월요일 교재 82p 사진 첨부

파일 경로 ==> articles/models.py

$ python manage.py makemigrations

기존에 존재하던 테이블에 새로운 컬럼이 추가되어야하는 상황이기때문에 migration 파일이 곧바로 만들어지지않고 일련의 과정이 필요

월요일 교재 85,86p 사진 첨부

$ python manage.py migrate

CREATE

• 인증된 회원의 게시글 작성 구현하기
• 작성하기 전 로그인을 먼저 한 상태로 진행

파일 경로 ==> articles/forms.py

• ArticleForm 출력시 불필요한 user필드도 함께 출력됨
• line6 : exclude = ('user',) 로도 대체 가능

파일 경로 ==> articles/views.py

• 이전 상태의 create함수를 이용해 게시글을 작성하면 외래 키에 저장되어야할 작성자 정보가 누락되기 때문에 create 함수 수정 필요

READ

• index.html & detail.html에서 각 게시글의 작성자 출력

파일 경로 ==> articles/index.html

파일 경로 ==> articles/detail.html

UPDATE

• 수정을 요청하는 사람과 게시글을 작성한 사람을 비교하여 본인의 게시글만 수정할 수 있도록 함

파일 경로 ==> articles/views.py

파일 경로 ==> articles/detail.html

• 해당 게시글의 작성자가 아니라면 수정/삭제 버튼 자체를 출력해주지 않음

DELETE

Comment - User CRUD

• Comment(N) - User(1)

[모델 관계 설정]

화요일 교재 6p 사진 첨부

파일 경로 ==> articles/models.py

• Comment 모델에 User모델을 참조하는 외래키 작성

$ python manage.py makemigrations

      -위의 Article_User와 같은 과정 필요

$ python manage.py migrate 

CREATE

• 인증된 회원의 댓글 작성 구현
• 작성하기 전 로그인 미리 한 상태에서 진행

파일 경로 ==> articles/forms.py

• CommentForm 출력 시 불필요한 피드 user가 출력됨
• exclude 사용해 제외

파일 경로 ==> articles/views.py

• 댓글 작성 시 외래 키에 저장되어야 할 작성자 정보가 누락 ==> 막아주기 위해 comments_create 함수 수정, comment.user에 현재 요청한 request.user를 넣어줌

READ

파일 경로 ==> articles/detail.html

• 댓글과 댓글 작성자가 함께 보이게 수정

DELETE

파일 경로 ==> articles/views.py

• 삭제 요청한 사람과 댓글 작성자가 같을때만 삭제가 가능하도록 함

• 추가로 해당 댓글의 작성자가 아니라면, 삭제 버튼 자체를 출력하지 않음

인증된 사용자에 대한 접근 제한

• is_authenticated와 View decorator 활용

파일 경로 ==> articles/views.py

• from django.views.decorators.http import require_POST : 최상단 import

파일 경로 ==> articles/detail.html

• 로그인되지않은 사용자에게는 CommentForm 자체를 보여주지 않음

• 외래 키(외부 키)

• 관계형 DB에서 다른 테이블의 행을 식별할 수 있는 키

• 참조되는 테이블의 기본 키를 가리킴(외래키의 값이 반드시 부모 테이블의 기본 키일 필요는 없지만 유일한 값이어야 함 - 참조 무결성)

  • 참조무결성? DB 관계모델에서 관련된 2개의 테이블 간의 일관성을 말함
  • 외래키가 선언된 테이블의 외래키 속성의 값은 그 테이블의 부모가 되는 테이블의 기본 키 값으로 존재해야 함

• 참조하는 테이블의 행 1개의 값은, 참조되는 측 테이블의 행 값에 대응됨

  • 이 때문에 참조하는 테이블의 행에는, 참조되는 테이블에 나타나지 않는 값을 포함할 수 없음

• 참조하는 테이블 행 여러 개가 참조되는 테이블의 동일한 행을 참조할 수 있음

N:1 (Comment(N) : Article(1))

• Comment 모델과 Article 모델 간 관계 설정
• n개 이상의 댓글은 1개의 게시글에 작성될 수 있음

월요일 교재 22p 사진 삽입

• Django Relationship fields

1. OneToOneField() : A one to one relationship
2. ForeignKey() : A many to one relationship

• N:1을 담당하는 django의 모델 피드 클래스

• 외래키 속성을 담당

• 2개의 필수 위치 인자 필요

  • 참조하는 model class
  • on delete 옵션

3. ManyToManyField() : A many to many relationship

Comment 모델 정의

파일 경로 ==> articles/models.py

• 외래 키 필드는 ForeignKey 클래스를 작성하는 위치와 관계없이 필드의 마지막에 작성됨
• ForeignKey() 클래스의 인스턴스 이름은 참조하는 모델 클래스 이름의 단수형(소문자)로 작성하는 것을 권장
  • ForeignKey 인스턴스를 생성하면 인스턴스이름_id로 컬럼이 생성된다.(명시적인 모델관계 파악을 위해)
• on_delete : 외래키가 참조하는 객체가 사라졌을 때, 외래키를 가진 객체를 어떻게 처리할 지를 정의(ex.CASCADE : 부모객체가 삭제됐을 때, 이를 참조하는 객체도 삭제)

$ python manage.py makemigrations

$ python manage.py migrate

• 모델에 대한 수정사항이 발생했기 때문에 migration 과정 진행

admin site 등록 파일 경로 ==> articles/admin.py

[관계 모델 참조]

• Related manager

  • Related manager는 N:1 혹은 M:N 관계에서 사용가능한 문맥
  • django는 모델 간 N:1 혹은 M:N 관계가 설정되면 역참조할 때에 사용할 수 있는 manager를 생성

[역참조]

• 나를 참조하는 테이블(나를 외래키로 지정한)을 참조하는 것
• 즉, 본인을 외래키로 참조 중인 테이블에 접근하는 것
• N:1 관계에서는 1이 N을 참조하는 상황(외래키를 가지지 않은 Article이 외래키를 가진 Comment를 참조)

article.comment_set.method()

• Article 모델이 Comment모델을 참조(역참조)할 때 사용하는 매니저
• django가 역참조 할 수 있는 comment_set 매니저를 자동 생성해 article.comment_set 형태로 댓글 객체를 참조할 수 있음
• N:1 관계에서 생성되는 Related Manager의 이름은 참조하는 "모델명_set" 이름 규칙으로 만들어짐
• 반면 참조 상황(Comment ==> Article)에서는 실제 ForeignKey클래스로 작성한 인스턴스가 Comment 클래스의 클래스 변수이기 때문에 comment.article 형태로 작성 가능

Comment CRUD

CREATE

파일 경로 ==> articles/forms.py

• 사용자로부터 댓글 데이터를 입력 받기 위한 CommentForm 작성
• exclude이용하여 article 제외한 나머지를 보여줌

파일 경로 ==> articles/views.py

• 최상단 CommentForm import 할 것

파일 경로 ==> articles/urls.py

• 댓글의 외래 키 데이터에 필요한 정보가 게시글의 pk값이기 때문에 url을 통해 변수를 넘기는 variable routing을 사용

파일 경로 ==> articles/views.py

• save(commit=False)

  • 아직 데이터베이스에 저장되지 않은 인스턴스를 반환
  • 저장하기 전에 객체에 대한 사용자 지정 처리를 수행할 때 유용하게 사용

파일 경로 ==> articles/detail.html

• line 28 - 32 : commentForm 추가

READ

파일 경로 ==> articles/views.py

파일 경로 ==> articles/detail.html

• line 28 - 34 추가

UPDATE

• 댓글 수정도 게시글 수정과 마찬가지로 구현이 가능하지만 댓글 수정 페이지가 따로 필요하게 됨
• 하지만 일반적으로 댓글 수정은 수정 페이지로 이동 없이 현재 페이지를 유지한 상태로 댓글 작성 Form 부분만 변경되어 수정할 수 있도록 함
• 이처럼 페이지의 일부 내용만 업데이트하는 것은 JS의 영역(현재 진행X)

DELETE

파일 경로 ==> articles/urls.py

파일 경로 ==> articles/views.py

• 최상단 Comment import

파일 경로 ==> articles/detail.html

• line 33 - 35 추가

Comment 추가사항

1. 댓글 개수 출력하기

1-1. DTL filter - length 사용

{{ comments|length }}

{{ article.comment_set.all|length }}

1-2. Queryset API - count() 사용

{{ comment.count }}

{{ article.comment_set.count }}

파일 경로 ==> articles/detail.html

• line 29 - 31 추가

2. 댓글 없는 경우 대체 컨텐츠

• for empty 문 사용
• line 41-42 추가

1. DDL(Data Definition Language)

• 데이터 정의 언어 : 관계형 데이터베이스를 구조(테이블, 스키마)를 정의(생성, 수정 및 삭제)하기 위한 명령어
• ex) CREATE, DROP, ALTER

2. DML(Data Manipulation Language)

• 데이터 조작 언어 : 데이터를 조작(추가, 조회, 변경, 삭제) 하기 위한 명령어
• ex) INSERT, SELECT, UPDATE, DELETE

3. DCL(Data Control Language)

• 데이터 제어 언어 : 데이터의 보안, 수행제어, 사용자 권한 부여 등을 정의하기 위한 명령어
• ex) GRANT, REVOKE, COMMIT, ROLLBACK

[DDL INDEX]

[CREATE TABLE]

데이터 타입 종류

1. NULL

• NULL value
• 정보가 없거나 알 수 없음을 의미

2. INTEGER

• 정수
• 크기에따라 0,1,2,3,4,6 또는 8바이트 같은 가변 크기를 가짐

3. REAL

• 실수
• 8바이트 부동 소수점을 사용하는 10진수 값이 있는 실수

4. TEXT

• 문자 데이터

5.BLOB(Binary Large Object)

• 입력된 그대로 저장된 데이터 덩어리(대용타입 없음)
• 바이너리 등 멀티미디어 파일
• ex) 이미지 데이터

6. Boolean type

• SQLite에는 별도의 Boolean 타입이 없음
• 대신 정수 0(False)와 1(True)로 저장됨

타입 선호도(Type Affinity)

• 특정 컬럼에 저장된 데이터에 권장되는 타입
• 데이터 타입 작성 시 SQLite의 5가지 데이터 타입이 아닌 다른 데이터 타입을 선언한다면, 내부적으로 각 타입의 지정된 선호도에 따라 5가지 선호도로 인식됨

1. INTEGER
2. TEXT
3. BLOB
4. REAL
5. NUMERIC

• 다른 데이터베이스 엔진 간의 호환성을 최대화
• 정적이고 엄격한 타입을 사용하는 DB의 SQL문을 SQLite에서도 작동하도록 하기 위함

제약조건(Constraints)

• 입력하는 자료에 대해 제약을 정함
• 제약에 맞지 않다면 입력이 거부됨
• 사용자가 원하는 조건의 데이터만 유지하기 위한 즉, 데이터의 무결성을 유지하기 위한 보편적인 방법으로 테이블의 특정 컬럼에 설정하는 제약
  • _데이터 무결성이란? DB내의 데이터에 대한 정확성, 일관성을 보장하기 위해 데이터 변경 혹은 수정 시 여러 제한을 두어 데이터의 정확성을 보증하는 것 _

Constraints 종류

1. NOT NULL

• 컬럼이 NULL 값을 허용하지 않도록 지정
• 기본적으로 테이블의 모든 컬럼은 NOT NULL을 명시하지 않는 경우 NULL 값을 허용

2. UNIQUE

• 컬럼의 모든 값이 서로 구별되거나 고유한 값이 되도록 함

3. PRIMARY KEY

• 테이블에서 행의 고유성을 식별하는 데 사용되는 컬럼
• 각 테이블에는 하나의 기본 키만 있음
• 암시적으로 NOT NULL 제약조건이 포함되어있음

4. AUTOINCREMENT

• 사용되지 않은 값이나 이전에 삭제된 행의 값을 재사용하는 것을 방지
• INTEGER PRIMARY KEY 다음에 작성하면 해당 rowid를 다시 재사용하지 못하도록 함

rowid의 특징

• 테이블을 생성할 때마다 rowid라는 암시적 자동 증가 컬럼이 자동으로 생성됨

• 테이블의 행을 고유하게 식별하는 64비트 부호있는 정수 값

• 테이블 새 행을 삽입할 때마다 정수 값을 자동으로 할당

  • 값은 1에서 시작
  • 데이터 삽입 시에 rowid 또는 INTEGER PRIMARY KEY 컬럼에 명시적으로 값이 지정되지 않은 경우, SQLite는 테이블에서 가장 큰 rowid보다 하나 큰 다음 순차 정수를 자동으로 할당(AUTOINCREMENT와 관계없이)

• 만약 INTEGER PRIMARY KEY 키워드를 가진 컬럼을 직접 만들면 이 컬럼은 rowid 컬럼의 별칭(alias)이 됨

[ALTER TABLE]

• 기존 테이블의 구조를 수정

1. RENAME a table
2. RENAME a column
3. ADD a new column to a table
4. DELETE a column

RENAME a table

RENAME a column

ADD a new column to a table

• 만약 테이블에 기존 데이터가 있을 경우 다음과 같은 에러가 발생함

  Cannot add NOT NULL column with default value NULL

• 이미 이전에 저장된 데이터들은 새롬게 추가되는 컬럼에 값이 없기 때문에 NULL이 작성됨 ➡️ 그런데 새로 추가되는 컬럼에 NOT NULL 제약조건이 있기 때문에 기본 값 없이는 추가될 수 없다는 에러
• 위의 경우 다음과 같이 DEFAULT 제약 조건을 사용하여 해결 할 수 있음
• 이러면 address 컬럼이 추가되면서 기존에 있던 데이터들의 address 컬럼 값은 'no address'가 된다.

DELETE a column

아래와 같은 경우 삭제하지 못함

• 컬럼이 다른 부분에서 참조되는 경우(FK 제약조건에서 사용되는 경우)
• PK인 경우
• UNIQUE 제약조건이 있는 경우

[DROP TABLE]

• 한 번에 하나의 테이블만 삭제 사능
• DROP TABLE문은 실행 취소하거나 복구할 수 없음

[DML]

*csv 파일 데이터를 테이블로 넣는 작업 *

1. csv 파일 속 데이터 형식과 맞게 테이블 생성
2. 데이터베이스 파일 열기

   $ sqlite3 mydb.sqlite3  # mydb부분에 원하는 파일 이름

3. 모드를 csv로 설정

   $ .mode csv

4. .import 명령어 사용하여 csv데이터를 테이블로 가져오기

   $ .import users.csv users

• .import (csv파일 명) (테이블 명)

[Simple query]

• SELECT문을 사용해 단일 테이블 데이터 조회
• 다양한 절과 함께 사용할 수 있다.(ORDER BY, DISTINCT, WHERE, LIMIT, LIKE, GROUP BY)

사용 예시

1. 이름과 나이 조회
2. 전체 데이터 조회

[Sorting rows]

• ORDER BY 절을 사용하여 쿼리의 결과를 정렬하기

사용 예시

1. 이름과 나이를 나이가 어린 순서대로 조회

• ORDER BY의 default가 오름차순이라 아무것도 쓰지 않아도 괜찮다. (뒤에 ASC를 붙여도 무방함)

2. 이름과 나이를 나이 많은 순서대로 조회(내림차순)
3. 이름,나이,계좌 잔고를 나이가 어린 순으로, 만약 같은 나이라면 계좌 잔고가 많은 순으로 정렬해서 조회

• 먼저 나오는 순서대로 정렬 우선순위를 가짐

NULL의 정렬 방식

• 정렬과 관련하여 SQLite는 NULL을 다른 값보다 작은 것으로 간주
• 즉, ASC를 사용하는 경우 결과의 시작 부분에 NULL이 표시되고, DESC를 사용하는 경우 결과의 끝에 NULL이 표시됨

[Filtering data]

• Clause
  • SELECT DISTINCT
  • WHERE
  • LIMIT
• Operator
  • LIKE
  • IN
  • BETWEEN

SELECT DISTINCT

• 조회결과에서 중복된 행을 제거
• DISTINCT 절은 SELECT 에서 선택적으로 사용할 수 있는 절
• DISTINCT절은 SELECT 키워드 바로 뒤에 나타나야 함 & DISTINCT 키워드 뒤에 컬럼 또는 컬럼 목록을 작성

사용 예시

1. 중복 없이 모든 지역 조회
2. 이름과 지역 중복 없이 지역순으로 오름차순 정렬하여 모든 이름과 지역 조회하기

WHERE

• 조회 시 특정 검색 조건을 지정
• WHERE 절은 SELECT, UPDATE, DELETE 문에서 선택적으로 사용 할 수 있는 절
• FROM 절 뒤에 작성

사용 예시

1. 나이가 30살 이상인 사람들의 이름, 나이, 계좌 잔고 조회
2. 나이가 30살 이상이고 계좌 잔고가 50만원 초과인 사람들의 이름,나이,계좌 잔고 조회

LIKE

• 패턴일치를 기반으로 데이터를 조회
• WHERE 절에서 사용
• 기본적으로 대소문자는 구분하지 않음
• SQLite는 패턴 구성을 위한 두개의 와일드카드를 제공

1. % (percent)

• 0개 이상의 문자가 올 수 있음을 의미

2. _ (underscore)

• 단일(1개) 문자가 있음을 의미

사용 예시

1. 이름에 '호'가 포함되는 사람들의 이름과 성 조회
2. 서울 지역 번호를 가진 사람들의 이름과 전화번호 조회
3. 나이가 20대인 사람들의 이름과 나이 조회하기
4. 전화번호 중간 4자리가 51로 시작하는 사람들의 이름과 전화번호 조회

[IN operator]

• 값이 값 목록 결과에 있는 값과 일치하는지 확인
• 표현식이 값 목록의 값과 일치하는지 여부에 따라 T/F를 반환
• IN 연산자의 결과를 부정하려면 NOT IN 연산자를 사용

사용 예시

1. 경기도 혹은 강원도에 사는 사람들의 이름과 지역 조회하기
2. 경기도 혹은 강원도에 살지 않는 사람들의 이름과 지역 조회하기

[BETWEEN operator]

• 값이 값 범위에 있는지 테스트
• 값이 지정된 범위에 있으면 True
• WHERE 절ㅇ레서 사용
• BETWEEN 연산자의 결과 부정 ➡️ NOT BETWEEN 사용

사용 예시

1. 나이가 20살 이상, 30살 이하인 사람들의 이름과 나이 조회
2. 나이가 20살 이상, 30살 이하가 아닌 사람들의 이름과 나이 조회하기

[LIMIT clause]

• 쿼리에서 반환되는 행 수를 제한
• SELECT문에서 선택적으로 사용할 수 있는 절
• row_count는 반환되는 행 수를 지정하는 양의 정수를 의미

사용 예시

1. 첫 번쨰부터 열 번째 데이터까지 rowid와 이름 조회하기
2. 계좌잔고가 가장 많은 10명의 이름과 계좌잔고 조회

[OFFSET keyword]

• LIMIT 절을 사용하면 첫번쨰 데이터부터 지정한 수 만큼의 데이터를 받아올 수 있지만, OFFSET과 함께 사용하면 특정 지정된 위치에서부터 데이터를 조회할 수 있음

사용 예시

1. 11번째부터 20번쨰 데이터의 rowid와 이름 조회

account app 생성

$ python manage.py startapp accounts

파일 경로 ➡️ settings.py

파일 경로 ➡️ crud/urls.py

파일 경로 ➡️ accounts/urls.py(new file)

파일 경로 ➡️ setting.py

User 모델 생성

파일 경로 ➡️ accounts/models

파일 경로 ➡️ settings.py

파일 경로 ➡️ accounts/admin.py

!중요!

• User model을 대체하여 Custom User 클래스를 프로젝트 중간에 바꾸는 것은 번거로운 작업이 수반될 수 있기때문에 항상 프로젝트 시작 시 모두 선언하고 migration을 해주는 것이 좋다.
• 피치 못한 사정으로 프로젝트 진행 도중 하게될 경우, 이전 앱의 migration 속 'init.py'를 제외한 '0001~'형식으로 생긴 파일들을 전부 지워주고, db.sqlite3 까지 모두 지운 후 다시 makemigrations, migrate를 진행 할 것

[Log-in]

파일 경로 ➡️ accounts/urls

파일 경로 ➡️ accounts/views

파일 경로 ➡️ accounts/login.html

[Log-out]

파일 경로 ➡️ accounts/urls.py

파일 경로 ➡️ accounts/views.py

파일 경로 ➡️ base.html

[회원 가입]

파일 경로 ➡️ base.html

• 회원가입 버튼 base.html에 생성

파일 경로 ➡️ accounts/forms.py(new file)

• Custom User model 사용을 위해 확장 파일 경로 ➡️ accounts/urls.py

파일 경로 ➡️ accounts/views.py

파일 경로 ➡️ accounts/signup.html

[회원 탈퇴]

파일 경로 ➡️ accounts/base.html

파일 경로 ➡️ accounts/urls.py

파일 경로 ➡️ accounts/views.py

[회원 정보 수정]

파일 경로 ➡️ base.html

• 회원정보수정 버튼 생성

파일 경로 ➡️ accounts/forms.py

파일 경로 ➡️ accounts/urls.py

파일 경로 ➡️ accounts/views.py

파일 경로 ➡️ accounts/updates.html

[login&logout status]

• login 된 상태 : 로그아웃,회원정보수정,회원탈퇴 show
• logout 된 상태 : 로그인, 회원가입 show