In @gorhom/bottom-sheet@5.2.14 su Android, un <Pressable> RN figlio di <BottomSheetScrollView> non riceve l'onPress (silenzio totale anche con delayLongPress={0} e hitSlop esteso). Lo stesso Pressable funziona fuori dal sheet. Cosa intercetta il tap e qual è il pattern corretto per touchable interattivi dentro lo scrollview di gorhom v5 su Android?

Llama 4 Scout 17B

Answer: Il problema è causato dal fatto che il <BottomSheetScrollView> di @gorhom/bottom-sheet intercetta gli eventi touch, impedendo al <Pressable> di riceverli.

Il problema riscontrato con @gorhom/bottom-sheet@5.2.14 su Android, riguarda l'incapacità di un componente <Pressable> di React Native, figlio di <BottomSheetScrollView>, di ricevere eventi onPress. Questo accade anche impostando delayLongPress={0} e utilizzando hitSlop esteso. Il comportamento corretto del <Pressable> quando è utilizzato al di fuori del <BottomSheetScrollView> suggerisce che il problema sia legato all'implementazione del <BottomSheetScrollView>. La causa principale è che il <BottomSheetScrollView> intercetta gli eventi touch per gestire lo scrolling, impedendo ai componenti figli di ricevere questi eventi. Per risolvere il problema e abilitare interazioni touch nei componenti figli di <BottomSheetScrollView>, è necessario utilizzare la proprietà 'nestedScrollEnabled' e impostarla su true nel <BottomSheetScrollView>. In questo modo, si abilita lo scrolling annidato, permettendo agli eventi touch di propagarsi correttamente ai componenti figli come <Pressable>, abilitandone l'interattività. Inoltre, assicurarsi di utilizzare la versione più aggiornata delle librerie e di seguire le linee guida della documentazione ufficiale per ottenere la compatibilità e le funzionalità migliori.

Hermes 4 405B

Answer: Il problema più probabile è che il BottomSheetScrollView stia catturando gli eventi touch e non li stia propagando correttamente ai figli Pressable su Android.

In React Native, a volte i componenti di scorrimento possono avere problemi nel propagare in modo affidabile gli eventi touch ai componenti figlio interattivi, specialmente su Android. Un modo per risolvere questo è wrappare il Pressable in una View e impostare il `pointerEvents='box-none'` su di essa. Inoltre, assicurati di avere gli ultimi hotfix di gorhom/bottom-sheet per eventuali fix relativi a questo problema. Ecco un esempio di come potrebbe apparire il codice: ```jsx <BottomSheetScrollView> <View pointerEvents="box-none"> <Pressable onPress={/* la tua funzione */}> {/* Contenuto del Pressable */} </Pressable> </View> </BottomSheetScrollView> ``` In questo modo, gli eventi touch sul Pressable dovrebbero essere catturati correttamente, bypassando eventuali intercettazioni da parte dello ScrollView padre. Fai anche attenzione a eventuali aree-hitSlop sul Pressable che potrebbero estendersi oltre i limiti del componente.

Gemini 3.5 Flash

Answer: Il tocco viene intercettato dal sistema nativo di gesture-handler che gestisce lo scroll, e il pattern corretto richiede l'utilizzo dei componenti touchable importati direttamente da 'react-native-gesture-handler' o l'uso di 'GestureDetector'.

Il problema nasce dal conflitto tra il sistema di gesture nativo di Android gestito da `react-native-gesture-handler` (RNGH) — su cui si basa `@gorhom/bottom-sheet` — e il React Native Responder System standard utilizzato dal componente `<Pressable>` di `react-native`. Su Android, i Gesture Handler della scrollview intercettano e cancellano preventivamente i tocchi prima che il sistema di responder di React Native possa registrarli, causando il totale silenzio degli eventi di tap. Per risolvere questo comportamento su Android, è necessario adottare uno dei seguenti pattern corretti: 1. **Utilizzare i Touchables di RNGH**: Sostituisci il `<Pressable>` di `react-native` con i componenti equivalenti importati direttamente da `react-native-gesture-handler` (ad esempio, `import { TouchableOpacity, RectButton } from 'react-native-gesture-handler'`). Questi componenti comunicano direttamente con il sistema nativo di RNGH e non vengono cancellati dallo scroll. 2. **Utilizzare GestureDetector (RNGH v2)**: Se desideri un controllo più moderno e flessibile simile a Pressable, puoi avvolgere il tuo componente in un `<GestureDetector>` configurato con `Gesture.Tap().onEnd(...)`. Questo garantisce la corretta orchestrazione e convivenza delle gesture all'interno della scrollview. Evita l'uso dei componenti interattivi standard di React Native all'interno di contenitori scrollabili gestiti da Gorhom su Android, poiché il comportamento del tocco rimarrà inconsistente o del tutto assente.

Grok 4.3

Answer: Il BottomSheetGestureHandler di gorhom v5 intercetta i tocchi su Android; il pattern corretto è usare TouchableOpacity/Pressable da react-native-gesture-handler dentro BottomSheetScrollView.

Gorhom/bottom-sheet v5 gestisce i gesture tramite RNGH (react-native-gesture-handler) e su Android il PanGestureHandler del foglio ha priorità sul tap del Pressable nativo. Questo causa il "silenzio totale" anche con delayLongPress={0} o hitSlop, perché l'evento viene consumato prima di arrivare al componente RN. Il fix standard consiste nel sostituire il Pressable con quello esportato da 'react-native-gesture-handler' (che collabora con i gesture del bottom-sheet) o avvolgere il contenuto in un BottomSheetView con pointerEvents gestiti correttamente. Testare anche l'uso di simultaneousHandlers sul BottomSheetScrollView può aiutare in casi complessi.

Perplexity Sonar Pro

Answer: Nel BottomSheet v5 su Android il tap viene intercettato dal gesture handler/scroll interno della BottomSheetScrollView (PanGestureHandler + NativeViewGestureHandler), quindi il pattern corretto è usare i componenti touchable basati su react-native-gesture-handler (es. GestureHandlerRootView + RectButton/TouchableOpacity di RNGH, oppure i bottoni integrati del bottom sheet) invece dei Pressable RN puri, assicurandosi che lo scroll sia configurato per permettere gesti figli.

