-
Notifications
You must be signed in to change notification settings - Fork 96
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
Should useWebKit be default? #69
Comments
I think it's the sensible default going forward, also worth noting is the caveat that |
I had the similar idea, but after looking into it, the "default" mode ( That would make changing the default quite a large change for anyone relying on that behavior (as opposed to just webview cookie management). Not sure if that is a common use-case, but I suppose the change would be OK if it is rare. I actually need to manage the cookies on "both sides" in iOS, so I've been using hacks like: for (const useWebkit of [false, true]) {
// Call both non-webkit and webkit variants on iOS, but only once on Android
if (!useWebkit || Platform.OS === 'ios') {
CookieManager.set(url, cookie, useWebkit);
}
} To me, it would be nice to auto-sync the cookies between the two stores on iOS -- but again, not sure if my usecase is common. |
Yeah the reason behind not defaulting to WebKit is that fetch is using There might be a cleaner design for this. Maybe even moving WebView related cookies to the WebView module #5 Looking to hear from everyone! |
Ah that makes sense now. I think just documenting it clearly would suffice. It's not 100% clear how they are shared so i had to look into Apple docs and read source to confirm. Not the fault of this lib but I can see others being confused by it. |
Sweet ill take this up as a documentation task |
Question
Should we default
useWebKit
totrue
as the default for all static methods? (e.g.CookieManager.clearAll(true)
) Given that react-native-webview from the community has now removed UIWebView entirely (link), it seems it would make sense to default to using WKWebView (akauseWebKit
).This would be a breaking chance, so despite 4.0 just being release it would probably to wait until 5.0 to be released.
Thoughts?
The text was updated successfully, but these errors were encountered: