Skip to content

James Postadan | Oct2025-2 | Module Legacy Code | Sprint 1 | Hashtag slowing down my browser - #3

Open
japostadan wants to merge 3 commits into
mainfrom
issue-03-hashtag-flash
Open

James Postadan | Oct2025-2 | Module Legacy Code | Sprint 1 | Hashtag slowing down my browser#3
japostadan wants to merge 3 commits into
mainfrom
issue-03-hashtag-flash

Conversation

@japostadan

@japostadan japostadan commented Jun 16, 2026

Copy link
Copy Markdown
Owner

🎯 Summary

  • Fixed: navigating to a hashtag no longer causes the page to flash blank on and off
  • Root cause identified and eliminated — the hashtag view was triggering an infinite re-render loop
  • Added Playwright regression tests confirming exactly one API fetch per navigation and stable content

🧾 Changelist

  • Root cause: views/hashtag.mjs called apiService.getBloomsByHashtag() without awaiting it. When the fetch resolved, state.updateState() dispatched a state-change event synchronously, which triggered handleRouteChange()hashtagView() again → another fetch → and so on forever. destroy() is called at the top of every hashtagView invocation, so every iteration wiped the DOM blank before re-rendering — the blank flash visible to the user. Confirmed 53 fetches in 300ms in the red test.
  • Fix: guard the fetch on state.currentHashtag. If the state already reflects the requested tag (i.e. the view is re-rendering due to an unrelated state change), skip the fetch and re-render from existing state. One fetch per navigation; subsequent state-change-driven re-renders are read-only.
  • Tests: added tests/hashtag.spec.mjs with two Playwright regression tests — one that intercepts network calls and asserts exactly one fetch to /hashtag/** per navigation, and one that asserts heading and bloom content are visible and remain stable after settling. Red before the fix (53 fetches / blooms never appeared), green after. Full suite passes 16/16.

Questions

  • The broader architectural issue — every state change triggers a full page re-render via handleRouteChange — is noted but left out of scope. Should this be tracked as a separate issue, or is the current guard sufficient as a long-term solution?

🙌 Notes for Reviewers

The profile view wired the login handler to a click on a non-existent
[data-action="proxy.php?url=https%3A%2F%2Fgithub.com%2Fjapostadan%2FModule-Legacy-Code%2Fpull%2Flogin"] element, so the login form rendered on a profile
page had no submit handler. Submitting it triggered a native form POST
to the static file server (501 on python http.server, 405 on nginx)
instead of authenticating.

- Wire the profile-page login form to its submit event, matching the
  home login view (lib uses handleLogin which preventDefaults).
- Add a Playwright regression test: login -> view profile -> logout ->
  log back in from the profile page.
hashtagView called getBloomsByHashtag() without awaiting it. When the
fetch resolved, state.updateState() dispatched a state-change event,
which triggered handleRouteChange() → hashtagView() again → another
fetch → infinite loop. destroy() on every iteration caused the visible
blank flash.

- Guard the fetch on state.currentHashtag so we only fetch when the
  hashtag actually changes; re-renders triggered by unrelated state-change
  events skip the fetch and just re-render from existing state.
- Add Playwright regression tests: verifies exactly one fetch per
  navigation and that heading + blooms are visible and stable.
@japostadan japostadan self-assigned this Jun 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant