Frontend

<img src="https://image.until.blog/ninefloor/article/1729926668847.jpeg" data-width="100%" data-align="center" alt="1895"><h1><code spellcheck="false">path alias</code>?</h1><img src="https://image.until.blog/ninefloor/article/1729926632812.png" data-width="75%" data-align="center" alt="1894">상대 경로를 이용하면 프로젝트가 커질수록 <code spellcheck="false">../../src</code> 처럼 복잡하여 구조파악이 어렵고 불편하다. 이를 해결하고 개발 경험을 증진시키는 해결 방법으로 대표되는 것이 path alias이다.path alias는 경로에 별칭을 붙인다는 뜻으로, 상대경로로 인해 복잡해지는 import를 간략하게 만드는 방법이다. 보통 모듈 번들러에서 해당 기능을 지원하며, 번들러마다 적용하는 방법이 약간씩 다르지만 맥락은 대부분 비슷하다. TS를 사용하는 경우 추가로 <code spellcheck="false">tsconfig.json</code>에도 작성해주어야 한다.path alias를 적용하면 해당 컴포넌트가 어디에 속해있는지 쉽게 파악할 수 있고 import 역시 편해진다.<blockquote> CRA의 경우 webpack을 사용하는데, webpack config를 따로 정의할 수 없기 때문에 eject하거나 craco와 같은 오버라이딩 라이브러리를 이용해 설정해야 한다.</blockquote><h1>Path Alias with Vite</h1>번들러 중 하나인 Vite에서도 마찬가지로 지원하는데, <code spellcheck="false">vite.config.js</code> 파일에 아래와 같이 작성하면 된다.<pre spellcheck="false"><code class="language-typescript">import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import path from 'path';

// &lt;https://vitejs.dev/config/&gt;
export default defineConfig({
 plugins: [react()],
 resolve: {
	// find: 해당 경로의 이름. 실제로 import문에 적용된다.
	// replacement: 경로 지정. 이때, path.resolve를 이용한다.
 alias: [
 { find: '@', replacement: path.resolve(__dirname, 'src') },
 {
 find: '@components',
 replacement: path.resolve(__dirname, 'src/components'),
 },
 {
 find: '@assets',
 replacement: path.resolve(__dirname, 'src/assets'),
 },
 {
 find: '@page',
 replacement: path.resolve(__dirname, 'src/page'),
 },
 {
 find: '@util',
 replacement: path.resolve(__dirname, 'src/util'),
 },
 {
 find: '@recoil',
 replacement: path.resolve(__dirname, 'src/recoil'),
 },
 ],
 },
});
</code></pre><h3>VScode 자동완성 설정 (w/ JavaScript)</h3>단, 해당 설정을 하고 나면 VSCode는 이를 인지하지 못해 자동완성이 안된다. 이 때는 <code spellcheck="false">jsconfig.json</code>에 아래와 같이 path alias를 정의해주면 정상적으로 자동완성이 동작한다. (TS의 경우 <code spellcheck="false">tsconfig.json</code>)<pre spellcheck="false"><code class="language-jsx">{
 "compilerOptions": {
 "baseUrl": ".",
 "paths": {
 "@/*": ["./src/*"]
 }
 }
}
</code></pre>

쩜쩜슬래시 지옥을 벗어나보자

Path Alias with Vite (+ 자동완성 설정)

🖥 백엔드

<h2>우리들의 패키지 구성 방법</h2>여러분의 패키지 구성법은 무엇인가요?<pre spellcheck="false"><code>// 도메인형
└─src
 ├─member
 │ ├─controller
 │ ├─repository
 │ └─service
 └─post
 ├─controller
 ├─repository
 └─service
// 레이어형
└─src
 ├─controller
 │ ├─member
 │ └─post
 ├─repostiory
 │ ├─member
 │ └─post
 └─service
 ├─member
 └─post</code></pre>패키지 구성법은 크게 2가지가 있는데, 이 중 도메인형에 대해 얘기해보려고 한다.<h2>API는 애석히도 여러 도메인에 걸친다</h2><pre spellcheck="false"><code>// 도메인형
└─src
 ├─member
 │ ├─controller
 │ ├─repository
 │ └─service
 └─post
 ├─controller
 ├─repository
 └─service</code></pre>다음과 같이 레이어를 구성할 경우, member와 관련된 api들은 <code spellcheck="false">/member/controller</code>에 들어가게 된다. 그런데, api는 애석히도 여러 도메인에 걸치는 경우가 많다.예를 들어보자. 다음의 api들은 각각 어떤 컨트롤러에 들어가야 할까?<ul class="tight" data-tight="true"><li>특정 회원의 팔로워들의 글을 최신 순으로 모아서 보여주는 api</li><li>특정 글에 '좋아요'를 누른 회원의 목록을 모아서 보여주는 api</li></ul>특정 '회원'의 '팔로워'의 '글'을 최신 순으로 모아서 보여주는 api의 얘기를 해보자. 이 api는 회원(member), 팔로우(follow), 글(post)라는 세 가지 도메인에 걸쳐있다.이렇게 된다면, <code spellcheck="false">MemberService</code> 혹은 <code spellcheck="false">PostService</code>는 3개의 다른 도메인의 의존성을 가지게 된다.이런 기능들이 쌓이다보면, <code spellcheck="false">MemberService</code>는 정작 회원과 관련된 일을 하지 못하고 점점 비대해지게 된다. <h2>API는 도메인과 겸상하지 않는다</h2>API는 클라이언트의 요구사항이자 사용자의 유스케이스를 보여주는 계층이다. 글 작성 api, 글 수정 api 등등… 모두 유스케이스 아닐까?도메인 로직은 영원하지만, 유스케이스는 바뀔 수 있다. ‘특정 회원의 팔로워들의 글을 최신 순으로 모아 보여주기’라는 유스케이스에 이건 <code spellcheck="false">Post</code>와 관련된 기능이라고 적어붙이는 것보다 더 나은 라벨링이 있지 않을까?왜 우리는 이런 유스케이스에 도메인의 이름을 붙여야 하는걸까?API를 도메인으로부터 분리해보면 어떨까.<h2>API와 Domain 분리하기</h2><pre spellcheck="false"><code>└─src
 ├─api
 │ ├─blog
 │ │ BlogMemberController.java
 │ │ BlogPostController.java
 │ │
 │ └─feed
 │ FeedMainPageController.java
 │ FeedRankingController.java
 │
 └─domain
 ├─member
 │ ├─repository
 │ └─service
 └─post
 ├─repository
 └─service</code></pre>‘특정 회원의 팔로워들의 글을 최신 순으로 모아 보여주기’는 피드 페이지의 기능이었다. 따라서 해당 api는 feed 폴더에 넣어주었다.'이 API는 Post의 기능'이라고 적어넣기 보다, 조금 더 실제 유저의 요구사항에 맞게 패키지를 구성하여 더 명시적인 프로젝트 구조를 만들 수 있었다.<h2>컨트롤러에 로직이 쌓여요</h2><pre spellcheck="false"><code class="language-java">public class FeedMainPageController {
 private final MemberService memberService;
 private final PostService postService;

 @GetMapping("/follower-posts")
 public FollowerPostDTO getFollowerPosts(
 @RequestParam("memberId") Long memberId,
 ) {
 if(!memberService.isMemberExist(memberId)) {
 throw new MemberNotFoundException(memberId);
 }
 
 List&lt;Long&gt; = memberService.getFollowerIds(memberId);
 List&lt;Post&gt; posts = postService.getPostsByMemberIds(followerIds);

 return new FollowerPostDTO(posts);
 }
}</code></pre>이렇게 특정 서비스에서 다른 도메인의 로직을 처리하는 일을 막을 수 있게 되었다. 하지만 이렇게 되니 컨트롤러에서 여러 다른 도메인의 서비스를 호출하는 역할이 생겨버렸다.명령 api와 같은 경우는 트랜잭션 등의 처리도 필요할텐데, 컨트롤러에서 이를 수행하는 건 좋지 않겠다.이를 처리해주는 새로운 레이어를 만들어보는 것은 어떨까?<h2>Usecase 레이어로 비즈니스 로직 더 잘 드러내기</h2><pre spellcheck="false"><code>└─src
 ├─api
 │ └─feed
 │ ├─controller
 │ │ FeedMainPageController.java
 │ │ FeedRankingController.java
 │ │
 │ └─usecase
 │ FeedUseCase.java
 │
 └─domain
 ├─member
 │ ├─repository
 │ └─service
 └─post
 ├─repository
 └─service</code></pre>API가 구현하고자 하는 실제 유스케이스의 로직을 나타내는 것이니 usecase라는 이름으로 레이어를 개설했다.컨트롤러 → 유스케이스 → 서비스 → 레포지토리와 같은, 4단계의 계층이 만들어진 셈이다.이러면 코드가 어떻게 될까?<pre spellcheck="false"><code class="language-java">public class FeedMainPageController {
 private final FeedMainPageUseCase feedMainPageUseCase;

 @GetMapping("/follower-posts")
 public FollowerPostDTO getFollowerPosts(
 @RequestParam("memberId") Long memberId,
 ) {
 var posts = feedMainPageUseCase.getFollowerPosts(memberId)
 return new FollowerPostDTO(posts);
 }
}

public class FeedMainPageUseCase {
 private final MemberService memberService;
 private final PostService postService;

 public List&lt;Post&gt; getFollowerPosts(Long memberId) {
 if(!memberService.isMemberExist(memberId)) {
 throw new MemberNotFoundException(memberId);
 }

 List&lt;Long&gt; = memberService.getFollowerIds(memberId);
 List&lt;Post&gt; posts = postService.getPostsByMemberIds(followerIds);

 return new posts;
 }
}</code></pre><h2>멀티 모듈의 초석이 될 수도 있다</h2>지금까지 api와 domain의 패키지 구조를 분리해봤다.이렇게 서로 성격이 다른 두 패키지를 분리했으니, 추후에 필요할 때에 이를 모듈로 나눠서 멀티 모듈 패키지를 구성해볼 수 있을 것 같다.<h2>멀티모듈이란?</h2><img src="https://image.until.blog/octoping/article/1717907997881" alt="until-428">api, domain과 같은 파트를 각각 한 단위인 모듈로 나눈다면, 우리는 원하는 부분만 따로 jar파일로 빌드하여 한 모듈이 다른 모듈을 라이브러리처럼 사용할 수가 있다.만약 그냥 api 서버만 있는게 아니라, 어드민 서버가 추가되야 한다면?<ul class="tight" data-tight="true"><li>어드민 서버 프로젝트 새로 파서 member, post 도메인의 코드를 복붙해오는 것은 조금 무식한 방법 아닐까.</li></ul><ul class="tight" data-tight="true"><li>어드민 모듈을 따로 만들어서 도메인 모듈을 라이브러리처럼 참고하면 되지 않을까?</li></ul><h2>마무리하며</h2>패키지와 레이어의 구성은 항상 정답이 있는게 아니다. 프로젝트가 간단하다면 컨트롤러 하나만으로 구성해볼 수도 있는 것이고, 프로젝트가 훨씬 복잡하다면 더 많은 레이어를 구성해볼 수도 있다.이 아티클에서 다룬 내용도 꼭 정답임은 아니기 때문에, 이 아티클은 참고 하되 항상 프로젝트의 특성과 일하고 있는 조직의 상황에 맞게 알맞게 구성하는 것이 정답이라고 할 수 있겠다.

레이어를 잘 설계해서 프로젝트를 깔끔하게 유지해보자

관습적 레이어 설정 탈피를 통해 프로젝트 개선하기

🍎 Mac

