Don't run effect
s created in a MockSession
#1049
Merged
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.
Closes #1034.
This PR makes it so that when a
@reactive.effect
is used in the UI-rendering phase of a Shiny Express app, it's a no-op; it doesn't schedule the function to be run later, during a reactive flush.Some thoughts about how this might be improved/generalized in the future:
MockSession
andSession
could to both be subclasses of another class, likeBaseSession
. OrMockSession
could just be a subclass ofSession
.effect.__init__()
, it currently does an explicit check ifsession
is aMockSession
object, but that is a bit crude. Instead,Session
andMockSession
could have a method, likeis_reactive()
, whicheffect.__init__()
could query to find out whether it should schedule execution on a reactive flush.MockSession.__init__()
method could take an argument,is_reactive
, to tell it whether to do reactivity or not. This could be useful if theMockSession
class is used for other purposes, like testing.