Skip to content

React native/pass http error code#11001

Merged
mchowning merged 6 commits intodevelopfrom
react-native/pass_http_error_code
Jan 31, 2020
Merged

React native/pass http error code#11001
mchowning merged 6 commits intodevelopfrom
react-native/pass_http_error_code

Conversation

@mchowning
Copy link
Copy Markdown
Contributor

Updates to version of FluxC that returns full error object for failed requests. Takes that full response and extracts the http error code from it and passes that along to mobile gutenberg.

⚠️ Before merging this PR, the associated FluxC PR should be merged and the FluxC version reference here should be updated.

Why We're Using a Bundle To Pass Error Information

This error information has to be passed from the WordPressmodule to the WordPressEditor module and then to the react-native-gutenberg-bridge module. In other words, WordPress depends on WordPressEditor, which depends on react-native-gutenberg-bridge. WordpressEditor, however, only has react-native-gutenberg-bridge as an "implementation" dependency (I'm guessing this was done for the very good reason of wanting to keep the core app clean of any React Native dependencies). As a result, WordPress does not know anything about react-native-gutenberg-bridge and react-native-gutenberg-bridge knows nothing about either WordPress or WordPressEditor.

This means that if we made a class to hold the error data, no matter where we put it, one of either WordPress or react-native-gutenberg-bridge would not be able to use it. Instead, we would be forced to have one class in WordPressEditor for passing the error data from WordPress to WordPressEditor. Then, inside WordPressEditor, we would have to convert that first data class to a new data class from react-native-gutenberg-bridge, so that the information could be passed to that module (because react-native-gutenberg-bridge would not know about the class from WordPressEditor).

Not only would we need these two, essentially identical, data classes, however. We would also need to convert the data class from react-native-gutenberg-bridge into a kind of object that can be sent over the javascript bridge to React Native (WritableMap). Fortunately, React Native has a helper method to automatically convert a Bundle into a WritiableMap.

FWIW, one other option would be to use a Map<String, Object> instead of a Bundle. React Native also has a helper to convert that kind of object to a WritableMap. I did not go with that approach because that has even less type-safety than a Bundle.

If you think there's a better way to handle this, please let me know. It just seemed that using a well-typed data class with these errors would require a substantial amount of boilerplate for little, if any, gain since that data would then just have to be convered into a WritableMap, which is essentially the same thing as a Bundle.

To Test

See test steps in wordpress-mobile/gutenberg-mobile#1686

PR submission checklist

  • I have considered adding unit tests where possible.

  • I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

@peril-wordpress-mobile
Copy link
Copy Markdown

peril-wordpress-mobile bot commented Dec 20, 2019

You can test the changes on this Pull Request by downloading the APK here.

putString("message", it)
}
}
onError(bundle)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if it's possible but what about sending a Pair instead? It seems less error prone than a bundle 🤷‍♂

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pair is actually what I used for my first implementation of this. 😀

I decided to use a Bundle instead because I had to convert the Pair to a Bundle-like React Native object (WritableMap) that can be sent across the javascript bridge to React Native (like with saving instance state for Activities you can only send a few special kinds of objects across the javascript bridge). That conversion involves exactly the same kind of putString(...) and putInt(...) calls that I am doing here, so it didn't seem like Pair was gaining me anything, it was just moving the place where I did the "risky" putX(...) calls. Using a Bundle directly seemed to make since on account of the fact that React Native has a helper method for converting a Bundle to a WritableMap automatically.

There is a helper for converting Map<String, Object to WritableMap as well, but that actually seemed less safe since we would have no type safety to insure that we only put objects into the map that could be sent across the bridge.

Using Bundle directly also seemed like a better longterm approach since if/when (most likely when) we end up wanting to pass a third piece of information from the error, I think we would need to convert this back from a Pair to a Bundle or start nesting Pair<Pair<>>. 😱 (

An alternative approach would be to change WordPress-Editor to use react-native-gutenberg-bridge as an api dependency instead of an implementation dependency. That would allow us to define a well-typed object for the relevant error information in react-native-gutenberg-bridge and use that object here in WordPress-Android (transitively, via the Editor module). I feel like this might actually end up being the best longterm solution, but it adds React Native dependencies to the WordPress app itself (as opposed to just being implementation dependencies of the Editor module) and I don't feel comfortable that I've thought through all the implications of doing that yet. wdyt?

@jkmassel jkmassel modified the milestones: 14.0, 14.1 Jan 14, 2020
@maxme maxme modified the milestones: 14.1, 14.2 Jan 27, 2020
Copy link
Copy Markdown
Contributor

@marecar3 marecar3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!
Probably we want to update this with the latest develop?

@mchowning mchowning force-pushed the react-native/pass_http_error_code branch from 6ad955f to 3ca029e Compare January 28, 2020 18:31
@mchowning mchowning merged commit d330001 into develop Jan 31, 2020
@mchowning mchowning deleted the react-native/pass_http_error_code branch January 31, 2020 17:53
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.

6 participants