andrewprifer / framer-motion-theatre Goto Github PK

And think about other name changes while we can.

We are attaching mouse listeners for hover and click directly to the selectionTarget for now, mainly so that we can receive these events even when the gizmo is not active. This wouldn't be necessary if we used a more robust system that'd be aware of hover even when the gizmo becomes active during a hover. Attaching these listeners to the gizmo would allow us to block pointer events to the element so that when the gizmo is active, users can hover over them without activating the regular behavior of the selectionTarget. We can't do this as long as we need pointer events for our own listeners.

studio="auto"

With start and stop, it doesn't make sense to tie it to the lifetime of the provider anyway. If theatre wants to animate values, the ticker should just run.

For reference: https://github.com/solidjs/solid/blob/main/packages/solid/package.json

Currently we simply have two different entry points, 1 for dev, 1 for prod. Use the define config property and tree-shaking instead. Have a conditional config we can run twice for each target. This will scale better to when we want to alter things deeper in the import hierarchy anyway, like stripping UI code from createThreeGizmo().

https://tsup.egoist.dev/#conditional-config
https://tsup.egoist.dev/#compile-time-environment-variables
https://tsup.egoist.dev/#custom-esbuild-plugin-and-options

If treeshaking is not working, try the treeshake option which runs Rollup on the output:
https://tsup.egoist.dev/#tree-shaking

This would have the advantages that

• Events wouldn't be blocked by overlapping elements
• Outline of the gizmo wouldn't be distorted by scaling
• Gizmo won't be removed by rerendering the children of the selection target

Disadvantages:

• Rectangles only, won't be conforming that well to the shape of the target, e.g. in the case of skew or rotations
• Maybe slower?