Road to 1.0 (request for comments)

[oblador]

I'm taking up development of this repo again of this package after a long silence in belief that this should be solved at the navigation level. I've been convinced that there still use cases for this package after all and my hopes of navigation libraries properly supporting shared element transitions hasn't really been fulfilled.

Since there has been a lot of developments in the React Native community (such as Android support, native animation driver etc) since the inception of this package, I'll be starting over from a clean slate. API will most likely change, but will keep backwards support when possible/sane. Before starting it'd be nice to hear from the community which features are the most important, so I've done a quick outline of my requirements/priorities.

Please comment with your thoughts and priorities. If you want to help out in in form (like development, documentation, issue triaging, testing etc) please reach out here or to me personally on twitter at @trastknast.

Must have

• Support for custom Image component (ImageProgress, FastImage etc)
• Support for lo-res thumbnail -> hi-res transition
• Set up CI to run tests and release
• Andorid hardware back button support
• Gesture to close by swiping down/up
• No dependency on navigation lib
• No dependency on Modal
• Improved peformance with native animation driver
• Feature parity between Android and iOS

Really nice to have

• Support for aspect-ratio change from thumbnail -> hi-res
• Pinch to zoom
• Support for gallery mode
• Configurable Touchable component
• Configurable transition properties
• Configurable status bar transitioning
• Configurable/custom header/footer

Nice to have

• Pure JavaScript implementation
• Integration library with react-navigation (et al)
• Integration library with redux
• Support Image->Video transition
• Some form of lifecycle support (will/did open/close)

On the fence

• Orientaion change support
• Programmatic way of opening/closing lightbox

Not doing

• Generic shared element transition

Ping @StevenMasini @peteroid @elkinjosetm @bilalsyed001 @ncuillery @ZackLeonardo @Kureev

[StevenMasini]

@oblador I don't know what you think about it, but if we are starting a new version of react-native-lightbox from scratch, we could review, add to the list and close the previous issues.

For instance, I think the iPhone X Support issues should also be added to the Must have list.

[peteroid]

@oblador The list looks good. How should we prioritize it?

IMO, these are first-class must-have:

• Feature parity (Android, iOS)
• Performance
  • Supports useNativeDriver
  • Support for lo-res thumbnail -> hi-res transition
• Gesture to close by swiping down/up
• Dependency-less
  • at least no navigation

Maybe we can branch a new v1 to contribute.

[oblador]

@StevenMasini Yup, iPhone X support is a given, but wouldn't consider it a major feature to list here. I have an X so no worries that it'll be implemented :-)

@peteroid Cool, those are all in the must haves right? Prioritization within each section is less important, just wanted to make sure I didn't omit anything important, or placed something in the wrong bucket.

[ZackLeonardo]

pull request #85 let overlay can be zoomed. Pinch to zoom😊

[ZackLeonardo]

Support for gallery mode, I will try this.

[oblador]

@ZackLeonardo Awesome! Before you start on gallery mode can we discuss the overall API in a ticket first?

[ZackLeonardo]

@oblador Sure. I run into kind of similar scene in my spare time app, I am thinking of its outline after work.

[ZackLeonardo]

@oblador My opinion: add galleryMode(true/false) and Key props to LightBox component, then those which galleryMode values are true and have the same Key value can be swiped in LightboxOverlay component.

[ZackLeonardo]

@oblador I just coded the gallery mode and commit it here: pull request #85 . I wanna get your suggestions to make it better.

[StevenMasini]

@oblador Any progression here ? How can we contribute to this ?

[oblador]

@StevenMasini I've gotten to a good start, have a first PR up here: #106

My thought is to get a foundation up in the phoenix branch and then you guys can start contributing by making PRs to that branch. I'll give you repo access soon too.

[StevenMasini]

@oblador thank you for the push access. I will run and review both branch phoenix and phonenix/pinch-to-zoom asap.

[oblador]

phoenix is empty so far, I intend to build it up via pull requests the coming few days for visibility.

[oblador]

Having a hard time breaking this up in well scoped PRs before knowing what I want as the final API, so I've gone ahead to create a proof of concept implementation with a new API. You can try it out here: https://github.com/oblador/react-native-lightbox/tree/phoenix-wip/Example/src

In essence you'll wrap your application with a LightboxPresenterProvider which will contain the overlay component (thus removing need for Modals) and general configuration such as how to render the header, what image component to use etc. I've only implemented one presenter so far which has AirBnB like transitions/interactions, but have plans on doing a neater shared element transition later too.

Galleries will similarly be wrapped with an optional GalleryProvider that contains a list of all images and potentially more meta data like hires source, title, description etc. It would be great to have just a <GalleryProvider> that will somehow aggregate the image sources of all nested children so you wouldn't have to duplicate the data, but can't come up with a clean and simple way so waiting a bit with that.

Lastly we have the LightboxImage that is a clickable image that will trigger the ligthbox. I'm not sure if this is the best API, maybe the current more generic approach with Lightbox is better but also harder to get right. Might also have multiple components as entry points to the lightbox.

LMK what your thoughts are and if I'm totally off somewhere.