calintamas / react-native-toast-message

Animated toast message component for React Native
MIT License
1.6k stars 252 forks source link

feat: add a ios native module to calculate inset top and bottom #511

Open seyedmostafahasani opened 7 months ago

seyedmostafahasani commented 7 months ago

I used react-native-safe-area-context to handle it.

calintamas commented 7 months ago

hey @seyedmostafahasani, thanks again!

I'm just thinking: could we do it in some way that doesn't involve adding a 3rd party dependency? Adding react-native-safe-area-context brings with itself a couple of complexities for the end-user of the library, like installing the native pods, wrapping the <Toast /> in the <SafeAreaProvider />, dep version incompatibilities, etc

I suggest either:

wdyt?

seyedmostafahasani commented 7 months ago

hey @seyedmostafahasani, thanks again!

I'm just thinking: could we do it in some way that doesn't involve adding a 3rd party dependency? Adding react-native-safe-area-context brings with itself a couple of complexities for the end-user of the library, like installing the native pods, wrapping the <Toast /> in the <SafeAreaProvider />, dep version incompatibilities, etc

I suggest either:

  • read the actual initial safe area values ourselves through a native module, written as part of toast message lib (so we don't depend on 3rd parties)
  • come up with some good-enough topOffset and bottomOffset values for different iOS versions. Could be done in a trial-and-error fashion, on different simulators

wdyt?

Hey Calin, I completely agree with you about 3rd party dependency. I will try to fix it with one of the above methods.

calintamas commented 7 months ago

@seyedmostafahasani looking good, thanks! I'll run a few tests in a demo app that I use and then we can merge. Will probably require a major bump, since it's a breaking change for installation.

seyedmostafahasani commented 7 months ago

@seyedmostafahasani looking good, thanks! I'll run a few tests in a demo app that I use and then we can merge. Will probably require a major bump, since it's a breaking change for installation.

Anytime! I agree with you about a major bump. Great! I tested it on different devices (iOS and Android), and it works correctly. Please check it out.

seyedmostafahasani commented 6 months ago

@calintamas Did you have time to test my PR?

calintamas commented 6 months ago

@calintamas Did you have time to test my PR?

hey, I did not manage to take a look yet. will try today

calintamas commented 6 months ago

@seyedmostafahasani Took a quick look, and everything looks fine! I just need some time to prepare the new readme for v3, with release notes migration docs, etc.

I published the change as v3.0.0-beta.1, if you need it in the meantime:

yarn add react-native-toast-message@3.0.0-beta.1
seyedmostafahasani commented 6 months ago

@seyedmostafahasani Took a quick look, and everything looks fine! I just need some time to prepare the new readme for v3, with release notes migration docs, etc.

I published the change as v3.0.0-beta.1, if you need it in the meantime:

yarn add react-native-toast-message@3.0.0-beta.1

I can help you if you need anything.

seyedmostafahasani commented 6 months ago

Hey Calin, I hope you are well.

Have you had enough time to release a new version of the library?

calintamas commented 6 months ago

Ah, not really :) Winter vacation and all that, I'll get back to it soon

seyedmostafahasani commented 5 months ago

@calintamas Hey Man, I can help you to release a new version of the library if you need anything.

calintamas commented 4 months ago

Does the native module work fine with Expo, or we need ajustments? I wanted to have this checked, but really had no time to do it.

seyedmostafahasani commented 4 months ago

Does the native module work fine with Expo, or we need ajustments? I wanted to have this checked, but really had no time to do it.

Hey Man, I think it works correctly but I will test it on a project with Expo then I will inform you about it.

seyedmostafahasani commented 2 months ago

Does the native module work fine with Expo, or we need ajustments? I wanted to have this checked, but really had no time to do it.

Hey Man, I think it works correctly but I will test it on a project with Expo then I will inform you about it.

Hey @calintamas I hope you are well. I tested this native module on Expo and it worked correctly, but it doesn't work on "Expo Go" as it requires custom native code. On "Expo Go" the toast message uses default number. If you agree we can release a new version of the library.

seyedmostafahasani commented 2 months ago

If you need anything let me know. I'm available 🤝

calintamas commented 2 months ago

Hey! I kept thinking if it's worth having a native module (only) for this after all...

I'm leaning towards the other solution I proposed back then -- some good-enough (hardcoded) defaults, with the already existing topOffset and bottomOffset props to overwrite them. It's simple and it worked fine as a solution until now, so why add more complexity?

A native module means: (1) more maintenance work down the road (with the new RN architecture), (2) potential issues for Expo users (which I don't have time to take care of, since I'm not actively using Expo).

I probably should have expressed my concerns earlier. I don't want to dismiss the work you did in any way, I just prefer solutions that are simpler to maintain in the long-term. Thanks for understanding!

seyedmostafahasani commented 2 months ago

Hey! I kept thinking if it's worth having a native module (only) for this after all...

I'm leaning towards the other solution I proposed back then -- some good-enough (hardcoded) defaults, with the already existing topOffset and bottomOffset props to overwrite them. It's simple and it worked fine as a solution until now, so why add more complexity?

A native module means: (1) more maintenance work down the road (with the new RN architecture), (2) potential issues for Expo users (which I don't have time to take care of, since I'm not actively using Expo).

I probably should have expressed my concerns earlier. I don't want to dismiss the work you did in any way, I just prefer solutions that are simpler to maintain in the long-term. Thanks for understanding!

Thank you for your attention. I am available to manage the library and address any issues related to this native module. Please don’t worry about it. We can release a new version with these changes to the native module. Additionally, many of my friends have used the beta version in various projects, and none of them have encountered any issues with native modules.

seyedmostafahasani commented 2 months ago

We also haven't removed the default variables topOffset and bottomOffset. If the native module doesn't function correctly, the library returns their default values. in a nutshell, don't worry about these changes.

calintamas commented 2 months ago

I understand your point. What I mean is that I don't think the native module is really necessary in this case (along with the reasons mentioned above, it brings a breaking change which I prefer to avoid).

If anyone needs custom values, it's relatively easy to do even right now:

import { Toast } from 'react-native-toast-message'

const App = () => {
  const insets = useSafeAreaInsets()

  return (
    <Toast
      // ...
      topOffset={insets.top}
      bottomOffset={insets.bottom}
    />
  )
}

I'd rather have some better default values (trading correctness for simplicity). It's a difference in the approach, nothing else.

seyedmostafahasani commented 2 months ago

I understand your point. What I mean is that I don't think the native module is really necessary in this case (along with the reasons mentioned above, it brings a breaking change which I prefer to avoid).

If anyone needs custom values, it's relatively easy to do even right now:

import { Toast } from 'react-native-toast-message'

const App = () => {
  const insets = useSafeAreaInsets()

  return (
    <Toast
      // ...
      topOffset={insets.top}
      bottomOffset={insets.bottom}
    />
  )
}

I'd rather have some better default values (trading correctness for simplicity). It's a difference in the approach, nothing else.

I understand your point. This way is good, but we can do it easier for all users with these changes. They don't need to install 3rd-party library.