-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
state()() #39
Comments
what about a persistence layer/option like saving to a redis db or some external db/file solution that way the bot can "save" its state to a db, stop its execution, then be turned on later by a cron job, to then load its state from a db then carry on maybe separate botaction? |
an agnostic db solution would be nice, something separate that uses pipe so state can be loaded/saved : from/to |
this could play nicely with #40 schedule() use |
initial state comes from pipe value unless HO param provided so you can create a BotAction that interacts with ie Redis to get the "state" of a bot to then load it so perhaps when state()() is done running, it returns its final state so then a subsequent BotAction that interacts with a db ie Redis can save the state to load it later, analyze, cause state machines to pull it in, process create new data whatever |
considering running BotActions in parallel that use the State inject to communicate signals asynchronously if its immutable/observable, then sure, but that kind of complexity for this kind of "action/logic flow" seems more complicated than necessary perhaps, state is readable with a special function to reduce it, perhaps it works from root (like entire object map replaced) or by key like a ngrx feature slice could create functions to observe changes, like registering callbacks/subscriptions/etc but i dont want to do that what instead if there was another BotAction that would setup an inject like edit: the more i think about it, introducing observability into State may very well promote an anti-pattern with BotActions because then you can string multiple units of functionality in a single BotAction that reacts in parallel to another running, making the aseembled functionality more entangled this it about keeping the spaghetti organized, so we can add, remove as many meatballs and sausages we want. All those features. |
when i think of State for Botmation, in the context of Bots, its like a mix of configuration and record of what the bot has done, maybe who on social media it commented on, a report on the posts it liked, and all of this can be accumulated into a State object to read/writing into other mediums like databases its almost like a ledger, an accumulative report that may guide BotActions in the future (like perhaps there is a list of users to ignore from commenting or liking posts) that doesnt impose a linear order on the piped value's data flow you could potentially pipe the report across from BotAction to BotAction but then you end up creating implicit linear relationships from BotAction to BotAction, creating an imposed order (1 <- 2 <- 3 <- 4 <- 5... so forth) which reduces code re-usability in theory, youll have a higher upper limit on code reusability if the data/signals dependency is on the inject State, then the pipe value because it doesn't impose what happens directly before. Pipe value imposes a specific predecessing BotAction while the inject opens the door for "middleware" Botactions |
as for configuring BotActions like setting a list of usernames to ignore from the following operations like Liking Posts should that be separated from State? Should State be renamed Report? Then Config would be something else? |
what about a HO BotAction that creates these kinds of dynamic "state" injectables with the "key" name set from the HO param then devs can decide for themselves to either centralize all state into one injectable Map like object or into multiple edit: if this is what i end up doing, i might punt this feature until v2, until the injects system is revamped into a Map/object/tbd. ie for now a single State()() BotAction then on v2, abstract it into a HO one |
Ability to pass in an object with key/value pairs representing the state of something(s) in the first call
state()
(with fallback for Pipe value as initial state) then assembleBotAction
's to run with that state object injected via the second callstate()()
.The initial concept is to inject a special
State
-like instance which is basically aMap
, or similar in functionality, so complex state objects can be maintained and shared through manyBotAction
's.Piping is nice, and could be used to share a
State
like object, so this would be another approach to sharing data acrossBotAction
's that free's up the Pipe for other purposesThe text was updated successfully, but these errors were encountered: