Jump to content
Search Community

AndreWAY

Members
  • Posts

    6
  • Joined

  • Last visited

Posts posted by AndreWAY

  1. Yeah, i've tried a lot of solutions posted by other people. The solution provided in the link above only works if you want to load GSAP via CDN.

     

    For this project we are using loadable components (https://loadable-components.com/). So basically we only want to load GSAP for components that are using it. The example code provided on the installation page works in every component.

     

    Then, for SSR you need to check if the code is running on the client or server:

    gsap-install-ssr.thumb.png.e033542be3de90dcf21354600de70b50.png

     

    That's why the hasWindow check is implemented. Which looks like this:

    haswindow.png.dd6b5822020d1bb41dd00ffd9c5c1ed2.png

     

    So the gsap.registerPlugin function should not be called when running on the server? But it is, so am I missing something here?

  2. I'm trying to upgrade a GSAP v2 integration in a large codebase to GSAP v3.

    Instead of one global import for GSAP + plugins, I've created feature imports like in the installation examples from the documentation:

     

    gsap-import.thumb.png.16f9006cf018c39352dcbbf6d33d15f0.png

     

    This is working fine in a (local) Webpack dev-server environment. However when i'm generating Webpack SSR production builds it seems like non compatible SSR code is leaking from the imported GSAP modules. Even with the client/server check when registering plugins.

     

    ssr-gsap.thumb.png.3731b9a1b7f98ed34c990f45f8826e93.png

     

    I'm running this generated SSR bundle on a IIS environment with a V8 engine for processing the SSR javascript.

    Has anyone encountered the same behaviour? If so, any help is much appreciated! 

×
×
  • Create New...