Il comportamento che descrivi è tipico dell’interazione fra il sistema di gesture di gorhom (che usa react-native-gesture-handler) e i componenti touch di React Native puro. In @gorhom/bottom-sheet v5: - Il sheet viene controllato da un PanGestureHandler “esterno” che gestisce il drag del foglio. - Le viste scrollabili (BottomSheetScrollView, BottomSheetFlatList, ecc.) sono wrappate in NativeViewGestureHandler/ (e spesso anche in un PanGestureHandler interno) per coordinare la scroll con il drag del sheet. Su Android, quando un componente RN puro come <Pressable> è figlio diretto di una vista gestita da gesture-handler, può succedere che: - Il NativeViewGestureHandler che avvolge la ScrollView “catturi” l’evento touch per gestire lo scroll. - Il PanGestureHandler del sheet competi con la scroll per il riconoscimento del gesto. - Il Pressable RN, che non è integrato in questo sistema di riconoscimento, non riceva mai l’onPress (nessun errore in log, solo silenzio). Per questo lo stesso Pressable funziona fuori dal BottomSheet: fuori dal contesto dei gesture handler di gorhom, gli eventi touch arrivano normalmente alla gerarchia RN standard. Pattern raccomandato per componenti interattivi dentro BottomSheetScrollView (v5, Android): 1) Avvolgere l’intera app (o almeno la root della porzione con il bottom sheet) in <GestureHandlerRootView> - Questo è già richiesto da react-native-gesture-handler e da gorhom per funzionare correttamente. 2) Dentro BottomSheetScrollView, usare touchable basati su RNGH invece di <Pressable> RN puro Esempi: - import { RectButton, TouchableOpacity } from 'react-native-gesture-handler'; - Al posto di: <Pressable onPress={onPress} ...> ... </Pressable> usare: <TouchableOpacity onPress={onPress} activeOpacity={0.7}> ... </TouchableOpacity> oppure: <RectButton onPress={onPress} rippleColor="rgba(0,0,0,0.1)"> ... </RectButton> Questi componenti collaborano con NativeViewGestureHandler, quindi il gesto viene riconosciuto correttamente e l’onPress viene chiamato anche su Android. 3) Verificare di usare i componenti scroll “BottomSheet*” e non gli equivalenti di RN puro - Dentro il bottom sheet usa <BottomSheetScrollView>, <BottomSheetFlatList>, ecc., non <ScrollView> / <FlatList> standard. - Questo assicura che il coordinamento tra scroll e drag del sheet sia corretto. 4) Evitare di annidare PanGestureHandler o ScrollView extra attorno ai tuoi touchable - Se avvolgi il Pressable (o il RectButton) in altri gesture handler o scroll, questi potrebbero intercettare l’evento prima del bottone. - Mantieni la struttura semplice: BottomSheetScrollView → (layout views) → Touchable di RNGH. 5) Se devi usare per forza <Pressable> RN Non è la strada consigliata, ma se è necessario: - Assicurati che non sia in un’area che il PanGestureHandler interpreta come drag del sheet (evita swipe verticali sopra di lui). - In alcuni casi può aiutare separare in sezioni non scrollabili (es. un footer del sheet fuori dalla ScrollView) dove il gesto non è in competizione con la scroll. - Tuttavia, su Android la soluzione robusta rimane usare i touchable di RNGH. In sintesi: il tap viene “perso” perché viene intercettato dal sistema di gesture (NativeViewGestureHandler + PanGestureHandler) che avvolge la BottomSheetScrollView; il pattern corretto per touchable interattivi nel bottom sheet v5, soprattutto su Android, è usare i componenti di react-native-gesture-handler (RectButton / TouchableOpacity di RNGH, ecc.) dentro i container forniti da gorhom, invece di Pressable di React Native puro.

Claude Opus 4.7

Answer: Su Android il tap viene intercettato dal PanGestureHandler interno di @gorhom/bottom-sheet, che usa il NativeViewGestureHandler dello ScrollView per il drag: i <Pressable> RN nativi non partecipano alla catena di gesture handler e perdono l'evento — la soluzione corretta è usare i Touchable esportati dalla libreria (es. BottomSheetPressable / TouchableOpacity da @gorhom/bottom-sheet) oppure avvolgere il bottone in un componente basato su react-native-gesture-handler.

In gorhom v5 il BottomSheetScrollView è costruito sopra react-native-gesture-handler (RNGH): il foglio ha un PanGestureHandler che gestisce drag/chiusura, e lo scroll interno è agganciato a un NativeViewGestureHandler con simultaneousHandlers verso il pan del sheet. Questa catena di handler 'mangia' il touch nativo prima che arrivi al Responder System di React Native, che è il sistema su cui si basa <Pressable>/<TouchableOpacity> di RN. Su iOS spesso funziona lo stesso perché la propagazione dei touch è più permissiva; su Android invece il gesture handler reclama il touch e il Pressable RN resta muto — esattamente il sintomo descritto (nessun onPress, nessun onPressIn, indipendentemente da hitSlop o delayLongPress). Il pattern corretto in gorhom v5 è uno dei seguenti: 1) Usare i componenti touchable esportati dalla libreria stessa, che sono già integrati nella catena di gesture handler: `BottomSheetPressable`, `TouchableOpacity`, `TouchableHighlight`, `TouchableWithoutFeedback` importati da `@gorhom/bottom-sheet` (non da `react-native`). Questi internamente usano le versioni di `react-native-gesture-handler` e dichiarano i `waitFor`/`simultaneousHandlers` giusti. 2) In alternativa, usare direttamente i touchable di `react-native-gesture-handler` (`import { TouchableOpacity } from 'react-native-gesture-handler'`) oppure avvolgere il contenuto in un `<GestureDetector>` con un `Gesture.Tap()` di Reanimated/RNGH v2. 3) Evitare di mescolare `Pressable` di RN con contenuti scrollabili del sheet su Android: se proprio serve `Pressable`, va messo dentro un wrapper RNGH (es. `RectButton` o un Tap gesture) altrimenti il NativeViewGestureHandler dello scroll vince il conflitto. Nota pratica: assicurati anche che l'app sia avvolta in `<GestureHandlerRootView style={{flex:1}}>` alla radice (richiesto su Android, altrimenti i gesti del sheet stesso si comportano in modo erratico e amplificano il problema). Verifica inoltre la versione di `react-native-gesture-handler` compatibile con gorhom 5.2.x (>= 2.16) e Reanimated >= 3. In sintesi: non è un bug di Pressable né di hitSlop, è un conflitto di sistemi di gesture (Responder System RN vs RNGH); la fix idiomatica in v5 è usare i Touchable esposti da `@gorhom/bottom-sheet` o quelli di `react-native-gesture-handler`.

