-
Notifications
You must be signed in to change notification settings - Fork 119
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
added routing module #382
added routing module #382
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
awesome work @gavinr! 👨🚀
``` | ||
|
||
```js | ||
todo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to do
solveRoute({
stops: [
[-117.195677, 34.056383],
[-117.918976, 33.812092],
],
authentication
})
.then(response)
// {routes: {features: [{attributes: { ... }, geometry:{ ... }}]}}
|
||
### License | ||
|
||
Copyright © 2017-2018 Esri |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gotta start at 2018 for this one.
@@ -0,0 +1,54 @@ | |||
{ | |||
"name": "@esri/arcgis-rest-routing", | |||
"version": "1.0.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1.13.2
for now. lerna will help us bump to 1.14.0
for the first actual release.
@@ -0,0 +1,23 @@ | |||
/* Copyright (c) 2017 Environmental Systems Research Institute, Inc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2018
@@ -0,0 +1,124 @@ | |||
/* Copyright (c) 2017-2018 Environmental Systems Research Institute, Inc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same
|
||
export interface ISolveRouteRequestOptions extends IEndpointRequestOptions { | ||
stops: Array<IPoint | ILocation | [number, number]>; | ||
travelMode?: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lets nix travelMode
and barriers
until we're actually handling them internally.
} from "./helpers"; | ||
|
||
export interface ISolveRouteRequestOptions extends IEndpointRequestOptions { | ||
stops: Array<IPoint | ILocation | [number, number]>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can see an example of how to include inline TSDoc for an interface property like stops
here:
arcgis-rest-js/packages/arcgis-rest-geocoder/src/helpers.ts
Lines 19 to 22 in 4af2014
/** | |
* Any ArcGIS Geocoding service (example: http://sampleserver6.arcgisonline.com/arcgis/rest/services/Locators/SanDiego/GeocodeServer ) | |
*/ | |
endpoint?: string; |
* }); | ||
* ``` | ||
* | ||
* @param address String representing the address or point of interest or RequestOptions to pass to the endpoint. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@param requestOptions Options to pass through to the routing service.
i decided to kill two birds with one stone and reorganize a few of the utility methods and interfaces you copied from the 'geocoder' package and put them in 'common-types' so they can be shared instead. this should resolve the problem @MikeTschudi reported in Esri/solution.js#3 (comment) as well. can you sanity check me please @tomwayson? |
@jgravois should we keep |
I definitely think we should not have fns in common-types. I really like what @jgravois set up for hub.js where there is a "common" package that has types and fns, and I think for rest-js v2.0 we should do exactly that. I understand why it would seem to make sense to just start using common-types like that now, but the problem is that it's name suggests, and up until now our convention has been, that it's an optional dependency that you only need if you're using TS. I don't think it's a good idea to all of the sudden make it actually required in some cases. In the meantime, I think we should go ahead and create |
that works for me. i'd be more inclined to go with @patrickarlt's suggestion but the types are already automatically stripped from built to do:
|
just curious, why not refactor geocoder to start using the fns in 'common' now? is that breaking? |
exactly. |
…ND types AFFECTS PACKAGES: @esri/arcgis-rest-common @esri/arcgis-rest-geocoder @esri/arcgis-rest-routing
okay, i finished refactor (2) and rebased to clean up my own tail of the commit history. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is the start of something beautiful
Beginning of the routing module and the the
solveRoute
function, covering the solve endpoint of the REST API.#47