node_modules의 최신 버전을 무시하고 옛날 버전을 강제로 다운받을때
front개발도 react 개발하기 위해 node_modules 필요
npm start 시 react가 동작
서버에 요청이 아닌 다시 페이지 자체에서 rendering
서버에서 json형태로 응답하면 XHR 객체로 서버에 요청
jsx로도 확장명 가능, react file을 구분짓는 확장명
return을 포함하는 js를 jsx로 확장명 가능
html처럼 보이지만 html이 아님
js해석기가 createElement로 html을 그리기 때문에 속도가 느림, 개발 편의성만 좋음(js해석기는 html해석기 뒤에 작동)
개발 편의성을 추구하는것은 성능이 점점 낮아지고 size가 점점 커짐
const(상수)는 배열 자체를 의미, 배열 안의 객체를 의미하는 것이 아님
react에서 자동으로 제공되는 기능
이름 규칙
앞의 배열의 요소의 이름이 a라면 뒤의 요소는 setA가 되어야함
한 영역에는 하나의 element만 가능, div 안에 nav와 modal을 집어넣어 해결
onchange라는 이벤트 리스너에 핸들러 설정
react 문법은 f() 대신 함수 이름을 중괄호 안에 넣음
같은 코드
주석 처리 시 cors 오류, 하지만 prefilght는 성공
web2 시절부터
백서버에서 js 출처를 구별하는것이아니라 클라이언트측에서 내가 보낸 요청 작업을 뿌려주기 직전에 나의 주소와 xhr로 넘어간 url이 같은지를 browser에서 비교 비교한 후 다르면 뿌리지 않음 처음부터 front 정보들을 8080서버, 백엔드 서버에서 static 정보들을 가지고 있어야함
백엔드 주소와 front 주소가 다르기 때문에 SOP 정책 위배되어 화면이 보이지 않음, 이를 풀기 위해 CORS 사용
app.use(express.json())
const cors = require('cors')
app.use(cors())요청 헤더에 cors 허용했다고 전송되어 화면이 잘 보여짐
웹브라우저가 자동으로 두번의 요청을 보내는것
XHR(post + json) => 사전요청
사전요청은 OPTIONS로 감
요청 헤더의 Access-Control-Allow-Origin의 아스타(*)를 보고
본요청을 보내도 되겠구나 하고 인식
아무것도 옵션을 주지 않으면 모든 url에서의 요청을 받을거라는 뜻
본요청은 POST
Access-Control-Allow-Origin의 아스타(*)를 보고 alert("ok")가 뜸
preflight : 불필요한 네트워크 엑세스 막음
preflight
1) HTTP 메서드가 GET, POST, HEAD 이외의 메서드인 경우
2) Content-Type이
- application/x-www-form-urlencoded,
- multipart/form-data,
- text/plain
이외의 값인 경우
3) 커스텀 헤더를 포함하는 경우
우리는 2번에 해당하므로 preflight가 진행
컨텐트 타입을 주석 시 preflight 진행하지 않음
cors는 가져온 데이터를 뿌릴지 말지를 결정하는거지
session을 사용하는 이유 > db를 계속 access 하지 않아 성능이 좋음
front 서버와 back 서버가 나누어졌을때 session을 사용하지 못함
session은 back 서버에 저장되어있어 front 서버에서 사용하지 못함
session은 쿠키의 일종, 쿠키는 자신이 속한 포트에서만 사용 가능(다른 포트는 다른 프로세스로 인식)
JWT는 무결성 체크, 기밀성 x JWT가 세션보다 무조건 좋은것은 아님
session, jwt 모두 탈취 가능
jwt는 데이터가 그대로 노출
session은 번호가 노출
