Passing data based on another api response from redux - reactjs

I have an api which will list what all access do the current user have, so once the app.js loads I am calling the api in the componentWillMount, so basically I have three routes , home, userslist, eachuser. So the home is a static text page.
userslist is a component where I list all the users, once you click on the edit icon of user it will take you to the details of the user in the eachuser component.
The problem is since the calls are async once the useraccessApi resolves and gets only the data I should call the usersListApi , by passing the useraccessApi response.
What I mean by happy flow is first user loads the localhost:3000/home so the useraccessApi will call and the redux have data, so while switching to userslist tab on componenWillMount it will work. But if the user directly selects localhost:3000/userlist it will throw error on componenWillMount so moved the code to componentWillRecieveProps().
So how can I resolve this issue. Or should I use mergeProps to resolve it.
App.js
componenWillMount(){
this.props.userAccessApi()
}
UsersList
componentWillMount(){
const {currentUserAccess} = this.props
// if its a happy flow else it will be currentUserAccess is undefined
if(currentUserAccess){
this.props.usersListApi(currentUserAccess)
}
}
// inorder to resolve it
componentWillRecieveProps(nextProps){
const {currentUserAccess} = nextProps
if(currentUserAccess){
this.props.usersListApi(currentUserAccess)
}
}
const mapStateToProps = (state) => {
return {
currentUserAccess: state.access
}
}

This is the expected behavior of React Lifecycle events.
For componentWillMount
This function is called right before the component’s first render, so at first glance it appears to be a perfect place to put data fetching logic.
But, there’s a “gotcha,” though: An asynchronous call to fetch data will not return before the render happens. This means the component will render with empty data at least once. Which is why your dispatch function fails and you get undefined.
Instead you should use ComponentDidMountas the event in which you will fetch data.
By the time componentDidMount is called, the component has been rendered once.
In practice, componentDidMount is the best place to put calls to fetch data.
Using it makes it clear that data won’t be loaded until after the initial render. This reminds you to set up initial state properly, so you don’t end up with undefined state that causes errors.

Related

When 'action'/'runInAction' is really needed in mobx react

Can someone explain to me what is the real difference and why both of the example here are working the same:
1) Change a state of observable via action/runInAction inside the store file:
colorStore file:
#observable
color='red'
#action
setColor(){
this.color='blue'
}
2)Change the state via the component itself (which assumed to be bad practice):
React Component file:
onClick = () => this.props.colorStore.color='blue' //still working...
Mobx action is doing the batching, similarly to how ReactJS batches multiple changes.
When you use reactjs click handler react is automatically batching changes that happen inside it, so you will not see component rendering multiple times, however, if you call setColor from some other event, let's say after loading some data, and have multiple calls to change the observable inside the setColor that will trigger the observer three times, and the component will be rendered three times.
When you wrap your function with #action decorator or you use runInAction function, only the last value will be used (green in the code below) and the component will be rendered only once.
setColor(){
// this will render three times
this.color='blue'
this.color='red'
this.color='green'
}
vanilla mobx example that reacts only once:
import { runInAction, observable, reaction, toJS } from "mobx";
const test = observable({
name: "sonic",
nick: "speed demon"
});
// console.log will be called only once with the value "name: 3"
reaction(
() => toJS(test),
data => console.log(`name: ${data.name}`)
);
runInAction(() => {
test.name = "1";
test.name = "2";
test.name = "3";
});
view on codesandbox
Also check out the discussion on the github repo: is #action really necessary?
The difference is more related to conventions and writing clean maintainable code than in the behavior of the program. So:
You are mutating store data in your UI component. This is not correct, because the UI should only visualize data and handle for example user actions which are then translated to certain action in the data store(in your case updating a color). It's store responsibility to manage the state of this data
All observable data is considered a good practice to be mutated only in actions. Why? Because the single source of mutating data is clear - only in actions and only in a data layer(the store). The code is less prone to errors and unclear state management and the great benefit is that you can enforce your application not to build if you turn on use strict mode

Using this.props.history.push("/path") is re-rendering and then returning

Edited the question after further debugging
I am having a strange issue, tried for a while to figure it out but I can't.
I have a React Component called NewGoal.jsx, after a user submits their new goal I attempt to reroute them to my "goals" page.
The problem: After they submit the browser loads in my goal page, but only for one second. It then continues and goes BACK to the NewGoal page!!
I am trying to understand why this is happening, I am beginning to feel that this might be an async issue.
Here is my code, currently it is using async-await, I also tried the same idea using a .then() but it also didn't work:
async handleSubmit(event)
{
const response = await axios.post("http://localhost:8080/addGoal",
{
goalID: null,
duration: this.state.days,
accomplishedDays: 0,
isPublic: this.state.isPublic,
description: this.state.name,
dateCreated: new Date().toISOString().substring(0,10),
}) */
// push to route
this.props.history.push("/goals");
}
While debugging, I tried taking out the functionality where I post the new message, and just did a history.push, code is below - and this completely worked.
// THIS WORKS
async handleSubmit(event)
{
// push to route
this.props.history.push("/goals");
}
But as soon as I add anything else to the function, whether before the history.push or after, it stops working.
Any advice would be very very appreciated!
Thank you
In the React Router doc's the developers talk about how the history object is mutable. Their recommendation is not to alter it directly.
https://reacttraining.com/react-router/web/api/history#history-history-is-mutable
Fortunately there are few ways to programmatically change the User's location while still working within the lifecycle events of React.
The easiest I've found is also the newest. React Router uses the React Context API to make the history object used by the router available to it's descendents. This will save you passing the history object down your component tree through props.
The only thing you need to do is make sure your AddNewGoalPage uses the history object from context instead of props.
handleSubmit(event)
...
//successful, redirect to all goals
if(res.data)
{
this.context.history.push("/goals")
}
...
})
}
I don't know if you're using a class component or a functional component for the AddNewGoalPage - but your handleSubmit method hints that it's a member of a Class, so the router's history object will be automatically available to you within your class through this.context.history.
If you are using a functional component, you'll need to make sure that the handleSubmit method is properly bound to the functional component otherwise the context the functional component parameter is given by React won't not be available to it.
Feel free to reply to me if this is the case.

Handling loading state in a React app that uses Redux with redux-thunk, going back to component after data has been fetched once

I have a React app that uses Redux with redux-thunk. Given a certain component that needs to fetch information from an API, I call a bound action creator to make that request after it mounts:
componentDidMount() {
this.props.fetchSomething();
}
For the UI to know whether it is in a loading state, I use a loading variable from the application state. My reducer handles three action types for LOADING, SUCCESS, and FAILURE. The loading variable is set to true when the LOADING action is emitted; then it is set to false on SUCCESS and FAILURE.
Thus there is the following in the render method:
render() {
if (this.props.loading) {
return <Spinner />;
}
return (
<div>
This part uses the fetched data, available via this.props.something
</div>
);
}
Because initially this.props.something is null, I also have to check for its existence before rendering the desired template, so the above if-statement becomes:
if (!this.props.something || this.props.loading) {
return <Spinner />;
}
This approach has served me well so far, but there are some issues, one of them being:
The first time I access the page, this.props.something is not yet set. But the second time I access the page, with the app already loaded, that data had already been fetched once, so this.props.something will have been defined. Because of that, there is brief moment in which the if statement condition is FALSE and the actual component template gets rendered.
(1) How would you guys take care of that issue?
(2) And with your approach, how would you handle a component that had to make multiple requests, like five of them, using the same approach above, with a different loading/something variable for each? I can duplicate the same approach above, but get the issue of brief if-statement failure for each resource that is already defined, but not loading.
1) You have two options. U can dispatch some RESET action on componentWillUnmount and reset your store, this.props.something will be null again. Second option is to show data if u already have them, show spinner and when second fetch is success merge it together. (depends on purpose and UI)
2) I have never needed it but what about to store it in redux as map {componentName: loaded} and check if all components are loaded?
Edit: When u set initial value of loading to true you don't need to check something prop.

How to clear error message coming from redux actions

