{"id":15750245,"url":"https://github.com/objarni/sm.js","last_synced_at":"2025-03-31T07:15:45.841Z","repository":{"id":142954256,"uuid":"53040425","full_name":"objarni/sm.js","owner":"objarni","description":"State machine library for JavaScript","archived":false,"fork":false,"pushed_at":"2016-03-08T09:05:40.000Z","size":21,"stargazers_count":0,"open_issues_count":0,"forks_count":1,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-02-06T11:55:18.212Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/objarni.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2016-03-03T10:05:30.000Z","updated_at":"2016-03-06T22:33:42.000Z","dependencies_parsed_at":"2023-04-29T12:46:35.303Z","dependency_job_id":null,"html_url":"https://github.com/objarni/sm.js","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/objarni%2Fsm.js","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/objarni%2Fsm.js/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/objarni%2Fsm.js/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/objarni%2Fsm.js/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/objarni","download_url":"https://codeload.github.com/objarni/sm.js/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":246429493,"owners_count":20775808,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-04T06:22:56.485Z","updated_at":"2025-03-31T07:15:45.814Z","avatar_url":"https://github.com/objarni.png","language":"JavaScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# sm.js\nA JavaScript state machine library.\n\nWhy?\n====\n\nI need a simple, elegant way to express state machines in JavaScript for a couple of my projects.\n\nI'm used to qp, Quantum Framework, from embedded systems programming, so I'm borrowing a lot of ideas from that framework:\nhierarchical state machines expressed as functions returning their parent, events passed to a general publish method, actor pattern\nto structure the application components.\n\nHowever, in the web development world, the resource constraints of embedded systems do not (usually) apply. So a full framework is\nnot necessary and would bloat the library.\n\nFeatures\n--------\n\n  * __Hierarchical State Machines__. Exact structure yet to be determined.\n  * __Entry/exit events__. These should implement the same outward-in, inward-out logic as qp for grokkability.\n  * __Dynamic creation/deletion of machines__. Since one of my applications is a game, a natural way to add and\n   remove state machines from the app is essential. Any number from 1 to 200 machines could exist as the\n   app is running. E.g. the start screen has one machine active, while in-game state hosts a constantly fluctuating\n   number of game objects, implemented as state machines.\n  * __No global event list__. This was one of the few annoyances with using the QP framework: it required of the\n  programmer to specify a global list of events, which felt wrong and brought down the feeling of elegence. Instead,\n  simple strings to identify events, used locally in actors/machines is all I need. Nothings hinders adding application-\n  level checking of valid events to decrease likelyhood of simple typo mistakes.\n\nScoped out\n----------\n\n * __No framework__. The lib should just simplify writing/unit testing state machines and their behaviour.\n * __No timers__. Just let the app handle this.\n * __No priorities__. Don't see any need for this.\n * __No subscriptions__. I can't see how the increased complexity of the lib/apps motivates adding this, as the resulting optimization is likely not even noticeable. sm.js is meant for up to 200 machines, not 2 million. Instead, all objects recieve all events and have to filter themselves.\n\nExamples\n--------\nTo implement the library, I'm planning to express unit tests, and implementation of, three devices:\n\n  * __Reload countdown__. This is the traditional mechanic of a (heavy) weapon in a game; user cannot fire until the weapon is reloaded.\n  * __Repeat last command behaviour__. This is a somewhat contrived example of a device that \"remembers\" a command in an application,\n    that can later be repeated on user invocation.\n  * __Pong game__. This device would implement (part of) the traditional 70's pong arcade game. Specifically, it would clearly express\n    the dynamic creation/deletion of machines as they differ from the general states of the game (1 in splash, 3+ ingame, 1ish in game\n    over).\n    \n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fobjarni%2Fsm.js","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fobjarni%2Fsm.js","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fobjarni%2Fsm.js/lists"}