First fn should probably be getEventServiceUrl(orgId). See the events API documentation for the query for that.

see Esri/arcgis-rest-js#255, #259

https://github.com/ArcGIS/Hub/blob/master/api.md#attendees-of-an-event

This line sends an unauthenticated request:

I think that will only work for public user accounts. Other user accounts prob return 403.

Also https://github.com/Esri/arcgis-rest-js/pull/243/files is blowing up my https app. Generally it would be a good idea to handle errors for each user request so we still return annos and whatever users are visible. Makes me pine for allSettled.

and make it grab the data by default.

searchAnnotations currently returns an additional included object with additional fields from the user accounts populated (e.g. portal item id, full name, etc...).

It would be quite useful to also populate the thumbnailUrl.

Like Esri/arcgis-rest-js#342, but for Hub.js

from @ajturner:

Currently, searchAnnotations requires the Feature layer url:

arcgisHub.searchAnnotations({url: annotationsUrl + "/0"}).then( response => {});

This is unnecessarily complex for developers and exposes the implementation of annotations. Instead, it should default to the Org annotations, or build the right feature layer.

arcgisHub.searchAnnotations({org: '...'})

arcgisHub.getAnnotationServiceUrl("...").then(
  annotationsUrl => {
    arcgisHub.searchAnnotations({url: annotationsUrl}).then( response =>  {});
 }
);

A few suggested changes for the initiative guide pages:

• initiatives not be under Getting Started, but should have their own top-level entry in the TOC like "Working with Initiatives"
• "Using the Initiatives "Coarse-Grained API" should just be "Create an Initiative", we can splain' there are 2 APIs (coarse and fine grained) in the description
• all the code snippets use fetchInitiative() and need to be updated to getInitiative()

We should add a "Using ES Modules" section under getting started like https://esri.github.io/arcgis-rest-js/guides/babel-and-webpack/ or https://esri.github.io/arcgis-rest-js/guides/babel-and-rollup/ - also, those 2 pages should just be combined into 1 "From ES Modules" why be hyper specific about what transpiler and bundler people use?

Improving the Getting Started experience by:

• Removing "abc123" and add something like , like this the code does not run and the user knows they have to replace it with something
• Give an example of an initiative ID, e.g. a public initiative, or maybe even set up and link to a public one that is intended for the demo
• Give guidance on how to find initiative ID (e.g. open initiative, copy item id from URL)
• As the initiative linked for the demo needs to be public (otherwise not accessible), mention the sharing settings as a precondition so that the demo works.

While it would be nice to mirror the Hub.py API, Python and JS are different languages, used in different contexts. For JS that runs in a browser, there is a real cost to adding bits that don't get used (like CRUD operations that won't get used in a read-only site), and potential memory leaks left around by objects that aren't destroyed. In those scenarios it's preferable to compose your application out of dependencies that expose stateless functions - like https://github.com/Esri/arcgis-rest-js/

If we need to mirror the Hub.py API, then maybe we just add a top level package to this repo that consumes the the libraries that expose stateless functions and exposes a hateful stateful API (const hub = new Hub(myCommunityOrgUrl)) that does all the things.

When adding annotations, some fields seem to be required:

• target
• author
• description
• created_at (?)

First 3 are in the example, but last one is just throwing an error when not specified. We are using the latest npm packages (last release).

Since annotations are backed by a feature service this will wrap queryFeatures(). Events will work the same way and I previously proposed searchEvents(eventServiceUrl, queryParams). That raises few questions.

Do we use the search or query prefix? The former is consistent w/ Hub.py, the latter w/ arcgis-rest-js. I think it's more important to be consistent w/ Hub.py.

Do we pass the url as the first param? So: searchAnnotations(annotationServiceUrl, queryParams). Or do we follow the pattern of just passing opts that is used by the the current implementation?

A number of fields seem to be 'locked' on the AGOL service when a new annotation service is created. This did not happen before (about 2 weeks ago), maybe just an issue with the current release:

It seems those fields are not populated correctly which causes the query (fetching the annotation service to be displayed in the SceneView) to fail (e.g. no author specified). author cannot be assigned anymore as shown in the example as a string (https://esri.github.io/hub.js/api/annotations/addAnnotations/).

In the docs there are refs to unpkg urls that use the hub- package names

i.e. https://unpkg.com/@esri/[email protected]/dist/umd/hub-annotations.umd.js

The correct url would be
https://unpkg.com/@esri/[email protected]/dist/umd/annotations.umd.js

Currently, there are multiple synonymous method prefixes that conceptually mean the same:

fetch vs. get vs. lookup vs. search

For the developer user - can we choose one that applies to all "READ" type operations, even if the implementation requires more complex operations. For example, can fetchInitiative and lookupSiteUrlByInitiative become getInitiative and getInitiativeSite?

Currently, searchAnnotations requires the Feature layer url:

arcgisHub.searchAnnotations({url: annotationsUrl + "/0"}).then( response => {});

This is unnecessarily complex for developers and exposes the implementation of annotations. Instead, it should default to the Org annotations, or build the right feature layer.

arcgisHub.searchAnnotations({org: '...'})

arcgisHub.getAnnotationServiceUrl("...").then(
  annotationsUrl => {
    arcgisHub.searchAnnotations({url: annotationsUrl}).then( response =>  {});
  }
);

The createAnnotationService function only allows to add orgId and authentication (correct?). I would have expected to see more like activateInitiative where a name can be specified as well as a group.

We expect to have the annotation service also being analyzed/retrieved through ArcGIS Online in a first version of Urban, so it would be good to being able to give it a proper name.

• bump to TS 3
• fix active links
• bump gh-release
• fix TypeDoc compilation errors

https://esri.github.io/hub.js/api/common/

its too cryptic to ask folks to dig into our fab tests.

ref: #111 (comment)

need to stash a couple encrypted environment variables for Travis

When trying to access an initiative which lives in an Enterprise organization, the following error appears (might be unrelated to this):

This does not let me open the demo of the Getting Started CDN sample.

Initiative Item ID: d2d8791e5fb846049193b877935b3435
Initiative Website: http://test-initiative-arcgis-urban-dev.opendata.arcgis.com/

First fn should probably be getAnnotationServiceUrl(orgId). We don't have the API documented for this, but here's the current implementation.

https://esri.github.io/hub.js/api/annotations/searchAnnotations/

The samples in add, update, and delete all seem fine.

See https://github.com/ArcGIS/opendata-ui/blob/c3611ae40a61ea4a4c1b24083c4454f68ac904f2/packages/ember-arcgis-layout-cards/addon/services/follow-initiative.js

Apps that are related to a Hub (and/or a specific initiative) would like a single (or few) fn call(s) that they can make to get all the information they will need to provide a seamless experience that is integrated with the initative/Hub.

As a rough cut of what such function could look like, I propose taking an initativeId as a string and returning the JSON proposed in https://devtopia.esri.com/Beijing-R-D-Center/ExperienceBuilder/pull/182/files#diff-d31e367decde8d27039b2d23659be3c2R73

As seen here:

https://devtopia.esri.com/Beijing-R-D-Center/ExperienceBuilder/blob/88f6c5d42d5efa401107eeeea1577bde068d071d/design/spec/hub.md#example-hub-configuration

I'm open to suggestion on that. For one thing, we should probably also include an array of indicators: [{....}] under the initiative. Also, we may find that this naturally decomposes into at least 2 fns, one for getting the info specific to initiative, and one for getting the "Hub" info.

Notice how I've artfully dodged the question of what to name these fns, I'll leave that as an exercise for the reader. 😉

After Esri/arcgis-rest-js#240 lands, we'll want to add fn here (in the fabled @esri/hub-auth package) that wraps beginOAuth2 and before returning the session will:

• fetch the user record
• see if they've just been created
• sets their access level to pubilc
• tags them w/ the hub org
• adds them to the hubRole:participant

Relevant code: https://github.com/ArcGIS/opendata-ui/blob/cfbcc8541de10ca67311375a59745e12c1cb5d3f/packages/opendata-ui/app/components/od-sign-in-modal/component.js#L93-L102

An uber package that will make it easier to use the stateless libraries.

Example:

import Hub from '@esri/hub'; // the only import you'll ever need

const config = { orgId : 'awefa' };
const hub = new Hub(config);`
hub.signIn(); // uses @esri/hub-auth and @esri/arcigs-auth under the hood
.then(() => {
  hub.getInitative('3ef'`); // uses @esri/hub-initiatives under the hood
  hub.getAnnotations({ // use @esri/hub-annotations, look ma, no url!
    where: "status='pending"
  });
  // hub.getEvents({...});
  // hub.getEventDetails(123456);
  // and so on
});

