개발하는 리트리버

맥북 마이그레이션 이후에

일반 터미널에서는 문제가 없었는데,

visual studio code에서만 유독 위와 같은 문제가 발생했다.

compinit:480: compdump: function definition file not found

.zshrc:188: add-zsh-hook: function definition file not found

zsh brew로 재설치후

zshrc 파일에 compinit과 bashcompinit 부분을 추가해주고나니

해결완료!

export ZSH="$HOME/.oh-my-zsh"

ZSH_THEME="robbyrussell"

source $ZSH/oh-my-zsh.sh

autoload -Uz compinit
compinit

autoload -U bashcompinit
bashcompinit

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

CRUD 정의

CRUD 는 약자로 아래의 함수(기능)을 의미한다.

Create

Read

Update

Delete

너무나도 쉬운 영단어로 되어있다.

이러한 기원은 데이터베이스에 있다고 한다.

이는 SQL에서는

Create = INSERT

Read  = SELECT

Update = UPDATE

Delete = DELETE

로 생각하면 된다. 

어떤 item에 대해서 CRUD개발, 이라고 한다면

해당 아이템을 만들고, 수정하고 지우기까지 하는 작업들을 의미한다고 보면 된다.

REST 정의

REST는 네트워크 애플리케이션 설계를 위한 아키텍처 스타일이며

HTTP 프로토콜이 사용된다. 

우리가 익숙한 GET, POST, PUT, DELETE가 여기에 포함된다.

둘의 차이점?

그럼 REST와는 차이 점이 있을까?

범위

CRUD는 4개의 기능(함수)을 이야기한다.

REST는 네트워크 리소스를 설계하고 상호 작용하는 방법을 정의하는 더 넓은 아키텍처 스타일이다.

작용범위

CRUD는 데이터 베이스와 작동한다.

REST는 HTTP 메서드를 사용하여 CRUD와 유사한 작업을 수행하지만, 네트워크 리소스의 맥락 내에서 이루어진다.

설계

CRUD는 데이터 작업에 중점을 두는 반면REST는 HTTP를 통해 클라이언트가 서비스와 상호 작용하는 방식을 설계하는 데 중점을 둔다.

둘의 비교 글이 좀 있기는 한데,

역할이나 범위, 정의를 생각해보면

 비교 대상이 아닌것 같다는 생각도든다.

참고 : https://www.logicmonitor.com/blog/rest-vs-crud

m1에서 node-sass 사용시 나는 에러이다.

제 세팅에서는 node 버전 16까지는 문제 없었는데,

18 위로 업데이트 후 부터 발생했다..

정확한 원인은 맥북의 arm환경 빌드에 대한 릴리즈가 없기때문이라고 한다.

해결법은 많이들 나와있는데,

node-sass제거하고 sass를 사용하는것이다.

$ npm uninstall node-sass 
$ npm install sass

그러고나면 정상적으로~

근데 node-sass, sass는 뭐하는 친구들일까??

styles.module.sass 같은 형식의 파일을 본적이 있는가?!

css모듈 사용시 만드는 파일 형식이다.

node-sass는 이 파일을 css코드로 변환해주는 역할을 한다!

(이렇게 야무진 일을 하는 친구였다..하지만 이제 보내주자)

저번에 올렸던 페이지에서 한번 보아하니

 node-sass 만나서 즐거웠어~!

프로젝트별로의 설정을 해 둘 필요가 있다.

각자의 vscode 설정이 코드에 영향을 주어 

코드 일관성을 해칠 수 있기 때문이다.

vscode를 따로 설정하는 방법은 2가지 이다.

1. .vscode  직접 폴더 만들기

루트 폴더에 .vscode 폴더를 만들고

setting.json 파일을만들어준다.

그리고 { ... } 내부에 원하는 설정을 추가해두면 끝!

 2. 좀 더 쉽게 자동으로 .vscode 폴더 만들기

1번의 방법은 설정 하나하나를 찾아봐야하는 귀찮음이 좀 있다.

[command + shif + p]를 통해서

Open Settings (UI)에 접속한다.

그리고 User가 아닌 Workspace탭을 클릭해준다.

그러고 나면? 이제 하나하나 설정을 UI에서 변경해줄 때 마다 

루트 .vscode/setting/json 파일에 변경이 반영된다.,.!!

auto save 설정을 바꾸니 json파일에 자동으로 추가가 싸악~

이제 우리들의 프로젝트의 일관성 유지를 위해

설정을 하나씩 추가해주자!  이전 글에 있던 import 자동 정리가

하나의 예가 되겠다.

	"editor.codeActionsOnSave": {
		"source.organizeImports": "explicit"
	},

물론 이렇게만 적어두면 다른 사람이 뭔지 파악하기 힘들고 

