[TIL] 자바스크립트 웹 개발 기본기 (상)과 Week2 리팩토링

오늘의 나는 무엇을 잘했을까?

1. Week2 리팩토링 완료! 여러가지 어려움이 있었지만 자잘하게 요구사항에서 벗어나는 것을 파악해 결국 리팩토링을 다 했다.

• article을 flex wrap와 align-content:center 로 정렬하는 것에서 grid로 변경했다.
• break 용도(글 줄바꿈)의 span을 br로 변경 display : none을 사용해 모드에 따라 적용했다.
• 62.5% Trick을 반영하여 px→ rem으로 변경하였다.
• media query의 width 범위 지정을 max로 통일하였다.
• 의미있는 class 명으로의 변경과 불필요한 id 지정을 변경하였다.(with ChatGPT)
• header를 absolute후 margin-top이 아닌 sticky로 변경했다.

오늘의 나는 무엇을 배웠을까?

[1] 자바스크립트 웹 개발 기본기 (상)

웹기초 다지기

✋ 잠깐!
개발자 도구의 Console 탭은 해당 코드에서 최종적으로 리턴하는 값을 출력한다. 만약 아무런 값도 리턴하지 않는 경우에는 undefined를 리턴한 것으로 간주한다.

웹 - World Wide Web의 줄임말로 가상의 연결망 세계이다.

URL

Uniform Resource Locator, 웹에 존재하는 특정 데이터를 나타내는 문자열

• ex) https://www.example.com/men/shirts?color=blue$size=m
  • Scheme - 프로토콜의 이름
    • 프로토콜 : 통신을 하는 주체가 지켜야하는 규약
  • Host : 전세계의 서버 중 하나의 서버를 특정. 도메인네임으로 되어있다.(원래는 숫자로 된 IP주소)
  • Path : 서버에 있는 데이터 중 원하는 데이터를 특정
  • Query : 데이터에 관한 세부적인 요구사항 (옵션임)

Domain Name Resolution

• 하나의 도메인 네임은 여러개의 도메인으로 구성된다.
• 더 상위의 도메인일수록 도메인 네임 중에서 오른쪽에 있다.
  • root domain은 빈 문자열로 나타내고, 보통은 표시하지 않는다.
    • 만약 나타내고 싶으면 도메인의 가장 오른쪽에 .을 찍으면 된다. ex) google.com. (이론적으로 더 완벽한 도메인 네임 😆ㅋㅋ)
  • root doamin 바로 하위에 Top-Level Domain(TLD) - kr, jp, net 등등
  • Second-Level Domain (SLD) - naver, codeit
  • Third-Level Domain(Third) - www

HTTPS - Hyper Text Transfer Protocol Secure

Request - 요청

[헤드][바디]로 이루어져있다.

헤드

• header : 헤드 안에 담긴 하나하나의 키와 값의 쌍

1. 메소드: equest에 header에 담겨져있다.

   GET - 데이터 조회

   POST - 데이터 추가. body에 데이터 담아서 보내야한다.

   PUT - 데이터 수정. body에 데이터를 담아서 보낸다.

   DELETE - 데이터 삭제

2. path 정보 - 웹브라우저가 무슨 데이터를 원하는 지 알 수 있다.

3. user-agent : request를 보낸 브라우저와 그것이 설치된 운영체제에 대한 정보가 담겨져있다.

REST API

REST architecture : 웹이 갖추어야 할 이상적인 아키텍처(구조)

• REST : Representational State Transfer, 표현적인, 상태 이전
• REST architecture는 아래의 6가지 기준을 충족하면 인정이 된다.
  1. Client-Server 구조로 양측의 관심사를 분리해야한다
  2. Stateless : client가 보낸 각 request에 대해 server는 그 어떤 context도 저장하지 않는다. 즉, 매 request는 독립적인 것으로 취급된다. 따라서 request에는 항상 필요한 모든 정보가 담겨야한다.
  3. Cache : Cache를 활용해서 네트워크 비용을 절감해야한다. Servers는 response에 Client가 reponse를 재활용해도되는지 여부(Cacheable)을 담아서 보내야한다.
  4. Uniform Interface - UI는 다음과 같은 하위 조건 4가지를 준수해야한다.
     • identification of resources
       • resource는 URI로 식별 가능해야한다.
     • manipulation of resources through representations
       • Client와 Server는 둘 다 리소스를 직접적으로 다루는 게 아니라 리소스의 '표현(representations)'을 다뤄야한다. 리소스'
         와 '리소스의 표현'이라는 개념 2개를 서로 엄격하게 구분
     • self-descriptive messages
       • 자기설명적인. 매 리퀘스트마다 필요한 모든 정보를 담아서 전송해야한다.
     • hypermedia as the engine of application state
  5. Layered System
     • Client와 Server 사이에는 프록시(proxy), 게이트웨이(gateway)와 같은 중간 매개 요소를 두고, 보안, 로드 밸런싱 등을 수행할 수 있어야한다. 이를 통해 Client와 Server 사이에 hierarchical layers가 형성된다.
  6. Code on Demand
     • Client는 받아서 바로 실행할 수 있는 applet이나 script 파일을 Server로부터 받을 수 있어야 한다.

🙋‍♀️ 4번에 대한 추가적인 내용

• URL은 리소스를 나타내기 위해서만 사용하고, 리소스에 대한 처리는 메소드로 표현해야 한다. 즉 URL에서 리소스에 대한 처리를 드러내면 안 된다
• 도큐먼트는 단수 명사로, 컬렉션은 복수 명사로 표시
  • document : 하나의 객체로 표현할 수 있는 리소스
  • collection : 여러 개의 document를 담을 수 있는 리소스

오늘의 나는 어떤 어려움이 있었을까?

Week2 article을 grid로 배치하면서 생긴 의문😂😂😂

현재 리펙토링을 하면서 사진과 같이 모바일 모드에서 제목(h2), 이미지, 설명(p) 순 배치를 위해 grid로 묶어주었다.

그런데 grid-template: repeat(2, auto) / repeat(2, auto); 부분을 개발자모드에서 해제하여도 사진처럼 배치가 되었다, 하위요소들을 grid-row : 1/3으로 위치 지정을 사용해서 가능한 건지? 의문이다..😂 추가적으로 👉grid-column을 명시하지 않아도 배치가 되었다.

궁금한 점

• grid-template: repeat(2, auto) / repeat(2, auto);의 repeat(2, auto) 의 auto 문법이 괜찮은 것인지..? '

  • 비율을 어떻게 할지 고민하다 계산을 하기 보다는 자동으로 배치되었으면 좋겠다는 생각에 적었는데 작동을 하는 듯 했다. 그런데 이렇게 작성한 다른 분들의 코드를 찾지 못했다..

• grid-template: repeat(2, auto) / repeat(2, auto); 이부분을 해제해도 잘 동작한다. 내 생각에는, 자식 요소들의 grid-row 때문이라고 생각하는데, 그렇다면 보통 grid comtainer에 template을 지정안하는 경우가 있는지..? 일반적이지 않은 것 같다.

• 하위요소들에 grid-row만 설정하고 👉grid-column은 설정하지 않아도 동작을 한다😱

  결론은 grid-template: repeat(2, auto) / repeat(2, auto);와 grid-column 없이 하위요소들에 grid-row만 설정해도 이 배치가 완성된다😱

  • 참고로 article 요소에 다른 grid나 flex 등 영향을 주는 건 없는 것으로 판단된다.

내일의 나는 무엇을 해야할까?

• Week3 Mission 레이아웃 구현
• 알고리즘 2문제