Implement lightweight OptimisticDependencyFunction<TKey> primitive. #50
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.
While just about any kind of dependency can be modeled with an
OptimisticWrapperFunction<TArgs, TResult>
, many sources of cache invalidation signals do not require the full machinery of wrapped functions:makeCacheKey
,[un]subscribe
functions, the ability to rerun the wrapped function to compute the latest value, and everything that comes with the internalEntry
class.Previously, these simpler use cases were handled by "disposable" wrapper functions, which were essentially just ordinary wrapper functions that never returned a value and could be recycled when they became orphans. Despite these restrictions, disposable wrapper functions were still just as expensive as full-featured wrapper functions, so we weren't really capitalizing on the opportunity to do less work.
For dependencies that will never have children of their own, and do not need to compute an expensive result, we can get away with something much simpler:
With this dependency logic, you can call
dependOnDirectory.dirty(directoryPath)
to dirty all cachedoptimisticReadFile
results that previously depended ondirectoryPath
(because the wrapped function calleddependOnDirectory(dirname(filePath))
wheredirname(filePath) === directoryPath
).Using the
dep<TKey>()
API makes sense when you can provide a singleTKey
value that uniquely identifies the dependency, rather than a series of arguments that need to be transformed bymakeCacheKey
.Using
dep
also implies the dependency is not associated with a function that computes a value. Instead, thedependOnDirectory
dependency exists purely to record dependencies viadependOnDirectory(directoryPath)
so thatdependOnDirectory.dirty(directoryPath)
can be called at a later time to invalidate any/all enclosing computations.Because these new
OptimisticDependencyFunction<TKey>
functions cannot have child dependencies of their own, they are appropriate for modeling leaves in your dependency graph/tree/DAG. Because these dependencies are lighter-weight than wrapped functions, you should see significant performance benefits from handling your leaves in this way.