consolidate loop logic

[dagda1]

One thing that frustrates me about gsap is that the answer to forum questions is often a big mush of pretty illegible code like the loop function in this.

I find this loop code in lots of answers, the code is not well-formatted and very hard to read.  Worse than that, it is slightly different more times than not depending on the context.

I think having this big slab of code as the answer is a bad answer and does not educate anyone on how to get the best of gsap.

 

Could this loop be turned into a primitive or something to stop this copy-whack of code to cure problem that is happening?
 

[Cassie]

Hey! Are you talking about this helper function?

https://gsap.com/docs/v3/HelperFunctions/helpers/seamlessLoop

 

As Jack mentions here

Quote

 

I didn't write the helper function with the goal of folks totally understanding everything in there - I wrote it mostly to simply provide the functionality and be efficient, so don't feel like you've gotta dissect it and understand every piece. Most helper functions are for people who are like "I need _____ but I can't figure out how to do it on my own...does GreenSock have something that could help?" 

 

So you can just copy/past the helper function and call it, feeding in whatever parameters it needs. Done. 

 

loops/sliders are pretty fiddly and over time people have asked for all sorts of functionality to be added - looping, skipping back and forwards and to an index value, highlighting the current index - this is all logic, not GSAP. So due to the number of people that asked for help and the complexity of the problem, it's wasn't really feasible for us to spend hours breaking this down in every forum post. That's why the helper exists - so that people would be able to just drop it into their projects.

I can totally see how this code could be super frustrating if you're not just trying to use it outright. If you were trying to understand and reverse engineer something from it that could be confusing.

FYI - @GreenSock Someone else (an Awwwards dev) was trying to reverse engineer it and did mention it was hard to read the other day too, so maybe it's worth looking at?

 

Quote

Worse than that, it is slightly different more times than not depending on the context.

In terms of it being slightly different in different answers, yep, The forums will obviously be full of slightly different answers as  people have different needs and have asked at different times. Some forum responses are years old. Some answers would have been written before the helper function existed, or as it was being built. The helper function on that page is the source of truth though.

More importantly though - How can we help here? What problem are you currently trying to solve? Are you struggling to figure out a specific coding challenge, struggling to use the helper, finding it difficult to adjust it to your needs? Let me know and we can try and find a way forward 💚

I just want to highlight that this is by no means the only way to loop objects, it's just the most bulletproof solution that covers the most use cases and features.

For example here's an example of a simpler loop using modifiers in case that helps?

See the Pen rNJNMGK?editors=1010 by PointC (@PointC) on CodePen

 

 

 

[GreenSock]

Yep, @Cassie is exactly right. Seamlessly looping elements is a lot more complex than most people imagine. It has nothing to do with GSAP - it's just a lot of logic stuff. 

 

In the early days, I'd see folks initially set up their markup/CSS so that all the elements were directly on top of each other and they'd apply a transform (x) to spread them out. Then, it'd be simple enough to animate their "x" value by the combined total width, and use a modifier with a gsap.utils.wrap() because they'd all wrap at exactly the same spot. Easy-peasy. But what if you just want to set up your stuff in the normal document flow instead of putting them on top of each other and using transforms to spread them out? Now they'd all wrap at different spots (x-wise). What if you want it to be responsive? What if you need snapping and draggable functionality with inertia? It becomes very tricky fast. 

 

Since we saw so many people struggling with that, we invested the time as a courtesy to come up with that plug-n-play helper function. It solves a ton of challenges. It was never intended to be something that everyone could read through and totally understand. It takes a lot of explaining to really get it all. I generally write code in a way that prioritizes performance and minimal file size.  

 

And yes, the code has evolved over time. It started out one way, and then we'd get requests for various features so we'd add those. Like centering things, draggability, inertia, etc. I wonder if you just came across forums posts that represented various stages of that evolution. That's also why we have all the helper functions in an official spot in the docs, so you can always just go there to get the latest/greatest. 

 

I hope it helps! Let us know if you need assistance with something in particular. 

[dagda1]

I'm definitely not denying it is complex but I still think the code lacks readability and rather than just blindly copy and pasting this code (which I have done :).

 

If people understood it, then maybe they would post fewer support questions.

 

I would like to understand it but the way it is written makes that hard.

 

Would it be possible to get a typescript version of the seamlessLoop?

I've tried to type it and it is not easy.  Performant code does not have to be illegible.
 

 

[GreenSock]

No, we don't have a TypeScript version of that, sorry. 

 

If you've got specific questions about parts of the code, I'd be happy to do my best to explain.