Is it possible to intercept/preprocess actions before they will be processed by the state?
Thought I could achieve this with action handlers
The action handler is an Observable that receives all the actions dispatched before the state takes any action on it.
https://ngxs.gitbook.io/ngxs/advanced/action-handlers
But looks like action handlers (including 'dispatched') are invoked after #Action methods actually.
If the action stream is not providing what you need, and if you want to intercept all actions prior to them being processed you could consider writing a NGXS Plugin.
The NGXS source for the LoggerPluginModule is pretty simple if you are looking for an example of a plugin.
Related
I have a parent-child states that manage reports and documents respectively.
When a report is submitted, I need to store the user posted data for the report and the async action returned id in the parent state, and the async action returned document in the document state.
Since I need the async action returned data in two different state actions, is there anyway to acomplish this without dispatching another action from the parent?
In React apps with redux toolkit different state slices can listen to pending/fulfilled/rejected states for the same async thunk so I was wondering if there is something similar for NGXS.
Thanks.
I know I can dispatch actions from another action providing different payloads so other sub states can listen to them and update accordingly, but I was hoping to accomplish that in one action.
I've also thought about calling the http async action first and after getting the result dispatch the store action but not sure if this is an anti-pattern.
I'm trying to wrap my head around Laravel's queued event listener vs jobs.
To me, it seems like that both are very similar:
Both implement the ShouldQueue interface (in the case of event listener, this is an option)
Both implement the handle() and failed() (optional) methods to perform their respective tasks.
Essentially, to me, both are queued items that can be run asynchronously.
What I am able to distinguish so far is that jobs have more "advanced" features/configurations like $timeout, $tries properties and you may also delay the 'trigger' of a job (courtesy of the Illuminate\Bus\Queueable trait).
There are more I'm sure, but I'm pointing out the one that pops out to me.
So, the question is, what's the actual difference between the two and more importantly, when do you favor one over the other?
Good question, I will begin by how laravel docs explains it
Events : Laravel's events provides a simple observer implementation, allowing you to subscribe and listen for various events that occur in your application. Events serve as a great way to decouple various aspects of your application, since a single event can have multiple listeners that do not depend on each other.
Where as
Jobs : Job classes are very simple, normally containing only a handle method which is called when the job is processed by the queue.
Essentially both are pushing jobs on to queues and/or do some processing its asked to do, the main difference I would say is how they are called.
Events are on the lookout to be called where as Jobs are always explicitly called.
Power of Events is that we can register multiple listeners for a single event and the event helper will dispatch the event to all of its registered listeners without us calling them explicitly. where in case of Jobs we would have to call them each one explicitly.
In short if you have a scenario where an event would trigger multiple method calls event would help. If its a single method call Jobs are good.
Events Scenario: user signs up -> Send email, Dispatch complimentary swag, Create a subdomain for a user profile userxyz.site.com etc etc
Jobs Scenario: user signs up -> Send email.
In the exact context of the question: "Event" is a "Queued Event Listener". Every Laravel Event has a Listener bound to it (the event listener), then, when we queue that event (in the listener) it is magically a "Queued Event Listener"
Well, they are very similar, the eventlistener takes an event as a parameter in the handle method, jobs don't.
Events are good in situations where you want to decouple the triggering part from the action part. For instance when you have several modules in the project and you want one module to react on an event in another.
One limitation of events compared to jobs are job chaining. If you for instance trigger several events from a controller you can't be sure that the worker dispatches them in sequence and that the first is completed before the other is started.
In these (rare) situations I sometimes end up with (non queued) listeners that in turn dispatches (queued) jobs that do the actual work (chained or unchained).
Short version of the question:
Can I fire UI actions from the store?
Long version of the question:
I'm writing food delivery app with reflux. It's seems like I'm not quite
understand how actions should go in my applications.
I have BasketStore, StatusOverlay (component) and actions:
// BasketStore actions
basketSync
basketSync.Completed
basketSync.Invalid
basketSync.Failed
// StatusOverlay actions
statusOverlayOpen
statusOverlayClose
The application works the following way:
I press button and send basketSync action. Once it happened the overlay is starting to be shown and BasketStore sends request for the data to the server.
Then accordingly to server response I fire basketSync.completed, basketSync.failed, basketSync.invalid. When it invalid or completed I close overlay, otherwise I show another overlay.
The question is how should I manage actions? Should I listen to basketSync inside of StatusOverlay to open it and close it on basketSync.completed, basketSync.invalid or it will be better to listen to just statusOverlayOpen, statusOverlayClose and fire these actions somewhere inside of BasketStore.
Short answer: In the standard Flux architecture, Flux stores should only emit a simple CHANGE event, so, no, you can't fire UI actions from the store.
I've seen stores triggering actions in many Flux applications. Some people like to put their async work inside the action creators and trigger "completed" and "failed" "sub-actions" inside the callbacks of the async work, others put the async work within the store itself and in that case trigger the sub-actions from there. They key point, as I've seen it pointed out, is that in the callbacks you should trigger a new action, rather than update state directly, so that data mutations only ever happens as an effect of actions, not async callbacks.
But with that said, components should not typically listen to actions at all. They should only listen to updates to the store and reflect that update any way necessary. So with the points mentioned above, stores could listen to the "completed" or "failed" actions, and appropriately update their state to reflect the "completed" or "failed" actions. The components then render any "error" indications based on the store's state, not on actions directly.
Is it equivalent/better to work
with the Event module on Event type
or with Observable on the publish property of an event
Functionally it seems equivalent, and I guess the difference is 'semantic' :
Are we inside the boundary where it makes sense to have access to the internal state of
the event ?
Or are we considering this event interface as a passive source from which a stream was exposed to us
Is that the correct thinking ?
The main difference between Event and Observable is in how they handle state and un-subscription.
Event functions attach to the source event and do not give you any way to unsubscribe. If you use stateful combinators (like Event.scan) and then attach multiple observers to the resulting event, then they will all see the same state.
Observable functions construct "specification" of the processing pipeline. When you attach a handler to IObservable value, you get back an IDisposable that can be used to remove all handlers. Each handler attached to IObservable will get a new state (because the runtime creates a new processing chain according to the "specification").
In practice, the main difference is in the statfullness - if you want to share state, you can use the Event module - implementing the same using Observable is possible but harder.
If you're using events inside async, then you should use Observable and AwaitObservable (instead of built-in AwaitEvent), because using event combinators will leak memory - it will attach event handlers that are never removed.
I have an object that is updated from a polling loop on a thread. This object fires particular events when data changes, etc.
I'm trying to use this object in conjunction with a windows form, where I create event handlers on the form to update the UI. Of course, this causes cross-thread operation exceptions if I try to manipulate the UI directly in these handlers.
I can get it to work by going through the standard procedure of checking InvokeRequired, using a delegate, blah blah blah. But I want to publish this object as a library, and I don't want end-users to have to worry about all that.
I want my object to somehow take care of synchronizing those event callbacks with the form so that end-users can manipulate the UI elements in those handlers worry-free.
Is there a way to do this??
If your object is always related to a single form, there is a simple trick indeed. The important fact here is, that you instanciate your object from the thread you like to affect the form later.
The trick is to instanciate a simple Control (new Control()) in your object in the constructor. When you perform logic on your form, use the Invoke/BeginInvoke methods on this simple control, to dispatch the action to the correct calling thread. So you have the dispatching logic directly in your object and there is no need for other users of your object to take care about this.