Built a small React reveal abstraction on top of GSAP – looking for architectural feedback

[theo-js]

Hi GSAP team,

I recently started using GSAP in a Next.js project and wanted to experiment with building a small declarative 'reveal' abstraction on top of it.

The goal was not to replace GSAP’s imperative model or the useGSAP() hook from @gsap/react, but to explore a declarative pattern for a very specific use case:

<Reveal animation="fadeUp">
   <div>Hello world</div>

</Reveal>

 

Under the hood:

• GSAP handles all animation logic

• No animation logic is reimplemented

• GSAP remains a peer dependency

• A single IntersectionObserver instance is used for performance

• Users can extend or override animation presets in a typed way

So this is not meant as a lifecycle hook alternative it’s more of a scroll-reveal DSL built on top of GSAP.

What I’d really like feedback on is:

• Does this kind of declarative layer conceptually align with GSAP’s design philosophy?

• Is relying on a singleton IntersectionObserver reasonable from a GSAP perspective?

I’m still fairly new to GSAP and want to make sure I’m not building something fundamentally misaligned before investing more into it.

If helpful for reviewing the architecture:  https://github.com/theo-js/-theo-js-react-gsap-reveal

Thanks for your time and insights !

[OSUblake]

Hey @theo-js

 

I love it!

There is no fundamentally correct "GSAP' way of doing anything. I've been rolling declarative GSAP animations since 2014, and not once I have ever been questioned about declarative vs imperative. Why? Because no-one else can tell the difference.

 

Think about a CSS `transition: all` command. Very declarative, but underneath the hood, there is a lot of animation magic the browser is doing.  Be that browser 😉


 

[Cassie]

Blake!! So nice to see you in the forums, that's made my weekend. I hope you're well?