Modify handler store, for better hooks notifications

[adrianlyjak]

Fixes/tweaks to address the following issues:

• Sub classes of stop events were not triggering stream completion
• Failures and cancellations were considered successes
• mutations to handlers on store state were not triggering re-renders
• no way to react to a bare handler

[adrianlyjak]

This is maybe silly, bad hook, but I was passing around handler references from a callback., and then not getting notifications from it in a state var (obviously, but also tempting to do).

Alternately, maybe we should not pass around the full handler, and just an ID like before to enforce that you get the handler details from the store?

[zhaotai]

It looks like you're trying to make handler observable, which should already be covered by store. If no then there might be some bugs. We need to fix those bugs instead of introducing a Pub/Sub inside store. (store itself already has Pub/Sub mechanism).

I will take care of this feature after events persistent merged. Just give me little more time.

[adrianlyjak]

@zhaotai

It looks like you're trying to make handler observable, which should already be covered by store. If no then there might be some bugs. We need to fix those bugs instead of introducing a Pub/Sub inside store. (store itself already has Pub/Sub mechanism).

I will take care of this feature after events persistent merged. Just give me little more time.

Ok, there's going to have to be a big overhaul to handlers then. Handlers are currently just being mutable from what I can see. From what I understand of Zustand, its some get/set sugar on top of standard flux immutable structure. If going towards zustand integration, I think perhaps the functions you call directly on handlers may want to be rethought. I think perhaps we want to move to functional/service APIs existing directly on the store interface, and you qualify with a handler id.

[adrianlyjak]

I will take care of this feature after events persistent merged. Just give me little more time.

IMO this seems much higher priority than persistent events. Right now this is not usable. Workflow handlers never complete, and their attributes never change. You can basically start a workflow and that's it

[zhaotai]

I will take care of this feature after events persistent merged. Just give me little more time.

IMO this seems much higher priority than persistent events. Right now this is not usable. Workflow handlers never complete, and their attributes never change. You can basically start a workflow and that's it

ok, let me prioritize this then.
Actually, I was using workflow-debugger as test instance. Now it all relies on handler-store.
You can take a look at run-details-panel. Is that also not working?

[zhaotai]

According to the requirement from this PR. Having a more comprehensive PR: #154