How to set menu position always bottom?

[crusherblack]

Hi i want to set the menu position to bottom only so the aux preview not overlapping each others

I want it to be like this everytime hold the item

Can you help me?
Thank you

[alexrisch]

@crusherblack did you find a way to do this?

[acdifran]

I am running into the same issue using zeego which uses this library for ios. I found that rendering a separate preview of the same content will keep the menu on the bottom, but introduces a small flicker: nandorojo/zeego#107. I've been poking around the source code to see if I can find a way to keep the menu on the bottom without the flicker, but no luck so far.

[acdifran]

After digging around a bit more I found that commenting out the highlightPreview and dismissalPreview interactions in RNIContextMenuView+UIContextMenuInteractionDelegate.swift solves the flicker. I think it's related to this currently always being set to self.menuTargetedPreview which is either an actual targeted preview that you specify or the current view (self) if there's no targeted preview. This might be causing the flicker when you use a custom preview since the view used for the preview interactions is then different from the preview itself. Obviously just commenting out this code is not a great solution since I imagine it would break the use of an actual targeted preview. @dominicstop any thoughts on this? I tried creating a targetedPreview with the view created by the previewProvider, but that didn't seem to work. I'm not well versed in swift or UIKit, so not sure what a good solution here would be.

before	after
ScreenRecording_11-05-2024.09-27-16_1.MP4	ScreenRecording_11-05-2024.09-24-38_1.MP4

[dominicstop]

@acdifran hello, thank you for the detailed response and for bumping this issue

i apologize for responding so late, this issue kind of got buried in my emails (so this is the first time i am seeing this)

to start things of, i need to make a test to repro this; can i ask what version of the library you are using?

unfortunately, i can only work on a fix for this in the latest pre-release major version

i might be able to backport it though if it's relatively simple

[acdifran]

hey @dominicstop thanks for looking into this! I am on 2.5.1. I tried upgrading to v3, but seems it is not set up to work with expo, is that right?

[dominicstop]

@acdifran hello, yes unfortunately i haven't tested it with expo yet; i just haven't had the time to do it since i'm no longer doing OSS for the time being.

the scaffolding + example app for v3 of this library was generated by react-native-builder-bob. I've been meaning to create another example directory/app using expo, but i don't really know how to set that up, unfortunately.

if you happen to know how, i would be grateful if you could help me set that up, so i can continue testing; here's a testfllight version of the example app just in case you need it (i think it might have gotten fix during the rewrite): https://testflight.apple.com/join/VsNeSTPq

i think it should still work with zeego, since i haven't really changed much of the API (though i did remove some of the internal cleanup stuff).

if you have time, can you please try installing: [email protected] + [email protected] and see if there are any problems? i'll release patches to fix the errors you encounter.

Edit: Hello, i added an example for expo, and it seems to work just fine.

please reply w/ min. example code to reproduce this bug so i can investigate; thank you

[acdifran]

hey @dominicstop just seeing your latest message above, thanks for putting up an expo example. I added a second example where the preview is the same as the main content where you can see the flicker.

ScreenRecording_11-08-2024.09-09-35_1.MP4

here's the code for the new example:

export function FlickerExample({ children }: { children: React.ReactElement }) {
  return (
    <ContextMenuView
      style={styles.menuContainer}
      previewConfig={{ previewType: "CUSTOM" }}
      renderPreview={() => children}
      menuConfig={{
        menuTitle: "BasicUsageExample01",
        menuItems: [
          {
            actionKey: "key-01",
            actionTitle: "Action #1",
          },
          {
            actionKey: "key-02",
            actionTitle: "Action #2",
          },
          {
            actionKey: "key-03",
            actionTitle: "Action #3",
          },
        ],
      }}
    >
      {children}
    </ContextMenuView>
  );
}

export default function App() {
  return (
    <View style={styles.container}>
      <StatusBar style="auto" />
      <BasicUsageExample01 />
      <FlickerExample>
        <Text style={styles.text}>Press And Hold To Show Context Menu</Text>
      </FlickerExample>
    </View>
  );
}

[acdifran]

hey @dominicstop wondering if you ever got chance to check this out. thanks!

[dominicstop]

hello, i'll take a look

edit: the reason why it "flickers" is because you're displaying the same thing in the preview + context menu body.

[acdifran]

hello, i'll take a look

edit: the reason why it "flickers" is because you're displaying the same thing in the preview + context menu body.

yeah I get that, but as mentioned above showing the same thing in the preview is the only way to have the menu always appear on the bottom. Without a custom preview the menu will appear on top if the item is near the bottom of the screen while a custom preview will move the preview up towards the center so the menu can still show on the bottom. If I comment out all the code at the bottom of RNIContextMenuViewContent+UIContextMenuInteractionDelegate.swift after line 197 the flicker goes away.

Explained in more detail in this comment above: #102 (comment)

[dominicstop]

i understand your frustration—but in order to fix this, i would have to impl. some entrance and exit animations for the custom preview, and for it not to break other things it has to be configurable (e.g. entrance and exit keyframe).

unfortunately, this library has been in maintenance mode for a while now, and i can't really add new features like that anymore—especially since this is just something i do in my free time (the fact that this library works in the new arch. at all took a monumental effort to do).

the best i can do is to recommend that you add some "animated" code to fade in and out the custom preview.

if you have the free time, you can submit a PR to fix this specific use case—or if you have the funds, you can commission a feature for the community (that would be nice, but understandably the least likely option).

alternatively, if you're comfortable w/ writing some swift code (and want a less hacky solution), you can make a quick patch for your app (via something like patch-package, or a custom fork that you maintain):

• the context menu delegate exposes an animation block when the context menu interaction starts and ends; this allows you to schedule synchronous animations alongside the context menu interaction
• all you'd have to do then is fade the custom preview in and out accordingly
• you can even animate other stuff, like the context menu label colors—or change the background blur
• this is the solution i suggest taking; swift is a really cool language, and i'd think you would have some fun implementing this yourself ✨

thank you for being patient with me—but this is the best i can do for now (maybe in the future, i can add an official fix)

[acdifran]

@dominicstop I completely understand, thanks for the info and your help on this so far. For now I have patched on my end to comment out the contextMenuInteraction code for highlightPreviewForItemWithIdentifier, previewForHighlightingMenuWithConfiguration, dismissalPreviewForItemWithIdentifier, and previewForDismissingMenuWithConfiguration, which prevents flickering when using a custom preview that is the same as the underlying view. As mentioned above (#102 (comment)), I believe that works because it prevents the menuTargetedPreview from animating in / out. Does that sound correct to you or am I missing something here? It's not super clear to me the purpose of those functions as commenting them out removes the flicker, but does not seem to break any other functionality that I can see.