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

[FEATURE ios] Add Collapse implementation #135

Merged
merged 1 commit into from
Nov 30, 2018

Conversation

javamonn
Copy link
Contributor

@javamonn javamonn commented Nov 28, 2018

As part of ongoing Local Discovery work, we needed an animated Collapse implementation and wanted to extend the existing implementation in Palette. We ran into a couple issues while building this out:

  • react-spring has a peerDependency on react at >=16.4.0. It looks like it depends on React.forwardRef, a feature added in React 16.3. Emission is on 16.3.0-alpha.1 and appears to not have this feature, causing react-spring to throw an error. I'm opting to pin react-spring via resolutions in emission at 5.5 (the latest working version) rather than downgrade the version used in palette as we are in the process of upgrading React Native and could upgrade seamlessly in the future and there are some fixes to the height: auto animation used in the web implementation that we'd lose if we downgraded.
  • react-spring's height: auto animation target support doesn't work on RN, so we have to manually measure the view to derive a static height prior to animating. I cribbed much of this logic from react-collapsible. It looks like we could upstream this to react-spring based on the same logic used for web support: https://github.com/drcmda/react-spring/blob/master/src/targets/web/fix-auto.js

@artsyit
Copy link
Contributor

artsyit commented Nov 28, 2018

Deploy preview for artsy-palette ready!

Built with commit b01b004

https://deploy-preview-135--artsy-palette.netlify.com

@zephraph
Copy link
Contributor

This might be one of those cases where we can explore the idea of how we can share an interface across components. This is a really minimal case where open is the only prop served between both of them. I don't really see it as necessary, just raising the idea.

Thoughts?

@javamonn
Copy link
Contributor Author

This would be a good simple case to test out sharing an interface. My concern though is that we don't currently have a way to test it from the perspective of Emission, as we're still consuming only web types as noted here. I might open an issue for this along with a note about figuring out shared and disjoint component props interfaces.

@l2succes
Copy link
Contributor

Right, even before we get type safety on the emission side with respect to not exposing web types on RN components.
If we can figure out a way to share the Props interface between React native web and mobile we'd be in a good spot.

@artsyit
Copy link
Contributor

artsyit commented Nov 30, 2018

🎉 This PR is included in version 2.23.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

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

Successfully merging this pull request may close these issues.

5 participants