dev_0hoon

이메일 발송, 알림, 통계 집계, 쿠폰 발급 등 회원에게 불필요한 로직일 때, 내 로직이 느릴 때, 본질로직과 부수로직 분리, 리스너, 이벤트 리스너 개발(JAVA SPRING)

dev_0hoon — Tue, 5 May 2026 13:05:08 +0900

1. 헬스앱 사이드 프로젝트 진행 중 기획자에게 연락이 왔다.

2. "센터 관장이 센터 등록할 때 로딩이 너무 긴것 같아서.. 중간에 이탈이 발생할 것 같아요. 속도를 빠르게 할 수 없을까요?"

3. 물론 안되죠! 라고 말하고 싶었지만, 나는 '친절한 개발자'이다.

4. 로직을 살펴 봤다.

  @Transactional
    public void saveCenterFirst(HttpServletRequest request, SaveCenterFirstReqeust saveCenterFirstReqeust) {
        Users findUser;

        try {
            // 1) 로그인 사용자 가져오기
            UsersDto user = UserContext.getUser(request);
            ...
            
            // 2) 가입 중인 경우 트레이너 프로필 Y로 변경
            findUser.setUserType(UserTypeEnum.TRAINER);
            ...
            
            // 3) 센터 저장 및 센터 트레이너로 등록
            Center center = saveCenterFirstReqeust.toEntity();
            center.setCenterStatus(CenterStatus.PENDING); // 승인 중
            ...
            ...
            centerTrainerRepository.save(CenterTrainer.create(saveCenter, trainer, CenterTrainerRole.OWNER, REQUESTED)); // 센터 오너이며 아직 요청 중

            
            // 4)사업자 등록증 저장
            try {
                List<UploadFileDto> uploadFileDtos = saveCenterFirstReqeust.getUploadFiles();
                fileService.linkToReferenceIdList(uploadFileDtos, saveCenter.getId(), FileType.BUSINESS_REGISTRATION_CERTIFICATE); //
            } catch (Exception e) {
                log.error(e.getMessage());
                throw new RestApiException(INTERNAL_SERVER_ERROR);
            }

            // 5) 센터장 가입 알림 메일 발송 (사업자 등록증 이미지 첨부)
            try {
                List<UploadFileDto> businessCertFiles = fileService.findUploadFilesByReferenceIdAndTypeAndStatusForMail(
                        saveCenter.getId(), FileType.BUSINESS_REGISTRATION_CERTIFICATE, FileStatus.SAVED, Sort.by(Sort.Direction.ASC, "ord")
                );

                SendSaveCenterEmail sendSaveCenterEmail = SendSaveCenterEmail.create(saveCenterFirstReqeust.getCenterName(), saveCenterFirstReqeust.getCenterLicenseNumber(), saveCenterFirstReqeust.getCenterMasterName()
                        , saveCenterFirstReqeust.getCenterMasterTel(), saveCenterFirstReqeust.getCenterIntro(), saveCenterFirstReqeust.getCenterTimeCode(), saveCenterFirstReqeust.getCenterAddress(), saveCenterFirstReqeust.getCenterAddressDetail()
                        , saveCenterFirstReqeust.getCenterPostcode(), saveCenterFirstReqeust.getCenterLat(), saveCenterFirstReqeust.getCenterLng(), saveCenterFirstReqeust.getUploadFiles()
                );
                emailService.sendSaveCenterEmail(
                        findUser.getUserName(),
                        sendSaveCenterEmail,
                        businessCertFiles
                );
            } catch (Exception e) {
                log.error("센터장 가입 알림 메일 발송 실패: {}", e.getMessage());
            }

        } catch (Exception e) {
            throw new RestApiException(INTERNAL_SERVER_ERROR);
        }
    }

5. 디버깅을 진행해보니 '센터장 가입 알림 메일 발송'에서 간헌절으로 속도가 느려짐을 캐치했다.

6. 운영에서는 서버속도가 빨라 dev나 qa에서는 충분히 타임아웃 등의 실패 요소가 숨어있어 보였다.

7. 이럴 때 사용하기 좋은 방법이 있다.

설명 1. Before/ After

Before — 직접 호출 방식

@Service
@RequiredArgsConstructor
public class UserService {
    private final UserRepository userRepository;
    private final EmailService emailService;
    private final SlackService slackService;
    private final StatisticsService statisticsService;

    @Transactional
    public void signUp(SignUpRequest request) {
        User user = userRepository.save(new User(request));
        emailService.sendWelcomeMail(user);      // 부수 효과 1
        slackService.notifyNewUser(user);         // 부수 효과 2
        statisticsService.increaseSignUpCount();  // 부수 효과 3
    }
}

signUp() 호출
  ↓
① User 저장
  ↓ (대기)
② 환영 메일 발송 (예: 2초)
  ↓ (대기)
③ 슬랙 알림 (예: 1초)
  ↓ (대기)
④ 통계 증가 (예: 0.5초)
  ↓
응답 반환 (총 3.5초+)

UserService가 이메일, 슬랙, 통계까지 다 알고 있음 (의존성 폭발)
알림 하나 추가할 때마다 UserService 수정 필요
이메일 발송이 느리면 회원가입 응답도 느려짐
슬랙 API가 죽으면 회원가입 자체가 실패할 수 있음

After — 이벤트 방식

@Service
@RequiredArgsConstructor
public class UserService {
    private final UserRepository userRepository;
    private final ApplicationEventPublisher eventPublisher;

    @Transactional
    public void signUp(SignUpRequest request) {
        User user = userRepository.save(new User(request));
        eventPublisher.publishEvent(new UserSignedUpEvent(user));
    }
}

UserService는 "회원가입 했음"만 알리고, 나머지는 각 리스너가 알아서 처리

Spring이 애플리케이션 시작 시점에 @EventListener 메서드들을 스캔해서 
"이벤트 타입 → 리스너 목록" 매핑 테이블을 만들어둔다. 
publishEvent()가 호출되면 이 테이블에서 해당 이벤트 타입의 리스너들을 찾아 호출한다.

이벤트 방식의 처리 흐름 (옵션별)

이벤트는 세 가지 모드로 동작할 수 있고, 어떤 어노테이션을 붙이느냐로 결정된다.

① 기본 (@EventListener) — 동기 + 같은 트랜잭션

signUp() 호출
  ↓
① User 저장 (트랜잭션 시작)
  ↓
② publishEvent() 호출
   ├─ WelcomeEmailListener 실행 (대기)
   ├─ SlackListener 실행 (대기)
   └─ StatisticsListener 실행 (대기)
  ↓
③ 트랜잭션 커밋
  ↓
응답 반환

문제: 리스너들이 같은 트랜잭션 안에서 동기로 돕니다. Before와 사실상 동일하고, 게다가 메일 발송 후 트랜잭션이 롤백되면 메일은 이미 나간 상태가 된다.

② @TransactionalEventListener(AFTER_COMMIT) — 동기, 커밋 후

signUp() 호출
  ↓
① User 저장
  ↓
② publishEvent() 호출 (이벤트는 일단 큐에 보관됨)
  ↓
③ 트랜잭션 커밋 ✓
  ↓
④ 보관된 이벤트의 리스너들 실행
   ├─ WelcomeEmailListener (대기)
   ├─ SlackListener (대기)
   └─ StatisticsListener (대기)
  ↓
응답 반환

롤백 시 메일이 안 나가는 문제는 해결됐지만, 여전히 순차 실행이라 응답이 느리다.

③ @Async + @TransactionalEventListener(AFTER_COMMIT) — 비동기, 커밋 후

signUp() 호출
  ↓
① User 저장
  ↓
② publishEvent() (큐에 보관)
  ↓
③ 트랜잭션 커밋 ✓
  ↓
④ 리스너들을 별도 스레드풀로 던지고 즉시 리턴
  ↓
응답 반환 ⚡ (빠름)

  [백그라운드에서 병렬로]
  ├─ Thread-1: WelcomeEmailListener
  ├─ Thread-2: SlackListener
  └─ Thread-3: StatisticsListener

이게 실무에서 가장 많이 쓰는 형태. 본질 작업(회원가입)은 즉시 응답하고, 부수 효과는 백그라운드에서 병렬 처리된다.

‼️ 이 경우 3번 방식에 대해 주의

@Async + ApplicationEventPublisher는 "단일 JVM 안에서만" 동작합니다. 이중화/다중 서버 환경에서는 발행한 서버에서만 리스너가 실행됩니다.

		[Load Balancer]
               /            \
         [Server A]      [Server B]
         (JVM A)         (JVM B)
         
         
         
         
Server A:
  signUp() → publishEvent(UserSignedUpEvent)
    ↓
  Server A의 리스너들만 실행됨
    ├─ WelcomeEmailListener ✓
    ├─ SlackListener ✓
    └─ StatisticsListener ✓

Server B: 아무 일도 안 일어남

서버가 이중화 된 경우에는 A에서 리스너를 사용하면 문제가 없습니다.

다만

[웹 서버 A] — API 받는 역할
[배치 서버 B] — 메일 발송 전담

문제 케이스: 이벤트를 받는 서버가 발행 서버와 달라야 할 때

예: 주문 서버에서 OrderPlacedEvent를 발행하고, 재고 서버·결제 서버·알림 서버가 각각 받아야 하는 마이크로서비스 구조.

문제 케이스 2: 처리 보장이 필요한 경우

@Async 리스너가 실행되는 도중 서버가 죽으면 이벤트는 그냥 사라집니다. 메모리에만 있었으니까요. "메일 발송 100% 보장"이 필요하면 이걸로는 안 됩니다.

해결책: 외부 메시지 브로커 사용

서버 간 이벤트 전파가 필요하면 메시지 큐/브로커를 도입해야 한다.

도구특징사용 시점

Redis Pub/Sub	간단, 빠름, 메시지 보장 X	캐시 무효화 같은 가벼운 신호
RabbitMQ	메시지 보장, 라우팅 유연	일반적인 비동기 작업 큐
Kafka	대용량, 이벤트 영속성, 재처리 가능	이벤트 스트리밍, MSA
AWS SQS/SNS	관리형, 인프라 부담 적음	AWS 환경

패턴: Spring 이벤트 + 외부 브로커 조합

실무에서 자주 쓰는 패턴입니다.

// 1. 도메인 로직: Spring 이벤트 발행 (JVM 내부)
@Service
public class UserService {
    @Transactional
    public void signUp(...) {
        userRepository.save(user);
        eventPublisher.publishEvent(new UserSignedUpEvent(...));
    }
}

// 2. 브릿지 리스너: 트랜잭션 커밋 후 외부 브로커로 전달
@Component
public class UserEventBridge {
    
    @TransactionalEventListener(phase = AFTER_COMMIT)
    public void publishToKafka(UserSignedUpEvent event) {
        kafkaTemplate.send("user-signed-up", event);
    }
}

// 3. 다른 서버의 컨슈머가 받아서 처리
@Component
public class WelcomeEmailConsumer {
    
    @KafkaListener(topics = "user-signed-up")
    public void handle(UserSignedUpEvent event) {
        emailService.sendWelcomeMail(...);
    }
}

판단 기준: "이 이벤트가 발행된 서버 안에서만 처리되어도 비즈니스적으로 문제 없는가?"

회원가입 후 메일 발송 → 어느 서버가 처리하든 OK → Spring 이벤트로 충분
모든 서버의 캐시를 갱신해야 함 → Spring 이벤트로 부족 → Redis Pub/Sub 필요

문제 케이스 2번에 대해서는 어떤 서버든 실패가 나올 수 있기 때문에, 차라리 이벤트를 보내기 전에 아웃박스로 진행하려한다.

-> 이벤트 테이블을 만들고, 이벤트를 생성한 로그를 남긴 뒤에 완료시에 SUCCESS 값을 남겨준다.

-> 추가로 배치를 만들어 EMAIL이 FAIL된 경우 따로 처리하도록 진행을 돕는 것도 방법이 된다.

아웃박스 패턴에 대해서는 다음 글에서 처리하려한다.

처리 현황

          // 5) 센터장 가입 알림 메일 outbox 적재 + AFTER_COMMIT 발송 트리거
            //    실패 시 외부 catch에서 INTERNAL_SERVER_ERROR로 변환되어 트랜잭션이 롤백된다.
            MailOutboxPayload payload = MailOutboxPayload.builder()
                    .recipientUserName(findUser.getUserName())
                    .centerId(saveCenter.getId())          // 발송 시점에 PII 복호화/파일 lookup
                    .centerName(center.getCenterName())
                    .build();
            String json = objectMapper.writeValueAsString(payload);

            MailOutbox outbox = MailOutbox.create(
                    "Center",                  // aggregateType
                    saveCenter.getId(),        // aggregateId
                    "CENTER_REGISTERED",       // eventType
                    json
            );
            MailOutbox saved = mailOutboxRepository.save(outbox);   // 같은 TX1
            eventPublisher.publishEvent(new CenterRegisteredEvent(saved.getId()));

        } catch (Exception e) {
            throw new RestApiException(INTERNAL_SERVER_ERROR);
        }

아웃박스 테이블에 create 및 save후에 이벤트를 전달

public record CenterRegisteredEvent(Long outboxId) {}

...

@Component
@RequiredArgsConstructor
public class MailOutboxEventListener {
    private final MailDispatcher mailDispatcher;

    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void onCenterRegistered(CenterRegisteredEvent event) {
        mailDispatcher.dispatch(event.outboxId());   // 다른 빈 → @Async 발화
    }
}

....

@Async("mailExecutor")
public void dispatch(Long outboxId) {
    if (!txService.claim(outboxId)) return;        // 단일 진입 보장 (★ 2회 발송 방지)

    MailOutbox outbox = outboxRepository.findById(outboxId).orElse(null);
    if (outbox == null) return;

    try {
        MailOutboxPayload p = objectMapper.readValue(outbox.getPayload(), MailOutboxPayload.class);
        Center center = centerRepository.findById(p.getCenterId());
        if (center == null) {
            throw new IllegalStateException("Center not found: " + p.getCenterId());
        }

        List<UploadFileDto> files = fileService.findUploadFilesByReferenceIdAndTypeAndStatusForMail(
                p.getCenterId(),
                FileType.BUSINESS_REGISTRATION_CERTIFICATE,
                FileStatus.SAVED,
                Sort.by(Sort.Direction.ASC, "ord"));

        // 평문 PII는 발송 시점에 복호화 (outbox에는 안 들어감)
        SendSaveCenterEmail dto = SendSaveCenterEmail.create(
                center.getCenterName(),
                encryptUtil.decryptLicenseNumber(center.getCenterLicenseNumber()),
                encryptUtil.decryptName(center.getCenterMasterName()),
                encryptUtil.decryptPhone(center.getCenterMasterTel()),
                center.getCenterIntro(),
                center.getCenterTimeCode(),
                center.getCenterAddress(),
                center.getCenterAddressDetail(),
                center.getCenterPostcode(),
                center.getCenterLat(),
                center.getCenterLng(),
                files
        );

        emailService.sendSaveCenterEmail(p.getRecipientUserName(), dto, files);
        txService.markSent(outboxId);
    } catch (Exception e) {
        log.error("메일 발송 실패 outboxId={}", outboxId, e);
        txService.markFailed(outboxId, e.getMessage());
    }
}

Nuxt 3에서 페이지 상태 유지하기 (뒤로가기 시 스크롤/데이터 복원)

dev_0hoon — Wed, 15 Apr 2026 22:22:45 +0900

사이드 프로젝트 중 상세에서 목록으로 이동할 때에 들어왔던 상태의 화면을 표시하려 했다.

1. KeepAlive 방식(시도)

// app.vue - NuxtPage에 keepalive 활성화
<NuxtPage :keepalive="true" />

// 페이지 파일 - 캐시할 페이지에 keepalive: true
definePageMeta({ layout: 'member', keepalive: true })

KeepAlive는 Vue와 Nuxt에서 컴포넌트의 상태를 메모리에 박제(캐싱) 해두는 기능이다.

사용자가 A페이지에서 B페이지로 이동하면, A컴포넌트는 파괴(Unmount)되고 메모리에서 사라진다.

하지만 KeepAlive로 감싸주면 컴포넌트가 파괴되지 않고 '비활성화(Deactivated)' 상태로 메모리에서 머물다가, 다시 돌아왔을 때 이전의 데이터, 입력값, 스크롤 위치 등을 그대로 보여준다.

KeepAlive를 사용하면 컴포넌트가 다시 나타날 때 onMounted가 호출되지 않는다. 대신 전용 훅을 사용해야 합니다.

onActivated: 캐시된 컴포넌트가 화면에 다시 나타날 때 실행됩니다. (데이터 갱신 로직을 여기에 넣습니다.)
onDeactivated: 다른 페이지로 이동하여 컴포넌트가 숨겨질 때 실행됩니다.

AI 왈:

KeepAlive는 "사용자가 입력하던 폼 내용이 많거나, 리스트 렌더링 비용이 너무 커서 0.1초의 딜레이도 없어야 할 때" 사용하면 좋습니다.

캐시방식으로 선택

1. 목록(/member/feedback/board, layout: member) → 상세(/common/feedback/detail/123, layout: default) 이동 시 레이아웃이 바뀐다.

2. 레이아웃을 바꿔 시도하려했으나, 해당 목록은 main의 성격을 띄고있어 상세와의 레이아웃이 같지 않다. 
3. 만약 레이아웃을 바꿔서(후에 레이아웃 안에 추가코드가 발생확률 큼) 시도한다면 괜찮을지 시도해봣으나,
이미 작업이 완료된 페이지인 터라, KeepAlive를 적용하려 보니 SSR 컴포넌트 생명주기와 엉켜서 제대로 작동되지 않았다.

원인을 파악하는데에 시간 소요가 클 것이라 판단, Vue에서 권장하는 캐시방식으로 작업을 진행했다.

1. 목록에서 돌아온 후 필요한 캐시 값들을 state로 선언해준다.

const cache = useState<{
  list: FeedbackPost[]
  ranking: FeedbackRanking | null
  category: string
  page: number
  hasMore: boolean
  scrollY: number
} | null>('feedback-board-cache', () => null)

2. 상세 이동 시 캐시 값을 담아준다. 참고로 현재의 scrollY와 현재 page는 페이징을 위해 필수가 된다.

// 상세로 이동 시 → 현재 상태 저장
const goToDetail = (id: number) => {
  cache.value = {
    list: feedbackList.value,
    ranking: ranking.value,
    category: activeCategory.value,
    page: currentPage.value,
    hasMore: hasMore.value,
    scrollY: window.scrollY,
  }
  router.push(`/detail/${id}`)
}

3. 상세에서 router.back()으로 돌아올 시에 마운트에서

캐시 값을 확인하는 코드를 담아서 복원해준다.

// 목록 마운트 시 → 캐시 있으면 복원, 없으면 fetch
onMounted(async () => {
  if (cache.value && cache.value.list.length > 0) {
    // 캐시에서 복원
    feedbackList.value = cache.value.list
    ranking.value = cache.value.ranking
    activeCategory.value = cache.value.category
    currentPage.value = cache.value.page
    hasMore.value = cache.value.hasMore
    const savedScrollY = cache.value.scrollY
    cache.value = null  // 사용 후 캐시 초기화
    isLoading.value = false
    nextTick(() => {
      setupObserver()
      setTimeout(() => window.scrollTo(0, savedScrollY), 50)
    })
    return
  }

  // 캐시 없음 → 새로 API 호출
  isLoading.value = true
  await fetchData()
  isLoading.value = false
})

✍️ 흐름정리

목록 (최초 진입)
  → cache === null → API fetch → 렌더링

목록 → 상세 이동
  → cache에 {list, scrollY: 500, ...} 저장
  → 컴포넌트 파괴 (but useState는 살아있음)

상세 → 뒤로가기
  → 목록 마운트 → cache !== null
  → 캐시에서 복원 (API 안 부름)
  → scrollTo(500) → 원래 위치

목록 (탭 메뉴에서 재진입)
  → cache === null (이전에 초기화됨) → API fetch

☝️ useState

useState와 ref의 차이점은 ref는 컴포넌트 내부에서만 사용되며, useStatesms 전역에서 사용된다. 따라서 페이지 이동시에도 유지가 된다. useStete(키, ()=>초기값)

Nuxt 사용기 (1)

dev_0hoon — Mon, 17 Mar 2025 17:46:22 +0900

개인 운동기록 & pt 매칭 프로그램을 만들며 Nuxt를 사용하게 됐다. 몇 주간 Nuxt을 개인적으로 공부하며 잡힌 사용 방법에 대해 기록한다.

✅ 파일구조

https://nuxt.com/docs/guide/directory-structure/layouts#named-layout

1️⃣ 서문

나는 백엔드를 주로 사용하던 개발자로써 기존 아키텍처에 대해 익숙하다

- 컨트롤러 -> 서비스 -> 맵퍼

- 컨트롤러 -> 서비스 -> 레파지토리

그리고 데이터를 운반하는 dto, vo, entity의 개념이 익숙하다.

1) domain별로 컨트롤러,서비스,레파지토리, dto, entity로 레이어드 아키텍처 파일구조 이거나

2) presentation, domain, infrastructure 로 클린 레이어드 아키텍처의 파일구조

2가지를 주로 사용한다.

2️⃣ Nuxt의 파일구조에 대한 생각

기존 vue에 대한 개념을 잡고 싶어 인프런의 캡틴 판교의 강의를 주로 참고 했다

생각 정리

1단계

<template>
  <!-- 전체 컨테이너 -->
  <div class="container">
    <!-- 상단 타이틀 (검색창 포함) -->
    <ManageHeader></ManageHeader>
    <!-- 카테고리 메뉴 -->
    <MemberList></MemberList>
    <!-- 하단 고정 푸터 -->
    <footer class="fixed-footer">
      <div v-for="item in category" @click="selectCategory(item)" class="footer-item" :class="{active : selectedCategory == item}" >{{ item }}</div>
    </footer>
  </div>
</template>

<script setup lang="ts">
  import ManageHeader from "~/components/user/manage/ManageHeader.vue";
  import {api} from "~/store/api";
  import {useMemberStore} from "~/store/member";
  import MemberList from "~/components/user/trainer/MemberList.vue";

  const memberStore = useMemberStore();
  const category = ref(['회원관리','마이페이지']);
  const selectedCategory = ref('회원관리');

  const selectCategory = (category) => {
    selectedCategory.value = category;
  }


</script>

<style scoped>

</style>

- page: page폴더에 아래에 들어오는 vue파일들은 자동으로 path에 연결된다.

1) / 는 index.vue

2) /user 는 user폴더 아래의 index.vue

3) /user/list는 user폴더 아래의 list.vue

4) /user/1 은 user폴더 아래의 [id].vue을 가지며 파라미터의 값은 useRouter를 사용해 값을 꺼내게 된다.

<template>
  <div>
    <div class="default-nav">
      <div v-if="memberStore.useFilter">총 {{memberStore.filteredMembersCount}}명</div>
      <div v-if="!memberStore.useFilter">총 {{memberStore.membersCount}}명</div>
      <div class="default-nav-item">
        <button @click.stop="clickSort" class="sort-btn">
          <img src="@/assets/icons//swap-vertical.svg" alt="">
          <span>
                정렬
          </span>
        </button>
      </div>
    </div>

    <div class="user-container">
      <!-- 회원이 없을 경우 표시될 문구 -->
      <div style="display: none;" class="no-users-message">등록하신 회원이 없습니다.</div>

      <div class="user-item-container">
        <!-- 회원 정보 -->
        <div class="user-item" v-for="item in membersList" :key="item.id">
          <NuxtLink :to="`/record/${item.userId}`" class="user-info">
            <div class="user-image">
              <img src="@/assets/images/1.png" alt="운동 아이콘">
            </div>
            <div class="user-text">
              <div class="user-title">{{item.userName}}</div>
              <div v-if="!item.isNew" class="user-descript gray-text">{{item.age}}세 | 마지막수업: {{item.latestCreatedAt}}</div>
              <div v-if="item.isNew" class="user-descript gray-text">{{item.age}}세 | 새로운 회원</div>
            </div>
          </NuxtLink>
        </div>
        <!--회원정보-->
      </div>
    </div>
    <!-- 정렬 모달 -->
    <div v-if="isShowSortModal" id="sortModal" class="user-sort-modal">
      <ul class="sort-options">
        <li @click="selectSort(item.sort)" v-for="item in sortTypes" class="sort-option" >{{item.name}}</li>
      </ul>
    </div>
  </div>
</template>

<script setup lang="ts">
  import {useMemberStore} from "~/store/member";
  import {computed} from "vue";

  //data
  const memberStore = useMemberStore();
  const isShowSortModal = ref(false);
  const sortTypes = ref([
      {name: '가나다순', sort: 'userName'},
      {name: '최근 수업순', sort: 'recent'}
  ])

  //lifeCycle
  onMounted(async () => {
    const data = {sortBy : ''}
    const response = await useMember().trainerMember(data);
    memberStore.setMembers(response.result.list);
    memberStore.setMembersCount(response.result.list.length);
  });

  //method
  const selectSort = async (sort) => {
    const data = {sortBy : sort}
    const response = await useMember().trainerMember(data);
    memberStore.setMembers(response.result.list);
    memberStore.setMembersCount(response.result.list.length);
    clickSort();
  }

  const clickSort = () => {
    isShowSortModal.value = !isShowSortModal.value;
  }

  //getters
  const membersList = computed(() => {
    if(memberStore.useFilter){
      return memberStore.filteredMembers.map(m => ({
        ...m,
        isNew : m.latestCreatedAt == null ? true : false
      }))
    } else {
      return memberStore.members.map(m => ({
        ...m,
        isNew : m.latestCreatedAt == null ? true : false
      }))
    }

  })


</script>

<style scoped>

</style>

- component: page 안의 html 코드를 공통으로 나누어 관리할 경우 사용한다.

? 1) 의문인 부분이다. 공통으로 사용하지 않아도 코드상의 깔끔함을 위해서도 나누어도 될까?

?2) emit과 props을 이용해 page에서 관리되는 데이터를 운용하게 된다. 지금은 store에 필요한 것들을 넣어서 사용 중인데 이래도 되나 싶다. emit과 props를 꼭 써야하는 것일까

import {api} from "~/store/api";

export const useRecord  = () => {
    const recordList = async(data) => {
        try {
            const response = await api().get(`/record/list`,data);
            return response;
        } catch (e) {
            console.error("[recordList] 요청실패 : ", e);
        }
    }

    return {recordList}
}

- composable: 공통이 되는 url의 호출을 관리하게 됌

1) 예를 들어 page에서 api를 요청해야 한다면, url 호출을 만든다.

import {defineStore} from 'pinia'

export const useMemberStore = defineStore('member',{
    state: () => ({
        members: [],
        membersCount: 0,
        filteredMembers: [], // 검색된 회원 목록
        filteredMembersCount: 0,
        useFilter: false,
        sortBy : '',
        searchUserName : ''
    }),
    actions: {
        setMembers(data) {
            this.members = data;
            this.setMembersCount(data.length);
        },
        setMembersCount(data) {
            this.membersCount = data;
        },
        setFilteredMemberCount(data) {
            this.filteredMembersCount = data;
        },
        setSearchUserName(data) {
            this.searchUserName = data;
            this.filteredMembers = this.members.filter(m =>
                m.userName.includes(data)
            )
            let count = this.filteredMembers.length;

            this.setFilteredMemberCount(count);
        },
        setUseFilter(data) {
            this.useFilter = data;
        }
    }
})

- store: 한 섹션 안에 전역으로 사용되는 state, action 들을 관리한다.

1) action은 setState명 식으로 만들어서, page에서 조작해왔다.

?2) 컴포서블을 이곳에서 호출하고 page에서 store을 통해 값을 꺼내서 사용하거나 한다던데.. 그렇게 해도 될지 모르겠다. 전체적인 구조가 아직 좀 낯설다.

그럼 만약 state의 값을 불러올 때 page에서는 onMounted만 해주고 store의 함수가 state의 값을 조절하는 것인지.. 조금 의문임

커스텀 컴포지션 함수

dev_0hoon — Sat, 25 Jan 2025 10:06:24 +0900

<template>
  <TodoHeader :appTitle="appTitle"></TodoHeader>
  <TodoInput :todoItems="todoItems" @add="addTodo"></TodoInput>
  <TodoList :todoItems="todoItems" @remove="removeTodo"></TodoList>
</template>

<script>
import TodoHeader from '@/components/TodoHeader.vue'; //vim
import TodoInput from '@/components/TodoInput.vue';
import TodoList from '@/components/TodoList.vue';
import { onBeforeMount, ref } from 'vue';
export default {
  components: {
    TodoHeader,
    TodoInput,
    TodoList
  },
  setup() {
    //data
    const todoItems = ref([]);

    //methods
    function fetchTodos() {
      const result = [];
      for(let i = 0; i < localStorage.length; i++) {
        const todoItem = localStorage.key(i);
        result.push(todoItem);
      }
      return result;
    }

    //라이프 사이클 api가 적용된 구간
    //todoItems.value = fetchTodos();
    
    //화면이 그려지기 전에 동작
    onBeforeMount(() =>{
      todoItems.value = fetchTodos();
    })

    function addTodo(todo) {
      todoItems.value.push(todo);
    }

    return {todoItems, addTodo}
  },
  methods:{
    removeTodo(index) {
      this.todoItems.splice(index, 1);
    }
  }

  ,
  data() {
    return{
      appTitle: '할일앱'
    }
  }
}
</script>

<style lang="scss" scoped>

</style>

위를 보면 소스가 많이 더럽지 않지만, setup안은 실무레벨에서는 엄청나게 길어 질 것으로 보인다.

이때에 커스텀 컴포넌트를 사용한다.

/hooks/useTodo.js

import { onBeforeMount, ref } from "vue";

function useTodo() {

    const todoItems = ref([]);
    
    //methods
    function fetchTodos() {
        const result = [];
        for(let i = 0; i < localStorage.length; i++) {
            const todoItem = localStorage.key(i);
            result.push(todoItem);
        }
        return result;
    }

    function addTodo(todo) {
        todoItems.value.push(todo);
    }
  
    //화면이 그려지기 전에 동작
    onBeforeMount(() =>{
        todoItems.value = fetchTodos();
    })

    return {todoItems, fetchTodos, addTodo }
}

export {useTodo}


//app.vue

import { useTodo } from './hooks/useTodo';
export default {
  setup() {
    const {todoItems,addTodo} = useTodo();
    return {todoItems, addTodo}
  },

useTodo.js에서 정의한 data와 methods를 다른 뷰에서 불러와 사용할 수 있다.

주의점이 있다.

    //화면이 그려지기 전에 동작
    onBeforeMount(() =>{
        todoItems.value = fetchTodos();
    })

위처럼 data, methods가 아닌 형태의 코드는 커스텀컴포넌트(js에 따로 뺴는경우)에 있다보면 확인이 어렵다. 이런 코드는 사용하는 .vue 파일에 두는게 옳다.

watch란?

dev_0hoon — Sat, 25 Jan 2025 09:44:57 +0900

watch API도 컴포지션 API에서 사용하는 watch 속성을 의미한다.

watch 속성

watch API

    export default {
        props:['todoItems', 'userId'],
        setup(props, context) {
            function remove(item,index) {
                localStorage.removeItem(item);
                context.emit('remove',index);
            }

            watch(props.todoItems, (newValue)=>{
                console.log({newValue}); 
            })

            return {remove}
        }
    }

위처럼 watch를 사용하면 todoItems가 바뀔 때마다 그 새롭게 바뀐 값이 newValue로 넘어온다.

watch는 최대한 사용하지 않는 것이 좋다. 많아지면 추적이 어렵기 때문이다. 기존의 emit, props 등을 이용해서 데이터를 운용하는 것이 바람직하다.

Lifecycle API 사용하기, mounted

dev_0hoon — Sat, 25 Jan 2025 09:36:55 +0900

인스턴스 라이프사이클이란 뷰의 인스턴스가 생성되어 소멸되기까지 거치는 과정을 의미합니다. 인스턴스가 생성되고 나면 라이브러리 내부적으로 다음과 같은 과정이 진행됩니다.

data 속성의 초기화 및 관찰 (Reactivity 주입)
뷰 템플릿 코드 컴파일 (Virtual DOM -> DOM 변환)
인스턴스를 DOM에 부착

https://joshua1988.github.io/vue-camp/vue/life-cycle.html#%E1%84%85%E1%85%A1%E1%84%8B%E1%85%B5%E1%84%91%E1%85%B3%E1%84%89%E1%85%A1%E1%84%8B%E1%85%B5%E1%84%8F%E1%85%B3%E1%86%AF-%E1%84%83%E1%85%A1%E1%84%8B%E1%85%B5%E1%84%8B%E1%85%A5%E1%84%80%E1%85%B3%E1%84%85%E1%85%A2%E1%86%B7

인스턴스 라이프사이클 훅: 컴포넌트 생명 주기에 따라 특정 로직을 실행할 수 있는 속성 함수. created, beforeMount() 등, 옵션API에서 사용하던 것

라이프사이클 API: 컴포지션 스타일로 작성된 인스턴스 라이프사이클 훅

https://joshua1988.github.io/vue-camp/composition/lifecycle.html#%E1%84%8B%E1%85%B5%E1%86%AB%E1%84%89%E1%85%B3%E1%84%90%E1%85%A5%E1%86%AB%E1%84%89%E1%85%B3-%E1%84%85%E1%85%A1%E1%84%8B%E1%85%B5%E1%84%91%E1%85%B3%E1%84%89%E1%85%A1%E1%84%8B%E1%85%B5%E1%84%8F%E1%85%B3%E1%86%AF-%E1%84%92%E1%85%AE%E1%86%A8%E1%84%80%E1%85%AA-lifecycle-api%E1%84%8B%E1%85%B4-%E1%84%8E%E1%85%A1%E1%84%8B%E1%85%B5%E1%84%8C%E1%85%A5%E1%86%B7

Lifecycle API | Cracking Vue.js

Lifecycle API Vue 3 라이프사이클(Lifecycle) API란 컴포지션(Composition API)에서 사용된 인스턴스 라이프사이클 훅을 의미합니다. 이 페이지에서는 컴포지션에서 인스턴스 라이프사이클 훅을 정의하는 방

joshua1988.github.io

setup(){
    //라이프 사이클 api가 적용된 구간
    //todoItems.value = fetchTodos();

    console.log('setup called');

    //화면이 그려지기 전에 동작
    onBeforeMount(() =>{
      console.log('onBeforeMount called');
      todoItems.value = fetchTodos();
    })
}

순서상 setup called 이후 onBeforeMount called가 발생하게 된다.

onUnMounted는 컴포넌트가 사라졌을 때라는데.. 다른 화면으로 갈 때 일어나는 거랑 비슷할까?

setup()에서 props 접근시 주의 점

dev_0hoon — Sat, 25 Jan 2025 09:18:05 +0900

        setup(props, context) {
            function remove(item,index) {
                localStorage.removeItem(item);
                context.emit('remove',index);
            }

            props.todoItems
            props.userId
            return {remove}
        }
        
        위처럼 코드를 생각하면
        
        setup({todoItems, userId}, context) {
            function remove(item,index) {
                localStorage.removeItem(item);
                context.emit('remove',index);
            }

            props.todoItems
            props.userId
            return {remove}
        }

아래처럼 props를 디스트럭쳐링을 하면 안된다. 디스트럭쳐링을 하는 순간, vue의 반응성(reactivity)가 사라지게 된다. 그래서 props는 있는 그대로 사용해야한다.

만약 디스트럭쳐링을 하면, props의 값이 바뀌어도 해당 함수의 값은 변하지 않게 된다!

computed API란?

dev_0hoon — Sat, 25 Jan 2025 09:08:52 +0900

컴퓨티드 api는 컴포지션 Api에서 사용된 컴퓨티드 속성을 의미한다.

<template>
  <div>{{ reversedMessage }}</div>
</template>

<script>
export default {
  data() {
    return {
      message: 'Hello'
    }
  },
  computed: {
    reversedMessage() {
      return this.message.split('').reverse().join('');
    }
  }
}
</script>

문자열을 반대로 정리해주는 computed가 보인다. 특정 연산을 담아두는 속성이라고 보면 된다. 기본이 되는 data를 다른 값으로 표현해주게끔 사용한다. (converter 같은 느낌도 들고?)

위는 속성으로 'computed 속성'이라 부른다.

<template>
    <h1>{{appTitle}}</h1>
    <h4>{{ newTitle }}</h4>
</template>

<script>
import { computed } from 'vue';

export default {
    props:['appTitle'],
    setup(props) {
        
        const newTitle = computed(()=>{
            return props.appTitle + '!!';
        })

        return {newTitle};
    }
}
</script>

컴포지션 API에서는 컴퓨티드API라고 부른다. 여기에서 왜 컴퓨티드가 아니라 메소드를 사용하는 걸까?

computed와 method의 차이점

캐싱
- computed는 결과를 캐싱해.
- 즉, computed에 사용된 종속 데이터(의존성)가 변하지 않는 이상 재계산을 하지 않아.
- 반면 method는 호출할 때마다 다시 실행돼.
- 이 차이가 성능에 중요한 영향을 줄 수 있어

export default {
  setup() {
    const count = ref(1);

    const computedValue = computed(() => {
      console.log("Computed 재계산");
      return count.value * 2;
    });

    const methodValue = () => {
      console.log("Method 실행");
      return count.value * 2;
    };

    return { count, computedValue, methodValue };
  }
}

- computedValue는 종속된 count.value가 변하지 않으면 콘솔에 로그가 출력되지 않아(캐싱).
- 반면, methodValue는 호출할 때마다 로그가 출력돼.

반응형 데이터와의 자연스러운 통합

computed는 반응형 시스템과 밀접하게 연동돼 있어.
computed 값을 사용하는 컴포넌트는 자동으로 업데이트돼.
하지만 method를 사용하면 해당 메서드를 수동으로 호출해야 값이 갱신돼.

예시

<template>
  <div>Computed: {{ computedValue }}</div>
  <div>Method: {{ methodValue() }}</div>
</template>

computedValue는 count가 변할 때 자동으로 UI가 업데이트돼.
하지만 methodValue()는 수동으로 호출되기 때문에 더 자주 호출되고, 성능상 비효율적일 수 있어.

computed를 사용하는 이유와 장점

성능 최적화
- 캐싱 덕분에 계산량이 많은 작업에 효율적이야.
- 예를 들어, 대량의 데이터 필터링이나 복잡한 계산이 필요할 때 computed가 성능적으로 훨씬 유리해.
코드 가독성
- computed를 사용하면 상태와 로직을 더 선언적으로 작성할 수 있어.
- "이 값은 이 데이터를 기준으로 계산된다"는 의도를 코드에서 명확히 표현할 수 있지.
재사용성
- computed 값은 다른 computed나 watch에서 쉽게 재사용할 수 있어.
- 이런 재사용성은 복잡한 프로젝트에서 특히 유용해.
반응형 데이터와의 통합
- computed는 Vue의 반응형 시스템과 긴밀히 연결되어 있어.
- Vue가 알아서 데이터의 종속성을 추적해 업데이트를 관리해 주지.

요약

computed는 캐싱과 반응형 업데이트 덕분에 성능 최적화와 개발자 경험에 유리해.
method는 호출할 때마다 실행되기 때문에 간단한 작업에는 적합할 수 있지만, 복잡한 연산이 필요하거나 UI 업데이트와 밀접한 작업에는 computed가 훨씬 효율적이야.

composition API에서는 왜 setup에서 .value로 접근해야 할까?

dev_0hoon — Sat, 25 Jan 2025 08:55:59 +0900

createApp(){
	setup(){
    	const message = ref('hi');
        
        const changeMessge = () => {
        	message.value = 'hello';
        }
        
        return { message }
    }
}

ref가 없다는 가정하에 'hi'만 message로 초기화 할 경우 'hi'가 바뀐 것을 추적하려면 proxy같은 것이 필요하다.

https://dev0hoon.tistory.com/404

Vue 3 Reactivity - Proxy 소개

new Proxy()를 통해서 프록시 객체를 만들었다. 프록시란 값을 넣어 모방하는 객체라고 볼 수 있다. 가짜 객체와도 비슷한데 여기에서는 값을 사용할 때에 추가적인 동작을 할 수 있게 만들었다. v

dev0hoon.tistory.com

애초에 vue를 사용할 때 자연스레 reactivity를 사용하고 있어서 못느끼겠지만 사실 내부에서는 값이 바뀔 때마다 set(), get()을 해준다고 봐야한다. 그걸 ref() 함수로 대체했다는 것이 이해하기 좋다.

https://vuejs.org/guide/essentials/reactivity-fundamentals.html#why-refs

Vue.js

Vue.js - The Progressive JavaScript Framework

vuejs.org

vue.js3 공식 문서의 설명

const num = 0; x

const num = {
	value : 0,
    get() {
    },
    set() {
    }
}

위와 같은 모양이라고 보면된다.

vue3 컴포서블 사용, 디스터럭쳐링 문법

dev_0hoon — Thu, 23 Jan 2025 20:44:18 +0900

/composible/useMessage.js

import { ref } from "vue";

function useMessage() {
    //data
    const message = ref('hello');

    //methods
    const changeMessage = () => {
    message.value = 'hi';
    }

    return {message, changeMessage}
}

export { useMessage }



/App.vue

export default {
     setup() {
      const {message, changeMessage} = useMessage;


꺼내기가 가능하다.

위처럼 useMessage.message가 아닌 const에서 객체상태로 꺼낼 수 있는 것을 디스터럭쳐링 문법이라한다. es6에서 사용하는 문법이라고 한다.

위처럼 따로 js에 소스를 관심사 분리를 해두는것이 컴포서블 api인데 깔끔하지만, 나중에는 소스를 보기 위해 이 파일 저 파일을 옮겨다녀야 해서 비용이 많이 나가게 된다.

const obj = {
  a:10,
  b:'hi'
}

const {a,b} = obj;

이렇게 사용한다.