componentjs icon indicating copy to clipboard operation
componentjs copied to clipboard

Neither synchronous state transitions nor state transition callbacks seem to work when using guards

Open Eminenz opened this issue 12 years ago • 3 comments

When using guards for asynchonous stuff like requests in methods like render/prepare, and changing the state of the component to visible, the callback is called before the guard even finishes.

Is there a possibility to check when the state actually changed except the visible:enter event or is that a bug?

Eminenz avatar Mar 26 '13 15:03 Eminenz

I'm not sure I really understood the problem. You mean you do a cs(...).state("visible", function () {....}) within a guarded section and that the callback function is called even if the state "visible" is still not reached (because the guard should prevent it), right? Do you have a piece of code snippet so I can better understand the exact context?

rse avatar Mar 26 '13 19:03 rse

I probably was too fast to blame it on CJS - on further investigation, the transition callbacks seem to work fine.

When using guards for asynchronous stuff like requests in methods like render/prepare, and changing the state of the component to visible, the transition finishes even when it should be synchronous.

see http://tinker.io/e5aec

As it is probably a bad idea to synchronously wait for an asynchronous event, I understand that this is probably intended behaviour, but it would be great to have it documented

Eminenz avatar Mar 27 '13 11:03 Eminenz

Ah, I see, I see. Very interesting code. You use "sync: true" to request a synchronous state transition of component which guards itself for 2sec. Well, yes, the result is correct, but needs to be documented: "sync: true" only means that ComponentJS tries once to perform the whole requested state transition. If it fails (usually because of guards!) it prevents a dead-lock and just queues the pending state transition for subsequent asynchronous attempts. So, "sync: true" is only fully synchronous if the state transition at the time of calling .state() has a chance to immediately and this way synchronously proceed. If this is not the case, it fallbacks to standard asynchronous processing. I'll some of this description to the API documentation. Thanks for figuring out this interesting combination of "sync: true" and guarding.

rse avatar Mar 27 '13 22:03 rse