-
Notifications
You must be signed in to change notification settings - Fork 30
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
watch is a stream #121
base: main
Are you sure you want to change the base?
watch is a stream #121
Conversation
this.range = range | ||
this.current = null | ||
this.previous = null | ||
this.map = opts.map || null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
map and unmap are already set in the superclass. Would either handle completely there, or completely in the subclasses.
KeyWatchStream
only seems to have map
and no unmap
, and no concept of _mapped
either, so probably makessense to keep in subclass
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The opened logic could live fully in the superclass btw, and the subclasses just need to overwrite _setup
--now it lives in both (sueprclass still has this.opened
)
this._differ = opts.differ || defaultDiffer | ||
this._checkout = opts.checkout || (opts.eager ? 1 : 0) | ||
|
||
this.opened = this._setup() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The opening flow is a bit confusing compared with how we do it elsewhere, normally this.opened
is a bool (in ready-resource). Not sure what the standard for streams is though
How about calling it this.opening
and exposing an async ready() { return this.opening }
method? That way the api is compat with ready resource
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can it opened on other streams in the stack so named it this for consistency. also you shouldn’t really use this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case it makes sense to keep the stream naming. Do note that await watcher.opened
is documented in the readme
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah ok, we should kill that. the stream already emits open when its open, so its mostly a stream concern anywho
}) | ||
|
||
if (!(await this._didRangeChange())) return null | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sanity check: no need for the if (this.destroying) return null
check here? (not sure if _didRangeChange
can return true with the stream being destroyed before this is code is reached)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea! Will add
Some changes to the experimental watch api