DictionaryClient Side Effects #73
Unanswered
joshhaines
asked this question in
Q&A
Replies: 1 comment
-
Hey @joshhaines! We're of the mindset that it's perfectly fine for the live implementation of an environment to execute side effects in the reducer, and we typically prefer this for quick, synchronous queries. As long as the environment can be controlled, everything should remain just as testable, and we can avoid the boilerplate and indirection of round-trip actions like |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Thanks so much for open sourcing this app. This provides a lot of great examples, and answers many questions that I’ve had. One thing that I’m a little confused on though is how the
DictionaryClient
is structured.My understand of the Reducer type (I’ve watched all of the episodes on TCA, but it’s been a while so I may be rusty) is that it is meant to be a pure function that is given a state, action, and environment and returns a mutated state through the
inout
state parameter. Side effects are packaged up through the Effect type, and the reducer doesn’t actually execute these side effects.However, what I see in the live implementation of the
DictionaryClient
is that thecontains
function accesses mutable global state. Typically something like this would be wrapped in an Effect, but I see that this is not. Isn’t this a side effect, and doesn’t this affect the purity of the reducer that calls this function? If the globalwords
dictionary is mutated between calls tocontains
then we could get different results.Out of curiosity, what was the reasoning to not return Effects for this client? I know it generally seems like you return the Effect type for dependencies. Just wondering why the choice was different for this client.
Beta Was this translation helpful? Give feedback.
All reactions