Skip to content

Using serverUrl constant for batch requests. #153

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

Merged
merged 1 commit into from
Jan 5, 2016

Conversation

peterdotjs
Copy link
Contributor

No description provided.

@codecov-io
Copy link

Current coverage is 79.00%

Merging #153 into master will increase coverage by +0.15% as of e29800d

@@            master   #153   diff @@
=====================================
  Files           37     37       
  Stmts         2833   2839     +6
  Branches       683    684     +1
  Methods          0      0       
=====================================
+ Hit           2234   2243     +9
+ Partial        191    190     -1
+ Missed         408    406     -2

Review entire Coverage Diff as of e29800d

Powered by Codecov. Updated on successful CI builds.

@andrewimm
Copy link
Contributor

Importing url seems like overkill to me.

@peterdotjs
Copy link
Contributor Author

@andrewimm I could take strip out the parsing pieces for the path rather than use the module if you concerned about bloat.

@andrewimm
Copy link
Contributor

// Remove the protocol
var url = serverUrl.replace(/https?:\/\//, '');
var path = url.substr(url.indexOf('/'));

should work, right?

@peterdotjs
Copy link
Contributor Author

That'll work for the current serverUrl config value but I'm also thinking about any corner cases that users might change the value to in the future.

@andrewimm
Copy link
Contributor

And what would those cases be? This works for urls with and without protocol. In a valid URL, slashes can only exist between the protocol and the domain, or within the path, so once the protocol is removed, the first slash is the beginning of the path. Beyond that, setting an invalid value to this will break the entire SDK anyways, so it's not unreasonable to us to say that only valid URLs are supported.

@andrewimm
Copy link
Contributor

Actually, we need the "does it end with a slash?" check to make it really work. Otherwise a value like "api.parse.com" fails. Otherwise, I think it's relatively bulletproof.

@peterdotjs
Copy link
Contributor Author

We'll need to handle the host case as well: https://localhost.com:8080/p/a/t/h

@andrewimm
Copy link
Contributor

@peterdotjs the code works for that:

var url = 'https://localhost.com:8080/p/a/t/h'.replace(/https?:\/\//, ''); // url = localhost.com:8080/p/a/t/h
var path = url.substr(url.indexOf('/')); // path = '/p/a/t/h'

Feel free to unit-test this thing into oblivion

@andrewimm
Copy link
Contributor

My only concern is adding a 650 LOC library to do something that can be done in 1-2 lines.

@peterdotjs
Copy link
Contributor Author

@andrewimm agreed that there are a lot of things in the lib we won't use. I'm sure there will be other cases that come up (//foo/bar) but your 2 line solution should work for most cases.

@andrewimm
Copy link
Contributor

For now, treat it as a private API (it's not like anyone could have their own Parse address anyways, this is basically for our internal tests for now). If we ever publicize it, we can establish expectations and shore up the code, but immediately, I like treating it like a black box.

@andrewimm
Copy link
Contributor

Also, once you land this change, I'd like to cut a release for 1.6.14, which will probably be the last one before 1.7

@peterdotjs
Copy link
Contributor Author

Ready for merging.

@andrewimm
Copy link
Contributor

LGTM, merging.

andrewimm added a commit that referenced this pull request Jan 5, 2016
Using serverUrl constant for batch requests.
@andrewimm andrewimm merged commit cf7f239 into parse-community:master Jan 5, 2016
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.

5 participants