[WIP] patch 0.3 to support all of v2's API surface area #82
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…PIs with deprecations.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
with deprecations
Unresolved Differences
node.remove, we'll need to do something like this: https://github.com/heimdalljs/heimdalljs-lib/blob/master/src/heimdall-tree/index.ts#L75And/Or finish off the concept of
streamablestats (tokens just can't be array index based only) in order to support a similar feature in-lieu of precise support.heimdall.node()still needs implemented. This convenience wrapper may not belong in the lib anymore, if not it will need to be deprecated.HeimdallTreeshould be updated to output a v2 compatible version of the graph for tooling (for now).support has been added for
heimdall.start(id: Object, schema: Function). Object IDs were converted toannotations. The inline/local schemas were also converted toannotations, but since these represent local "counter" data, we may want a specialized counter-store just for them. This is tricky because unlike monitors, these counts might segment but should not ever be snapshotted / incremented outside of the bounds of the node's start/stop. With the advantages that monitors come with, we may not want to keep a formal primitive around this in favor of users using ad-hoc annotations if needed.