Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LottieWeb: Remove expressions eval, harden SSR check. #30872

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

CodyJasonBennett
Copy link
Contributor

Related issue: #29572 (closed #29572 (comment))

Description

Upstreams pmndrs/three-stdlib#415 and pmndrs/three-stdlib#398.

// Checks for SSR including partial DOM implementation and emulation.
// In these environments, Lottie should not be loaded or it can crash.
// https://github.com/pmndrs/three-stdlib/pull/398#issuecomment-2600778156
const isSSR =
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why isn't this something apps can't check before importing lottie loader? Something like:

if ( isSSR === false ) {

    const { LottieLoader } = await import( 'three/addons/loaders/LottieLoader.js' );

}

Copy link
Contributor Author

@CodyJasonBennett CodyJasonBennett Apr 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is because three/addons brings in LottieLoader when evaluated on the server side.

I can add a CI step for this, which is as simple as node examples/jsm/Addons.js.

The changes here aren't strictly necessary for SSR (completed in #26989), only environments that partially implement DOM APIs. I wouldn't be opposed to keeping it as-is, but I've seen requests from users who use mocking in testing environments or more modern runtimes that are headless.

// https://github.com/airbnb/lottie-web/issues/2828
// https://github.com/airbnb/lottie-web/pull/2833
// Bail out if we don't want expressions
function noOp(_value) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not ideal to modify library code in this way since if we want to update lottie_canvas, we have to apply the same fixes again. I understand the argument that lottie isn't properly maintained anymore but then we should consider to remove the dependency and the loader altogether.

LottieLoader isn't complex. Users should be able to call const animation = lottie.loadAnimation( { } ); on their own and then apply lottie's canvas to a CanvasTexture.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I volunteer to upstream any and all updates to/from Lottie Web for the next decade.

Does that really change anything, though? I don't think that's the problem.

Copy link
Contributor Author

@CodyJasonBennett CodyJasonBennett Apr 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see; maybe the class should be deprecated (or removed? how does this work for examples?) and the example updated to use CanvasTexture directly.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mrdoob originally added this loader. Let's see how he thinks about this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants