How to use MicroMachine with Rails ActiveRecord models?

You need to instantiate MicroMachine in your model, define transitions, and manually persist state using callbacks or before_save, as shown in the README examples. This approach gives flexibility but requires extra code for synchronization.

MicroMachine vs aasm: which should I choose for a Ruby project?

Choose MicroMachine for minimalism and control with under 50 lines of code, ideal when you dislike DSLs. Opt for aasm if you need built-in ActiveRecord support, DSL syntax, and features like guards out of the box, as it's more feature-complete but heavier.

Can MicroMachine handle conditional transitions based on data?

No, it doesn't support conditional transitions natively. You must implement checks outside the FSM, such as in callbacks or before triggering events, adding complexity to your codebase.

Is MicroMachine thread-safe for concurrent Ruby applications?

The library doesn't mention thread safety; since it's minimal and state is stored in instance variables, you should manage concurrency yourself, such as using mutexes in multi-threaded environments.

How to test a state machine built with MicroMachine?

Test by mocking the MicroMachine instance or integrating it into model tests, focusing on transition outcomes and callbacks. Use `trigger?` to verify valid states without side effects, as recommended in the README.

What's the performance impact of using MicroMachine?

It's lightweight with negligible overhead due to its small codebase, making it fast for simple state management. However, complex callbacks or frequent state checks might add latency, so profile if performance is critical.

Open-Awesome

MicroMachine

MITRuby3.0.0

A minimal finite state machine implementation for Ruby with less than 50 lines of code.

GitHub

523 stars38 forks0 contributors

What is MicroMachine?

MicroMachine is a minimal finite state machine implementation for Ruby that provides essential state transition functionality in under 50 lines of code. It solves the problem of managing state changes in Ruby applications without the complexity of larger FSM libraries, offering a clean, composable approach to state management.

Target Audience

Ruby developers who need lightweight state management in their applications, particularly those working with models that require state transitions like order processing, user workflows, or approval systems.

Value Proposition

Developers choose MicroMachine for its extreme simplicity and minimal footprint—it provides only the essential FSM functionality without complex DSLs or dependencies, making it easy to understand, integrate, and maintain.

Overview

Minimal Finite State Machine

Use Cases

Best For

Managing state transitions in ActiveRecord models
Implementing lightweight workflow automation in Ruby
Adding state management to Ruby objects without heavy dependencies
Building composable state machines within larger applications
Educational purposes for learning finite state machine concepts in Ruby
Projects where minimal code footprint is a priority

Not Ideal For

Projects needing complex business logic in state transitions (e.g., guards or conditional branching)
Teams wanting a declarative DSL for state machine definition without manual hash manipulation
Applications requiring built-in persistence or ActiveRecord integration out of the box
Systems that demand hierarchical or nested state machines for advanced workflows

Pros & Cons

Pros

Minimal Code Footprint

At under 50 lines, it eliminates bloat and dependencies, making it easy to audit and understand, as highlighted in the README's emphasis on providing only essential FSM functionality.

Simple, Composable Design

It uses plain Ruby hashes and methods like `when` for transitions, allowing flexible instantiation within models without mixins, as demonstrated in the ActiveRecord integration examples.

Flexible Callback System

Supports callbacks on specific states or any transition with payload passing, enabling custom actions like persisting state changes, as shown in the `on(:any)` example.

Explicit State Inspection

Provides methods like `trigger?` for safe state checking and `events` for listing all possible transitions, aiding in debugging and dynamic workflows.

Cons

Manual Persistence Handling

Lacks built-in persistence; developers must manually sync state to databases, as admitted in the README's verbose ActiveRecord examples requiring callbacks or before_save hooks.

Limited Advanced Features

Missing common FSM features like conditional transitions, state guards, or event guards, forcing custom logic outside the library for complex scenarios.

Verbose Transition Definition

Defining transitions via hash assignments can become cumbersome for large state machines compared to DSL-based alternatives, increasing boilerplate code.

Frequently Asked Questions

Related Projects

AASM

AASM - State machines for Ruby classes (plain Ruby, ActiveRecord, Mongoid, NoBrainer, Dynamoid)

Stars5,227

Forks644

Last commit19 days ago

Statesman

A statesmanlike state machine library.

Ruby finite-state-machine-inspired API for modeling workflow

Stars1,798

Forks205

Last commit9 months ago

state_machines

Adds support for creating state machines for attributes on any Ruby class

Stars870

Forks98

Last commit5 days ago

Community-curated · Updated weekly · 100% open source

Found a gem we're missing?

Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.

Submit a project Star on GitHub