After watching a few Redux tutorials I still have a few questions:
After creating my store, i have:
ReactDOM.render(, document.getElementById('root'));
Going into the App component, I define:
function mapStateToProps(state) {
return {
posts: state.posts,
comments: state.comments
}
}
function mapDispatchToProps(dispatch) {
return bindActionCreators(actions, dispatch)
}
Where do state and dispatch come from? Is this automatically referring to the store's state and dispatch since i connected it to my component?
One of my React components has a form which on submit, calls a function:
handleSubmit(event) { ... }
So in the constructor of that component, I have:
constructor() {
super()
this.handleSubmit = this.handleSubmit.bind(this);
}
Is calling super() always necessary when declaring a React class component?
Why do I need to do this type of binding there?
After submitting that form, I dispatch an action called addPost.
How does it "go" to the reducer? Is it just because the reducer was given when I created the store and using mapDispatchToProps(dispatch) I "let" Redux know which actions could be dispatched to that reducer?
The reducer simply returns a state object. Where is the logic that actually "saves" that state into the store? Is it hidden?
Yes, treat state and dispatch as references to your redux state and the dispatch function respectively.
React docs say:
If you don’t initialize state and you don’t bind methods, you don’t need to implement a constructor for your React component.
Try an arrow function for your handler:
class MyComponent extends Component {
handleSubmit = () => {
// ...
}
}
The reducer was given to the store, the store was given to the react-redux <Provider> component, and the Provider component provides a React context where dispatched actions in descendant components get picked up by said reducers.
That logic is in the redux library.
Please check out our new official React-Redux docs . Specifically, you should read through connect: Extracting Data with mapStateToProps and connect: Dispatching Actions with mapDispatchToProps.
If you define a constructor for a class, and it extends another class, then yes, you need to call super() as the first line of the constructor - that's how ES6 classes are defined to work.
Redux only has a single reducer function. The insides of dispatch() look like this:
function dispatch(action) {
newState = rootReducerFunction(oldState, action);
subscriberCallbacks.forEach(callback => callback() );
}
You might want to read through the Structuring Reducers page in the Redux docs to get a better understanding of how and why reducers are normally split into smaller functions.
In most cases, the logic that combines the different "state slices" back together is in combineReducers(), because you used it to generate the "root reducer" function.
Where do state and dispatch come from? Is this automatically referring to the store's state and dispatch since i connected it to my component?
State is one of the hardest to understand topics and comes in front and center when we start concentrating on Redux. Each class-based component that we define has its own state object.
mapStateToProps is our ability to interface from the application level state down to the component level. Its where we sort of pluck properties off our state object and inject them into our components.
dispatch is how you change the state in your application, you dispatch an action.
In your implementation, you are using bindActionCreators, which turns an object whose values are action creators, into an object with the same keys, but with every action creator wrapped into a dispatch call so they may be invoked directly.
I personally have not ever connected redux actions this way, so I had to look this one up.
Is calling super() always necessary when declaring a React class component? Why do i need to do this type of binding there?
Yes, React components always have to call super in their constructors to be set up properly.
For an in-depth explanation of this kind of binding trickery, begin with the React docs. If you are not so inclined, just know that in React, whenever you define an event handler that uses this, you need to add this.methodName = this.methodName.bind(this) to your constructor function.
Related
Let's say I have a lot of app state to manage in my React application.
Therefore, I would like to split the state into smaller, manageable chunks.
For example I have the following main component with state and methods that alter this state.
class App extends Component {
constructor(props) {
super(props);
this.state = {
foo: ['some', 'items'],
bar: [{ arr: 'of objects'}]
}
}
changeFoo() {some code in here...}
changeBar() {some code in here...}
}
The state and methods written in the App component are getting out of hand. Yet it must be written in the App component since the state is passed to other components as props.
How would you usually manage this?
When you see that the state of your React application is getting out of hand, it's usually time to bring in a state management library like Redux (there're a few and Redux is the most popular one).
It'll help you have a global state that is managed in a reasonable way.
When we see how React works. It is based on one-directional data flow.
So, usually the Application state is kept at the top most Component (Say, App Component) in your case. So that data/state can be passed down as props to the component that needs it.
There, however may be the cases where children components of the parent, needs to work with the same data(Say in case of an event - a button click that happens in the child component.) In that case we write a function in the parent component and pass the function as props to the children, so that the state gets updated in the parent itself and any child gets updated data.
In pure React (without using any state management library), we have to pass the state as props to work with our app. But in case you choose to use a state management library such as Redux, then the components (known as Containers) can directly communicate with the Application State.
And If your application state contains objects within objects(like you have shown) or Array of Objects containing more Objects, then you cannot use setState() to update the state directly. In most of the cases, you take copy of the state and then use JSON.parse(JSON.stringify(state)) to do deep cloning and work with the state in a best possible manner.
There are other things in the example, the functions that you have used within the class , you need to bind the scope of this variable to point to the current class. This we do inside the constructor method, or simple make use of arrow function in order to avoid errors.
If you need more explanation, I will share with you :)
One solution is to make a generic change() function with a parameter for the key that should be changed:
change(key, value) {
setState({key: value, ...this.state});
}
Now when you want to add a listener to a child component:
<Foo onChange={ value => change('foo', value) }/>
<Bar onChange={ value => change('bar', value) }/>
I am learning how redux works but its a lot of code to do simple things. For example, I want to load some data from the server before displaying. For editing reasons, I can't simply just use incoming props but I have to copy props data into the local state.
As far as I've learned, I have to send a Fetch_request action. If successful, a fetch_success action will update the store with new item. Then updated item will cause my component's render function to update.
In component
componentWillMount() {
this.props.FETCH_REQUEST(this.props.match.params.id);
}
...
In actions
export function FETCH_REQUEST(id) {
api.get(...)
.then(d => FETCH_SUCCESS(d))
.catch(e => FETCH_FAILURE(e));
}
...
In reducer
export function FETCH_REDUCER(state = {}, action ={}) {
switch (action.type) {
case 'FETCH_SUCCESS':
return { ...state, [action.payload.id]: ...action.payload }
...
}
Back in component
this.props.FETCH_REDUCER
// extra code for state, getting desired item from...
Instead, can I call a react-thunk function and pass some callback functions? The react-thunk can update the store and callbacks can change the component's local state.
In component
componentWillMount() {
this.props.FETCH_REQUEST(this.props.match.params.id, this.cbSuccess, this.cbFailure);
}
cbSuccess(data) {
// do something
}
cbFailure(error) {
// do something
}
...
In action
export function FETCH_REQUEST(id, cbSuccess, cbFailure) {
api.get(...)
.then(d => {
cbSuccess(d);
FETCH_SUCCESS(d);
}).catch(e => {
cbFailure(d);
FETCH_FAILURE(e);
});
}
...
Is this improper? Can I do the same thing with redux-observable?
UPDATE 1
I moved nearly everything to the redux store, even for edits (ie replaced this.setState with this.props.setState). It eases state management. However, every time any input's onChange fires, a new state is popping up. Can someone confirm whether this is okay? I'm worried about the app's memory management due to redux saving a ref to each state.
First of all, you should call your API in componentDidMount instead of componentWillMount. More on this at : what is right way to do API call in react js?
When you use a redux store, your components subscribe to state changes using the mapStateToProps function and they change state using the actions added a props through the mapDispatchToProps function (assuming you are using these functions in your connect call).
So you already are subscribing to state changes using your props. Using a callback would be similar to having the callback tell you of a change which your component already knows about because of a change in its props. And the change in props would trigger a re-render of the component to show the new state.
UPDATE:
The case you refer to, of an input field firing an onChange event at the change of every character, can cause a lot of updates to the store. As mentioned in my comments, you can use an api like _.debounce to throttle the updates to the store to reduce the number of state changes in such cases. More on handling this at Perform debounce in React.js.
The issue of memory management is a real issue in real world applications when using Redux. The way to reduce the effect of repeated updates to the state is to
Normalize the shape of state : http://redux.js.org/docs/recipes/reducers/NormalizingStateShape.html
Create memoized selectors using Reselect (https://github.com/reactjs/reselect)
Follow the advice provided in the articles regarding performance in Redux github pages (https://github.com/reactjs/redux/blob/master/docs/faq/Performance.md)
Also remember that although the whole state should be copied to prevent mutating, only the slice of state that changes needs to be updated. For example, if your state holds 10 objects and only one of them changes, you need to update the reference of the new object in the state, but the remaining 9 unchanged objects still point to the old references and the total number of objects in your memory is 11 and not 20 (excluding the encompassing state object.)
In my project I have a call to an action that makes a webservice call and in turn dispatch actions to the result of the ws, these actions edit the store.
My problem is in :
ComponentDidUpdate () {
If (this.props.messages.length) {
Const items = this.props.messages.filter (this.isDisplayable);
This.timer = setInterval (() => {
If (items.length> 0) {
This.props.popItem (items);
} Else {
ClearInterval (this.timer);
}
}, This.props.interval);
}
}
In fact it is launched several times and I have warnings of
Warning: flattenChildren (...): Encountered two children with the same
key, 1. Child keys must be unique; When two children share a key,
only the first child will be used.
I used the componentDidMount but it launches it before api responds.
my question is:
Is that there is a way to update the component only at the response of my action, or alternatively to pass the warnings ?
try this :
componentWillReceiveProps(nextProps) {
if (this.props.messages === nextProps.messages) return;
i had some probleme and i resolve it by force update
forceUpdate () {
If (this.props.messages.length) {
...
}
}
In my project I have a call to an action that makes a webservice call and in turn dispatch actions to the result of the ws, these actions edit the store.
None of the methods componentDidMount and componentDidUpdate are good.
Observe the Store in Redux and update your component accordingly when the correct action TYPE is found.
Since you are using the Redux architecture, the state for all your components is in a single place — in the Store.
yes i know, but the problem is that componentDidUpdate is called several times which gives me the index error.
This is quite normal in React. Check this lifecycle.
What you should do is the govern the Redux architecture.
I will try today to provide some diagrams for you.
In general, anything you do will be from the global Store.
You may forget the React.Component state, and props you had in the non-Redux applications.
You typically need to use the Wrapper as a context provider around your app, where the context is the property of React.Component.
The context will be passed to all children and grandchildren so this will be the global Store organization.
Then you will need to read the Store from the context, and call the two typical methods: dispatch and subscribe.
I have redux store that looks something like this:
{
user: {},
alerts: [],
reports: [],
sourses: []
}
For each one of this parts of state i have a bunch of React Components wrapped in a container wich connected via react-redux. And has mapStateToProps like this
(state) => {alerts: state.alerts}
(state, ownProps) => {alert: _.filter(state, {id: ownProps.curId})}
Problem that when i for example launch some action for Alerts like CREATE_ALERT or EDIT_ALERT and redux state updated, ALL REACT COMPONENTS WILL RESPOND TO THIS CHANGE even ones that works with different parts like sources or reports.
My question: how to "bind" certain components to certain parts of a tree. So each container component WILL UPDATE ONLY WHEN APROPRIATE PART OF REDUX STATE UPDATED and ignore other changes.
Expected behavior
Dispatch CREATE_ALERT -> Alert reducer -> Redux store update -> ONLY Alert container component re-rendering.
When you are changing state in redux the whole state becomes just a new object.
Then your component is given by this new object (new reference) and re-renderes itself.
To fix this behaviour you need to add some logic to compare if your component got props with different value (not reference).
The easiest and fastest way is to use React.PureComponent. You can also override shouldComponentUpdate function and handle changes by yourself. But note that PureComponent works only with primitives (it does a shallow compare).
Check also Immutable.js which helps you with intelligent way of changing references of props.
if you use connect method, then pass only selected redux state to the component, this will prevent rendering of other components
example:
User Component:
const mapStateToProps = state =>({
users: state.users
});
export default connect(mapStateToProps)(User)
Alert Component:
const mapStateToProps = state =>({
alerts: state.alerts
});
export default connect(mapStateToProps)(Alert)
Check this out: Avoid Reconciliation
There explains what Neciu says.
Container components created with connect will always receive notifications of all updates to the store.
The responsibility for consuming these updates falls on the receiving connect component. It should contain the logic to extract the data relevant to it.
I'm creating a component that handles the state with Redux architecture (yes, this is probably bad by definition because a component should delegate the state to the app but anyway).
This component accepts different props. My problem comes when I have to handle a callback. Let's put a practical example to picture this better.
Let's say we need a component like <App onSubmit={() => {}} />.
We could create a store when the component gets mount, so then all inner components can dispatch actions/subscribe changes/etc.
The attempt could be to have an action called submit(). This way the store will know there's a change to apply so any subscriber will know and somebody will call this onSubmit callback.
So the code would look like:
class App extends Component {
constructor (props) {
super(props)
this.subscriber = this.subscriber.bind(this)
}
componentWillMount() {
this.store = createStore()
this.store.subscribe(this.subscriber)
}
subscriber (action) {
if (action.type === 'submit')
this.props.onSubmit()
}
render () {
return (
<Provider store={this.store}>
<FooComponent />
</Provider>
)
}
}
The problem is that, although subscriber is called on every action dispatched, subscriber can't know what was the last action dispatched. So there's no way to know when to call onSubmit.
How can we use subscriber to know changes on the store?
Should I stop trying a redux arquitecture in here?
This is an anti-pattern in Redux.
There is no such thing as “the last action” because Redux reserves the right to notify you just once in case of several nested dispatches.
Instead, you should perform the local side effect together with the action. Redux Thunk is a popular way to do this. If you need more decoupling, you might enjoy Redux Saga instead.