-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
7aac168
commit f92f35a
Showing
1 changed file
with
54 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,54 @@ | ||
# Ch 11. 일급 함수 2 | ||
|
||
### 혜성 | ||
|
||
- 고차 함수 이점 | ||
- 반복적으로 해야하는 연산에서 콜백만 쓰면 되서 최적화가 용이 | ||
- 함수를 리턴하는 함수 | ||
- try catch 블록을 일급처럼 추상화 | ||
- 감싸진 함수를 변수에 할당해서 사용할 수도 있음 | ||
- 팩토리 메소드 패턴과 비슷한 간지다~ | ||
- 중용을 지키는게 중요하다 | ||
- 능숙하게 쓸 줄 알아야 하지만 더 좋은 코드를 만드는데 써야 함 | ||
|
||
### 상범 | ||
|
||
- 함수 본문을 콜백으로 바꾸기 (고차함수) 이 방법이 가장 괜찮아 보였음. → 커링?! | ||
- 나중에 큰게 나올거같은.. 도움닫기 느낌이었다. 지금까지는! 기대가 됩니다. | ||
|
||
### 예찬 | ||
|
||
- 여기서는 앞의 10장에 이어 세번째 리팩토링 기법을 더 추가로 소개하는구나 | ||
- function factory 리팩토링 기법 | ||
- 여기서도 일급의 개념이 드러남 | ||
- 함수 본문을 콜백으로 바꾸는 방법에서 조금 더 나은 방법을 소개하고 있음 | ||
- 이 기법은 커링과 다를바 없는 기법으로 보인다. | ||
- 여기서 드러난 일급의 개념은? 값이 아니라면 함수에서 return 할 수 없다. | ||
- 결국 이러한 일급의 개념이 중요한 이유는 값으로 다룰 수 없었던 것을 값으로 다룰 수 있게 되면서 훨씬 더 유연한 시스템 구축이 가능하다는게 장점이구나. | ||
|
||
### 대윤 | ||
|
||
- 함수 내부에서 달라지는 부분이 있다면 본문이 될 수 있음. | ||
- 고차함수 쓰면 정형화된 코드를 만들 수 있고, 이것은 패턴화 된 것 | ||
- 결국 패턴이나 원칙을 정형화 시킨다는 것이 고차함수를 의미하는 것이구나 | ||
- 객체 지향의 캡슐화같은 느낌.. | ||
- 감싸서 내부에서 알아서 실행해줄게 | ||
- 고차함수의 장단점? | ||
- 회사에서 잘 안씀 | ||
- 사이드 프로젝트에서도 잘 안씀 | ||
- useCallback, useMemo 같이 만들어져있는 거만 썼음 | ||
- 이유는 가독성이 떨어지는 것 같아서..라고 생각했는데 역시나! 책에서도 그렇게 말함 | ||
|
||
## 논의 | ||
|
||
- 함수를 작성할 때, 도메인에 관련된 부분을 범용적으로 변경하는 것이 좋을까? | ||
- 예를 들어 sortCartItems 를 sortIds로 바꾸는 경우 | ||
- 다들: 좋은 것 같은데 | ||
- 혹시 다른 사람이 쓸 때, 가독성에 문제가 생길 수도 있다는 의견이 있음 | ||
- 예찬: 저는 이런 네이밍을 선호해요. setFieldBy(Price), setFieldBy({name: Price}) 이렇게 인자까지 함께 읽을 수 있는 방식 | ||
- 객체 리터럴에서 getter, setter 많이 쓰시나요? | ||
- 다들: 잘 안씀요 | ||
- 객체 안에서 프로퍼티를 수정하는 것을 방지하기 위해서 쓰는거 같은데..잘 모르겠다. | ||
- 장점이 뭐지? → 캐시가 된다? | ||
- 단점은 뭐지? | ||
- valtio가 캐시를 해주네. get 냅다쓰면 https://valtio.pmnd.rs/docs/guides/computed-properties |