Submitted 6 months agoA solution to the Manage landing page challenge
Manage landing page
accessibility, pure-css
@Em3ka

Solution retrospective
What are you most proud of, and what would you do differently next time?
š§ This project was loads of fun and frustrating in some instances, but here are the highlights of what I learnt.
- Detecting ResizeObserver overload issues early.
- Spotting race conditions in form validation logic.
- Recognizing when requestAnimationFrame isn't sufficient alone.
- Separating UI state updates from expensive DOM work.
- Applying visual classes immediately to prevent flicker.
- Throttling layout recalculations for performance.
- Understanding event sequencing across input, blur, and submit.
- Avoiding shared state pitfalls by recalculating values when needed.
- Applying requestAnimationFrame with proper timing awareness.
šļøGlide edge case
- I faced issues like disappearing slides, misaligned peeks, and incorrect start positions.
šRace condition in form validation
- I relied on a shared currentError across input, blur, and submit, which led to inconsistent validation states.
ārequestAnimationFrame timing issues
- Using rAF delayed the application of
.resizing, which led to visual glitches (e.g., nav briefly flashing). This caused a lot of headaches.
šÆ My solution:
I separated the visual state change (adding .resizing) from expensive work (running syncOverlay()). I still debounced the expensive work, but the visual state is applied immediately, preventing flicker.
All constructive feedback is welcome. š
Code
Loading...
Please log in to post a comment
Log in with GitHubCommunity feedback
No feedback yet. Be the first to give feedback on Em3ka's solution.
Join our Discord community
Join thousands of Frontend Mentor community members taking the challenges, sharing resources, helping each other, and chatting about all things front-end!
Join our Discord