One of the stated SpineJS goals is to make the entire UI non-blocking (i.e. display the change to the user, even though it might have not been updated successfully on the server side yet).
Can it be used in a standard "blocking" manner?
Yes it can. Look here under "callbacks":
http://spinejs.com/docs/ajax
You can basically block the UI at any point, and I do it for things that just can't be deferred to the server. Note that I don't even use the ajaxSucess() event, but just custom bindings for events. Here is an example use case in meta programming:
Bind 'clickHandlerFinish' event to clickHandlerFinishWork()
Bind 'click' event on button a to clickHandler()
User clicks on button a
clickHandler() gets fired
clickHandler disables the button and blocks the UI
clickHandler makes an AJAX call to the server to do work
(Remember UI is still blocked)
AJAX call finally returns, and fires the clickHandlerFinish() callback
clickHandlerFinish() unblocks the UI, re-enables the button, and presents the new changes
I've used this successfully on a few instances. Works great for me!
Related
I am learning the Angular 5+ and recently comes to the subject/subscription part, I see many tutorial would like to use the subscription in the certain way:
Declare the subscription in component
Subscribe it in ngOnInit via a service's subject or ngrx/store
Unsubscribe it in ngOnDestroy
However, I am not sure if we have to subscribe/unsubscribe every subscription in the component in ngOnInit and ngOnDestroy. For example, if my subscription will get updated through a button click event, which plan should I subscribe it in my component?
Only ngOnInit
Only button click event
Both ngOnInit and button click event
Why would we always subscribe a subscription in ngOnInit? The ngOnInit would be like a Page_Load in page life cycle, so it would only be called once at the very first time, if so whenever the subscription gets updated, will the ngOnInit be fired over and over again? If so, will my component be loaded over and over again which would cause a performance issue if in large application?
You usually put Observables to subscribe to inside a Service and make them available via getters and setters.
When subscribing to an Observable it behaves in a certain way like an EventListener. Whenever the object inside the Observable gets changed, an Event gets fired and your code inside the subscription gets executed. Additionally, you get provided the updated object.
Even if you init the subscription inside ngOnInit this won't cause your entire Component to reload when an update arrives. Only those parts that get updated by your code inside the subscription.
You don‘t have to put a subscription inside ngOnInit(). It depends on what you want to achieve in the component. But most of the time you want to load and display data directly when you access the component and update the UI when this data changes. That's why it is good practice to put the subscription in ngOnInit().
In WPF, for most UI events, we have PreviewX event as well. How come there is no such a thing in Universal Apps? Is the events system fundamentally different from that of WPF that there is no need for it?
Found the answer, the system has changed from bubbling and tunneling. Now it works with Routed Events. More information can be found here. Here is the important excerpt:
Earlier we said that setting Handled to true prevents most handlers from being called. But the AddHandler method provides a technique where you can attach a handler that is always invoked for the route, even if some other handler earlier in the route has set Handled to true in the shared event data.
So instead of adding the event handler as usual, you'll need to call AddHandler to add your "Preview" handler.
Something to note: the documentation does not say that these special handlers are executed before the regular ones, so it is not exactly the same as the PreviewX method.
Could someone explain why the transitions (at least the default one - entrance) are not starting right away when a user clicks on a link (navigate) with Durandal?
In other words, do we need two mechanisms (loader animation + transition) to indicate that there is an action underway (ex. ajax call inside the activate method).
I'm sure there's a good reason, or maybe I just have to modify the entrance transition?
It seems like Durandal's transitions run once the activate function resolves. I asked a similar question where I enumerated some of the possible solutions that I found which worked for my situation specifically:
Manually animate away every view in its deactivate() and animate it back in via its viewAttached()
Bind the .page-host div's visibility to router.isNavigating (using a custom binding to handle the transition such as the fadeVisible example from the knockout site)
Manually subscribe to router.isNavigating and run custom logic when it changes
Hopefully this helps.
If you did not compress your entire application then the first process will be requirejs downloading the next amd module and then downloading the appropriate view.
The next step is durandal calling activate on your module. Activate if it returns a Deferred then it will wait for the deferred to complete.
Once activate is complete then the transition is called. The transition is responsible for swapping out the old view for the new one.
So, if its taking a while to kick off the transition its probably because its lagging in downloading your module and view.. or your activate method is taking a bit of time to finish.
Most of the MSDN WinJS app samples I've seen call WinJS.UI.processAll() after the app's activated event. I've also seen a number of non-MSDN tutorials that call WinJS.UI.processAll() after the DOMContentLoaded event.
Is there any practical reason to use one approach over the other?
It's a question of timing; personally I call it on DOMContentLoaded:
WinJS.Utilities.ready().done(function() {
WinJS.UI.processAll();
});
One of the primary reasons is that you can return the promise to the activation handler (the setPromise call you see in the templates), so that the splash screen is held a little longer until the WinJS.UI.processAll completes. This enables a better transition from splashscreen to completed content, without seeing partially constructed UI.
However, if you have UI that changes based on the activation type, you may want to delay this until you've constructed the DOM anyway. Since you need the activation type to make those differences, you'll need to call it after the activation event is raised.
I want to add listeners on selection event, but implementation via code below fired event two times. Only javascript core onClick event is fired correctly one time.
dojo.connect(myTabCont, "onButtonClicked", function(tabList){
console.log(tablist);
});
dojo.connect(myTabCont, "selectChild", function(tabList){
console.log(tablist);
});
//work fine - one click one fire
dojo.connect(myTabCont, "onClick", function(event){
console.log(event);
});
Is there is feature or bug? Or can you help how to workaround these funcionality or way how to broke this feature || bug.
Thanks
Sounds like a bug. selectChild() is idempotent so there's no harm in calling it twice (except for people like you that are connecting to it :-) ), so that's why we didn't notice the problem.
You could monitor the [widgetId]-selectChild topic, which will only fire once, or just ignore myTC.selectChild(foo) calls when foo == myTC.selectedChildWidget.
You could monitor the
[widgetId]-selectChild topic, which
will only fire once, or just ignore
myTC.selectChild(foo) calls when foo
== myTC.selectedChildWidget.
Equals check between old-selection and new-selection in Stack_Container.selectChild method is ok!
There is no bug. Registered "selectChild" is called two times and this is correct behaviour. First calling of "selectChild" is event fired by user, the second calling is programmaticlly when StackContainer check if old-selection NOT equals new-selection and fire onclick on tabItem explicitly.