Feature: WE/Flux Sidebar Integration#603
Conversation
… init-community route
|
Warning Review limit reached
More reviews will be available in 36 minutes and 25 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
✅ Deploy Preview for fluxsocial-dev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
WE ↔ Flux Sidebar Integration
Branch:
feat/we-flux-sidebar-integration→ base:feat/postmessage-ws-proxyRepo:
coasys/fluxOverview
When Flux is embedded inside WE, the WE sidebar already shows all spaces — so Flux's own sidebar is redundant. This PR wires the two together: WE hides Flux's sidebar and drives its navigation, giving the user a single unified sidebar experience.
A companion PR in
coasys/we(see below) broadcastsNAVIGATE_PERSPECTIVEpostMessages when the user clicks a space. This PR is the Flux side that consumes them.Problem
Message Protocol
communityId= WE'sspaceId= Flux's routercommunityId. Both stripneighbourhood://from the shared URL, or use the raw UUID for local perspectives — no transformation needed on either side.Changes
app/src/app.tsHide sidebar on embed:
When
isEmbedded()is true, callsuiStore.setAppSidebarOpen(false)immediately after Pinia is ready, permanently collapsing Flux's sidebar so WE's unified sidebar is the sole navigation surface.NAVIGATE_PERSPECTIVElistener:Attaches a
window.addEventListener('message', ...)that filters fortype === 'NAVIGATE_PERSPECTIVE'and callshandlePerspectiveNavigation(communityId).handlePerspectiveNavigation:Looks up
communityIdinappStore.myCommunities, trying both the neighbourhood-prefixed key and theprivate://variant. If found, pushes the user to their last-remembered route for that community (viarouteMemoryStore), falling back to the community root. If the perspective exists but has no Flux community, redirects to the newinit-communityroute.Pending navigation queue:
If
NAVIGATE_PERSPECTIVEarrives before Flux finishes initialising, thecommunityIdis stored inpendingPerspectiveNavigation. After init completes, this is dispatched as the first navigation, replacing the default "go to last community" logic.app/src/router/index.tsAdds a single new route nested under the main layout:
app/src/views/main/InitCommunityView.vue(new)Shown when the user navigates in WE to a perspective that has no Flux community yet.
appStore.myPerspectivesby matchingcommunityIdagainst the strippedsharedUrlor raw UUID.createCommunity({ perspectiveUuid, name, client })from@coasys/flux-api, refreshesmyCommunities, then navigates to the new community.Edge Cases
NAVIGATE_PERSPECTIVEarrives before init completesinit-communityviewinit-communityshows "Space not accessible" error stateFiles Changed
app/src/app.tsapp/src/router/index.tsapp/src/views/main/InitCommunityView.vue(new)packages/ui/meta.json(build artifact bump, not for review)Companion WE PR
Branch:
feat/we-flux-sidebar-integrationincoasys/weThe sole functional change is in
SpaceStore.tsx:navigateToSpace()now callsbroadcastPerspectiveNavigation(spaceId)after updating the route, which queries allwe-iframeelements and posts{ type: 'NAVIGATE_PERSPECTIVE', communityId }to each. No schema or UI changes required on the WE side.