New: Add state setters with options

[AlexIchenskiy]

Resolves #68

As an enhancement to the freshly implemented getters and setters, this PR introduces a new way to set the state of nodes and edges using objects that specify state with additional parameters such as isSingle and isToggle. Now, it is possible to use both the regular setter:

node.setState(state)

and the new setter:

node.setState({ state: GraphObjectState.SELECTED, options: { isSingle: true } })

edge.setState({ state: GraphObjectState.SELECTED, options: { isSingle: false, isToggle: true } })

and so on. This provides more customization flexibility to the user, with default values for these parameters set to false. It should be easily extendable for adding even more options.

[AlexIchenskiy]

I feel like these iterations through all nodes/edges can be slow. Any ideas? And do we want to clear the state of all nodes/edges or only the adjusting ones?

[cizl]

How about using hash maps? Obviously, this would require a lot of code change. Just starting a discussion, I don't think it's doable right now.

For the second question, I would say only the ones that are being adjusted.

[cizl]

Or maybe to supplement this nodes array we can keep an index where nodeIndex[node.id] === nodes.findIndex((el) => el.id === node.id)

[AlexIchenskiy]

Are you suggesting storing nodes in a hashmap? As far as I know, retrieving elements from an array by a known index is O(1) complexity, so iterating through an array vs a hashmap (which also has O(1) complexity for retrieving element by key) may not make a big difference here. I might have misunderstood your point, or perhaps I missed something, so feel free to clarify it further :)

[tonilastre]

If all nodes are in state X, and you want to clear them up if they are not node with ID 1, you still need to to N - 1 updates. So hash maps or any other structure won't help there, you already have the fastest structure, an array.

But, you can do this and increase the memory footprint: I am not sure if it makes sense to go into this right now, but this would be the plan:

• Graph keeps a structure of nodes/edges by state, so each state has a structure of nodes and edges (probably just id) - a set of a map.
• States in nodes and edges are just views, readonly
• When state is updated in node, edge it is just updated in the graph

This way, if you have isSingle: true, graph, as an owner of the data can then literally take all selected nodes from a set or a map, clear those states and set the new node as single selected. This would improve the speed, but it would worse the memory footprint and code simplitiy because owner of the state becomes the graph, not graph objects (node/edge).

I would keep this as is and fix only if we see that it hurts performance.

[cizl]

Sorry, I misunderstood the functionality. I saw === instead of !==. I thought you were trying to clear the state of anode with a specific id.

[tonilastre]

Either have this._state = <function that handles options in general>(results.state) where function doesn't mutate the state, but returns what the new state should be, or keep this as is, but still change the toggleState to not mutate the this._state because I don't see a reason why it should. The best functions are the clean ones, which do not mutate state (if it is possible to make them).

[tonilastre]

For these checks, please use utils/type.utils.ts because of:

• cleaner code, isNumber vs `typeof x === 'number'
• handles edge cases, isPlainObject vs typeof result === 'object' (edge case is: typeof null will return 'object').

[tonilastre]

Same comments as for edges.

[tonilastre]

In these cases, when it is options, it would be best not to have optionals here, but where you use it, line 17: Partial<IGraphObjectStateOptions> where options can also be optional, e.g. options?: Partial<...>.

If you move external logic (having optional params) too deep into the type, it is harder to handle that in some other cases. E.g. if you wish to create default params, you could then just say: const default: IGraphObjectStateOptions = { ... } and you would be forced to define both. If you would use options from Parameters you would see that this object is optional here with all its children. The context of when is something optional, when it isn't is being kept.

[tonilastre]

If all nodes are in state X, and you want to clear them up if they are not node with ID 1, you still need to to N - 1 updates. So hash maps or any other structure won't help there, you already have the fastest structure, an array.

But, you can do this and increase the memory footprint: I am not sure if it makes sense to go into this right now, but this would be the plan:

• Graph keeps a structure of nodes/edges by state, so each state has a structure of nodes and edges (probably just id) - a set of a map.
• States in nodes and edges are just views, readonly
• When state is updated in node, edge it is just updated in the graph

This way, if you have isSingle: true, graph, as an owner of the data can then literally take all selected nodes from a set or a map, clear those states and set the new node as single selected. This would improve the speed, but it would worse the memory footprint and code simplitiy because owner of the state becomes the graph, not graph objects (node/edge).

I would keep this as is and fix only if we see that it hurts performance.

[tonilastre]

Can you maybe simplify this to if (data && data.options?.isSingle && data.type === 'node')?

[AlexIchenskiy]

I believe it could be possible, but only after reworking IObserverDataPayload into a more generic solution as you mentioned here. Currently, I am using some sort of custom type guard because of the interfaces used in that payload

[tonilastre]

It is nitpicking really, but maybe getNextState would be a better name.