add transformOrigin style property

[lelandrichardson]

This PR was being discussed in this issue: #1964

I've decided to submit a PR just so that the conversation can have a bit more context with the code involved, etc.

transform-origin spec

How it works

the transform origin property works by defining a translation matrix T which translates to the desired origin, and transforming a transform matrix M into M' by the following formula:

M' = TMT^-1

This is accomplished in the precomputeStyle method and only introduces new code paths if the transformOrigin property is assigned.

Known Issues with this PR

1. The CSS spec interprets transform-origin: 0px 0px as placing the transform origin at the bottom left of the transformed element, where-as this code puts transformOrigin: { x: 0, y: 0 } to mean the center of the element (the default origin). This issue is difficult to remedy because in precomputeStyle, we don't have any knowledge of the width/height of the element in order to actually calculate what the "bottom left" of the element would be. For similar reasons, this makes it difficult to include other aspects of the CSS spec for this property, such as percentage values, etc.
2. The transform origin property allows for x, y, and z points. If we want to animate these values with the new animated API, a new AnimatedValueXYZ class would need to be created, or the existing AnimatedXY class should be extended. I've left untouched for now as the z property of transformOrigin is seldom needed.
3. The transform style property and the transformOrigin style property are not independent of one another, which mens that if we are animating one of them, the other must be included in the passed up style props to .setNativeProps. In order to accomplish this, a small check was added to the AnimatedStyle::getAnimatedValue() method. I'm open to suggestions on how we could potentially make this cleaner.

Example Usage:

                <Animated.View style={{
                    transform: [
                        {
                            rotateY: loading.interpolate({
                                inputRange: [0, 1],
                                outputRange: ['90deg', '0deg']
                            })
                        }
                    ],
                    transformOrigin: { x: -140, }
                }}>
                    ...
                </Animated.View>

[browniefed]

@lelandrichardson any more work on this?

[felixakiragreen]

👍

[azproduction]

typeof input === 'object' ?
Linter says that this code is not reachable.
@lelandrichardson could you fix? That is the only noticeable thing that stops this PR from being accepted.

[lelandrichardson]

@azproduction sorry for not seeing this sooner. I'm happy to fix this or anything else if that's all that's stopping it.

Do we feel like the other 3 issues I brought up are compromises we are willing to make at this time?

[azproduction]

I think it is important to have transform-origin CSS-compatible in order to avoid future collisions and misunderstandings.

By default, a layer's anchorPoint is (0.5, 0.5), which lies at the center of the layer

// Obj-C Fix
view.layer.anchorPoint = CGPointMake(0, 0);

Which could be applied somewhere here in React/Views/RCTViewManager.m

Or even we could make a separate property and avoid matrix math on JS-side. This also fixes 3-rd issue.

RCT_CUSTOM_VIEW_PROPERTY(transformOrigin, RCTTransformOrigin, RCTView)
{
  view.layer.anchorPoint = json ? [RCTConvert RCTTransformOrigin:json] : defaultView.layer.anchorPoint;
}

// RCTTransformOrigin and [RCTConvert RCTTransformOrigin] to be defined
// defaultView.layer.anchorPoint to be defined as CGPointMake(0, 0)

• We could use anchorPoint instead of multiplying matrixes in order to support % values (with the default value of 0, 0).
• Pixel values we could be casted to % using view.frame.

@vjeux any ideas how to fix it a better way?

[atticoos]

Currently struggling to animate around a specific point, this would be very helpful. Currently using a container to reposition the element I'd like to rotate around a point, and animating that container.

[danleveille]

Any updates on this? 👍

[satya164]

ping @lelandrichardson

[lelandrichardson]

@satya164 @danleveille I'm happy to bring this work up to date, but I don't want to waste the time if it will never get merged... Right now I think there are too many issues with this property diverting from the web spec. I'm hoping someone from the core team can comment on next steps or whether or not these differences are small enough to move forward with this PR.

[satya164]

cc @mkonicek

[mkonicek]

Maybe @sahrens has some context?

[satya164]

Closing since no activity on the PR. let's re-open if you wanna work on it again.

[stephensprinkle-zz]

👍

[sahrens]

There is still a lot of demand for this. Maybe we could just name it rn-transform-origin or something and get it in? Then we don't have to worry too much about deviating from the spec, and we can implement it correctly in the future without a collision.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. If you think this issue should definitely remain open, please let us know why. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. If you think this issue should definitely remain open, please let us know why. Thank you for your contributions.

[cinder92]

Any update on this?

[hramos]

This PR has been inactive for a long while, and does not seem to be on a path towards getting merged in. If anyone wants to take over, please do send a new PR.