Introduce eager option to function-based modifiers
#222
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
chriskrycho
force-pushed
the
function-base-modifier-eager
branch
2 times, most recently
from
611a008
to
e24b69c
Compare
This was referenced Mar 24, 2022
Closed
Introduce an options argument to the `modifier()` function used to
create function-based modifiers, with a single initial option: `eager`.
Passing `{ eager: false }` opts out of the previous default beahvior of
eagerly consuming all arguments, so that function-based modifiers can
have normal auto-tracking semantics -- that is, only rerunning when the
tracked state they use changes. This allows users to opt into the new
(`eager: false`) behavior on a per-modifier basis.
There are three changes to accompany the new options object here:
1. Add overloads to `modifier` for the following cases:
- the user passes no options (the default up till now)
- the user passes `{ eager: true }` (matching the previous default)
- the user passes `{ eager: false }` (the new target behavior)
These overloads intentionally do *not* support invoking with a
"signature" for `{ eager: false }`. If users want to introduce an
explicit signature for function-based modifiers, they should first
convert to the `{ eager: false }` semantics.
2. Update the function-based modifier manager internals to support
this. As a result, we now need to create a new instance each time,
with the corresponding options.
3. Update the internals of the function-based modifier manager to use
a state bucket, aligning it with the internals of the class-based
modifier manager and getting rid of the need for `Map`s for keeping
track of modifier elements and teardowns.
chriskrycho
force-pushed
the
function-base-modifier-eager
branch
from
e24b69c
to
f67d218
Compare
This allows existing places people are exlpicitly using the type to continue to work with the looser type supplied via `ArgsFor`.
chriskrycho
force-pushed
the
function-base-modifier-eager
branch
from
3a5b7d2
to
43eafa9
Compare
rwjblue
requested changes
Mar 24, 2022
Since the number of options is limited, we can just create one instance for the two scenarios we care about.
chriskrycho
force-pushed
the
function-base-modifier-eager
branch
from
f3c5a6f
to
f4b946d
Compare
rwjblue
reviewed
Mar 25, 2022
rwjblue
reviewed
Mar 25, 2022
rwjblue
approved these changes
Mar 25, 2022
7 tasks
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.
Introduce an options argument to the
modifier()function used to create function-based modifiers, with a single initial option:eager. Passing{ eager: false }opts out of the previous default beahvior of eagerly consuming all arguments, so that function-based modifiers can have normal auto-tracking semantics -- that is, only rerunning when the tracked state they use changes. This allows users to opt into the new (eager: false) behavior on a per-modifier basis.There are three changes to accompany the new options object here:
Add overloads to
modifierfor the following cases:{ eager: true }(matching the previous default){ eager: false }(the new target behavior)These overloads intentionally do not support invoking with a "signature" for
{ eager: false }. If users want to introduce an explicit signature for function-based modifiers, they should first convert to the{ eager: false }semantics.Update the function-based modifier manager internals to support this. As a result, we now need to create a new instance each time, with the corresponding options.
Update the internals of the function-based modifier manager to use a state bucket, aligning it with the internals of the class-based modifier manager and getting rid of the need for
Maps for keeping track of modifier elements and teardowns.(Docs and deprecation of the legacy behavior will follow!)