search

rse / componentjs

ComponentJS -- Powerful run-time Component System for structuring HTML5-based Rich Clients
http://componentjs.com/
Other
85 stars 13 forks source link

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

Open Eminenz opened 11 years ago

Eminenz commented 11 years ago

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?

rse commented 11 years ago

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?

Eminenz commented 11 years ago

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

rse commented 11 years ago

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.