how is this different from gorhom's bottom sheet?

[bryanltobing]

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.

[bryanltobing]

i agree with Gorhom's bottom sheet; it often glitches.

by the way, have you looked into this approach before? https://rnas.vercel.app/guides/sheetmanager

it helps save a lot of dev time and reduce code repetition when using bottom sheets, but it might require a provider to manage the IDs though. maybe we can introduce this approach as an option for user to use?

[lodev09]

Yeah, I was thinking with something similar. However, it doesn't really play well with the native setup. Like this issue. The sheets need to be rendered along side the same view controller and cannot be placed in one place.

I can, however, introduced a name prop that maps into the ref handle tag and the user can just call a static method like so:

<TrueSheet name="my-sheet">
  // ...
</TrueSheet>

TrueSheet.present('my-sheet')

I think this is much simpler 🤔

Regarding the payload functionality, I think it's too much for this simple package. I guess a separate package that should handle all this in the future 😅

[lodev09]

Added the name feature here #6.

// Define the sheet as usual
<TrueSheet name="my-sheet">
  // ...
</TrueSheet>

// Somewhere in your screen
const presentMySheet = async () => {
  await TrueSheet.present('my-sheet')
  console.log('🎉')
}

return (
  <Button onPress={presentMySheet} />
)