맥북에서 터미널에서 code 커맨드라인을 지정해두고 해당 명령어를 통해 vscode를 실행하는데 실행할 때마다 dock에 vscode가 중복으로 생성되는 문제가 있었다.<img src="https://image.until.blog/morethanmin/article/1715356082565" alt="until-3">한동안 습관적으로 지워주면서 사용하고 있다가 매번 귀찮다는 생각이 들어서 원인을 찾아보았다.vscode 레포에서 동일한 증상을 겪고 있다는 <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/microsoft/vscode/issues/60579">이슈</a>를 발견해서 찾아보니, vscode와 관계없이 실행중인 상태의 애플리케이션을 터미널을 통해 실행하는 경우 발생하는 이슈라는 것을 알게 되었다.해결책은 크게 두가지가 있었다.<h2>Disable "Show suggested and recent apps in Dock"</h2>최근 사용한 앱을 독에 띄워주는 기능 자체를 끄는 것이다.해당 기능 자체를 끄는 것이기에 해당 영역자체가 사라진다.<h2>Edit <code spellcheck="false">code</code> function</h2>기존 code 명령어를 수정함으로써 해결이 가능하다.<code spellcheck="false">vim ~/.zshrc</code> 를 입력해 기존 <code spellcheck="false">code</code> 명령어를 아래와 같이 수정해보자.<pre spellcheck="false"><code class="language-auto">code() {
 if [ -t 1 ] &amp;&amp; [ -t 0 ]; then
 open -a Visual\\ Studio\\ Code.app "$@"
 else
 open -a Visual\\ Studio\\ Code.app -f
 fi
}</code></pre>위 코드를 해석하면 아래와 같다. (채찍피티 인용)<blockquote>ChatGPT 왈: 이 코드는 <code spellcheck="false">~/.zshrc</code> 파일에 작성되어 있는데, 이 파일은 Zsh 셸의 설정 파일입니다. 여기서 정의된 <code spellcheck="false">code()</code> 함수는 주로 Visual Studio Code를 실행하는 데 사용됩니다.이 함수는 두 부분으로 나뉘어 있습니다. 첫 번째는 <code spellcheck="false">if</code> 문으로 시작하여 터미널에서 실행 중인지(<code spellcheck="false">-t 1</code>과 <code spellcheck="false">-t 0</code>를 통해 확인) 확인하고, 그렇다면 주어진 파일이나 디렉토리를 Visual Studio Code로 엽니다. 두 번째 부분은 이와 반대로 터미널이 아닌 상황에서 Visual Studio Code를 엽니다.여기서 <code spellcheck="false">open</code>은 macOS에서 파일을 열거나 애플리케이션을 실행하는 명령입니다. <code spellcheck="false">-a</code> 플래그는 특정 애플리케이션을 지정하여 파일을 열도록 합니다. <code spellcheck="false">Visual\\ Studio\\ Code.app</code>은 Visual Studio Code 애플리케이션의 경로를 나타냅니다. 공백을 포함하는 이름을 사용할 때는 이스케이프 문자(<code spellcheck="false">\\</code>)를 사용하여 공백을 인식하게 합니다.따라서 이 코드는 Zsh 셸에서 <code spellcheck="false">code</code> 명령어를 입력하면, Visual Studio Code가 실행되며, 터미널에서 실행 중인 경우에는 주어진 파일이나 디렉토리를 열도록 하며, 터미널이 아닌 경우에는 그냥 Visual Studio Code를 엽니다.</blockquote><hr>나는 애초에 최근앱 기능을 잘 사용하지 않다보니 첫번째 방법을 사용해서 해결했다.

맥북에서 터미널에서 code 커맨드라인을 지정해두고 해당 명령어를 통해 vscode를 실행하는데 실행할 때마다 dock에 vscode가 중복으로 생성되는 문제가 있었다.한동안 습관적으로 지워주면서 사용하고 있다가 매번 귀찮다는 생각이 들어서 원인을 찾아보았다.vscode 레포에서 동일한 증상을 겪고 있다는 이슈를 발견해서 찾아보니, vscode와 관계없이 

mac dock에 vscode가 중복 생성되는 이슈

스프링을 싫어하는 사람들이 많이 하는 말이 있다. 스프링은 어노테이션이 덕지덕지 붙어서 극혐이라고..하지만 어노테이션도 잘 쓰면 로직을 간단히 추상화해줄 수 있어서 좋은 점이 많다.어노테이션을 이용해서 로그인한 유저만 api를 호출할 수 있도록 하고, 미로그인 유저는 400 에러를 발생하도록 필터링하는 기능을 구현해보려고 한다.<pre spellcheck="false"><code>@NeedLogin
@Operation(summary = "아티클 작성하기")
@PostMapping("/{username}/articles")
fun writeArticle(
 @PathVariable("username") username: String,
 @RequestBody request: BlogArticleWriteRequestDTO,
) {
 TODO("로직은 알아서 잘 딱 깔끔하게")
}</code></pre>설명하기 앞서, 원하는 결과물은 이렇다.api의 위에 <code spellcheck="false">@NeedLogin</code> 어노테이션을 붙이는 것 만으로 API가 로그인을 필요로 한다는 것을 명시적으로 나타내줄 수 있다.언어는 코틀린으로 짜여있지만, Java로도 코드가 크게 다르진 않을 것이니 따라가봅시다레츠고~<hr><pre spellcheck="false"><code class="language-kotlin">@Retention(AnnotationRetention.RUNTIME)
@Target(AnnotationTarget.FUNCTION)
annotation class NeedLogin</code></pre>간단하게 어노테이션을 만들어주자. API가 실행될 때 로그인 상태를 검증하는 것이니 RUNTIME이고, 함수에 붙여줄 생각이니 타겟은 FUNCTION으로 한다.<pre spellcheck="false"><code class="language-kotlin">@Component
class NeedLoginInterceptor(
 private val tokenProvider: TokenProvider,
) : HandlerInterceptor {
 override fun preHandle(
 request: HttpServletRequest,
 response: HttpServletResponse,
 handler: Any,
 ): Boolean {
 // NeedLogin 어노테이션이 붙어있지 않은 함수면 패스
 if (!hasNeedLoginAnnotation(handler)) {
 return true
 }

 // 로그인된 상태인지 체크
 if (!hasValidAccessToken(request)) {
 throw UserNotAuthorizedException()
 }

 return true
 }

 private fun hasValidAccessToken(request: HttpServletRequest): Boolean {
 return getAccessCookie(request)
 ?.let { tokenProvider.validateToken(it) }
 ?: false
 }

 private fun hasNeedLoginAnnotation(handler: Any): Boolean {
 return handler is HandlerMethod &amp;&amp;
 handler.method.isAnnotationPresent(NeedLogin::class.java)
 }
}</code></pre>api가 호출될 때 마다 검증해야 하기 때문에 Interceptor를 사용해준다. <code spellcheck="false">HandlerInterceptor</code>를 상속받아서 <code spellcheck="false">NeedLoginInterceptor</code>라는 클래스를 만들었다.'api가 실행되기 전에' 로그인 상태를 검증해야 하므로 <code spellcheck="false">preHandle</code>에 로직을 적어넣었다.NeedLogin 어노테이션이 붙어있는지 체크해서 없을 경우 패스하기 위해 리턴 시켜준다.그 후 각자의 방법으로 로그인 여부를 체크해준 후 미로그인 상태일 경우 Exception을 터트려주면 된다. 나는 AccessToken을 이용하는 방법을 사용했기 때문에 해당 방법으로 구현해주었다.<pre spellcheck="false"><code class="language-kotlin">@Configuration
class WebConfig(
 private val needLoginInterceptor: NeedLoginInterceptor
) : WebMvcConfigurer {
 override fun addInterceptors(registry: InterceptorRegistry) {
 registry.addInterceptor(needLoginInterceptor)
 .addPathPatterns("/**")
 }
}</code></pre>마지막으로는 인터셉터를 적용해주기 위해 WebMvcConfigurer에다가 내가 만든 인터셉터를 적용해주었다.그러면 끝!<pre spellcheck="false"><code class="language-kotlin">@NeedLogin
@Operation(summary = "아티클 작성하기")
@PostMapping("/{username}/articles")
fun writeArticle(
 @PathVariable("username") username: String,
 @RequestBody request: BlogArticleWriteRequestDTO,
) {
 TODO("로직은 알아서 잘 딱 깔끔하게")
}</code></pre>나머지는 이렇게 api 위에다가 NeedLogin 어노테이션만 붙여주면 된다.<pre spellcheck="false"><code class="language-kotlin">@RestControllerAdvice
class GlobalExceptionHandler {
 @ExceptionHandler(UserNotAuthorizedException::class)
 fun handleUserNotAuthorizedException(exception: UserNotAuthorizedException): ResponseEntity&lt;ErrorResponse&gt; {
 return ResponseEntity.status(HttpStatus.UNAUTHORIZED)
 .body(ErrorResponse(exception.message))
 }
}</code></pre>마지막으로 예외가 발생했을 때 400 에러와 exception 메시지를 출력해주기 위해 ExceptionHandler로 받아다가 원하는 에러 코드와 메시지를 전달해주면 된다.<pre spellcheck="false"><code>{
 "error": "로그인이 필요합니다."
}</code></pre>그러면 이렇게 API를 실행했을 때 401 에러와 함께 메시지가 떨어져나오는 모습을 볼 수 있다~앞으로도 인터셉터와 어노테이션 기능을 잘 활용하여 로직을 잘 추상화하고 반복을 제거해보자

어노테이션으로 로그인 체크 쉽게 하기!

어노테이션으로 로그인한 유저만 api를 호출할 수 있도록 간단히 필터링하기

⚛️ React

<img src="https://image.until.blog/morethanmin/article/1715876172847" alt="until-47"><blockquote>이 글은 기본적인 react-hook-form의 사용방법을 설명하고 있지 않습니다.</blockquote>리액트에서 폼을 다룰 때 빼놓을 수 없는 react-hook-form. (최근에 확인해보니 토스가 스폰서더라..)react-hook-form을 사용하면서 watch를 통해 values를 가져와 계산하는 컴포넌트를 만들었는데, useForm을 사용하는 컴포넌트 전체가 리렌더링 되면서 퍼포먼스가 구려지는 이슈가 있어서 원인을 찾아보았다.<h2>watch API</h2>watch란 무엇일까? 공식문서를 확인해보자.<blockquote>This method will watch specified inputs and return their values. It is useful to render input value and for determining what to render by condition.</blockquote>아래와 같이 사용할 수 있다.<pre spellcheck="false"><code class="language-typescript">// ...
const Summary: FC = () =&gt; {
 const { watch } = useFormContext&lt;Values&gt;();

 const value = watch();

 if (values.type === 'a') return &lt;Result {...getAResultProps(values)} /&gt;;
 if (values.type === 'b') return &lt;Result {...getBResultProps(values)} /&gt;;
 return &lt;Result 판매금액={0} 최종손익={0} /&gt;;
};

