codestates / codestates/withpuppy
[❗️Error] 12/15 (최우철) 비동기 요청을 따로 정리해야 하는 이유
- Dominant language
- JavaScript
- Stars
- 0
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Description
### 마주친 에러에 대한 설명
- 에러라기 보다는, 전략적이지 못하고 관습적으로도 어긋나는 방식을 사용하고 있었는데 서버를 만들 때에 endpoint를 어떻게 설정해야되지 하는 의문을 이제서야 갖고 구글링을 했더니 전부 다 바꿔야 하는 것을 알게 되었다

- stack overflow 형님들에 따르면, 엔드포인트는 반드시 하이픈(-) 을 이용해서 단어를 구분해야 해야 crawlable(웹 크롤링) 적으로 유리하다고 한다.
> 왜냐하면 하이픈은 두 단어를 따로 구분하지만, camel case나 underbar은 그 전체를 하나의 단어로 인식하기에 웹 크롤링 적으로 유리하지 않다고 한다(또한 관습적으로도 옳지 않다고)

### 에러 메세지 상세 내용
- 따라서 모든 엔드포인트에 사용된 camel case를 수정해야 하는 상황이었는데, 만약 비동기 요청작업을 모든 컴포넌트에 개별적으로 실행했다면 이 수정된 엔드포인트를 위해서 모든 컴포넌트를 다 뒤져야 했다는 결론이 난다
- 지금 현재 컴포넌트만으로도 고역스러운데, 만약 그 수가 많았다면 정말로 유지보수 개념으로서는 답이 없는 상황이었을것이다.
- 하지만, 다행이도 redux-toolkit에서 제공하는 비동기 액션객체를 서버요청에서 사용하고 있었고, 이것을 모두 파일별로 정리하고 있었기 때문에 크게 문제되지 않고 수정을 할 수 있었다.

> 그저 비동기 함수에 존재하는 엔드포인트를 수정하면 됐었다. 참 다행이었다.

- 또한, redux toolkit에서 제공하는 비동기 액션객체 생성함수는 자동으로 pending, fulfilled, rejected의 형태로 만들어 처리를 해주고, 리덕스 스토어의 상태객체를 전달받아 곧바로 응답내용에 따라 업데이트가 가능하기 떄문에 비동기적인 요청처리를 하나로 연결하여 관심사를 분리할 수 있으며, 필요에 따라서는 "unwrap" 이라는 메소드를 이용하여 컴포넌트 내에서도 해당 결과물을 받아 그곳에서 요청결과의 처리를 진행할 수 있기 때문에 선택의 폭이 많아진다고 할 수 있다.

### 레퍼런스
[why you should use hypen to set the endpoint of server](https://stackoverflow.com/questions/10302179/hyphen-underscore-or-camelcase-as-word-delimiter-in-uris)
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.