state()()

[mrWh1te]

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 assemble BotAction's to run with that state object injected via the second call state()().

The initial concept is to inject a special State-like instance which is basically a Map, or similar in functionality, so complex state objects can be maintained and shared through many BotAction's.

Piping is nice, and could be used to share a State like object, so this would be another approach to sharing data across BotAction's that free's up the Pipe for other purposes

[mrWh1te]

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?

[mrWh1te]

an agnostic db solution would be nice, something separate that uses pipe so state can be loaded/saved : from/to

[mrWh1te]

this could play nicely with #40 schedule()

use state to set a flag so a new BotAction abortState() can return an Abort Line Signal when the state meets a condition

[mrWh1te]

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

[mrWh1te]

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 Messages that works like a messaging queue to react to signals asynchronously. These messages could carry payloads.

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.

[mrWh1te]

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

[mrWh1te]

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?

[mrWh1te]

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