How to fix your front-end visual bug (StackOverFlow Inspired).

2026 Day 174. #TechDays.

I have been trying to dynamically load some Medium articles on my website. I took the feed and polled it on each website load to get the latest articles that I have posted. I also had a fallback component displaying “Unable to load content at the moment” in case it the dynamic generation fails. Everything looked fine at this point.

During my local front-end development I made the component purposely fall back to the failure component because there were simply too many refreshed and I did not to keep polling it all the time. Just below the component I had a GSAP animation based on ScrollTrigger with scrub enabled.

With the failed component, the timing of the animation felt really off. This was a reusable animation that was playing around with some text. the other sections worked fine and I could only see the issue here. Like any developer today I started writing a prompt to find a solution.

I have a reusable component that animates text. I have used this exactly 4 times in my website.

3/4 times it works perfectly. I am trying to figure out why it does not work one time.

The issue as I have found so far is the misplacement of the trigger. With the gsap markers:true I was able to see that the start and end position are exactly the same for each component (as expected). The placement of the trigger is at the top of the div for 3/4 and at the bottom of the div for the problematic one.

To promote reusability I only pass the sentence that I want to animate. Everything else about the component remains the same.

The issue as I perceive lies with the div just above the problematic component. The div above pulls in data from an rss feed everytime the website loads. If this feed does not load correctly it displays only the one default item instead of 5. I believe this decrease in layout at runtime is causing the misplacement of the trigger.

Since this is the last such animation I cannot confirm if all animations after this are affected.

Assuming this is the issue, what can I do to solve this?

I assume the issue has to do with the useLayoutEffect that renders the animation or the ScrollTrigger plugin itself.

(prompt was edited for spelling mistakes and grammatical issues.

A fairly large, detailed prompt that instantly gave me the solution. The fun part is I had only planned the first 3 lines. The rest came to me as I thought about the problem in detail and much more clearly. I had arrived at the root of the problem correctly, I just did not know how to go about solving it.

The prompt was not intended as a prompt but the most accurate description of a problem on StackOverFlow. I wrote down everything that I could see, and perceive from the issue. Based on my observations I had singled out two problems that could have been the root cause and one of them was indeed the problem.

This prompt is a step by step explanation of how to go about solving this problems.

State the Problem.

The problem was painfully obvious and I tried to describe it as succinctly as possible. I try to keep it as simple as possible so the focus moves away from how complex a problem is and more on how the smallest change could fix it.

Do some debugging via tools, logging, print statements (console.log for web dev) to understand the problem better.

I prefer using GSAP for my animations. There is a built in option called “markers”. This allows you to view exactly where you requested animation will start playing and how long it will play for. Works best when you have a scrub based ScrollTrigger animation with a specified start and end position.

The issue becomes clear, and now let it settle in your brain for a second.

Being able to compare a working state to a defective state I was able to recognise the issue. The animation trigger was on the top of the div for 3/4 examples and somewhere close to the bottom for the last one. This is what was messing up the entire animation for me. Since all of the animations were essentially the same component with a different text, it made sense that the problem was the placement of the trigger.

Only when you have fully understood the issue can you go about fixing it.

Now I wen

If there are more than one possible causes try them in the order or ease of implementing it.

As recommended by my LLM, the issue was ScrollTrigger. It calculated the placement of the animation trigger based on the height of the div above it. Because of changes in the size the height of the div got shorter and the components below it filled up the space. The trigger however did not move as its position had already been calculated.

The simple fix was to refresh the ScrollTrigger calculations once the dynamic component had finished coding.

gsap.registerPlugin(ScrollTrigger);

useEffect(() => {
  if (!isLoading) {
    requestAnimationFrame(() => {
      ScrollTrigger.refresh();
    });
  }
}, [isLoading, items.length]);
// this is what the LLM gave me. I had to do some modifications to adpat i

This was more or less the entire fix. The entire process reminded me of how things used to work at StackOverFlow.

A good question would involve a person stating their issue, followed by their trials and errors in fixing it, some context for other solvers, and people would recommend some solutions based on this. It was a fairly straightforward process and working with LLMs is exactly like this. The response time has virtually gone down to 0, but the overall accuracy can be questioned. With more context the LLM does tend to answer more reliably but it is still an major upgrade than waiting for possibly weeks for a solution.

This method of writing a prompt has two benefits.

1. You are doing some actual thinking. You are not vibe-coding a solution, vibe-finding and issue, and then vibe-debugging the issue. This saves context, time, tokens, and patience. It also helps your brain stay a little more active as it is being utilised rather than relying completely on an LLM. The ability to think and act individually is what makes us human. If we start relying entirely on computers, we might as well give up on living entirely. Understanding problems fixing them at the core or working around them is what the majority of software engineering has been. Writing code is definitely simpler, but debugging is where most people would get caught off guard. You have to understand the issue, try out a solution or two, know why or why it did not work and do this fairly quickly to keep up a productive pace. This will separate out the coders in the future.
2. You get to your answer quickly. Structured explanations, accurate and appropriate description of the problems, and detailed context help single out a lot of the issues quickly. This saves you time and tokens by not having to write multiple prompts for the same issue.

Think out your problems clearly before attempting a fix. The solution may be simpler than you imagine.

See you tomorrow.