Export deepObserve
's IChange
with more specific name
#322
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.
Adds changes to export the alias of change types supported by
deepObserve
with a slightly less generic name.Also adds more detail to the relevant doc comments.
Export
The alias used by MobX-utils for the
change
parameter ofdeepObserve
, previously namedIChange
, is not currently exported.It only consists of types exported by MobX, though. So, when setting up a listener in an application importing
mobx-utils
, I can define something along these lines to get type information for my listener:Nonetheless, the exact set of supported types of changes could of course change in the future (such as once #298 addressed). So, exporting this alias directly from MobX-utils would provide up-to-date type information directly from the package itself.
Renaming - Rationale
The thinking for renaming
IChange
toIDeepDidChange
is influenced by:Deep
- I thought perhaps it would be good to have something not quite as generic as simply 'change' to reflect the fact that this is coming from MobX-utils, and that there are different types of changes are supported indeepObserve
than in MobX core right now (seen in deepObserve not working with ObservableSet #298)That said, I'm open to a different name than the one proposed, if there is something that better matches MobX conventions or I'm simply reading too much into the conventions here.
Documentation
I'm assuming I should just change the JSDoc comment, as it seems the README is auto-generated before a release? Let me know if that is not the case or I need to update the README as well.
Beyond that, I tried also documenting the callback more thoroughly via a separate JSDoc block, like so:
Which was valid for generation (I tested with
yarn run build-docs
), but the callback was then given the same level of nesting asdeepObserve
(and others) in the README instead of being nested under it (presumably what we'd want). It looks like there is possibly a way to get documentation to do that, though? Let me know if you see value in pursuing that (also for elsewhere)