You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discussed in the discord, it would be great to separate node state from its definition, and provide an easier/simpler api for implementing nodes.
Currently you need to declare a node as a class that inherits from a node type, and create a constructor that passes values to the parent, for example with Branch:
It inherits from two different classes - you have to follow values/methods up the inheritance tree
A lot of boilerplate code to define a node
State is stored in a bunch of nodes and not all in one place and can be harder to debug.
State is combined with node definition
You have access to the whole fiber object, but in reality you don't and shouldn't have access to its entire api. exposing more of the api than is needed makes things harder to implement and more prone to calling it the wrong way.
A much easier thing to implement method could look like:
This also is more testable - it's easier to write tests around this triggered function this way as you can simulate state and don't need to setup the entire engine/fiber classes.
If all the nodes state is stored in one place, lets say in the engine class, its easier to debug; it also makes it possible to reset the entire nodes state without having to rebuilt all these definition instances.
This is also more readable - you can know what variables flow/branchFlow and Branch represent by just looking at the code, without having to go to the definition of NodeDescription constructor
The text was updated successfully, but these errors were encountered:
As discussed in the discord, it would be great to separate node state from its definition, and provide an easier/simpler api for implementing nodes.
Currently you need to declare a node as a class that inherits from a node type, and create a constructor that passes values to the parent, for example with
Branch
:A few issues with this approach:
A much easier thing to implement method could look like:
Then the implementation is as clean/readable as:
This also is more testable - it's easier to write tests around this
triggered
function this way as you can simulate state and don't need to setup the entire engine/fiber classes.If all the
nodes
state is stored in one place, lets say in the engine class, its easier to debug; it also makes it possible to reset the entire nodes state without having to rebuilt all these definition instances.This is also more readable - you can know what variables
flow/branch
Flow
andBranch
represent by just looking at the code, without having to go to the definition ofNodeDescription
constructorThe text was updated successfully, but these errors were encountered: