Code reuse with Nerves and gen_statem/gen_state_machine

I am currently tinkering with a poc, which is a rewrite of an existing product originally implemented in Python.
I recently saw a presentation on :gen_statem, and wanted to play around with it. I quickly realised that it might fit nicely my case.

The problem/case:

The existing product functions both as a SaaS product and a “firmware” for an IoT product. Given that I hope to utilise Nerves, for the IoT product, I suddenly see a case for adding additional states, that only is a concern for the Nerves variant of the product.

What I’m asking

Is it possible to develop a standalone software, that can run in a container, but also be imported and extended in the Nerves software?

Such that I can extend the “Sensor” gen_state_machine, adding additional states, and override a selection of callbacks already implemented in “Sensor” module?

Do I need a macro for this?
Is this bad practice?

Thanks! :smiley:

1 Like

You don’t. If you think about it you’re doing the same with gen_statem already. It provides the underlying logic on how to run a state machine, while the module you implement provides the logic of which states act how.

You could provide your own behaviour and extension points within to further allow another behaviour implementing module to extend what you built on top of gen_statem.

Its possible that I’ve misunderstood behaviours.
So I basically just add a bunch of typespecs for callbacks & types, similar to the implementation of gen_state_machine, and then make some state_function overridable?

That would be one way to do that, yes.

You can see similar “stacked implementations” with e.g. LiveView.

Similarly for plain channels use Phoenix.Channel modules are also started as GenServer processes.

I don’t think I understand.
Looking at the second link with Phoenix.Liveview.Channel, I see no use of Phoenix.Liveview

It’s the other way round. The channel isn’t a LV. But the channel is what “runs” a LV.

E.g. here you can see it forwarding non-internally-handled handle_info messages to the liveview: