compact, modular JavaScript wrappers for ArcGIS Hub that run in Node.js and modern browsers.

• Example
• API Reference
• Instructions
• Packages
• FAQ
• Issues
• Versioning
• Contributing
• Code of Conduct
• License

npm install @esri/hub-initiatives

import { fetchInitiative  } from '@esri/hub-initiatives';

// pass in an initiative id
fetchInitiative("abc123")
    .then(
        response => // get back initiative metadata
    );

The documentation is published at http://esri.github.io/hub.js/ (source code here).

You can install dependencies by cloning the repository and running:

npm install

Note: This project uses volta to manage node/npm versions. We strongly suggest you do to :)

Afterward, for a list of all available commands run npm run.

Some useful commands include:

• npm test runs all the tests and confirms the API is functioning as expected.
• There is also a Debug Node Tests configuration in the .vscode/launch.json which will run the Node tests in the VS Code debugger.
• npm run test:chrome:debug runs all the tests in a browser, and will re-run when changes are made. Note: in some situations, spies/stubs will fail on subsequent test runs. We are not certain why this occurs, but the resolution is to stop/start the test runner.
• npm run docs:serve will run the documentation site locally at http://localhost:3000
• npm run build will run the ES5, ESM, CJS and UMD build for all the packages

• @esri/hub-common - Common TypeScript types and utility functions.
• @esri/hub-discussions - Module to interact with ArcGIS Hub Discussions API
• @esri/hub-downloads - Helper functions for working with downloads.
• @esri/hub-events - Helper functions for working with Events.
• @esri/hub-initiatives - Helper functions for working with Initiatives.
• @esri/hub-search - Helper functions for search on ArcGIS Online.
• @esri/hub-sites - Helper functions for working with Sites, Pages and Domains.
• @esri/hub-surveys - Helper functions for working with Surveys.
• @esri/hub-teams - Helper functions for working with ArcGIS Online groups in a Hub context.

• @esri/hub-annotations - Hub Annotations have been replaced with Hub Discussions, see @esri/hub-discussions
• @esri/hub-auth - moved to @esri/hub-common
• @esri/hub-types - moved to @esri/hub-common
• @esri/hub-content - moved to @esri/hub-common

hub.js is designed as a set of data manipulation functions, not persistent objects with behavior. You should not use new in conjunction with this library. Just include the modules your application needs and use them to hide lower-level abstractions for making API calls for hub related things. Your application should manage the state of the data you receive from these methods.

This project builds on the packages in arcgis-rest-js, so if you want even lower-level access, you can also use them directly.

Persistent objects often introduce memory leaks in JavaScript applications. As soon as you instantiate a new object, you need to consider its lifespan. If you happen to assign that object inside a closure or somewhere else long-lived, you might end up with references that cannot be destroyed by the garbage collector. Creating clean separation between functions-that-fetch-or-manipulate-data and application-state-as-a-javascript-object helps to avoid this problem.

We are aiming for functional equivalence to hub-py so that the objects and capabilities are familiar, not necessarily to make the APIs identical.

More about Javascript Memory Leaks

• Is this a supported Esri product?
• Why TypeScript? What if I prefer Vanilla.js?

If something isn't working the way you expected, please take a look at previously logged issues first. Have you found a new bug? Want to request a new feature? We'd love to hear from you.

If you're looking for help you can also post issues on GIS Stackexchange.

For transparency into the release cycle and in striving to maintain backward compatibility, @esri/hub.js is maintained under Semantic Versioning guidelines and will adhere to these rules whenever possible.

For more information on SemVer, please visit http://semver.org/.

This project uses semantic release which is automated release tooling that uses commit messages to determine the correct semantic version for any given release.

The process of initiating a release is simple: merge a PR into the master or beta branches, and semantic release will look at the included commits, compute the next version, and release the packages to NPM.

This system is founded in the use of the Angular Commit Message Format

<type>(<scope>): <short summary>
  │       │             │
  │       │             └─⫸ Summary in present tense. Not capitalized. No period at the end.
  │       │
  │       └─⫸ Commit Scope: hub-common | hub-content | hub-discussions | hub-downloads | hub-events | hub-initiatives | hub-search | hub-sites | hub-surveys | hub-teams (can also be left blank)
  │
  └─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|test

The <type> and <summary> fields are mandatory, the (<scope>) field is optional.

Must be one of the following:

• build: Changes that affect the build system or external dependencies
• ci: Changes to our CI configuration files and scripts
• docs: Documentation only changes
• feat: A new feature
• fix: A bug fix
• perf: A code change that improves performance
• refactor: A code change that neither fixes a bug nor adds a feature
• test: Adding missing tests or correcting existing tests

Important Note:

Not all of the commit types above will result in a new release being published to Github and NPM. Specifically, docs, refactor and test do not automatically trigger a release. If you need a release to be automatically published when you merge your pull request, please be sure to include at least one commit message using one of the other types listed above. If you find yourself in this situation after having already merged, you can manually trigger a build by issuing an empty commit directly against the master or beta branches, e.g. git commit --allow-empty -m "fix(): A descriptive patch message" or git commit --allow-empty -m "feat(): A descriptive minor message".

To specify a breaking change, you need to use a multi-line commit message, and start a line with BREAKING CHANGE.

fix(): solve i18n issue in arcgis-hub-content-gallery

BREAKING CHANGE: i18n strings must be loaded from a new location

If you are writing commit messages at the console, you can do this by just hitting enter twice while writing the commit message, before closing the quotes.

$ git commit -m 'fix(): solve i18n issue in arcgis-hub-content-gallery

BREAKING CHANGE: i18n strings must be loaded from a new location'

Commit messages are run through commitlint using husky pre-commit hooks.

Please do not use --no-verify unless you are really sure you must.

Copyright © 2018-2019 Esri

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

A copy of the license is available in the repository's LICENSE file.