export default Summary;
</code></pre>동작은 하지만 <code spellcheck="false">Summary</code>컴포넌트 상위의 Root 컴포넌트까지 전부 리렌더가 발생한다. 음... 내가 생각한 의도에 맞는 것 같은데... 좀만 더 읽어보자.<blockquote><ul><li>This API will trigger re-render at the root of your app or form, consider using a callback or the <a target="_blank" rel="noopener noreferrer nofollow" href="https://react-hook-form.com/docs/usewatch">useWatch</a> api if you are experiencing performance issues.</li><li><code spellcheck="false">watch</code> result is optimised for render phase instead of <code spellcheck="false">useEffect</code>'s deps, to detect value update you may want to use an external custom hook for value comparison.</li></ul></blockquote>헉... watch를 쓰면 root부터 리렌더가 발생한다고한다. 실제 사용하는 경우에는 컴포넌트의 리렌더가 발생할 수 있으니 useEffect의 deps로써 활용할 수 있도록 최적화 되어있고, 실제 예시와 같은 사용방식에서는 적합하지 않은 것 같다.그럼 문서에 나와있는 useWatch를 알아보자.<h2>useWatch API</h2>문서를 읽어보면 다음과 같이 설명하고 있다.<blockquote>Behaves similarly to the <code spellcheck="false">watch</code> API, however, this will isolate re-rendering at the custom hook level and potentially result in better performance for your application.</blockquote>음... 그럼 전체 리렌더링이 발생하는 <code spellcheck="false">watch</code>를 사용했을 때 얻는 이점은 뭐지..? 일단 적용해보았다.<pre spellcheck="false"><code class="language-typescript">// ...

const Summary: FC = () =&gt; {
 const values = useWatch&lt;Values&gt;();

 if (values.type === 'a') return &lt;Result {...getAResultProps(values)} /&gt;;
 if (values.type === 'b') return &lt;Result {...getBResultProps(values)} /&gt;;
 return &lt;Result 판매금액={0} 최종손익={0} /&gt;;
};
export default Summary; 

// ...</code></pre>Root에 존재하는 form은 리렌더하지 않고 <code spellcheck="false">Summary</code> rootLevel부터 리렌더되는 이슈는 해결되는 것을 확인할 수 있었다. 👍<h2>useWatch의 deep partial type 이슈</h2>한가지 문제가 더 있었다. <code spellcheck="false">useWatch</code>를 사용한 경우 (정확히는 parmeterless한 <code spellcheck="false">useWatch</code>를 사용한 경우) <code spellcheck="false">watch</code>와 다르게 deepPartial이 적용된 타입이 적용된다는 것이다.이 문제는 <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/orgs/react-hook-form/discussions/10610">해당 논의</a>와 <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/react-hook-form/react-hook-form/issues/9954">이슈</a>에서도 확인해보면 알 수 있다.결론적으로 <code spellcheck="false">watch</code>와 다르게 <code spellcheck="false">useWatch</code> 의 타입이 정의되어있는 것은 v8 버전에서 resolve가 된다고 한다.<h3>그럼 지금은 어떻게 대응해야할까?</h3>아래와 같이 하거나... 필요한 필드만 뽑아서 사용해야할 것 같다.<pre spellcheck="false"><code class="language-typescript">const values = useWatch() as Values</code></pre><h2>결론</h2><code spellcheck="false">watch</code>와 <code spellcheck="false">useWatch</code>의 네이밍만보고 동작하는 방식이 같을 것이라고 생각하고 로직안에 오류가 있다고 생각해서 해결하기까지 생각보다 시간을 썼던 것 같다. 문서를 자주 봐야겠다.

이 글은 기본적인 react-hook-form의 사용방법을 설명하고 있지 않습니다.리액트에서 폼을 다룰 때 빼놓을 수 없는 react-hook-form. (최근에 확인해보니 토스가 스폰서더라..)react-hook-form을 사용하면서 watch를 통해 values를 가져와 계산하는 컴포넌트를 만들었는데, useForm을 사용하는 컴포넌트 전체가 리렌더링 

react-hook-form의 useWatch와 watch의 차이점

<img src="https://image.until.blog/steady/article/1727700265407.png" alt="until-1670"><h2>어디서 나타났니?</h2><hr>여기다 이런걸 써도 되나 모르겠다만 언틸은 생각보다 꽤나 흥미로웠다.뭔가 글을 적는 재미가 있달까? 그냥 좀 간지가 난달까? 이런 사소한 이유도 있긴하지만 내가 느낀 점을 적어보고 싶었다.나는 개발자로서 기술 블로그를 작성하며 내 가치를 늘려보자라고 생각하며 여기저기 기웃거린 전적이 있다. (until에 대한 정보를 얻은 곳도 기웃대던 곳 중 하나인 Velog 다.)하지만 대체로 정착을 못했는데 다 각각의 변명거리가 있었다.그래서 내가 각 플랫폼에 느낀 느낌을 적어보자면<h2>다른 블로그들은?</h2><hr><h3>Tistory</h3>: 개발에 대한 궁금증을 구글에 검색하다보면 가장 많이 보였던 블로그였다.<ul><li>기술을 제외한 다양한 주제의 글들이 많다.</li><li>진입장벽이 있다. (초기 셋팅을 하지 않으면 작성글이 보기에 썩 좋지 않다.)</li><li>기능이 뭐가 많다. (근데 어떻게 쓰는지 몰라 배워야한다.)</li></ul>그래서 이쁘게 글을 쓰고 싶다보니 글을 열심히 적는게 아니라 여러 설정들을 찾아보고 있는 나를 발견했다.<h3>Velog</h3>: 사이트 분위기가 가벼워 간단하게 글을 쓰기 좋은 느낌의 블로그였다.<ul><li>에디터가 묘하게 불편하다. (글을 작성하는 부분과 미리보기 하는 부분이 2분할 되어있다.)</li><li>잔버그가 있었다. (썸네일 이미지가 본문에 자동으로 추가된다던지...)</li></ul>아무래도 글을 작성하는 부분이 불편하다 보니 자주 안적게 되며 눈팅족이 되어버렸다.<h2>언틸은?</h2><hr><ul><li>그냥 맨바닥에 글을 쓰는데 편하고 스스로 만족스럽게 볼만하다.</li><li>개발자 입장에서 흥미로운 아티클들이 많다.</li><li>우선 깃허브에서 영감을 받은 듯한 잔디심기가 은근 재밌다. (얼른 글을 작성해 색칠하고 싶어진다.)</li><li>아직 사람이 많지 않아서 그런지 최신 아티클에 내 글이 뜨는게 재밌다.</li></ul><h3></h3><h5>진짜 사소한 아쉬운점</h5><ul><li>이미지를 편하게 다루면 좋겠다.(한 행에 2~3개 둔다던지)</li><li>이게 지금 팔로우를 한건지 안한건지 모르겠다.<img src="https://image.until.blog/steady/article/1727702641092.png" alt="until-1674"></li></ul><h5>아무튼 이렇게 마음에 쏙 드는 블로그를 만들어 주신 개발자께 감사드리며.</h5><h2>결론은?</h2><hr><img src="https://image.until.blog/steady/article/1727702304083.png" alt="until-1671"><blockquote>언틸아 아프지 말고 오래오래 건강해야한다~</blockquote>

