The Interpreter pattern is one that I am rediscovering lately, or at least a limited variation of it (more in line with Free + Interpreter). The Elm Architecture (aka MVU) has an interpreter built in for side effects. For example, you can return a declared Http side effect, and it will later run an interpreter to perform the side effect, then send a message back to your decision logic with the result.
So the advantage of Interpreter, is that it can turn processes which need side-effects into purely deterministic code. That makes it very testable and easy to isolate the discrete steps of the process. I am planning to make a post on how to adapt MVU for the server-side -- represent effectful processes as pure, testable functions. (And actually, there's no V anymore and Effects are added, since Elm does not allow you to create your own within Elm.) I have been internally calling it Decide-Perform, and it has more than a passing resemblance to an OODA loop.
I don't have an article yet. But I recently posted a gist with a code example. The code fetches AWS Simple System Manager Parameter Store values. Maybe it is terrible. See what you think. Here is the gist.
The upshot is that the update function is pure/deterministic/referentially-transparent and therefore very testable. You can even test that the correct side effects are triggered (without actually running them).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The Interpreter pattern is one that I am rediscovering lately, or at least a limited variation of it (more in line with Free + Interpreter). The Elm Architecture (aka MVU) has an interpreter built in for side effects. For example, you can return a declared Http side effect, and it will later run an interpreter to perform the side effect, then send a message back to your decision logic with the result.
So the advantage of Interpreter, is that it can turn processes which need side-effects into purely deterministic code. That makes it very testable and easy to isolate the discrete steps of the process. I am planning to make a post on how to adapt MVU for the server-side -- represent effectful processes as pure, testable functions. (And actually, there's no V anymore and Effects are added, since Elm does not allow you to create your own within Elm.) I have been internally calling it Decide-Perform, and it has more than a passing resemblance to an OODA loop.
Cool. I have to admit I didn't know that one. I'm looking forward to the article.
I don't have an article yet. But I recently posted a gist with a code example. The code fetches AWS Simple System Manager Parameter Store values. Maybe it is terrible. See what you think. Here is the gist.
The upshot is that the
updatefunction is pure/deterministic/referentially-transparent and therefore very testable. You can even test that the correct side effects are triggered (without actually running them).