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

added routing module #382

Merged
merged 4 commits into from
Nov 14, 2018
Merged

added routing module #382

merged 4 commits into from
Nov 14, 2018

Conversation

gavinr
Copy link
Contributor

@gavinr gavinr commented Nov 7, 2018

Beginning of the routing module and the the solveRoute function, covering the solve endpoint of the REST API.

#47

@gavinr gavinr requested a review from jgravois November 7, 2018 14:47
@coveralls
Copy link

coveralls commented Nov 7, 2018

Coverage Status

Coverage remained the same at 100.0% when pulling 207eaab on gavinr:routing-module into ee76650 on Esri:master.

Copy link
Contributor

@jgravois jgravois left a 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
Copy link
Contributor

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
Copy link
Contributor

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",
Copy link
Contributor

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.
Copy link
Contributor

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.
Copy link
Contributor

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;
Copy link
Contributor

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]>;
Copy link
Contributor

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:

/**
* 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.
Copy link
Contributor

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.

@jgravois
Copy link
Contributor

jgravois commented Nov 8, 2018

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 jgravois requested a review from tomwayson November 8, 2018 00:35
@patrickarlt
Copy link
Contributor

@jgravois should we keep common-type for just types and make a separate shared-utils package for shared utility methods?

@tomwayson
Copy link
Member

tomwayson commented Nov 8, 2018

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 @esri/arcgis-rest-common, and start by moving these fns there. We could even move the types there too before a v2 release and deprecate the entire @esri/arcgis-rest-common-types.

@jgravois
Copy link
Contributor

jgravois commented Nov 8, 2018

I think we should go ahead and create @esri/arcgis-rest-common, and start by moving these fns there.

that works for me. i'd be more inclined to go with @patrickarlt's suggestion but the types are already automatically stripped from built umd output and i'm hopeful we could do the same in cjs. if so, and we can make sure only d.ts files are created for types in the esm build, it'd make for another tidy little package.

to do:

  • revert the changes in my last commit and move the shared functions into a second new package called @esri/arcgis-rest-common
  • make sure routing includes common as a dependency and not common-types
  • refactor geocoder to use common at v2.0.0
  • figure out how to help @MikeTschudi with his unrelated problem

@tomwayson
Copy link
Member

just curious, why not refactor geocoder to start using the fns in 'common' now? is that breaking?

@jgravois
Copy link
Contributor

jgravois commented Nov 8, 2018

why not refactor geocoder to start using 'common' now? is that breaking?

exactly.

…ND types

AFFECTS PACKAGES:
@esri/arcgis-rest-common
@esri/arcgis-rest-geocoder
@esri/arcgis-rest-routing
@jgravois
Copy link
Contributor

jgravois commented Nov 9, 2018

okay, i finished refactor (2) and rebased to clean up my own tail of the commit history.

Copy link
Member

@tomwayson tomwayson left a 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

@jgravois jgravois merged commit eeafb6b into Esri:master Nov 14, 2018
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