Elixir Blog Post: Finitomata :: The Proper FSM for Elixir

Thank you very much, @mudasobwa! I must be going blind because I really didn’t see the examples directory in Finitomata’s repository . Really useful example.

There is https://github.com/am-kantox/finitomata/tree/main/examples/ecto_intergation non-official take on integration with ecto (which would not be the best implementation, but still.)
Aside from that, all other real-world examples I have I cannot actually share. I will try to come up with a better more sophisticated example, thanks.

First, really great package, @mudasobwa. Easy to use and intuitive. Thank you for this contribution to the Elixir ecosystem.

Some days ago I tried to implemented a FSM to manage the setup of an application, but then I realized that maybe is not the proper use case.

Aside from the examples given in Finitomata’s documentation, have you got some application example with Finitomata implemented? Just to learn until I have the necessary time to implement some ideas I have.

Thanks in advance!

these examples are great. this opens up a whole new section in my head. thanks!

Great! But in my understanding, the textual representation is easier to grasp and it produces a diagram in docs for free.

This reminds me of the FSM framework I wrote for usage in my own project.

I did however not resort to parsing a description string, I used some macros instead.

defmacro __using__(_opts) do
  quote do
    Module.register_attribute(__MODULE__, :transitions, accumulate: true)

    import     unquote(__MODULE__)

    # ensure our additional functions are added only right before compilation
    # after all module attribute values have been fully determined
    @before_compile unquote(__MODULE__)
  end
end

defmacro __before_compile__(_env) do
  quote do
    def transitions, do: @transitions
  end
end

defmacro transition(list) do
 # [...] omitted some checks for required fields for example 

  quote do
    @transitions unquote(list)
  end
end

You can then add transitions like this:

  use # "<module name>"

  transition(state: :idle, in: :start,    next: :wait)
  transition(state: :wait, in: :continue, end:  :pass)
  transition(state: :end,  in: :finish)

I ended up supporting waiting for different incoming messages, a join, end states, and “guard functions” that can further refine if a transition is taken.

The resulting list of transitions then ends up in a module attribute I can read and process.

(The part of handler functions or callbacks is not shown as it is not specific to describing the transition table. I defaulted to handle/2 as a default function for incoming functions, and allowed a user-defined handler name if needed that could be defined differently for every single transition.)

FWIW, I have implemented mermaid support. This is how the documentation for the generated module looks when mermaid syntax is used. Kudos and many thanks!

Screenshot_20220403_1150401284×748 60.4 KB

Wow. Thanks! Somehow I missed this possibility. Will surely support it alongside PlantUML. BTW, the compile-time check is already implemented in the library during definition parsing.

I think there’s probably a smart way to use mermaid (which is easy to ship with exdoc now) instead. Plantuml is kind of tricky syntax and while it’s open source, it’s really hard to install and put into a pipeline :P. Though at work I forced the database tables to be plantuml documented by creating a compile-time check.

Turned out, I’ve already written about another real example: webhooks.