[Phase 2] feat(fe): 지도 매물 API 연동 및 마커 표시 - #12
Merged
Conversation
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (4)
📝 WalkthroughWalkthroughPhase 2 of the property map frontend replaces the static mock store and SVG map with a live Naver Maps integration. New files add an Axios HTTP client, property API helpers, and a memoized Naver Maps SDK loader. The Pinia store is rewritten with API-driven state and request-sequencing to guard against stale responses. ChangesPhase 2: Property Map Frontend
Backend CORS Configuration
Environment Configuration
Sequence Diagram(s)sequenceDiagram
actor User
participant MapExplorer as MapExplorer.vue
participant naverMaps as loadNaverMaps
participant mapStore as Pinia mapStore
participant propertiesAPI as properties.js
participant SpringBoot as Spring Boot API
rect rgba(100, 149, 237, 0.5)
note over MapExplorer,naverMaps: Map initialization on mount
MapExplorer->>naverMaps: loadNaverMaps()
naverMaps-->>MapExplorer: window.naver.maps
MapExplorer->>MapExplorer: new Map(container, { center, zoom })
MapExplorer->>MapExplorer: map.addListener("idle", onIdle)
end
rect rgba(144, 238, 144, 0.5)
note over MapExplorer,SpringBoot: Property fetch on map idle
MapExplorer->>mapStore: setBounds(map.getBounds())
MapExplorer->>mapStore: fetchProperties()
mapStore->>mapStore: requestSeq++, isLoading=true
mapStore->>propertiesAPI: fetchProperties(bounds + filters)
propertiesAPI->>propertiesAPI: cleanParams(merged)
propertiesAPI->>SpringBoot: GET /api/v1/properties?...
SpringBoot-->>propertiesAPI: { data: { data: [...] } }
propertiesAPI-->>mapStore: properties[]
alt requestSeq matches current
mapStore->>mapStore: properties=data, totalCount
else stale response
mapStore->>mapStore: discard
end
mapStore-->>MapExplorer: filteredProperties updated
MapExplorer->>MapExplorer: clear markers, render new markers
end
rect rgba(255, 165, 0, 0.5)
note over User,SpringBoot: Property selection and detail load
User->>MapExplorer: click marker or list item
MapExplorer->>mapStore: selectProperty(id)
mapStore->>mapStore: isDetailLoading=true
mapStore->>propertiesAPI: fetchPropertyDetail(id)
propertiesAPI->>SpringBoot: GET /api/v1/properties/{id}
SpringBoot-->>propertiesAPI: { data: { data: {...} } }
propertiesAPI-->>mapStore: property detail
mapStore->>mapStore: selectedProperty=detail, isDetailLoading=false
mapStore-->>MapExplorer: selectedProperty updated
MapExplorer->>MapExplorer: map.panTo(coords), show detail panel
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related issues
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
phases/property-map-fe/phase2-property-map-fe.md (1)
27-28: ⚡ Quick winClarify the initial map bounds and seeded data behavior.
The implementation instruction to "Keep the initial map centered around the seeded Seoul property data" lacks specificity. It should clarify:
- What map bounds and center coordinates define "seeded Seoul property data"?
- What happens if the backend returns no seeded properties (fallback bounds)?
- Should the map pan/zoom to fit the seeded data, or is a fixed initial viewport sufficient?
This will help implementers avoid ambiguity and ensure consistent behavior across deployments.
📝 Suggested clarification
-Use `VITE_API_BASE_URL` for the Spring Boot base URL and `VITE_NAVER_MAP_CLIENT_ID` for the browser map SDK. Keep the initial map centered around the seeded Seoul property data, then fetch by map viewport after the SDK is ready and whenever the map becomes idle after movement or zoom. +Use `VITE_API_BASE_URL` for the Spring Boot base URL and `VITE_NAVER_MAP_CLIENT_ID` for the browser map SDK. Initialize the map with a default viewport centered on Seoul (e.g., 37.5665, 126.9780 with an appropriate zoom level). After SDK readiness, fetch properties by map bounds and continue fetching whenever the map becomes idle after movement or zoom. If a "seeded" initial property set should be displayed before user interaction, define those bounds explicitly in the store constants or accept them from an environment variable.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@phases/property-map-fe/phase2-property-map-fe.md` around lines 27 - 28, The implementation instruction in the phase2-property-map-fe.md file needs to be clarified regarding the initial map setup behavior. Update the instruction that mentions "Keep the initial map centered around the seeded Seoul property data" to explicitly specify the exact initial map bounds and center coordinates for Seoul, define the fallback map bounds to use if the backend returns no seeded properties, and clarify whether the map should dynamically pan and zoom to fit the seeded data bounds or use a fixed initial viewport. This will eliminate ambiguity for implementers and ensure consistent behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@frontend/src/store/mapStore.js`:
- Around line 46-47: The issue is that detail requests can complete out of
order, causing older responses to overwrite newer selections or repopulate
selectedProperty after the panel is closed. Guard against stale responses by
using the requestSeq field already initialized in the store state. Increment
requestSeq each time a new detail request is initiated in the selectProperty
action or method, pass this sequence number with the request, and only update
selectedProperty if the response's sequence number matches the current
requestSeq value. This ensures only the most recent request's response updates
the state while stale responses are ignored.
In `@frontend/src/utils/naverMaps.js`:
- Around line 21-27: The code does not check if the existing naver-map-sdk
script tag has already finished loading or failed, causing event listeners to
never fire on already-settled scripts, leaving the loader pending indefinitely.
Additionally, failed loads keep a rejected memoized sdkPromise that prevents
retries in the same session. Check the script's readyState property and whether
window.naver.maps exists when the existing script is found to resolve or reject
immediately instead of waiting for events. For failed loads, reset the memoized
sdkPromise to null before rejecting so subsequent calls can attempt a fresh
load. Apply the same logic to the new script tag creation section around lines
33-45 to ensure consistency.
In `@frontend/src/views/MapExplorer.vue`:
- Around line 125-133: The article element in the v-for loop with the
`@click`="store.selectProperty(property.id)" handler is not keyboard-accessible
because it lacks focus management and keyboard event handlers. Add tabindex="0"
to make the article element focusable, then add `@keydown.enter` and
`@keydown.space` event handlers that call the same
store.selectProperty(property.id) method to enable keyboard users to select
properties using the Enter or Space keys.
In `@phases/property-map-fe/phase2-property-map-fe.md`:
- Around line 6-12: Add the missing `frontend/pnpm-workspace.yaml` file entry to
the Files section in the phase2-property-map-fe.md document. Include this file
in the list alongside the other configuration and API setup files (such as
`frontend/.env.example` and the API helpers) with a brief description indicating
it corrects the frontend pnpm workspace settings, as referenced in the PR
objectives.
---
Nitpick comments:
In `@phases/property-map-fe/phase2-property-map-fe.md`:
- Around line 27-28: The implementation instruction in the
phase2-property-map-fe.md file needs to be clarified regarding the initial map
setup behavior. Update the instruction that mentions "Keep the initial map
centered around the seeded Seoul property data" to explicitly specify the exact
initial map bounds and center coordinates for Seoul, define the fallback map
bounds to use if the backend returns no seeded properties, and clarify whether
the map should dynamically pan and zoom to fit the seeded data bounds or use a
fixed initial viewport. This will eliminate ambiguity for implementers and
ensure consistent behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 8eb570a9-6088-4a0a-9a46-78c8c1caba9f
📒 Files selected for processing (9)
frontend/.env.examplefrontend/pnpm-workspace.yamlfrontend/src/api/http.jsfrontend/src/api/properties.jsfrontend/src/assets/main.cssfrontend/src/store/mapStore.jsfrontend/src/utils/naverMaps.jsfrontend/src/views/MapExplorer.vuephases/property-map-fe/phase2-property-map-fe.md
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.env.example (1)
12-14: ⚡ Quick winReorder Supabase variables to follow alphabetical key ordering.
The dotenv-linter rule
UnorderedKeyflags thatSUPABASE_DB_PASSWORDshould appear beforeSUPABASE_DB_URLto maintain consistent alphabetical ordering within grouped configuration sections.🔧 Proposed reordering
# Spring Boot datasource. Use the Supabase PostgreSQL JDBC connection string. # Example: # SUPABASE_DB_URL=jdbc:postgresql://aws-0-ap-northeast-2.pooler.supabase.com:6543/postgres?sslmode=require -SUPABASE_DB_URL= -SUPABASE_DB_USERNAME= SUPABASE_DB_PASSWORD= +SUPABASE_DB_URL= +SUPABASE_DB_USERNAME=🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.env.example around lines 12 - 14, Reorder the three Supabase database configuration variables in the .env.example file to follow alphabetical ordering. The variables SUPABASE_DB_URL, SUPABASE_DB_USERNAME, and SUPABASE_DB_PASSWORD should be rearranged alphabetically by their full key names so that SUPABASE_DB_PASSWORD appears first, followed by SUPABASE_DB_URL, and then SUPABASE_DB_USERNAME to comply with the UnorderedKey linting rule.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.env.example:
- Around line 12-14: Reorder the three Supabase database configuration variables
in the .env.example file to follow alphabetical ordering. The variables
SUPABASE_DB_URL, SUPABASE_DB_USERNAME, and SUPABASE_DB_PASSWORD should be
rearranged alphabetically by their full key names so that SUPABASE_DB_PASSWORD
appears first, followed by SUPABASE_DB_URL, and then SUPABASE_DB_USERNAME to
comply with the UnorderedKey linting rule.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: a4c456b4-eef2-4682-92ae-e5586f33a02e
📒 Files selected for processing (2)
.env.examplefrontend/.env.example
✅ Files skipped from review due to trivial changes (1)
- frontend/.env.example
HOKAGO-MEMORIES
changed the title
This was referenced Jun 22, 2026
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
변경 내용
연결 이슈
closes #11
테스트
환경 변수
Summary by CodeRabbit
VITE_API_BASE_URLand Naver Maps client guidance.