When I was developing I noticed the getUserMedia was returning a promise and this was not documented in ts.
Please fill in this template.
[x] Use a meaningful title for the pull request. Include the name of the package modified.
[x] Test the change in your own code. (Compile and run.)
[ ] Add or edit tests to reflect the change. (Run with npm test.)
[ ] Follow the advice from the readme.
[x] Avoid common mistakes.
[ ] Run npm run lint package-name (or tsc if no tslint.json is present).
Select one of these and delete the others:
If changing an existing definition:
[ ] Provide a URL to documentation or source code which provides context for the suggested changes: <>
[ ] If this PR brings the type definitions up to date with a new version of the JS library, update the version number in the header.
[ ] If you are making substantial changes, consider adding a tslint.json containing { "extends": "dtslint/dt.json" }. If for reason the any rule need to be disabled, disable it for that line using // tslint:disable-next-line [ruleName] and not for whole package so that the need for disabling can be reviewed.
The previous type for `Snapshot<K>` defaulted `K` to `any`, but with a
type constraint for `K` that often resolves to `never`: any time the
`ModelRegistry` has no entries. `any` is not assignable to `never`, so
this always produces a type error with an empty registry.
In general, users have gotten past this by either adding a model to the
registry, if they are using Ember Data, or by removing the Ember Data
types if they are *not* using Ember Data. Both eliminate the type error! However, the
type is strictly *wrong*, and not just in a theoretical sense: it can
and *will* break users who have an Ember addon or app which uses Ember
Data in a composite TS project, because [TS resolves *all* `@types`][1]
unless overridden. For the sub-projects which do not have any entry in
the registry, they get the expected type error: "'any' does not satisfy
the constraint 'never'".
The appropriate default for `K` here is just `keyof ModelRegistry`: this
resolves to `never` when `ModelRegistry` is empty, or the keys of the
registry otherwise, which achieves the goal of users never having to
specify the key manually. The generic becomes effectively an invisible
implementation detail, as it should be.
[1]: https://www.typescriptlang.org/v2/en/tsconfig#types
* chore: format d3-cloud definitions and tests
* fix: change param type for spiral function in d3-cloud
Reference https://github.com/jasondavies/d3-cloud#spiral
* fix: annotate an unused function param in d3-cloud test
* request-promise-apu-generics: Adding generics to request promise API
* request-promise-apu-generics: adding a default generic of type any
Co-authored-by: Puneet Arora <parora@atlassian.com>
* reflect useThemUI return types from official doc
* add simple test case for useThemeUI
* match theme-ui npm version
* match theme-ui npm version
* specify ts version
* remove optional chaining
* specify ts version
* Upgrade to Viewer v7.2
Release notes: https://forge.autodesk.com/blog/viewer-release-notes-v-72
* Upgrade to Viewer v7.4
Release notes: https://forge.autodesk.com/blog/viewer-release-notes-v-74
* Added getDefaultGeometry method
* Added missing methods to Navigation class:
- getWorldPoint
- screenToViewport
* Added missing method to Viewer3DImpl class:
- viewportToRay
* getDocumentNode returns any rather than object
* added interface to specify API endpoint
* move properties to top of the class
Co-authored-by: Jan Liska <jan.liska@autodesk.com>
Dave Brudner