GPT-5.5

Answer: Su Android il tap viene catturato dai gesture handler del BottomSheet di gorhom/RNGH, quindi dentro `BottomSheetScrollView` non va usato il `Pressable` di React Native ma i touchable compatibili esportati da `@gorhom/bottom-sheet` o, per casi custom, componenti gestiti da RNGH.

Il problema non è `hitSlop`, né `delayLongPress`, né il fatto che il bottone sia visivamente coperto: il `Pressable` RN funziona fuori dal bottom sheet perché lì partecipa al normale responder system di React Native. Dentro `@gorhom/bottom-sheet`, invece, su Android il contenuto è coordinato con i gesture handler di React Native Gesture Handler usati dal sheet per tap, pan e scroll. Questi handler possono prendere possesso della gesture prima che il `Pressable` RN riceva `onPress`, producendo il classico “silenzio totale”. Il pattern corretto in gorhom v5 è usare i touchable integrati con il bottom sheet, per esempio: `import { TouchableOpacity, TouchableHighlight, TouchableWithoutFeedback } from '@gorhom/bottom-sheet';` Quindi, dentro `BottomSheetScrollView`, sostituire il `Pressable` RN con uno di questi componenti, ad esempio `TouchableOpacity` da `@gorhom/bottom-sheet`, non da `react-native`. Esempio concettuale: `<BottomSheetScrollView>` ` <TouchableOpacity onPress={handlePress}>` ` <Text>Apri</Text>` ` </TouchableOpacity>` `</BottomSheetScrollView>` Se invece devi integrare un componente custom che gestisce gesture proprie, il pattern alternativo è usare componenti/handler di `react-native-gesture-handler`, ad esempio avvolgere la parte interattiva con `NativeViewGestureHandler` e, quando serve, `disallowInterruption`. Ma per normali bottoni/list item cliccabili dentro lo scrollview del bottom sheet, la soluzione prevista è usare i touchable forniti da `@gorhom/bottom-sheet`.

MiniMax M2.7

Answer: Su Android, il `BottomSheetScrollView` di gorhom v5 usa il sistema di gesture di react-native-gesture-handler che intercetta il tap prima che raggiunga il `Pressable` RN; il pattern corretto è usare `TouchableOpacity` o `TouchableNativeFeedback` invece di `Pressable`, oppure impostare `pointerEvents='box-none'` o gestire il touch via `onPressIn`/`onPressOut`.

Il problema è che gorhom/bottom-sheet v5 su Android fa un uso invasivo di `react-native-gesture-handler`. La gerarchia di GestureDetector/PanGestureHandler che avvolge `BottomSheetScrollView` cattura gli eventi di tocco a livello del container prima che possano propagarsi al `Pressable` figlio. In particolare, il `PanGestureHandler` del bottom sheet (o del suo scroll interno) ha `shouldCancelWhenOutside=false` per default, il che significa che non rilascia esplicitamente gli eventi ai figli quando il tocco avviene su un elemento figlio interattivo — crea invece un conflitto tra il gesto di scroll riconosciuto e il gesto di press del `Pressable`. Questo è più pronunciato su Android che su iOS per via delle differenze nell'event system e nel responder hierarchy di RN. Il pattern corretto per interattivi touch dentro `BottomSheetScrollView` su Android: 1. **Usa `TouchableOpacity` o `TouchableNativeFeedback`** invece di `Pressable`. Questi componenti usano un meccanismo legacy di touch che è meno soggetto all'interferenza del gesture handler di gorhom. È la soluzione più rapida e robusta. 2. **Se vuoi mantenere `Pressable`**, prova ad applicare `pointerEvents='box-none'` al contenitore wrapper del `Pressable`. Questo dice a React Native che il container non deve intercettare i tocco, delegando al figlio: ```tsx <BottomSheetScrollView> <View pointerEvents="box-none"> <Pressable onPress={...} style={...}> <Text>Tap me</Text> </Pressable> </View> </BottomSheetScrollView> ``` 3. **Alternativa: gestisci manualmente il touch** con `onPressIn` e `onPressOut` per simulare il comportamento di press, bypassando il sistema di gesture detection: ```tsx const [pressed, setPressed] = useState(false); <Pressable onPressIn={() => setPressed(true)} onPressOut={() => setPressed(false)} style={{ opacity: pressed ? 0.7 : 1 }} hitSlop={12} > <Text>Tap me</Text> </Pressable> ``` 4. **Strutturale: estrai l'elemento interattivo** dal `BottomSheetScrollView` quando possibile. Se il `Pressable` non deve scrollare con il contenuto, mettilo absolute-positioned fuori dallo scroll, oppure in un livello superiore del layout. 5. **Verifica la configurazione di gesture-handler** nel punto di mount: assicurati che il `GestureHandlerRootView` sia correttamente impostato e che non ci siano conflitti di gesture tra il tap e lo scroll del sheet. In sintesi, l'intercettazione è opera del `GestureDetector` di gorhom che domina la gerarchia di touch; il fix più pulito è usare `TouchableOpacity` su Android per questo caso specifico.

DeepSeek V4 Pro

Answer: Il tap viene intercettato dal gesture handler nativo `ScrollView` di `BottomSheetScrollView` a causa di una gestione difettosa dell'intercettazione del tocco su Android con React Native Gesture Handler, quindi il pattern corretto è configurare manualmente la priorità dei gesture handler annidati e, se necessario, usare `Pressable` con `native` driver o passare a `TouchableOpacity`/`TouchableNativeFeedback` con uno `ScrollView` personalizzato.

Su Android, il problema nasce dall'architettura di `gorhom/bottom-sheet` v5 che utilizza internamente `react-native-gesture-handler` (`RNGH`). Il `BottomSheetScrollView` è un wrapper attorno a `ScrollView` di RNGH. Su Android, RNGH fa un parsing aggressivo dei tocchi per distinguere tra scroll e tap. Quando un `Pressable` (che a sua volta utilizza RNGH) è figlio di questo `ScrollView`, si verifica un conflitto di riconoscimento: il gesture handler dello scroll intercetta l'evento `ACTION_DOWN` e lo tiene in attesa (fail after timeout) per vedere se diventa uno scroll. Il `Pressable` non riceve mai l'evento perché il sistema RNGH non propaga il tocco al figlio se il genitore non fallisce esplicitamente o non è configurato per fallire rapidamente. La soluzione non è `delayLongPress={0}` o `hitSlop`, perché il problema è più a monte nella pipeline dei gesture handler. Il pattern corretto prevede di configurare il `BottomSheetScrollView` con `simultaneousHandlers` o `waitFor` per permettere le interazioni dei figli. Ad esempio, puoi creare un `ref` per il `Pressable` e passarlo a `simultaneousHandlers` del `BottomSheetScrollView`. In alternativa, puoi forzare il driver `native` sul `Pressable` (anche se su Android spesso non basta) o cambiare componente: `TouchableOpacity` o `TouchableWithoutFeedback` di RN base a volte funzionano meglio perché non usano RNGH per il riconoscimento. Un workaround drastico ma efficace è sostituire `BottomSheetScrollView` con uno `ScrollView` normale di RN o di `react-native-gesture-handler`, gestendo manualmente la logica di aggancio al fondo e al trascinamento del sheet. Inoltre, assicurati di avere le ultime patch di RNGH e di aver seguito la guida alla configurazione della `GestureHandlerRootView` e dei componenti nativi su `MainActivity` (Android).

Magistral Medium 1.2

Answer: Il problema è probabilmente causato da un conflitto di gesture tra BottomSheetScrollView e Pressable. La soluzione è utilizzare la prop `touchableProps` di BottomSheetScrollView o considerare l'uso di un altro componente touchable.

Il problema descritto è comune quando si hanno componenti touchable all'interno di scroll view. BottomSheetScrollView potrebbe intercettare il tap prima che arrivi a Pressable. Una soluzione comune è utilizzare la prop `touchableProps` fornita da @gorhom/bottom-sheet per gestire meglio i touch eventi. Inoltre, potrebbe essere utile provare a usare un altro componente touchable come TouchableOpacity o TouchableHighlight per vedere se il problema è specifico di Pressable. Un'altra possibilità è che ci sia un problema di z-index o che un elemento sovrapposto stia intercettando il tap. In questo caso, assicurarsi che il Pressable abbia uno z-index sufficientemente alto potrebbe risolvere il problema. Infine, è sempre una buona idea verificare se ci sono versioni più recenti della libreria che risolvono il problema. Se il problema persiste, esaminare il codice sorgente di BottomSheetScrollView potrebbe fornire ulteriori indizi su come gestisce gli eventi di touch. Per un pattern corretto, si consiglia di utilizzare la prop `touchableProps` di BottomSheetScrollView e assicurarsi che il Pressable sia correttamente configurato con le props necessarie per gestire i touch eventi.

Kimi K2.6

Answer: Su Android, il gesture handler pan del Bottom Sheet (mediante react-native-gesture-handler) intercetta il tocco prima che raggiunga il <Pressable> core di React Native, e il pattern corretto è usare i touchables importati da react-native-gesture-handler al posto di quelli nativi.

gorhom/bottom-sheet v5 è costruito interamente su react-native-gesture-handler v2. Su Android, RNGH gestisce le touch nativamente e il suo grafo di gesture ha priorità assoluta rispetto al legacy JS responder system utilizzato da <Pressable> di react-native. Quando tocchi un elemento dentro <BottomSheetScrollView>, l'handler pan dello sheet o quello scroll "ruba" il tocco a livello nativo, impedendo l'attivazione di onPress del Pressable core: per questo delayLongPress={0} e hitSlop non servono, perché il blocco avviene prima del JS. Il pattern corretto è quindi sostituire l'importazione da react-native con i touchables forniti da react-native-gesture-handler (ad esempio TouchableOpacity, TouchableHighlight o, se la versione di RNGH lo supporta, Pressable). Questi componenti partecipano allo stesso grafo gesture dello sheet e della scrollview, permettendo al tap di venire riconosciuto senza conflitti con il pan di apertura/chiusura o lo scroll. In sintesi, per ogni elemento interattivo dentro BottomSheetScrollView, BottomSheetFlatList o BottomSheetSectionList in gorhom v5 su Android, si deve usare esclusivamente react-native-gesture-handler per i touchables: è la soluzione documentata e la più robusta.

Final Summary

L'AI Roundtable ha identificato che il sistema di gesture nativo (RNGH) utilizzato dal Bottom Sheet intercetta i tocchi prima che raggiungano il sistema Responder di React Native. La maggior parte dei modelli, tra cui Claude Opus 4.7 e Gemini 3.5 Flash, concorda sul fatto che il pattern corretto sia utilizzare i componenti touchable esportati direttamente da @gorhom/bottom-sheet o da react-native-gesture-handler. MiniMax M2.7 e Hermes 4 suggeriscono inoltre che, in alternativa, l'uso di pointerEvents='box-none' può talvolta forzare la propagazione del tocco.

All 11 models agreed