uploadContent: Attempt some consistency between browser and node #230
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Make sure we parse the json content of errors from uploadContent before trying to turn them into MatrixErrors.
Previously, the API for uploadContent differed wildly depending on whether you were on a browser with XMLHttpRequest or node.js with the HTTP system library. This lead to great confusion, as well as making it hard to test the browser behaviour. The browser version expected a File, which could be sent straight to XMLHttpRequest, whereas the node.js version expected an object with a `stream` property. Now, we no longer recommend the `stream` property (though maintain it for backwards compatibility) and instead expect the first argument to be the thing to upload. To support the different ways of passing `type` and `name`, they can now either be properties of the first argument (which will probably suit browsers), or passed in as explicit `opts` (which will suit the node.js users). Even more crazily, the browser version returned the value of the `content_uri` property of the result, while the node.js returned the raw JSON. Both flew in the face of the convention of the js-sdk, which is to return the entire parsed result object. Hence, add `rawResponse` and `onlyContentUri` options, which grandfather in those behaviours.
richvdh
force-pushed
the
rav/uploadContent_platform_consistency
branch
from
f932e0b
to
4794dfc
Compare
dbkr
approved these changes
Oct 10, 2016
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, the API for uploadContent differed wildly depending on whether you were on a browser with XMLHttpRequest or node.js with the HTTP system library. This lead to great confusion, as well as making it hard to test the browser behaviour.
The browser version expected a File, which could be sent straight to XMLHttpRequest, whereas the node.js version expected an object with a
streamproperty. Now, we no longer recommend thestreamproperty (though maintain it for backwards compatibility) and instead expect the first argument to be the thing to upload. To support the different ways of passingtypeandname, they can now either be properties of the first argument (which will probably suit browsers), or passed in as explicitopts(which will suit the node.js users).Even more crazily, the browser version returned the value of the
content_uriproperty of the result, while the node.js returned the raw JSON. Both flew in the face of the convention of the js-sdk, which is to return the entire parsed result object. Hence, addrawResponseandonlyContentUrioptions, which grandfather in those behaviours.(Includes #229)