4주차의 목표는 단순했다.
사람들이 글(포스트)을 더 잘 찾게 만들기.
근데 개발은 늘 그렇다.
검색 기능 추가는 쉬운데, 검색이 풀리지 않게 만드는 건 어렵다.
검색어를 넣고, 필터를 고르고, 정렬까지 선택해놓고
2페이지를 눌렀더니… 전부 초기화.
이건 사용자가 아니라, 개발자가 사람을 배신한 UX다.
그래서 이번 주는 기능보다 더 중요한 것—
문맥(context)을 지키는 검색 경험을 만드는 데 집중했다.
1) 어느 페이지에서 검색하든, 그 페이지에 남게 만들기
이번 주의 핵심은 이거였다:
/posts에서 검색하면/posts에서 계속 검색/feed에서 검색하면/feed에서 계속 검색/users/:id/favorites에서 검색하면 거기서 계속 검색
즉, 검색 폼이 한 곳에서만 작동하는 구조가 아니라
페이지마다 자기 길을 지키는 검색이 되게 했다.
이를 위해 뷰는 단단하게, 방어적으로 바꿨다.
@search_url이 있으면 그걸 쓰고- 없으면
request.path로 fallback
결과적으로 어떤 컨트롤러에서 렌더링하든
검색 폼은 길을 잃지 않는다.
2) 페이지네이션이 검색을 지우지 않게 만들기
검색 UX의 고전 비극이 있다.
2페이지 눌렀더니 검색이 풀렸어요.
이건 정말… 개발자 입장에서도 부끄러운 일이다.
Kaminari가 나쁜 게 아니다.
그냥 우리가 query parameters를 같이 넘겨주지 않았을 뿐.
그래서 pagination을 이렇게 고쳤다:
- 페이지 이동 링크에
request.query_parameters를 함께 유지
이제 사용자는
검색어, 필터, 정렬을 고른 채로
페이지를 넘겨도 그대로 이어진다.
검색은 일회성이 아니라 여정이 되었다.
문맥을 지키는 게 핵심이다.
3) Favorites 페이지도 검색/필터/정렬이 되게
찜 목록(favorites)은 사람의 취향이 쌓이는 곳이다.
여기서 검색이 안 되면, 찜은 그냥 창고가 된다.
그래서 favorites 페이지에도
posts index에서 쓰던 흐름을 그대로 가져와 적용했다.
- 검색
- 타입 필터
- 정렬(인기/가격/기본)
- 페이지네이션 유지
기본 정렬은 찜한 날짜순으로 두었다.
이게 가장 인간적인 정렬이라서.
4) Week 4에서 잡은 버그들
이번 주는 한 번 만들고 끝이 아니라
구석구석 다듬으면서 안정화도 같이 했다.
by_popularity가 likes를 세고 있던 걸 →favorites_count기반으로 수정
(성능도 좋아지고 의미도 맞아졌다)near_location거리 계산이 너무 단순했던 걸 → km 기준으로 보정
(SQLite 환경에서 현실적인 수준으로)apply_filters에서 pagination을 또 해버리던 이중 페이징 제거
(페이지가 이상해지는 그 찝찝함 해결)
5) 마지막은 테스트로 잠금
기능은 감으로 만들 수 있지만,
완성은 테스트가 한다.
favorites에서 검색/정렬/페이지네이션 파라미터 유지까지
통합 테스트를 추가했고,
전체 테스트도 모두 통과했다.
이제 4주차는 작동한다가 아니라
깨지기 어렵게 만들어졌다.
이번 주의 한 줄 회고
검색을 만들었다기보다,
사람이 길을 잃지 않게 표지판을 만든 주였다.
그리고 이상하게도,
이런 작업을 하고 나면
프로젝트가 조금 더 앱 같아진다.
사용자 입장에서 덜 짜증나고,
개발자 입장에서 덜 불안한 상태.
그게 곧, 다음 주로 갈 수 있다는 신호다.
개발자가 덜 불안한 상태. 그게 완성.