MIL : 프로그래머스 데브코스 한달 회고

jh·2023년 10월 24일
0

원래 tistory를 사용하면서, 배운 것들은 무조건 다 기록하자! 라는 마인드로 접근했었는데 솔직히 크게 남는 건 없었던 것 같다..
여러 멘토님들의 블로그 관련 조언을 들으면서, 나름대로의 관점을 잡았는데
만약 리액트의 useMemo라는 것을 배웠다고 하면

  • 이 기능을 왜 쓰는지?(기존에 내가 알고 있던 비슷한 기능과 비교해서 장단점이 있는지)
  • 어떤 상황에서 사용했고, 어떤 부분에서 막혔는지
  • 이 기능에 대한 내 의견
    단순히 배운 내용을 기입하기 보다는, 그 과정에서 내가 느꼈던 점을 기록해보려고 한다.

vanilaJS로 기능 구현하기

예전부터 프레임워크 사용없이도 기능 구현을 할 줄 알아야한다 ~ 라는 말은 수없이 들었지만, 그럼 어떤 식으로 시작해야 될지가 막막했다.
그냥 아무 기준없이 화면만 돌아가게 하는 거 아니라, 뭔가 어떤 레퍼런스?를 가지고 만들어 보고 싶었는데 생각보다 관련 자료가 많이 없어서 라는 핑계로 미뤄왔던 걸 진행해보았다.
만들어 보면서 가장 크게 느낀 점은

리액트는 vanilaJS를 보다 편리하게 사용하기 위한 프레임워크 라는 점이었다.

내가 생각하는 리액트의 핵심은

  • 화면을 컴포넌트 단위로 쪼개서 관리
  • 데이터(상태)가 바뀌면 화면은 자동으로 렌더링된다
  • 렌더링 과정에서 가상 돔을 활용해 바뀐 부분만 알아서 바꿔준다
  • 그래서 데이터에 따라 화면을 어떻게 그려줄 것이고, 이 상태를 어떻게 관리해야 하는지를 신경써야 한다

그렇다면 사람들이 왜 리액트를 사용할까 ?

  • 저런 방식으로 개발하는 것이 무언가 이점이 있기 때문이라는 생각이 들었다.
  • 그렇다면 vanilaJS로는 불가능 한가 ? (X)
    물론 최적화 관련 알고리즘들을 전부 구현하기는 어렵겠지만(굳이 그래야 할 필요도 없
    고..) 저런 핵심 기능들이 리액트를 사용해야만 가능하다는 것은 아니라는 뜻이다.

물론 아직 상태관리나, 렌더링을 deep하게 신경쓸 필요가 없기 때문에

1. 데이터(상태)에 따라서 화면이 구성된다
2. 데이터가 바뀌어야 할때 무조건 화면을 다시 바꿔줘야 한다
3. 굳이 바뀌지 않아도 되는 곳은 안 바꿀 수 있도록 노력한다 

일단 1,2번은 무조건 추가했고, 3번은 가능하다면 구현해보려고 노력중이다.

이렇게 했을 때의 장점이라면, 생각이 단순해진다

function Component = () => {
this.state = [1,2,3,4,5]

this.render = () => {
$div.innerHTML = `
this.state.map(data => <div>{data}</div>
`).join('')
}

this.render()

this.setState = (nextState) => {
	this.state = nextState
    this.render()
}
}
  • 생성자 함수 or class 한개가 하나의 컴포넌트 역할을 한다
  • render()는 인자를 받지 않고 무조건 state 값에 따라 화면을 그려줌
  • setState() 를 사용해서만 데이터를 변경해 줘야 함
  • 변경 후에 render()를 통해 화면도 자동으로 바꿔줌

개인적으로는 class를 사용하는 것이 컴포넌트들이 하는 일을 더 명확하게 볼 수 있다고 생각하는데, JS에서 사용하는 class가 다른 객체지향 언어의 class와는 다른 점이 존재한다고 한다(일종의 Syntax Sugar같은 느낌)
class 관련 문서

기술만큼 중요한 기능 구현

아직까지는 엄청나게 어려운 로직을 다루지 않고 있기 때문에, 공부하는 차원에서 새로운 기능들을 추가해보려 노력했다.
예를 들어, 컴포넌트 2개 있는 프로젝트에서 state 중앙 관리를 도입한다던지, ES2022 기능들을 추가하는 등 다양한 기능들을 도입해보려고 노력했다.
하지만, 가장 중요한 건 어쨌든 '누군가가 요청한 기능을 구현해야 한다는 것'이다.
컴포넌트 종속성, 재사용성 , 최적화 등도 물론 중요하고 특히 협업 과정에서 굉장히 중요하지만
일단 기능 구현이 최우선 목표가 되어야 한다는 점을 조금은 간과하고 있었던 것 같다..

기술만큼 중요한 설명

코드 리뷰를 하면서, 멘토님이 하신 말씀 중에

'Readme와 설명만 보고서도 해당 프로젝트에 바로 투입되어 일 할 수 있어야 한다' 라는 말이 기억에 남는다.

gif로 페이지 동작을 보여주거나, 파일 구조를 시각화해서 보기 편하게 만들었다거나, 해당 기능의 도입 이유, 막힌 점 등을 기록하는 등 여러가지 내용을 Readme나 다른 설명을 통해 적어주신 분들을 보고 조금 반성했다..
다음부터는 하루를 날을 잡고 저런 설명에 투자하는 시간을 가져야 겠다고 생각했다

0개의 댓글