State observation via returning callbacks#3
Draft
Hexcede wants to merge 7 commits into
Draft
Conversation
67eb265 to
af2029d
Compare
af2029d to
45c317b
Compare
This file contains hidden or 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
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.
Based on #2
This pull request aims to provide big usability improvements to the
observelibrary by introducing new callback based APIs for representing raw data.The new APIs reduce the amount of boilerplate required to write observers for things like Fusion states, which in the current version of
observerequires extra intermediate Signal objects to be instantiated.observeinstead of signals passed toobserve.Stateobservers:Value, which returns acleanup&onChangedfunction. TheonChangedfunction, when called, will update the state of the observer.ClearableValue, which is almost identical toValue, except a value ofnilis treated as a clear and does not invoke the handler (but does invoke cleanup).nilvalues, which is a common pattern. It is used by the existingChildandSetClearSignalsobservers.Clearable.Arrayfor unordered arrays, which returns acleanup,onAdded, andonRemoved.Setfor sets, returns acleanup,onAdded, andonRemovedcallback.onAddedwill currently NOT invoke cleanup & re-invoke the handler on re-insertion of a value already present in the set. I am currently unsure if this is good in practice. The alternative would be more in-line with what existing observer APIs do even if it's a bit wasteful.DistinctArrayfor arrays with distinct (unique, non-duplicate) items. Identical toSet, other than its initial value being an array instead of a set.Set, no re-invocation on re-insertion.DistinctArraycurrently has duplicated code used inSet. It might be desirable to removeDistinctArrayand expect users to useSetthemselves, or to alternatively implementDistinctArrayusingSetunder the hood, simply passing in a blank array and adding the values using the callbacks. Should resolve this after Strict typing #2 is either merged or rejected.Mapfor maps, which returns acleanup&onChangedfunction. TheonChangedfunction takes a key and value argument. The handler also takes both a key and a value. Otherwise, works exactly how you would expect.