I have my service and need to get data using getWithQuery, but I don't need NgRx store to be updated. I just need to get this data and use them in subscribe method.
I've tried different EntityActionOptions.mergeStrategy but cache is still updated.
Any ideas?
Thanks!
This isn't possible AFAIK #ngrx/data is bound to the store.
If you just need the data, you can invoke the service directly.
The ngrx store purpose is to be responsible for the app state. It means if you want to fetch something you dispatch an action that updates the store and then you select this data from the store.
If you want to fetch data directly skipping the store and select parts - it means you follow against ngrx purpose and perhaps you don't ngrx at all.
If you want to ngrx then consider writing you app in the way that it always puts data into the store if something is updated / fetched and to display the data it's always selected from the store.
Why reducer must return new state what is the reason for that .Why can't we return the updated state? Is that the pattern that we must follow or what?Also please let me know that ngrx and redux are they completely different?
I think because the view layer needs to compare current state and previous state, they should be different objects. Also, it can support other features like debugging, time travel.
In both the library, They return a newly modified state or the original state
Just going through the official docs of both NgRX reducer and Redux reducer
NGRX Reducer
Reducers in NgRx are responsible for handling transitions from one state to the next state in your application.
Reducer functions are pure functions in that they produce the same output for a given input. They are without side effects and handle each state transition synchronously. Each reducer function takes the latest Action dispatched, the current state, and determines whether to return a newly modified state or the original state
Redux Reducer
Reducers specify how the application's state changes in response to actions sent to the store.
Regardless of the state management pattern, You need to change the state through reducers as actions are responsible fpr source of information for the store. They are the entry points to interact with store in Both NgRx and 'redux', moreover in Vuex too.
As per the state management library implementation, I guess they both follow same principle of Actions, Reducer to update the state async. There might be some possibly they may have different feature.
Hope this helps!
Both libraries aim to manage a state which is only manipulated in particular, predefined ways; reducers are the access they provide to the state.
By limiting the ability to manipulate the state directly, they make it easier to understand how a particular state was reached; it is always possible to reach a particular state by dispatching the same actions again, and a given state can only be reached as a result of the actions dispatched to state (at least, this is the ideal - impure* reducers would potentially lead to different states being reached from the same actions).
If we imagine a state manager which allowed functions to manipulate state, which is what would be required to return a mutated version of the original state, then it would be far more difficult to understand how a given state was reached, as the store could have been manipulated at any point by any function.
This article gives a good overview of the key ideas behind redux and explains why redux does the things it does. Here are the relevant parts for your question:
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.
Changes are made with pure functions
To specify how the state tree is transformed by actions, you write pure reducers.
Reducers are just pure functions that take the previous state and an action, and return the next state. Remember to return new state objects, instead of mutating the previous state. You can start with a single reducer, and as your app grows, split it off into smaller reducers that manage specific parts of the state tree. Because reducers are just functions, you can control the order in which they are called, pass additional data, or even make reusable reducers for common tasks such as pagination.
I have far less experience with ngrx, though as it seems like a redux-inspired store, I'll presume it follows more or less the same principles. I'd be happy to be proven wrong, in which case I can update this answer.
*An impure function function would do one or many of the following:
Access state other than the arguments it was passed
Manipulate the arguments it was passed
Contain a side effect - something which affects state outside of itself
Mutating state is the most common cause of bugs in Redux applications, including components failing to re-render properly, and will also break time-travel debugging in the Redux DevTools. Actual mutation of state values should always be avoided, both inside reducers and in all other application code.
Use tools such as redux-immutable-state-invariant to catch mutations during development, and Immer to avoid accidental mutations in state updates.
Note: it is okay to modify copies of existing values - that is a normal part of writing immutable update logic. Also, if you are using the Immer library for immutable updates, writing "mutating" logic is acceptable because the real data isn't being mutated - Immer safely tracks changes and generates immutably-updated values internally.
From Redux Doc.
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
All:
I am pretty new to Redux, React-redux and React, one concept I learn about Redux is single store.
I kinda having some difficulty to determine where to store data when use React with Redux, what kind of data I should store in Component Class state, and what should store in Redux store?
Any simple example will be appreciated
Thanks
How you divide up your state is entirely up to you. A recent Reddit comment has some pretty good rules of thumb:
Do other parts of the application care about that list?
Do you need to be able to derive data from that list?
Is the same data being used to drive multiple components/features
Is there value to you, to being able to restore the state to a given point in time (ie: time travel / debugging)
Do you want to cache the data, ie: reload it from state if it's already there instead of requesting it again?
Not /everything/ needs to go into your global app state. There can be benefits to putting every-last bit of thing into your state, but there can also be complications.
The Redux FAQ also discusses this topic: http://redux.js.org/docs/FAQ.html#organizing-state-only-redux-state
Most examples of Flux use a todo or chat example. In all those examples, the data set you are storing is somewhat small and and be kept locally so not exactly sure if my planned use of stores falls in line with the flux "way".
The way I intend to use stores are somewhat like ORM repositories. A way to access data in multiple ways and persist data to the data service, whatever that might be.
Lets say I am building a project management system. I would probably have methods like these for data retrieval:
getIssueById
getIssuesByProject
getIssuesByAssignedUser
getIssueComments
getIssueCommentById
etc...
I would also have methods like this for persisting data to the data service:
addIssue
updateIssue
removeIssue
addIssueComment
etc...
The one main thing I would not do is locally store any issue data (and for that matter most store data that related to a data store). Most of the data is important to have fresh because maybe the issue status has updated since I last retrieved that issue. All my data retrieval method would probably always make an API requests to the the latest data.
Is this against the flux "way"? Are there any issue with going about flux in this way?
I wouldn't get too hung up on the term "store". You need create application state in some way if you want your components to render something. If you need to clear that state every time a different request is made, no problem. Here's how things would flow with getIssueById(), as an example:
component calls store.getIssueById(id)
returns empty object since issue isn't in store's cache
the store calls action.fetchIssue(id)
component renders empty state
server responds with issue data and calls action.receiveIssue(data)
store caches that data and dispatches a change event
component responds to event by calling store.getIssueById(id)
the issue data is returned
component renders data
Persisting changes would be similar, with only the most recent server response being held in the store.
user interaction in component triggers action.updateIssue(modifiedIssue)
store handles action, sending changes to server
server responds with updated issue and calls action.receiveIssue(data)
...and so on with the last 4 steps from above.
As you can see, it's not really about modeling your data, just controlling how it comes and goes.