I have an API, which may return an error. In the simplistic form, the component reads as below. The question is, when an error occurs, what is the steps to dismiss/clear the error message?
class LoginError extends Component {
render() {
return (
{
this.props.error != null ?
<h2>this.props.error</h2> :
undefined
}
)
}
}
const mapStateToProps = (state) => {
return {
error: state.error
};
}
export default connect(mapStateToProps, null)(LoginError);
There is no straight forward way to do this, you basically have two options: set the error to undefined in the reducer when another action fires, or provide a close button on the error itself using a reusable error component, that dispatches an action that will set the error to undefined in the reducer.
Personally i've always used the first method, lets take the submit of a form as an example. When the user submits the form you fire form-submit/request and maybe show a loading message. If the form is sent correctly you fire form-submit and if an error happens you fire form-submit/error, setting the error in the reducer. Then in form-submit/request you clear the error, so the user gets feedback if an error happens but if the form is submitted again the error is cleared. If you don't want to do anything when the form is submitted, which is odd, you can clear the error when form-submit is fired. The downside of this approach is that if for example you want to clear the error when any field of the form is changed, you'll have to add another action and make the error undefined for that action as well.
Now if you put a close button in the error component you can reuse the error React component, but you'll have to have a action/dismiss-error action for every API call and set the error to undefined on the reducer for each one of them, this can get very tedious quickly.
The best approach for me is to use the first method, but choosing carefully how much errors you display for each page or section. This way each page can have its error section that will be displayed for any API call that is associated with the page and you only need an error action for each page, not for every API call.
Quote from docs:
A store holds the whole state tree of your application. The only way
to change the state inside it is to dispatch an action on it.
That's it. If you keep something in redux state then to change it's value you have to dispatch an action.

Meteor handle.ready() in render() not triggering rerender of component

I have the following code in my render method:
render() {
return (
<div>
{this.props.spatulaReady.ready() ? <p>{this.props.spatula.name}</p> : <p>loading spatula</p>}
</div>
)
}
Which according to my understanding, checks if the subscriptionhandle is ready (data is there) and displays it. If no data is available, it should display a simple loading message. However, when I first load the page this snippet is on, it get's stuck on the loading part. On a page reload the data (usually) displays fine.
If I check the spatulaReady.ready() when the page first loads and while the display is stuck on 'loading spatula', and the data that should be there, the handle reports as ready and the data is there like it is supposed to be. If I refresh the page it all displays fine as well. The problem is, this way of checking for data and rendering if it has arrived has worked fine for me in the past. Is it because the render method is not reactive? Because handle.ready() should be reactive.
What makes it even weirder is that it sometimes DOES correctly display the data on page load, seemingly at random.
CreateContainer code:
export default createContainer(props => {
return {
user: Meteor.user(),
spatulaReady: Meteor.subscribe('spatula.byId', props.deviceId),
spatula: SpatulaCollection.findOne()
}
}, SpatulaConfig)
Publication code:
Meteor.publish('spatula.byId', function(deviceId) {
const ERROR_MESSAGE = 'Error while obtaining spatula by id'
if (!this.userId) //Check for login
throw new Meteor.Error('Subscription denied!')
const spatula = SpatulaCollection.findOne({_id: deviceId})
if(!spatula) //No spatula by this id
throw new Meteor.Error(403, ERROR_MESSAGE)
if(spatula.ownedBy != this.userId) //Spatula does not belong to this user
throw new Meteor.Error(403, ERROR_MESSAGE)
return SpatulaCollection.find({_id: deviceId})
})
I know I'm missing a piece of the puzzle here, but I've been unsuccessful at finding it. If you don't know the solution to my specific problem, pointing me in the right direction with another way of waiting for the data to arrive before displaying it is also greatly appreciated.
EDIT: After doing some trial-and-error and reading various other posts somewhat related to my project, I figured out the solution:
export default createContainer(props => {
const sHandle= Meteor.subscribe('spatula.byId', props.deviceId)
return {
user: Meteor.user(),
spatulaReady: sHandle.ready(),
spatula: SpatulaCollection.findOne()
}
}, SpatulaConfig)
It still makes no sense to me that moving the ready() call to create container fixed all my problems though.
As you figured out, moving the .ready() call to createContainer fixes the problem. This is because Meteor reactivity only works when you call a reactive data source (a reactive function), such as collection.find() or subscriptionHandle.ready() within a reactive context, such as Tracker.autorun or createContainer. Functions within the React component, including render, are not reactive contexts from Meteor's perspective.
Note that React and Meteor reactivity are two different things. React's reactivity works simply so that whenever a component's props or state change, it's render function is re-run. It does not understand anything about Meteor's reactive data sources. Since createContainer (that is re-run by Meteor reactivity when reactive data sources in it change) simply passes props to the underlying component, the component is re-rendered by React when the props given from createContainer change.

Resources