{"id":24407534,"url":"https://github.com/nykenik24/loveflow","last_synced_at":"2026-04-20T06:03:00.349Z","repository":{"id":273208330,"uuid":"918653101","full_name":"Nykenik24/LoveFlow","owner":"Nykenik24","description":"Event Driven Architecture (EDA) implementation inside Love2d.","archived":false,"fork":false,"pushed_at":"2025-01-22T21:25:07.000Z","size":233,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-10-14T12:07:39.082Z","etag":null,"topics":["event-driven-architecture","implementation","library","love2d","lua"],"latest_commit_sha":null,"homepage":"","language":"Lua","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/Nykenik24.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,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2025-01-18T14:03:42.000Z","updated_at":"2025-01-22T21:25:10.000Z","dependencies_parsed_at":"2025-01-19T13:58:43.795Z","dependency_job_id":"70bf265c-7682-4dfa-a7be-4b615390f69c","html_url":"https://github.com/Nykenik24/LoveFlow","commit_stats":null,"previous_names":["nykenik24/loveflow"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/Nykenik24/LoveFlow","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Nykenik24%2FLoveFlow","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Nykenik24%2FLoveFlow/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Nykenik24%2FLoveFlow/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Nykenik24%2FLoveFlow/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Nykenik24","download_url":"https://codeload.github.com/Nykenik24/LoveFlow/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Nykenik24%2FLoveFlow/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":32035276,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-20T00:18:06.643Z","status":"online","status_checked_at":"2026-04-20T02:00:06.527Z","response_time":94,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"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":["event-driven-architecture","implementation","library","love2d","lua"],"created_at":"2025-01-20T05:11:39.775Z","updated_at":"2026-04-20T06:03:00.309Z","avatar_url":"https://github.com/Nykenik24.png","language":"Lua","funding_links":[],"categories":[],"sub_categories":[],"readme":"# LoveFlow\nLoveFlow is an Event-Driven Architecture (EDA) implementation inside Love2d. LoveFlow allows for flexible customization of a message bus, controllable event handlers, publisher-subscriber systems and more.\n\n# Installation\nTo install LoveFlow, follow this steps:\n\n1. Clone or add as a submodule:\n```bash\ngit clone https://github.com/Nykenik24/LoveFlow.git path/to/loveflow\n# or\ngit submodule add https://github.com/Nykenik24/LoveFlow.git path/to/loveflow\n```\n2. Require loveflow\n```lua\nlocal loveflow = require(\"path.to.loveflow\")\n```\n\n# Usage\nAfter installing LoveFlow, you need to **create an architecture**:\n```lua\nlocal loveflow = require(\"loveflow\")\nlocal arch = loveflow.newArch()\n```\nThen create your publishers and subscribers\n```lua\n--...\nlocal pub = arch.bus:newPublisher()\nlocal sub = arch.bus:newSubscriber()\n```\nAnd finally update your architecture in `love.update`\n```lua\nfunction love.update(dt)\n\tarch:updateAll()\nend\t\n```\n\nNow you can publish events:\n```lua\npub:publish(\"Hello, World!\")\npub:publish({msg = \"Hello, World!\", some_var = 5})\n```\nSubscribe to publishers:\n```lua\nsub:subscribe(pub)\n-- or\nsub:subscribe(pub.id)\n```\nAnd handle events manually or with `subscriber:handleEvents`:\n```lua\nsub:handleEvents(arch.bus, function(self, event)\n\t--...\nend)\n-- or manually\nlocal sub_events = sub:getEvents()\nfor id, event in pairs(sub_events) do\n\t--...\nend\t\n```\nYou can also broadcast events through `bus:broadcast`\n```lua\narch.bus:broadcast(\"DOOM!? Here in New York!?\")\nprint(sub:getLastBroadcast(arch.bus))\n```\n## Components\nComponents in LoveFlow are:\n- Publishers.\n- Subscribers.\n- Event buses.\n- Listeners.\n\nThis section explains each one of them:\n### Event bus *(or event broker)*\n---\n- Handles the event pool.\n- Can broadcast events to all subscribers.\n### Publisher\n---\n- Sends events. \n- Subscribers can suscribe to them to receive all published events.\n### Subscriber\n---\n- Receives events.\n- Can subscribe to publishers.\n- Can get broadcasts.\n### Listener\n---\n- Listens to events in an event bus.\n\n![EDA Example](images/EDA_example.png)\n\u003cdetails\u003e\n\u003csummary\u003eCode\u003c/summary\u003e\n\n```lua\nlocal loveflow = require(\"loveflow\")\nlocal arch = loveflow.newArch()\n\n-- ## Create all comps ## --\n-- publishers --\nlocal pub_a = arch.bus:newPublisher()\nlocal pub_b = arch.bus:newPublisher()\n\n-- subscribers --\nlocal sub_a = arch.bus:newSubscriber():subscribe(pub_a)\nlocal sub_b = arch.bus:newSubscriber():subscribe(pub_b)\nlocal sub_c = arch.bus:newSubscriber():subscribe(pub_a):subscribe(pub_b)\n\n-- listener --\nlocal listener = arch.bus:newListener()\n\n-- ## Publish and broadcast ## --\npub_a:publish(\"Event A\")\npub_b:publish(\"Event B\")\narch.bus:broadcast(\"broadcast\")\n```\n\u003c/details\u003e\n\n# Recomended usage\nLoveFlow is made to be as customizable and flexible as possible, handlers and events are completely custom.\n\nBut, there is a recommended workflow i suggest you to follow if you want good event handling.\n\n\n## `event.type`\nYou can add a variable called `type` to your events for subscribers to know what to do for every type of event.\n```lua\n-- enemy.flow is the publisher\n-- player.flow is the subscriber\n\nenemy.flow:publish({\n\ttype = \"attackPlayer\",\n\tdmg = enemy.dmg, -- damage\n\tin_range = enemy:inAttackRange(player)\n})\n\nplayer.flow:handleEvents(bus, function(_, event)\n\tif event.type == \"attackPlayer\" then\n\t\tif event.in_range then \n\t\t\tplayer:takeDamage(event.dmg) \n\t\tend\t\n\telseif event.type == \"onDeath\" then\n\t\tplayer:respawnOnLastCheckpoint()\n\tend\nend)\n```\n**Note**: I recommend having some function that handles all the event types instead of a chain of `if` and `elseif`.\n\n## Always make events tables\nTables are the way to go when making your events, they allow for easy storage of all the information you need, a type variable, etc.\n\nIf you used strings, then using an event bus instead of a message bus would be dumb. If you used numbers then... What would you really be able to do? If you used booleans then you would have less possibilites than with numbers. \n\nFunctions aren't possible to use because the library discards functions when getting and handling events to avoid passing `last` or any other internal method. If you want to use functions, you could store them in a table and use them like `event[1](...)` or `event.func(...)`.\n\n## Use broadcasts only when necessary\nBroadcasts are really useful when you need all subscribers to do something, like a `quit` event that makes all subscribers save their state in the save file before the game is closed.\n\nBut if you need a group of subscribers to respond to one source of events, just subscribe them to that source. You can make a publisher have multiple subscribers and viceversa. \n\nBroadcasts go to all subscribers so you could break something if not careful when using them.\n\n## Use publisher and subscriber alias if you need them\nWhen calling `newSubscriber` and `newPublisher` there is an optional argument: `alias`. Alias is a string that allows you to find a subscriber/publisher inside the bus without having to know the ID.\n\nTo find a publisher/subscriber by alias, use the bus methods `findPublisherByAlias` and `findSubscriberByAlias`, this methods will return the publisher/subscriber and their id (publisher) or index (subscriber).\n\nIf you use alias, make them as short and understandable as possible. If your publisher takes as a source the player inputs, you can use the alias `Input handler`, `Input publisher` or just `Input`. \n\n## Use listeners instead of subscribers when needed\nIf you need something that takes all events, but don't want to create a new subscriber or use one that isn't really related or important, use *listeners*.\n\nListeners take all events from all sources of an event bus and handles them with the function you provide. \n\nThese are useful when you want something that takes all events sent and have too many publishers to make a subscriber that's takes events from every publisher.\n\n# More about EDA\n## What is EDA?\n*[src: Geeks For Geeks article on EDA](https://www.geeksforgeeks.org/event-driven-architecture-system-design/)*\n\nWith event-driven architecture (EDA), various system components communicate with one another by generating, identifying, and reacting to events. These events can be important happenings, like user actions or changes in the system's state. In EDA, components are independent, meaning they can function without being tightly linked to one another. When an event takes place, a message is dispatched, prompting the relevant components to respond accordingly. This structure enhances flexibility, scalability, and real-time responsiveness in systems.\n\n\n## Why is EDA useful?\nEvent-driven architecture inside your game allows for a very flexible game event system, allowing for modularity and control of internal game events.\n\nLoveFlow implements a simple EDA system that allows to quickly setup publishers, subscribers, event handlers, etc. in a fast and easy manner.\n\n\n\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnykenik24%2Floveflow","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fnykenik24%2Floveflow","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnykenik24%2Floveflow/lists"}