오늘의 스크럼
- UI 작성 내용 확인
(영화 API를 가져오는 메인페이지는 해당 부분 비어둔 상태)
(상세페이지 아직 손 보지 않음) - 영화 API 받아오는 방법
- 프론트 공통 CSS 필요성 : reset.css & root color
- local DB 연결 후 테스트 해보자
오늘 한 것
- header의 box office 부분 UI 수정
- signup의 따로 작성된 라우터(POST)를 기존 라우터에 추가
- mysql로 작성한 signup post를 sequelize문으로 변경
(sequelize 객체 생성, config 파일 작성, user table 생성) - axios 요청하여 signup DB test (DONE)
- 노션 스크럼 & 트러블슈팅 정리
하면서 배운 것
reset.css의 필요성
header.ejs에서 볼 때랑 이 헤더를 갖다 붙인 파일을 열었을 때 미묘하게 위치가 달랐다. 그래서 reset.css를 설정한 후에 프론트를 시작해야 했다고 생각했다. (지난 포스팅) 어느 정도 진전이 있던 터라 이야기를 망설이다 꺼냈는데 각자 CSS 설정이 조금씩 달라지는 건 다들 느꼈는데 모두의 동의로 reset.css를 추가하기로 했다.
reset.css는 태그에 기본적으로 있는 속성들(ex. body의 margin, a 태그의 text-decoration, li의 line-style 등)을 모두 없애고 완전한 백지에서 스타일링을 시작하는 것.
🌱 장점
-
요소마다 스타일을 어떤 식으로 줬는지 역추적하기 쉽다.
-
우리 팀은 프론트를 시작하기 전에 별다른 기준을 정하지 않았다. 그래서 페이지마다 따로 작성하다가 유저가 사용하듯 하나의 흐름으로 보면 유난히 width가 작은 페이지와 큰 페이지가 있다. 이에 대한 기준 잡기도 쉬울 거라는 생각이 든다.
뷰포트가 달라져도 가로 스크롤 생기지 않게 하려면?
-
처음 생각한 건
flex-wrap: nowrap -
하지만 이보다 더 간단하게 body에
overflow-x: hidden를 줘도 된다. 분명 아는 속성인데 body의 width를 넘어서는 특정 요소에 해당 속성을 주는 바람에 잘 적용되지 않았다.
백 로그인 axios 요청
sequelize를 사용해서 만들었다. 컨트롤러에 불러올 모델은 테이블 생성하는 객체 모델이 아니라, 그 테이블들을 한데 모아 db로 묶어준 index 였단 것..
잡담
반응형....
맥에서는 왜 늘 엉망으로 보일까..... 반응형을 반드시 해내라는 의미인가...
데스크탑에서도 같은 크롬 같은 해상도인데 나랑 옆 분 화면이 너무 다르게 보여서 두 화면 모두에게 잘 보이는 쪽으로 바꿨는데, 맥은 아예 화면이 작아버리니까 이런가보다. 반응형을 꼭 넣어야겠다..
프론트랑 백을 같이 해서 그런가. 기본 뼈대만 잡아두고 이후 백과 데이터를 주고받으며 필요한 내용을 채워가면서 UI도 세세히 수정하는 게 좋은 것 같다. 아마 프론트/백 나눠서 했다면 얘기가 달랐겠지.
예상 일정
~일요일까지 백 기능 구현
월~수 프론트 위주(+ 반응형)로 정리.
우선 내일
영화 API 해결하기가 목표!
- 어제 거 배포 업뎃
- 워크벤치에 테이블 생성 (서버와 동일하게)
- 일별 박스오피스 API 받아와서 보여주기
- 이거 자동 슬라이드 구현 - 이건 내일로 미룰 수도
- 집 가기 전에 배포
+) TMDB에서 영화 API 받아와서 일부 보여주기
