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

map-specific access token #8364

Merged
merged 19 commits into from
Jul 10, 2019
Merged

map-specific access token #8364

merged 19 commits into from
Jul 10, 2019

Conversation

peterqliu
Copy link
Contributor

@peterqliu peterqliu commented Jun 18, 2019

Launch Checklist

solves #6331

Adds an accessToken parameter to Map options, that optionally overwrites the token specified in mapboxgl.accessToken for just that map.

  • briefly describe the changes in this PR
  • write tests for all new functionality
  • document any changes to public APIs
  • post benchmark scores
  • manually test the debug page

@@ -50,6 +50,19 @@ test('Map', (t) => {
t.end();
});

// t.test('map-specific token', (t) => {\
Copy link
Contributor Author

Choose a reason for hiding this comment

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

How can we instantiate a map with a bad token?

Would like to add a test for the positive case, where it starts with mapboxgl.accessToken = badtoken but gets overwritten by a valid token inside the map options.

Copy link
Contributor

Choose a reason for hiding this comment

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

How can we instantiate a map with a bad token?
The unit tests don't exercise any access token specific logic.

Map options are set-only with no ability to read back to options that were used to instantiate a map object. Since the access token is passed through to the RequestManager unit tests are probably suited to the behavior of that class.

@peterqliu peterqliu marked this pull request as ready for review June 18, 2019 22:04
debug/token.html Show resolved Hide resolved
@@ -50,6 +50,19 @@ test('Map', (t) => {
t.end();
});

// t.test('map-specific token', (t) => {\
Copy link
Contributor

Choose a reason for hiding this comment

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

How can we instantiate a map with a bad token?
The unit tests don't exercise any access token specific logic.

Map options are set-only with no ability to read back to options that were used to instantiate a map object. Since the access token is passed through to the RequestManager unit tests are probably suited to the behavior of that class.

src/util/mapbox.js Outdated Show resolved Hide resolved
src/util/mapbox.js Outdated Show resolved Hide resolved
@peterqliu
Copy link
Contributor Author

bit stumped by the no-unused-vars lint error -- the flagged variable is used at https://github.com/mapbox/mapbox-gl-js/pull/8364/files#diff-3bdcadb35be47763a1abccc9707d22e0R375

Copy link
Contributor

@asheemmamoowala asheemmamoowala left a comment

Choose a reason for hiding this comment

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

@ryanhamley @peterqliu IS there a reason to separate the implementation of the normalize...URL methods from the RequestManager? This PR would be a lot simpler if those were flattened, and all access to a token was through a RequestManager#accessToken() method.

src/util/mapbox.js Show resolved Hide resolved
src/index.js Outdated
@@ -70,6 +70,7 @@ const exported = {
},

set baseApiUrl(url: string) {
console.log('setting');
Copy link
Contributor

Choose a reason for hiding this comment

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

console.log

@ryanhamley
Copy link
Contributor

IS there a reason to separate the implementation of the normalize...URL methods from the RequestManager? This PR would be a lot simpler if those were flattened, and all access to a token was through a RequestManager#accessToken() method.

@asheemmamoowala I'm not sure I follow. the normalize...URL methods aren't being separated from RequestManager in this PR. Flattening them is hard because they have the same or similar signatures and it would be hard to know which method to call internally based on inputs. You could definitely have a RequestManager#accessToken() getter/setter but it would have to be an instance method which doesn't really help in getting the token in the normalize...URL methods.

@asheemmamoowala
Copy link
Contributor

Flattening them is hard because they have the same or similar signatures and it would be hard to know which method to call internally based on inputs.

Why do the methods need to exist outside the RequestManager class? They are no longer exported, so the implementation could live within the RequestManager entirely.

You could definitely have a RequestManager#accessToken() getter/setter but it would have to be an instance method which doesn't really help ...

The RequestManager#accessToken getter will need to be public so that access token can be shared with Telemetry event types

Copy link
Contributor

@asheemmamoowala asheemmamoowala left a comment

Choose a reason for hiding this comment

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

There is one instance of config.ACCESS_TOKEN in src/ui/attribution_control.js that needs to be updated to reference the map-specific access token as well.

@ryanhamley
Copy link
Contributor

Ohhh I get what you're saying @asheemmamoowala. Yes, they could be moved into the RequestManager class. This PR didn't move them out of the class though. They just were never in it. Even if we moved the implementations into RequestManager, I'm not sure we could flatten them though.

@peterqliu
Copy link
Contributor Author

sounds like something we could tackle in a future PR 👍 @asheemmamoowala @ryanhamley do you see any other blockers to this one?

@ryanhamley
Copy link
Contributor

ryanhamley commented Jul 4, 2019

Agreed that we can refactor in a separate PR

Did you see Asheem's comment above @peterqliu?

There is one instance of config.ACCESS_TOKEN in src/ui/attribution_control.js that needs to be updated to reference the map-specific access token as well.

@peterqliu
Copy link
Contributor Author

👍 done ^

Copy link
Contributor

@ryanhamley ryanhamley left a comment

Choose a reason for hiding this comment

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

Looks good! 🎉

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.

3 participants