quesurifn
How to store state in module?
So, I’m building an SMTP client that I’d like to be able to be called from different processes and have different state for each process. The SMTP client needs to track for example if the HELO command has been used or not. How do I handle state?
My current code is this:
defmodule Client do
@moduledoc """
Documentation for `Smtpclient`.
"""
use Agent
def start_link(_opts) do
Agent.start_link(fn -> %{} end, name: __MODULE__)
end
def connect(pid, tld) do
set_value(pid, "tld", tld)
{:ok, records} = DNS.resolve(tld, :mx)
Enum.sort_by(records, fn(r) -> elem(r, 0) end)
sock = do_connect(records, 0)
set_socket(pid, sock)
set_value(pid, "hostname", tld)
{:ok, sock}
end
@spec helo(any) :: any
def helo(pid) do
already_helloed = get_value(pid, "already_helloed")
if already_helloed do # if already helloed return early
{:error, "already helloed"}
end
sock = get_socket(pid)
tld = get_value(pid, "tld")
sock |> Socket.Stream.send!("HELO #{tld}")
set_value(pid, "already_helloed", true)
sock |> Socket.Stream.recv!
end
def noop(pid) do
try do
sock = get_socket(pid)
sock |> Socket.Stream.send!("NOOP")
sock |> Socket.Stream.recv!
rescue
Socker.Error -> {:error, :no_connection}
end
end
def quit(sock) do
try do
sock |> Socket.Stream.send!("QUIT")
sock |> Socket.Stream.recv!
sock |> Socket.close!()
rescue
Socket.Error -> {:error, "something is wrong"}
end
end
def rctp_to(pid, email) do
try do
sock = get_socket(pid)
sock |> Socket.Stream.send!("RCPT_TO #{email}")
sock |> Socket.Stream.recv!
rescue
Socker.Error -> {:error, "something is wrong"}
end
end
defp set_socket(pid, sock) do
Agent.update(pid, &Map.put(&1, "socket", sock))
end
defp get_socket(pid) do
Agent.get(pid, &Map.get(&1, "socket"))
end
defp set_value(pid, key, value) do
Agent.update(pid, &Map.put(&1, key, value))
end
defp get_value(pid, key) do
Agent.get(pid, &Map.get(&1, key))
end
defp do_connect(hostnames, i) do
try do
host = elem(Enum.at(hostnames, i), 1)
Socket.TCP.connect!(to_string(host), 25, packet: :line)
rescue
Socket.Error ->
if Enum.at(hostnames, i) == nil do
{:error, "all mx servers down"}
end
do_connect(hostnames, i + 1)
end
end
end
Most Liked
IloSophiep
I think there are two “default” ways to handle state (and a lot more specific ones):
- Store them in the client process
- Store them in a dedicated process
Because Elixir is really good with processes people sometimes expect everything they code to do “process-y” stuff. But if you can, i think, it is recommended to start simple and do not introduce processes if you don’t need to. Your first sentence makes me think, that might work for you.
As an example: You have a module TodoList with a function add/1 that adds one item to the list. You might think “How / Where do i keep that list, so calling add/1 three times keeps all the old entries still there?” The easiest answer is "Just return the data to the caller and let them keep the state around! So instead of
defmodule TodoList do
def add(item) do
# Where does before come from?!
[ item | before ]
:ok
end
end
you use
defmodule TodoList do
def add(state, item) do
# renamed "before" to "state", so the
# concept hopefully becomes clearer
[ item | state ]
end
end
so the caller of your client keeps the state around and hands it to you for you to work on it.
Sebb
I find :gen_statem very hard to understand. I prefer functional fsm with the state in map/struct and pattern matching in multiclauses as handlers. Also because fsm can become hard to test if they have side effects (like timeouts) I think its worth to think about how to make them as pure as possible.
Popular in Chat/Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