어디서 나타났니?여기다 이런걸 써도 되나 모르겠다만 언틸은 생각보다 꽤나 흥미로웠다.뭔가 글을 적는 재미가 있달까? 그냥 좀 간지가 난달까? 이런 사소한 이유도 있긴하지만 내가 느낀 점을 적어보고 싶었다.나는 개발자로서 기술 블로그를 작성하며 내 가치를 늘려보자라고 생각하며 여기저기 기웃거린 전적이 있다. (until에 대한 정보를 얻은 곳도 기웃대던 곳 

[Until] 내가 Until을 쓰는 이유

언틸 서비스에는 블로그에 업로드되는 이미지들을 저장하기 위해 AWS의 S3 서비스를 이용하고 있다. 파일을 업로드하면 해당 파일의 이름에 따라 해당 파일에 액세스할 수 있도록 URL을 제공하고 있는데, 언틸에서는 따로 파일의 확장자를 지정하지 않고 저장하고 있었다.덕분에 url이 이렇게 나오고 있었다. <code spellcheck="false">https://{언틸_S3_URL}/octoping/profile/1722161760968</code>물론 지금 생각해보면 왜 그랬을까 싶긴 한데... 열심히 개발하면서 아무 생각 없이 저질렀던 것 같다.<h1>코드</h1><pre spellcheck="false"><code class="language-kotlin">@Profile("real")
@Service
class S3ImageUploadService(
 private val s3Config: S3Config,
 private val imageDataSaver: ImageDataSaver,
 private val profileReader: ProfileReader,
) : ImageUploadService {
 override fun uploadImage(request: ImageUploadRequest): ImageUploadResult {
 val blog = profileReader.findById(request.blogId)
 val filePath = createFilePath(blog.username, request.fileType)
 val imgUrl = uploadImageAndGetUrl(filePath, request)
 
 // ...
 }

 private fun createFilePath(username: String, fileType: FileType): String {
 val fileName = System.currentTimeMillis().toString()
 return username + "/" + fileType.storePath + "/" + fileName
 }
}
</code></pre>다음이 해당 부분의 코드다.블로그의 username과 파일의 타입 (프로필 사진인지, 아티클 사진인지 등)을 받아 저장될 path를 생성하는 함수가 보인다. 여기에서 <code spellcheck="false">fileName</code>은 현재 시각을 통해서 만들고 있는데. 보시다시피 확장자를 따로 삽입해주고 있지 않았다..결국 이것들이 S3에 올라간 시점에서는 타입을 구분하기가 어려워진다. <h1>문제</h1>저장된 파일의 확장자가 없으니 S3의 url만 가지고는 어떤 파일인지를 알 수 없게 된다. 이것이 이미지인지, 동영상인지, 그냥 파일인지 알 수 없다. 물론 언틸의 경우 지금이야 이미지만 저장하고 있으니 괜찮지 않을까?<h2>WebP 변환 이슈</h2>이미지에도 종류가 여러 가지가 있다. jpg, png, webp, gif...그 중 WebP는 구글이 웹페이지 로딩 속도를 높이기 위해 개발한 이미지 포맷인데, 기존 포맷들에 비해 용량을 크게 줄일 수 있어 많은 사이트들에서 웹 사이트의 로딩 속도를 향상시키기 위해 사용하고 있다.그리고 보통 이미지의 WebP로의 변환은 <code spellcheck="false">CloudFront</code>의 <code spellcheck="false">Origin Response</code>에서 <code spellcheck="false">Lambda@Edge</code>를 통해 on-the-fly 방식으로 이루어지게 된다.<img src="https://image.until.blog/octoping/article/1729522382526.png" data-width="75%" data-align="center" alt="until-1840">이 WebP로 변환하는 람다 함수에서는 <code spellcheck="false">Sharp</code>라는 라이브러리를 사용한다. 이 라이브러리는 다양한 확장자의 이미지를 지원하지만 그럼에도 지원하지 않는 이미지 포맷이 존재한다. (ex. BMP 파일)따라서 WebP 변환을 진행하는 함수에서 확장자 검사를 진행해야 하는데, 앞서 소개한 상황에서는 확장자를 지니고 있지 않으니 다음을 진행할 수가 없다.<h1>해결</h1><pre spellcheck="false"><code class="language-kotlin">// Before
private fun createFilePath(username: String, fileType: FileType): String {
 val fileName = System.currentTimeMillis().toString()
 return username + "/" + fileType.storePath + "/" + fileName
}

// After
private fun createFilePath(username: String, fileType: FileType, contentType: String): String {
 val fileName = System.currentTimeMillis().toString()
 return username + "/" + fileType.storePath + "/" + fileName + "." + contentType.split("/")[1]
}</code></pre>다음과 같이 파일 이름에 확장자를 추가해주었다.<code spellcheck="false">MultipartFile</code>에서 넘어오는 <code spellcheck="false">contentType</code>은 <code spellcheck="false">image/png</code>와 같은 형식으로 주어지므로, <code spellcheck="false">contentType.split("/")[1]</code>와 같은 형식으로 파싱해주면 된다.<img src="https://image.until.blog/octoping/article/1729523218239.png" data-width="100%" data-align="center" alt="until-1841">이제는 확장자가 잘 붙은 것을 볼 수 있다.. 😢 다시는 하지 말자 이런 실수

S3에 파일을 업로드할 때는 꼭 확장자도 같이 붙여줍시다