Angular is based on Event Driven or Data Driven Model.
using of ngRx follows which pattern data driven or event driven.
I think it really depends on your implementation.
If your implementation is based on CRUD, I guess you say it is data driven as any http requests will mutate state data that will eventually trigger UI update.
However, if your overall system is implemented in for example SignalR based architecture, then coming SignalR event shall dispatch ngrx actions with a playload to be able to mutate state. In this case, I guess you can say it is an event driven model.
Related
What is the difference (benefits/cons) of using Vuex vs a service for state management.
I am working on an application that displays a catalog of items. These items are fetched from an API. At the moment users have the ability to apply filters and sort the items.
I am using a service to handle updating the view based on what filter the user applies. The items are filtered on the back end so each time a filter is triggered an update method fetches the items from the API.
There's a few levels of component nesting for this application (and these are reused among diff pages with sim functionality) and I used an event bus as a quick way to handle the events and test the API endpoints, but now I need to use Vuex to handle the state.
I am starting to write the Vuex store and I am noticing there's quite a bit of functionality that I'm transferring over from the service.
I would like to know how the too differ?
I'm relatively new to VueJS, so please take this with a grain of salt.
I think it depends on the size of the app, as well as the complexity. If you're emitting a lot of events, using state makes sense because you have a single source of truth (a single file, literally) for your app state vs an event bus which will have to be imported into every component. From the Vuex site,
If you've never built a large-scale SPA and jump right into Vuex, it may feel verbose and daunting. That's perfectly normal - if your app is simple, you will most likely be fine without Vuex. A simple global event bus may be all you need. But if you are building a medium-to-large-scale SPA, chances are you have run into situations that make you think about how to better handle state outside of your Vue components, and Vuex will be the natural next step for you. There's a good quote from Dan Abramov, the author of Redux.
Hope this helps. Good luck :)
I'm writing a react/redux app that has a Job object that fires Events from time to time. On these Events the user is expected to react. I can easily write the React component that shows such a job or events, but don't know where to put the logic when
the user is not on the Job page
and an Event happens
and I would like to pop up a notification
Of course, once I get access to the store, I can create the notification too.
Shall I handle such logic in a React container that render() nothing?
Or handle it with vanilla JS when I load a Job data?
Or to handle it in the reducer when the data is stored? (probably not recommended)
My problem with the option two is that I don't know how to access the redux store from a totally ad-hoc code, as my store is not a global object.
What do you recommend?
Generally speaking, the two places that you'd put code that needs to access the store (for either dispatching or receiving state updates) is in middleware or a connected component. If you specifically want to respond to an action coming through, then you would need to use middleware.
I actually threw together a sample timer middleware in a chat discussion a few weeks ago. I just pasted it as a gist here as an example: https://gist.github.com/markerikson/ca96a82d6fdb29388aca4052a9455431 . Illustrates the idea of doing something asynchronously in the background.
You may also want to look through the list of middlewares in my Redux addons catalog: https://github.com/markerikson/redux-ecosystem-links/blob/master/middleware.md . Numerous examples of ways to execute background-ish logic.
Finally, https://github.com/yelouafi/redux-saga (which is itself a middleware) is a fairly common lib used to do background-ish logic.
I am building a simple React application with the following component hierarchy structure:
--- ReqList (shows a list of Request Items)
------ ReqListHeader (A div that has list title and some buttons)
------ ReqTable (list of request items)
--------- ReqRow (one row of request)
------------ ReqItemHeader
------------ ReqItemBody
------------ ...few more components in between
--------------- ReqEditor
------------------ TextArea
The root component receives data via ajax call and calls setState(data), as per the standard docs of React, and all is well, and this works correctly. I am able to show all descendant components and their values.
However for form input (textarea), the input doesn't change. I understand that I have to implement a change handler. The thing that I am unsure about is, where to implement it?
Option I:
I initially thought, I would just add a changeHandler function in its immediate owner, by calling setState() on it. But I am afraid that I am breaking the uni-directional data flow principle by introducing a state in a middle level component.
Option II: Should I pass a changeHandler callback as a property from say "ReqRow" component all the way down to ReqEditor, so that it could be bound to textArea change event?
Option III: Or should I start at the root of the hierarchy i.e. ReqList? That is because, even ReqRow receives the data from its owner and its parent and so on, since that is the entry point for data.
I am not too sure, the level of upwards propagation that I should do in this case. Most of the examples are simple ones with two level hierarchy. I am sure this can be done, but involves passing down the change handler callback all the way from to its grand child.
Is this correct, or is there any other better way?
The problem your facing is solved by using any of the Flux pattern implementations. React only provides a solution for the data rendering part, but it does not provide any clue on how to handle the data flow.
Flux is a pattern proposed by Facebook that tries to structure your app so changes in the data are manageable in a clean way.
From the Flux documentation:
All data flows through the dispatcher as a central hub. Actions are provided to the dispatcher in an action creator method, and most often originate from user interactions with the views. The dispatcher then invokes the callbacks that the stores have registered with it, dispatching actions to all stores. Within their registered callbacks, stores respond to whichever actions are relevant to the state they maintain. The stores then emit a change event to alert the controller-views that a change to the data layer has occurred. Controller-views listen for these events and retrieve data from the stores in an event handler. The controller-views call their own setState() method, causing a re-rendering of themselves and all of their descendants in the component tree.
This dense paragraph is a summary of the solution to your problem.
EDIT: You can also employ baobab, a library that offers an inmutable tree of data that emits events when some field (or its children) are updated. So each component listens to changes on the fields that it needs. There is a package for integrating it with React. I've used it and works great.
In Flux every action should be handled by the dispatcher.
What about an action that doesn't alter the view or the markup, such as "scroll this element into view"? What is the "Flux-way" of handling such a scenario? To by-pass the dispatcher? Or to handle it in the dispatcher without involving the stores or the components?
Flux is really more about application state management, and is not at all about the details of what components are rendered in the view. That's the domain of React. Flux simply assumes you have some kind of reactive view layer -- usually that's React.
Application state is not the same as component state. Application state is something that needs to be known in multiple components. For component state, React's this.state is perfectly adequate. An input component is a good example of something that might need this.
So in your case, if only one component needs to know the scroll position, there may not be a good case for moving that state to a Flux Store. But as soon as that needs to be known in multiple components -- especially components in different branches of the tree -- you probably want that state being managed in a Store.
The other issue your question raises is the role of Flux Actions. A Flux application always uses Actions as the origin of the data flow. There are a lot of good reasons for doing this: stable application state, keeping the app resilient to new features, keeping it easy to reason about, undo history, reconstitution of application state, stateless view components, etc.
Occasionally people want to write as little code as possible and they use a callback passed between components to change this.state in the parent component instead of dispatching a new action to go through the Flux data flow. I find this to be mixing the view and state management layers of an application, and while expedient, this can lead to a lot of headache. It isn't very flexible in the long run, because now the state is coupled to these few components. Building up a Flux data flow from the start is much simpler in the long run, and much more resilient to new features. That said, it also requires more investment in code up front.
If your app doesn't need to know about scrolling (seems rare that it would), there's no need to fire an action. Since Flux is really there to handle data flow (and subsequent changes based on that data flow), it doesn't need to know about every action that occurs.
What is the advantage of using Flux over a global event bus? I think the dispatcher is all that is needed:
component publishes 'user event' with data to the dispatcher
dispatcher executes handler of the subscribed store
handler publishes 'update event' with the store's updated properties
dispatcher executes handler of the subscribed component, and updates component state with the store's updated properties
What am I missing here that I can't do without Flux?
I think what others have said about application structure and the change event is important, but I should add this one thing:
The dispatcher's waitFor method is the biggest difference between registering the stores with a dispatcher vs. the stores listening to a global event bus. This method lets you manage which stores update before others. And that becomes vital when you want StoreB to look first at what StoreA did before it decides what to do.
You could think of the dispatcher as a global event bus with a waitFor method, and that would be somewhat accurate.
I'm not an expert in flux but an architecture doesn't enable you to do something that wasn't possible before, it gives your application a structure that is extensible and understandable.
I believe it's all about code structure which is understandable even in large scale.
Supose you have appState which holds underlying data for components.
The components call action. Action is responsible for gather data from XHR or modify the incoming data from component and then it dispatch complete data to subscribed store.
Store is the only part of your code, which can modify your appState and it is basically the only thing, what it does. It takes data from action and store them to appState or removes some data from appState according to action.
Then you fire stateChanged event, which your component should listen to and will rerender.
So you have all action specific logic in actions. You handle appState only in stores. And that should help you keep your code understandable.
Flux pattern
My understanding of why is good idea to dispatch only complete data comes mainly from this article. And it is based on official Facebook Flux diagram
The advantages of this approach are:
stores are simple and synchronous, does not contain decision logic, just handles given data
there is no need to fire another action in store, which will break one-directional chain of Flux
dispatcher is the single channel for all state changes, it knows what action with what data is processed, so its easier for debugging
You basically described flux, the only difference is:
stores emit a change event
And the component updating its state isn't part of flux, that's a common practice for integrating flux and react.
Flux just names each of these pieces and gives guidelines on what each piece's responsibility is.
It's essentially a main event emitter (dispatcher), the event types (actions), functions that emit an event on the dispatcher (action creators; the event body is a payload), and other event emitters that: keep state, listen to the dispatcher and emit change events (stores).
At least that's how it works in JS. The core principle is the unidirectional data flow. There are plenty of event emitters that are used for bidirectional communication.