Sheffield | 25-SDC-Nov | Sheida Shabankari | Sprint 1 |New Feature: Rebloom #122
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.
-[x] I have titled my PR with Region | Cohort | FirstName LastName | Sprint | Assignment Title
Briefly explain your PR.
✨ Re-bloom Feature Implementation
This PR implements the Re-bloom feature in the Purple Forest application, allowing users to reshare blooms while keeping a clear distinction between original blooms and reblooms. The feature covers backend data modeling, API endpoints, state management, and frontend UI changes, aligning with the architecture of the application.
Users can re-bloom an existing bloom by pressing a new Re-bloom button.
A rebloom adds the bloom to the user’s feed and their followers’ feeds as if they posted it themselves, but it clearly shows:
Original author of the bloom
User who rebloomed it
Each bloom displays rebloom count and last rebloomed timestamp when applicable.
Profile pages continue to display only original blooms; reblooms are shown only in the Home Feed.
A new table reblooms was created to track reblooms:
Column Type Notes
id bigint Primary key
original_bloom_id bigint Foreign key to blooms, not null
rebloomed_by integer User ID who performed the rebloom, not null
rebloomed_at timestamp without timezone Timestamp of rebloom, default CURRENT_TIMESTAMP
Unique constraint ensures a user cannot rebloom the same bloom twice.
Endpoints added:
POST /rebloom/<bloom_id> → creates a rebloom if it doesn’t exist for the user
GET /reblooms/user/ → fetches reblooms made by a specific user
Bloom data model updates:
Added optional fields: rebloomer, rebloom_count, last_rebloomed_at
New backend functions:
has_user_rebloomed(original_bloom_id, user_id) → checks if user already rebloomed
add_rebloom(original_bloom_id, user_id) → inserts a rebloom record
get_reblooms_for_user(username) → fetches all reblooms by a user as Bloom objects
Feed query updates:
get_blooms_for_user now includes rebloom count and last rebloom timestamp
Reblooms are merged into the feed and ordered by their rebloom timestamp for proper timeline display
Timeline component (timeline.mjs):
createBloomWithRebloom() renders rebloom info if available: rebloomer, count, and timestamp
Adds a Re-bloom button to each bloom that supports reblooming via event delegation
Home view (home.mjs):
Listens for rebloom button clicks
Calls API to perform rebloom and refreshes timeline and profile state
API service updates:
rebloom(bloomId) function handles rebloom requests and updates state accordingly
State is updated via central state object, following the existing SSOT and unidirectional data flow.
Reblooms trigger state-change events to automatically re-render the Home Feed.
New database table to track reblooms
API endpoints for creating and fetching reblooms
Bloom model updates to include rebloom metadata
Feed and timeline rendering now supports rebloom information
Frontend event handling for rebloom actions
Profile pages unchanged – reblooms excluded
This implementation ensures a clear distinction between original blooms and reblooms, preserves original content, tracks rebloom counts, and integrates seamlessly with the existing Purple Forest SPA architecture.