how is this different from gorhom's bottom sheet?

[bryanprimus]

Well, I believe that this question belongs in the discussion section. But I see that we don't have that.

However, I'm curious. What is the motivation for building this library? Is it going to be more performant than other sheet libs especially gorhom bottom sheet since all the code implementation is on the native side? What's the direction towards? Why there is a plan to integrate with reanimated? gorhom bottom sheet already uses reanimated btw

I'm heavily using gorhom bottom sheet in most of my projects. The DX is good, but there are just too many little bugs that aren't handled, which I need to live with. This is probably because the library wants to achieve so many things.

[lodev09]

What is the motivation for building this library?

1. I previously used gorhom's bottom sheet on the App I'm working. It worked great for a bit. However, it glitches when you have lots of content (I noticed in android using FlashList). The codebase is kinda bloated already and is doing too many things for just simple bottom sheet.
2. I wanted that native iOS shrinking effect.
3. I wanted that extra blur functionality.

Is it going to be more performant than other sheet libs especially gorhom bottom sheet since all the code implementation is on the native side

Yes, theoretically.

What's the direction towards?

At least for version 1, need to support inline sheet and context API. I'm thinking of similar approach with how react-navigation manages the screens. Basically the ability to present/dismiss the sheets from anywhere without passing the ref.

Why there is a plan to integrate with reanimated?

This is the home screen of the app I'm working on. I wanted to use the sheet here. Currently, it's a custom reanimated/gestured view.

In order to do that, the lib needs to support worklet during slide/drag and also an inline prop.