설정한 사람도 시간이 지나서 무슨 내용인지 까먹을 수 있으니

아래 처럼 주석으로 옆에 표시하거나

settings-desc.json 파일을 별도로 만들어서 관리하는 방법도 있겠다.

	"editor.codeActionsOnSave": {
		"source.organizeImports": "explicit" // 저장 시 미사용 import 정리
	},

쓰지 않는 코드는 삭제하기!

이 얼마나 간단한 말인가 싶지만

정신없이 코드작업을 하고나면 사용하지 않는 코드들이 조금씩 남는다.

특히나 import 부분은 가장 상단에 있어서 자주 보는 부분도 아니라

사용했다가 지운, import들이 희미한 글자로만

남아있는 케이스가 종종있다.

이럴때를 대비해서 저장시마다 사용하지 않는 import를 제거해주는 방법이 있다! 🥺

1. 미사용 import 지우기 직접 실행하기

프로젝트 페이지로 이동해서 오른쪽 클릭하면 중간정도에 Source Action 이 나온다.

이를 클릭,

클릭하면 위 같이 새로운 창이 나온다. 

여기서 'Organize Imports' 를 클릭해주면

선언되어 있지만, 미사용 import를 깔-끔하게 제거해준다!

2. save 할때마다 import 관리하기

언제 매번 이렇게 지우겠나? 저장할때마다 지우기를 원한다면!

Settings 탭을 열고 오른쪽 상단에 아이콘중

파일에 화살표가 감싸고 있는 아이콘을 클릭해준다. (open setting JSON)

그러면 설정 json 파일로 넘어간다.

그리고 json파일에

"editor.codeActionsOnSave": {
               "source.organizeImports": true
},

이 부분을 추가해준다.

그러면~ 저장하는 모든 순간에 import 부분을 정리해준다. 

끝! 이제 import를 신경쓰지 않고 코딩에 집중할 수 있다!

2번이 그럼 무조건 좋겠지? 싶지만 서도

생각보다 적응이 안될 수 있다.

잠깐 컴포넌트를 지우고 위치를 옮기거나 하는 모든 순간에

import가 정리되서 다시 import를 선언해 주어야 한다..

그래서 신나게 적용시켰다가 

뭔지 모를 이질감에 살짝 당황했다는 후문이 ... 

참고 : https://medium.com/@sebastiantolomeo/how-to-automatically-organize-imports-in-visual-studio-code-e80d87b4f263

https://www.npmtrends.com/

npm 페이지에 들어가보면 이번주 다운로드 수라든지 

절대적인 수치들이 표시되어있다.

하지만,

절대적인 값 보다는 우리가 고민하는

또 다른 모듈과의 비교가 더욱 궁금하다. 

그래야 뭘 쓸지 흔들리는 우리의 마음을 다 잡을 수 있으니까.

그럴땐? 위의 페이지에서 찾을 수 있다. 

페이지 접속시 상단에 아래와 같이 되어있다. 

상단 이 부분에 찾고자 하는 npm package를 검색하면 된다.

뭐 react, recoil 등~

그러면 아래와 같이 다운로드수와 해당 패키지의 정보가 나온다.

여기에 미쵸버리는 뽀인트, 검색을 추가적으로 해서 바로 값을 비교할 수 있다.

또 다른 상태관리 패키지 zustand를 검색해보자.

크.. 한눈에 두 패키지를 비교할 수 있게끔 배치해준다.

뭐.. 거의 4배 차이가 나는군..

물론 많이 쓴다고 무조건 좋은 패키지가 아니라는 것은 언제나 명심!

자기에게 맞는 것을 골라서 사용하기!

그 아래에는 많이들 검색한 비교에 대해서도 몇개 뽑아주고 있다!

https://www.npmtrends.com/

프런트 회사 공고를 보면 (24년기준)

많은 회사들이 리덕스를 아직 사용중이다.

개인적으로.. 너무 싫다. 뭐 하나 만들려고 하면 아주 난리다. 

처음에 코드를 볼때도 무슨 기능인지 

타고타고타고타고~  아...**

벌써 아찔하군

요즘  상태를관리하는 여러 방법이 나왔다.

한번씩 다들 써보면서 "나 이거써봄~" 할 수 있는 멋쟁이가 되어보쟈.

그 중에 Recoil에 대해서 살포시 알아보도록 하쟈!

(그리고 이지피지한 사용법 뒤에 가려진 어두운면까지..)

Recoil에서는 하나의 상태를 [atom]이라고 부른다.

그리고 그 atom을 호출해서

atom의 값을 쓰거나 값을 수정해준다.

사용 방식은 아래와 같다.

      <RecoilRoot>
        <BrowserRouter>
          <App />
        </BrowserRouter>
      </RecoilRoot>

App.tsx에서 

일단 <App />컴포넌트를 <RecoilRoot>로 감싸준다.

( yarn을 통해서 recoil을 받아주는것 잊지 마시구)

export const totalPrice = atom<number>({ 
  key: 'totalPrice' , 
  default: 14 , 
});

그리고는 따로 파일을 만들어서

사용하고자하는 atom을 만들어준다.

(atom폴더를 따로 관리하는 것도 좋을것 같다 - 사견)

key는 해당 atom을 분간하기 위해서 사용하고,

default에 디폴트 값을 넣어준다.

string, number, array, object 타입이 뭐든 상관없다.

해당 타입은 atom옆에 <>로 넣어주면 된다.

const [price, setPrice] = useRecoilState<number>(totalPrice);

 그리고 원하는 페이지에서 useRecoilState관련 선언을 해준다.

순간 뭐랑 비슷? 맞다

useState과 상당히 유사하다. 

앞에 price는 상태값

setPrice는 상태 변경함수,

그리고 totalPrice는 atom파일에서 선언한 값을 가지고 오면 된다.

useState를 사용해서 상태 값을 관리해줄때는

컴포넌트를 통해서 값과 set함수 둘다 넘겨주는 노고를 했어야했다.

특히나.. 저 멀리 부모 컴포넌트에서 사용하는걸..

여러단계 아래에 있는 자식컴포넌트가 사용한다면?

...수많은 props에 태워줘야한다. (+ set함수 타입 검색까지 ..)

반면 Recoil을 사용한다면 사용하는 컴포넌트에서

위 한줄만 딱 선언해주면

언제 어디서든 값에 도달하고 수정할 수 있다! 홀리몰리

이제 앞으로 Recoil로만 개발하면 되겠다 ^오^

으림없는 소리!!

이 표보터 보자,

https://npmtrends.com/jotai-vs-recoil-vs-zustand 해당 페이지에서 얻은 정보다

이 페이지는 패키지들의 다운로드 횟수를 수치화해서 보여준다.

요즘 트랜디(?)한 상태관리 친구들 3개를 비교해보면

이제 고개를 조오~금 들고는 있지만

저 위에 zustand라는 친구가 굳건이마냥
압도적인 다운로드 횟수를 보여준다.

물론 많이 사용한다고 좋은 라이브러리라고 확정지을 수는 없지만

업데이트 주기까지 보면..녜에 ^^

또한 개인적으로는 SSR이 많이들 주목받고 있는 현 시점에

 Recoil은 클라이언트 사이드에 최적화 되어있기에

엄청나게 많은 사랑을 받지 못하는게 아닌가 싶다.

하지만 개인 프로젝트나 작은 프로젝트에서 사용하기는

간단한 사용법을 필두로 좋은 역할을 할수있지 않을까 하는 생각은 변함없다.

저 같은 경우 해당 현상은

SSR인 Nextjs에서 emtion을 사용하여 styled 컴포넌트 작성시에

:first-child 를 사용했기 때문이였습니다.

서버사이드 렌더링에서 이런 Emotion이나 styled-components 같은

CSS-in-JS 라이브러리를 사용할때,  위와 같은 문제가 발생할 수 있습니다.

해결 : first-child를 first-of-type으로 변경해준다.

근데.. sass나 css파일에서

first-child는 아무 문제 없었던 것 같은데..?!

그건 해당 파일이 처리되는 시점이 달라서 입니다.

sass나 css파일은 빌드타임시에 처리됩니다.

때문에 서버와 클라이언트에서 같은 스타일을 적용시킵니다!

반면 CSS-in-JS는 런타임에 동적으로 생성하기 때문에 

서버와 클라이언트 HTML구조가 다르면 다르게 작동할수 있어서

위와 같은 에러가 나오는것이라고 합니다.

참고 : GPT와의 딥토크 + https://inpa.tistory.com/entry/%F0%9F%8C%9F-first-child-first-of-type

서울숲 복합문화센터 강좌중하나인

헬스를 거진 1년 반 넘게 다니고 있다.

무리하게는 하지 않고 2~3일에 한번씩 방문해서

한 시간씩 하는 정도로의 강도로 지속했었죠

엄청난 고강도의 운동도 아니었고, 시간도 너무 길게 하지 않기에

문제가 될것은 없다고 생각했어요. 하지만...

회사가 있는 공용오피스에서 이벤트를 열어주었습니다.

목과 어깨쪽, 마사지를 해주는 이벤트였어요.

들뜬 마음에 바로 달려갔죠.

그런데 진단과 마사지를 해주시는 분이 

제 어깨와 목쪽을 만져보시더니 많이 놀라시더라구요,,

" 이건 자세가 좋지 않아서 굳은 거랑은 느낌이 달라요.. "

원인을 찾다가 헬스를 하다가 이렇게 된것 같다는 결론을 내려주셨어요.

대체 왜 헬스가..? 무리도 안했는데?

아마 잘못된 자세로 목과 어깨에 너무 많은 힘이 들어가서... (쥬륵)

이때 문득 PT의 중요성을 느꼈어요. 초반에 잘 배우고 시작했더라면

목과 어깨가 이렇게 되지는 않았을 텐데 싶더라구요.

여러분들은 저같은 실수 하시지 않기를 바라며...!

서울 숲 복합 문화센터에는 두 분의 PT쌤들이 계세요! (전문 트레이너 분들이시죠!)

PT시간대는 위와 같아요! 

가격은 변동 가능성이 있으니까,

https://sports.happysd.or.kr/fmcs/191?page=1&lecture_type=R&center=SUNGDONG13&event=1000000000&class=1000040000&category=&subject=

위 링크로 들어가서 [수강신청] 버튼을 눌러 현재 가격을 확인할 수 있어요~!

직접 들어가서 확인해보세요~

그리고 이번 기회에 PT한번 도전해보세요!!

좀더 멋쟁이가 되어가는 내일을 위해서 말이죠~!

Next 특정 버전 부터 app router 형식이 추가되었습니다.

전 주로 page router 형식만 다루었어서

공부차 app router에 대해 다루어 보려고 합니다.

기본적인 차이는 스택오버플로우 형님이 아래 표로 정리해주셨습니다.

참조 : https://stackoverflow.com/questions/76570208/what-is-different-between-app-router-and-pages-router-in-next-js 

[page.tsx]

기본적으로 이런 구조를 가진다. 

app 폴더에서 page.tsx가 처음으로 렌딩될 페이지 이다.

여기서 새로운 페이지를 추가하려면 폴더와 함께 새로운 page.tsx를 생성해준다.

그러고나면 /main 경로로 페이지가 추가가된다.

*여기서 프로출신들이 사용한다는 야무진 방법하나 추가*

(물론 프로출신이란 말은 죠큽니다.)

폴더 이름에 괄호'( )' 로 감쌀 수 있습니다. 이를 통해서 디폴트 그룹으로 묶을 수 있습니다!

위 처럼 (main)으로 폴더 명을 만들어두면 디폴트 페이지가 되고,

접근하려고 할때 /main 이 아닌 /  으로 바로 접속가능합니다!

물론 이때에는 기존에 /app에 있었던 page.tsx 파일을 삭제해주어야 한다는것~! 

있다면 (main)을 만들어도 루트에 있는 page.tsx를 바라봅니다.

( ) 괄호 스킬을 여러 폴더에 걸쳐서 사용할 수도 있는데,

어플리케이션의 커다란 분기를 나눌때도 사용할 수 있습니다.

위처럼 큰 분기를 (app), (web) 두개로 나누어서 개발을 하고 page.tsx에서

아래와 같이 분기를 쳐주면 모바일일 경우 (app) 폴더에서, 웹일 경우 (web) 폴더에서 

디폴트 경로가 설정되게 됩니다!

export default function MainPage() {
  return isMobile ? <MobileMain /> : <DesktopMain />;
}

[layout.tsx]

page.tsx 파일과 함께 있는 것이 layout.tsx 파일이다.

이는 여러 라우터들이 같이 공유하는 UI라고 생각하면 편하다.

이 layout 상에서는 상태가 보존되고 리렌더링이 발생하지 않는다.

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="en">
      <body className={inter.className}>{children}</body>
    </html>
  );
}

기본적인 레이아웃의 코드인데, 해당 {children} 부분에 라우터가 들어온다고 생각하면 됩니다.

위에 만든 main 폴더안에도 layout을 새로 선언해줄 수 있습니다. 다만 최상단 /app 밑에는

반드시 layout.tsx파일이 있어야 합니다

또한 layout.tsx은 기본적으로 상위에서부터 중첩되어 적용된다.

main폴더에 layout을 만들었다고 해당 레이아웃만 적용되지 않고,

최상단에 존재하는 layout.tsx가 적용된 상태에서 추가적으로 적용된다.

아래는 NEXT에서 제공해주는 이해를 돕기위한 그림이다.

요롷고롬 dashboard 하위에 있는 layout은

최상단 layout속으로 들어갑니다.

보통 예전부터 있던 프로젝트에서만 개발을 진행하다보면 

 익숙하지 않은 새로운 구조가 나온 경우가 좀 있는것 같아요.

페이지 라우팅만 하다가 앱 라우터를 가볍게 알아보니 새롭군요..

이런게 개인의 뚝딱거림이 필요하다는 이유중 하나 아닐까 싶군요

참고 : https://nextjs.org/docs/app/building-your-application/routing/pages-and-layouts ㅁㄴ