Is there any tool out there which can generate sequecne diagrams from redux actions calls ? Basically i have written a client side applciation using javascript, Redux and Angular and want to generate a sequence diagram
The short answer: I didn't see anything like that until now.
But it should be relatively easy to implement, here are some of my thoughts:
With Redux you already should have most of the stuff in your hand:
The communication partners are various web components which are triggering actions and/or subscribing to the store.
A request between a communication partners is represented by a dispatched action.
Each time an action has been dispatched we persist (depending on the application perhaps as part of the state) the following information that is later needed to draw a sequence diagram:
the communication partner that triggered the dispatch of the action (a property within the action)
the action type
the receivers, i.e. the communication partner(s) that is(are) interested in the changes that were triggered by the action. This could perhaps come from additional "acknowledgement" actions triggered by the receivers or from a static configuration that contains a mapping of which subscribers are interested in which parts of the state.
Related
I have the following use-case. I use NgRx Store/Effects and I need to send a request to my back-end service.
Request is initiated in my component, then dispatch to NgRx Effect and then sent to my back-end service.
But I need to attach a piece of state to my Http request. So far I see two ways of doing it:
1) Select state from Store in the component and include into Action as payload
2) Inject Store into Effect and select piece of the state from Store in the specific effect
What is the suggested way from NgRx-driven point of view?
Personally I would opt for option one if possible. Because it's easier to understand with the benefit that it's easy to test.
There are some times where this isn't possible or where it would cause too much overhead, if that's the case I use a withLatestFrom(storeSelector) inside an effect.
From: https://redux.js.org/introduction/three-principles
State is read-only. The only way to change the state is to emit an action, an object describing what happened. This ensures that neither the views nor the network callbacks will ever write directly to the state. Instead, they express an intent to transform the state. Because all changes are centralized and happen one by one in a strict order, there are no subtle race conditions to watch out for. As actions are just plain objects, they can be logged, serialized, stored, and later replayed for debugging or testing purposes.
Two questions arise for me from this...
How is redux enforcing that changes happen in a strict order? If I change state synchronously then I don't see why this would ever be a problem. If I want to change state after async event 1 and async event 2 in order then wouldn't I have to do something like use callbacks or promises regardless of whether I'm using redux to ensure that the state changes in the order I expect?
Why is it easier to log an action? If I weren't using redux, couldn't I just console.log every state change I make to make it easier for debugging and testing? Am I just saving the time of writing console.log upon each state change by learning redux?
To answer your questions:
redux's execution is synchronous so when you dispatch an action, you're executing a a method on the redux store, which call the reducer to compute the new state. The concept of "async actions" don't exist in redux, which is why you have a host of solutions to enable them: redux-thunk, redux-saga, redux-observable and so on. All "async actions" library eventually have to execute the dispatch function synchronously to change the redux state.
In a well-written redux applications, changes to any state contained within the redux store could only have been caused by an action dispatched from somewhere within the application that has access to the dispatch function. This allows you to have total control and knowledge of where and how state changes happen. That's the main selling point of redux: "predictable state container." You can certainly store your local state in some global variable and manually mutate it but then you'll have to use something like Object.observe (which is actually deprecated with no replacement in sight) on that state variable to monitor changes to it.
In redux,
If an action creator wants to modify two combined reducer states.
Then, what is it better:
The action creator dispatches two action types?
The action creator dispatches one action type and the two reducers listen to that action?
When I cannot subscribe actions to a reducer, (i.e. the reducer of react router) the only solution that I have is to dispatch my reducer action and then to dispatch the result of an action creator (i.e. react router's push or replace) as a side effect using a thunk or saga
What do you guys think?
Either is a viable approach. The Redux FAQ addresses this under "Should I dispatch multiple actions in a row from one action creator?":
In general, ask if these actions are related but independent, or should actually be represented as one action. Do what makes sense for your own situation but try to balance the readability of reducers with readability of the action log. For example, an action that includes the whole new state tree would make your reducer a one-liner, but the downside is now you have no history of why the changes are happening, so debugging gets really difficult. On the other hand, if you emit actions in a loop to keep them granular, it's a sign that you might want to introduce a new action type that is handled in a different way.
I also addressed the topic in my article Idiomatic Redux: Thoughts on Thunks, Sagas, Abstraction, and Reusability.
In flux I'm wondering, is it okay to
make async operation
change multiple values (by different keys) in state
trigger actions
in a single store? If I need to update 2 keys of store, should I create another store to separate concerns and make store responsible for a single first level property in state?
E.g. in Redux reducer is responsible for a single first level key on resulted object, asaik
Make async operations:
Typically it is better to keep your stores synchronous... they should be dumb and just receive data. Makes everything easier and testable! The action creator should dispatch the appropriate action once it has resolved.
Change multiple values (by different keys) in state:
This isn't that bad, but as you eluded too, perhaps you need to rethink how your app state is structured. It depends on the action though... hard to say without knowing the context.
Trigger actions:
Your views are responsible for triggering actions... So stores should not trigger actions!
Some links:
Async requests with React.js and Flux, revisited.
Using a Redux store in your React.js application
I am writing an Adobe AIR application using PureMVC.
Imagine that I have an page-based application view ( using ViewStack ), and user is navigating through this pages in some way ( like clicking the button or whatever ).
Now for example I have an Account Infromation page which when instantiated or showed again needs to load the data from WebService ( for example email, account balance and username ), and when the data is returned I want to show it on my Account Information page in the proper labels.
The problem is when I will execute this three Web Calls, each of them will return different resultEvent at different time. I am wondering what is the best way to get the information that ALL of the service calls returned results, so I know that I can finally show all the results at once ( and maybe before this happens play some loading screen ).
I really don't know much about PureMVC, but the as3commons-async library is great for managing async calls and should work just fine in any framework-setup
http://as3commons.org/as3-commons-async/
In your case, you could create 3 classes implementing IOperation or IAsyncCommand (depending on if you plan to execute the operations immediately or deferred) encapsulating your RPCs.
After that is done you simply create a new CompositeCommand and add the operations to its queue.
When all is done, CompositeCommand will fire an OperationEvent.COMPLETE
BTW, the library even includes some pre-implemented common Flex Operations, such as HTTPRequest, when you download the as3commons-asyc-flex package as well.
I would do it in this way:
Create a proxy for each of three information entities (EMailProxy, BalanceProxy, UsernameProxy);
Create a delegate class which handles the interaction with your WebService (something like "public class WSConnector implements IResponder{...}"), which is used by the proxies to call the end ws-methods;
Create a proxy which coordinates all the three results (CoordProxy);
Choose a mediator which will coordinate all the three calls (for example it could be done by your ApplicationMediator);
Create notification constants for all proxy results (GET_EMAIL_RESULT, GET_BALANCE_RESULT, GET_USERNAME_RESULT, COORD_RESULT);
Let the ApplicationMediator get all 4 notifications;
it is important that you should not only wait for all three results but also be ready for some errors and their interpretation. That is why a simple counter could be too weak.
The overall workflow could look like this:
The user initiates the process;
Some mediator gets an event from your GUI-component and sends a notification like DO_TRIPLECALL;
The ApplicationMediator catches this notification, drops the state of the CoordProxy and calls all 3 methods from your proxies (getEMail, getBalance, getUsername).
The responses are coming asynchronously. Each proxy gets its response from the delegate, changes its own data object and sends an appropriate notification.
The ApplicationMediator catches those notifications and changes the state of the CoordProxy. When all three responses are there (may be not all are successful) the CoordProxy sends a notification with the overall result.
I know it is not the best approach to do such an interaction through mediators. The initial idea was to use commands for all "business logic" decisions. But it can be too boring to create the bureaucracy.
I hope it can help you. I would be glad to know your solution and discuss it here.