react-native-shared-element icon indicating copy to clipboard operation
react-native-shared-element copied to clipboard

resize and align props don't work when used with "move" animation, on iOS

Open tberman opened this issue 4 years ago ā€¢ 12 comments

the resize property isn't working when using this from react-navigation-shared-element. I am running the most recent versions.

I have been trying to run the Example locally but running into all kinds of yalc issues.

Via some debugging/breakpoints I can tell that resize is definitely coming through into the shared element, but it doesn't appear to be respected (on iOS).

tberman avatar Sep 13 '19 21:09 tberman

If you go into the DetailsScreen.js inside https://github.com/IjzerenHein/react-navigation-shared-element-rn60demo and add resize: "clip" to the text animation, you can see that it doesn't do what I would expect there.

tberman avatar Sep 13 '19 21:09 tberman

Hey Todd. Could you maybe drop a video of it here so I can see whatā€™s going on?

As for the Example app, I must have accidentally committed the yalc deps to the package.json. Running ā€˜yarn add react-native-shared-element react-navigation-shared-elementā€™ in the Example app should fix that.

IjzerenHein avatar Sep 14 '19 05:09 IjzerenHein

https://cl.ly/3e7ec8c5182b is a screen recording that shows the issue. It is scaling the text, but I have changed it to add resize: "clip" to the text animation.

tberman avatar Sep 15 '19 00:09 tberman

Thx for the video. Iā€™m not quite sure whatā€™s going on, but it seems also not to do the ā€œfadeā€ animation as well. The resize and align props really only apply when ā€œfadingā€ from one element to another (e.g. to reveal more content without stretching). It does not apply to the default ā€œmoveā€ animation, which only renders the start element. It seems I have not documented this restriction yet. Could this be whatā€™s going on?

IjzerenHein avatar Sep 15 '19 07:09 IjzerenHein

Ah, so that is definitely what is going on. I changed the animation to move in order to trigger it.

That restriction isn't obvious and is kind of unexpected. Why wouldn't the resize mode and alignment not apply in the move case?

tberman avatar Sep 15 '19 15:09 tberman

Well, this is mostly due to a implementation detail in the iOS code. The android implementation doesnā€™t have that restriction, but has some other quirks with the align prop at the moment. Iā€™ve been working on the web implementation and once that is done, I will port that code structure back to the iOS and Android parts, which will resolve the first mentioned issue.

The reason I didnā€™t put any effort in this so far is that I believe that using the resize & align props, will not create a nice and convincing effect when using ā€œmoveā€. Move only renders the start element and can therefore not reveal any new content (except for image transitions). What kind of transition did you have in mind?

IjzerenHein avatar Sep 16 '19 18:09 IjzerenHein

So this transition is just moving text that is exactly the same size (but not in the same sized view), so both a fade or a move work fine (there is a separate issue related to how our app works re: datafetching that I will open up in another issue to get your thoughts on once I find a cogent way of explaining it).

The problem I was having is that a move should do what I want and the resize property was just not working, and in reading the docs it didn't mention that I had to change to fade to get it to do what I'd expect.

tberman avatar Sep 16 '19 18:09 tberman

Good point! Yes the docs are basic at this stage. More will follow, as well as more examples

IjzerenHein avatar Sep 16 '19 18:09 IjzerenHein

Long term, do you think this is a bug in the iOS implementation or expected behavior you'd like to document? (Going to clean up this issue so its useful for you but want to move it in the right direction)

tberman avatar Sep 16 '19 18:09 tberman

Well preferably I would like the code to have as little possible ā€œedgeā€ cases and just work where possible (even when the effect doesnā€™t necessarily makes sense). So yes, this can be considered a ā€œquirkā€. You may leave this issue open and I will close it when it is implemented on ios

IjzerenHein avatar Sep 16 '19 19:09 IjzerenHein

Thanks and very good job for making this open. @IjzerenHein

GodwinEbikwo avatar Sep 23 '19 13:09 GodwinEbikwo

Hi @tberman ! I'm Aleks and I'm here to help out a little bit with maintenance.

I realize it's been a while since this issue was updated, but I would love to make sure the problem you faced has been addressed. Since you opened your issue the example app has changed. I did a screen recording of some move and scale animations in the example app. Please let me know if that's the behavior you were looking for, or if there's still work to be done. The screen recording was done on an iPhone simulator.

https://user-images.githubusercontent.com/4152181/174501978-6b123fca-f52b-4969-a21a-e3009d8a6116.mov

p-syche avatar Jun 19 '22 22:06 p-syche

There's no activity in this issue so I'm closing it as stale.

p-syche avatar Jan 26 '23 12:01 p-syche