This should also help align w/ the python API #13.

Start w/ getDomain() - see #3 (comment)

packages/initiatives/dist/umd/@Esri/hub-initiatives.umd.js

our custom `IRequestOptions' interface should account for that.

I've already wanted this for fetching users, and the upcoming implementation of creating initiatives that we're going to port from the Hub relies heavily on allSettled and hashSettled.

Do we just make RSVP a dependency of this library? Will that end up being de-duped in Ember apps?

Or do we bring in a standalone implementation?

After #21 we can add the fns to fetch events by org, initiative, etc listed in #13 (comment)

Repro:

• add an annotation anonymously (results in empty author field)
• run searchAnnotations(...)
• a request is made to https://www.arcgis.com/sharing/rest/community/users/?f=json which fails with message: "You do not have permissions to access this resource or perform this operation."
• this throws an error which is not handled

Adding search option where: "author <> ''" solves the problem, but like this, we cannot fetch the anonymous comments.

Repro:

• run searchAnnotations({ url, authentication, returnGeometry: true })
• request to the server is correct (returnGeometry: true) and returns the geometry
• returned data object does not contain the geometries

Maybe start w/ a fn to read the auth out of the cookie and fallback to localStorage like this?

https://github.com/Esri/arcgis-rest-js/blob/7ab02af0a6ed86cf0f526609df4f27dac97fde8c/support/changelog.js#L79-L85

and link from readme

A modular, high quality toolkit for working with ArcGIS Hub.

the above would be an improvement. bonus points for injecting something more specific in individual API ref pages.

It's odd that addAnnotations requires adds: [] - which seems redundant to the actual name. This is because the function is a thin wrapper to feature service, but unnecessary for these focused functions.

arcgisHub.addAnnotations({url: annotationsUrl + "/0", adds: [
              {attributes: {description: "Test Anonymous", target: "none", author: "Hamilton"}}
            ]}).then( response => {
              console.log("addAnnotations", response);
          });

should become

arcgisHub.addAnnotations({url: annotationsUrl, annotations: [
              {attributes: {description: "Test Anonymous", target: "none", author: "Hamilton"}}
            ]}).then( response => {
              console.log("addAnnotations", response);
          });

Call https://www.npmjs.com/package/@esri/telemetry .logEvent() if an instance of Telemetry is provided.

This probably makes the most sense after #75 since we'll probably want something like this:

import Hub from '@esri/hub';
import Telemetry from '@esri/telemetry';

const telemetryConfig = { /* base telemetry config here */ };
const hubConfig = { orgId : 'awefa', telemetry: { /* hub specific telemetry config here */ } };
const hub = new Hub(hubConfig);
hub.teletmetry = new Telemetry(telemetryConfig);
hub.signIn()
.then(() => {
  hub.getInitative('3ef'`); // calls hub.telemtry.logEvent() after calling @esri/hub-initative getInitiative()
});

The hub specific telemetry config might map hub.js packages/functions to categories/actions.

Also, having it as a property would expose telemetry to so that the app can use it for non-hub specific things like:

// after transitioning to a route
hub.telemetry.logPageView(options);

As proposed by Andrew: https://gist.github.com/ajturner/cd7b927b387b360e4c1f20a0f6a34014

We propose to add the following functions to hub.js:

• add positive or negative vote to an annotation (e.g. addAnnotationVote)
• get positive votes for an annotation (e.g. searchAnnotationUpVotes)
• get negative votes for an annotation (e.g. searchAnnotationDownVotes)

A thin wrapper around searchItems() and should at least support the params listed in #13 (comment)

This will underpin the fetchOrgInitiatives(orgId) fn also listed in ^^^, which probably can be included in the same PR.

With those two and the existing fetchInitiative(), we'll have functional parity w/ Hub.py for initiatives.

See: https://github.com/ArcGIS/Hub/blob/master/api.md#register-for-an-event

example: https://esri.github.io/hub.js/api/annotations/deleteAnnotations/

Function defined in packages/annotations/src/delete.ts:16