omarel

Right, trying to access the DOM outside of useEffect could throw errors because the DOM may not be loaded so I can't test if doing DOM manipulations outside of useEffect causes the same error from above. Ultimately I haven't been able to reproduce the same error from above with the Scroll Trigger registerPlugin outside of useEffect, but the error is resolved with your suggestion either way!

Well DOM manipulations and other side effects in react should be done inside the useEffect(). Perhaps that’s the core of the error with gsap manipulations happening outside useEffect with React…

I do appreciate the fix. Just a note: I did test adding properties to the body tag but it doesn't throw any error though. So perhaps worth looking into the cause of the console log error with registerPlugin at the top: useEffect(() => { //testing adding css to body - no console log errors document.body.classList.add("test-class"); document.body.style.color = "red"; //moving registerplugin to useeffect fixes console log error gsap.registerPlugin(ScrollTrigger); let ctx = gsap.context(() => { gsap.fromTo( h1Ref.current, { opacity: 0, }, { opacity: 1, duration: 3, } ); }); return () => ctx.revert(); }, []);

That did remove that error, but I haven't tested if scroll trigger actually works when the registerPlugin placed in the useEffect as I've never placed it there. Can I assume so?

The error happens only with the scroll trigger import not gsap. I didn’t know it was possible to place the plug-in registration in useEffect. I’ll try that and report back on the thread.

I guess you haven't seen it yet. Updated the link once again. I was able to access it logged out: https://codesandbox.io/p/github/oelbaga/nexts13.4_gsap_scrolltrigger_bug/main "use client"; import { useEffect, useRef, useState } from "react"; import Image from "next/image"; import styles from "./page.module.css"; import { gsap } from "gsap"; //importing gsap scrolltrigger throws console log error import { ScrollTrigger } from "gsap/ScrollTrigger"; gsap.registerPlugin(ScrollTrigger); export default function Home() { const tl = useRef(); const h1Ref = useRef(); useEffect(() => { let ctx = gsap.context(() => { gsap.fromTo( h1Ref.current, { opacity: 0, }, { opacity: 1, duration: 1, } ); }); return () => ctx.revert(); }, []); return ( <main className={styles.main}> <h1 ref={h1Ref}>Hello World</h1> </main> ); } Scroll Trigger import error: Warning: Extra attributes from the server: style

I updated the codesandbox share link. It should work now. I mistakenly placed in the codepen area. This is a client component, not server component.

Hi I'm testing using scrollTrigger in NextJS 13.4 app directory where all components are server side first but this component is specified as a client component. For some reason, the simple importing of ScrollTrigger has a significant console log error. Whenever I remove the ScrollTrigger import the error goes away. Can we look into this? Sandbox: CodeSandbox Test by looking at the console and hide and unhide the import: import { ScrollTrigger } from "gsap/ScrollTrigger"; gsap.registerPlugin(ScrollTrigger); Produces the console log error: Warning Extra attributes from the server: style

The repo above was done in Next 12. So the first step I would do is take the repo above clone it on Next 13 as is and see if it works. Then if it does you know it works in 13 then you can move into debugging your own project.

There shouldn’t be any difference in using gsap with Next 13 app directory as far as I’m aware. The only thing is Next 13’s app directory uses React server components by default until you mark a component as client. You can’t use gsap in server components since server components do not allow useEffect() which gsap with React relies on. So use it in the components marked as client. (Also worth noting Next 13’s app directory is still in beta)

Firstly thank you Greensock for taking initiative on this! Just a question regarding this new feature to solve the double render issues: Is there any difference between the new context and @Cassie original solution in this thread to use immediate render false and .kill() on the animations. I love that we now have a more specific way to solve for this but just wondering if there’s any more differences with using .context() and .kill()? Because I notice with context you have to wrap all your gsap code in it whereas with .kill() you can just return it in the useEffect hook itself directly.

@Cassie Of course, but with React 18 running into these issues threw us off. Maybe just bad timing. 3.10 and React 18 nearly on the same day! I realize there are all these conditionals to go around mentioned above but simply not worth it for a basic .from fade in I can't speak for all devs but we want it to be simple as gsap is meant to be used. I did a fade in test with react 18 using Framer Motion and no issues. (updated the demo with framer motion) You are correct .to didn't give us an issue I updated the demo. I think the reliability of knowing either .from or .to works the same is important though. Certainly gsap is amazing and a lot to offer, I think Greensock should consider evaluating mitigating some of these issues thoigh. We will still use GSAP and see if we run into too many more issues with React 18. Ive already seen a few with ScrollSmoother I'll use other threads for but still testing. Dan did mention some potential workarounds for the GSAP API such as below. Thanks again. I really do love GSAP and what it has to offer. We'll figure it all out and work around what we can.

Thank you @GreenSock. If this does become part of the map to smooth out double calls I would love to look out for a future release or documentation. We would love to use GSAP with React 18 @gaearon I suppose this is more of a react question but related to the gsap implementation. Is the double invoking issue in the demo related to reactstrictmode being on or the keep alive feature. If reactstrictmode, the docs say reactstrictmode only runs in development. So can I understand if we technically ship an app to production this double invoking in the initial demo would not occur within the React app? Wont be realistic way to debug animations in development, but am curious. https://codesandbox.io/s/proud-dawn-uic35x Also, can we assume in React 18 that any useeffect in our demos even when called (with an empty dependency array) can now run more than once and is this tied to using ref?

@OSUblake I don’t think the issue is happening with only .from. I believe more tweens have the issue if I play with it more. I’ve seen it with .to I can create some demos. I did think @Cassie solution was pretty darn elegant while keeping reactstrictmode on and thank you @gaearon for all the wonderful specifics of exactly what's happening! It does seem like a more organic fix from Greensock is warranted in due time with some more analysis so that we don’t have to do all these conditionals. and some analysis on why some tweens get affected and others don’t with React 18. We just released a project with React 17 and gsap and didn’t see any of these issues. I’m so excited about the latest gsap 3.10 release and appreciate the hard work! I just so happened to see this while playing witb the latest 3.10 gsap release on the latest React because we always create new apps with the latest versions of react.