Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

seyedmostafahasani
Copy link
Contributor

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

@calintamas
Copy link
Owner

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?

@seyedmostafahasani
Copy link
Contributor Author

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.

src/types/index.ts Outdated Show resolved Hide resolved
src/hooks/useSafeArea.ts Show resolved Hide resolved
@calintamas
Copy link
Owner

@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
Copy link
Contributor Author

seyedmostafahasani commented Dec 15, 2023

@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 seyedmostafahasani changed the title chore: add safeArea for handling inset top and bottom feat: add a ios native module to calculate inset top and bottom Dec 15, 2023
@seyedmostafahasani
Copy link
Contributor Author

@calintamas Did you have time to test my PR?

@calintamas
Copy link
Owner

@calintamas Did you have time to test my PR?

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

@calintamas
Copy link
Owner

@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
Copy link
Contributor Author

@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
Copy link
Contributor Author

seyedmostafahasani commented Dec 31, 2023

Hey Calin,
I hope you are well.

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

@calintamas
Copy link
Owner

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

@seyedmostafahasani
Copy link
Contributor Author

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

@calintamas
Copy link
Owner

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
Copy link
Contributor Author

seyedmostafahasani commented Feb 14, 2024

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
Copy link
Contributor Author

seyedmostafahasani commented May 2, 2024

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
Copy link
Contributor Author

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

@calintamas
Copy link
Owner

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
Copy link
Contributor Author

seyedmostafahasani commented May 9, 2024

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
Copy link
Contributor Author

seyedmostafahasani commented May 9, 2024

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
Copy link
Owner

calintamas commented May 9, 2024

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
Copy link
Contributor Author

seyedmostafahasani commented May 9, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants