Get data from promise in redux - react-redux

When Reducer update state and I get state from store it returns a promise. Inside promise in values I have my data How can I access this value in promise.
enter image description here

To use async actions with Redux, you are going to want to use a middleware, mostly either redux-thunk or redux-saga. See Why do we need middleware for async flow in Redux?
As a beginner at Redux you should probably start with the official documentation on the topic.

Related

NGXS multiple sub states update from same async action

I have a parent-child states that manage reports and documents respectively.
When a report is submitted, I need to store the user posted data for the report and the async action returned id in the parent state, and the async action returned document in the document state.
Since I need the async action returned data in two different state actions, is there anyway to acomplish this without dispatching another action from the parent?
In React apps with redux toolkit different state slices can listen to pending/fulfilled/rejected states for the same async thunk so I was wondering if there is something similar for NGXS.
Thanks.
I know I can dispatch actions from another action providing different payloads so other sub states can listen to them and update accordingly, but I was hoping to accomplish that in one action.
I've also thought about calling the http async action first and after getting the result dispatch the store action but not sure if this is an anti-pattern.

How to set up a pinia store to wait for the state

I have a (composition) store that is used in s couple of modules, they are unaware of each other and can be initialized in the same moment as well as at different times.
The store retrieves data from an API and saves it in the state. All of the modules await the execute store's fetchData method, all of them await a promise it returns.
The problem is that when the modules are initialized at the same moment, both perform fetchData resulting in two requests fired. The ideal situation would be to
Allow only one request being fired (that's pretty easy to do, just save the request state in a ref, f.e. "pending")
Export the state as a promise, so that the module awaits the state to be loaded from an API, receiving it's data only thereafter.
Those with a requirement that the modules are unaware of the store implementation - the less code on their side the better.
How do you handle such cases?
Is a there anything wrong with this approach? If not - how to implement it?

GraphQL resolvers - when to make resolver functions async or not?

I completed this tutorial on making a graphql-node backend server built on Prisma2 and GraphQL. The tutorial doesn't explain why it writes some Resolver functions async and some not.
I thought that the async was added to functions that interacted with the database, but you can see this resolver gets data from the database but doesn't use async. But in this resolver it does use async.
Can somebody please explain why there is this seemingly arbitrary usage of async? When and why I should use it? Thanks in advance.
The first thing you should do is read up on Promises. Promises are a way in JavaScript to encapsulate computations that are still ongoing. This is usually the case when you talk to an external service like a database or the operating system. They have been replacing callback style APIs.
In GraphQL a resolver can either return a value or a Promise that resolves to a value. This means, you can freely choose returning a value or a Promise, but if you call a database function like Prisma, you will get a Promise back, so you are kind of forced to stay "in Promise land", as there is no way to turn a Promise into a value. You can only chain functions, that should be executed with the value "in the future" (with then).
The last concept to understand is async/await. These async syntax is an addition to JavaScript syntax, that makes working with Promises easier. With await, you can stop the execution of a function until a value in a Promise arrives. Now, this looks like you are turning a Promise back into a value, but in reality, you function implicitly returns a Promise. For the VM to know about this, you have to state, that a function might use async by adding the keyword await in front of the function.
So when do you use async for a resolver? You could do it all the time, and the code would be correct. But doing it, even when you don't need to (e.g. you are not talking to a service) might have some performance implications. So it's better to only do it, if you really want to use the await keyword somewhere. I hope this can get you started with the concepts above, there is really a lot to learn. Maybe just go with your intuition and TypeScript errors until you deeply understand what is going on.

React-Admin: How can we dispatch a store action from within the `authProvider` code?

In the async fetch of the AUTH_LOGIN we want to dispatch an action after we fetch data from additional endpoints (apart from the login endpoint, for example we call another endpoint to bring data for the account, etc.).
We have all in place (action, reducer, used the combineReducers, etc.), but we are not sure how we can "connect" the authClient function in the authClient.js file, as this is not a component in order to use the connect function.
How could we dispatch an action then?
As you can see in the authentication side effect, the data returned by your authClient will be set as the payload of the USER_LOGIN_SUCCESS action which will be dispatched automatically when the authClient resolve.
To apply any logic to the authentication payloa and eventually dispatch some custom actions, you'll have to create a custom saga which will react to USER_LOGIN_SUCCESS actions.
We should definitely add an example in the documentation

ReactJS - AJAX call in componentWillMount

React documentation suggest to fetch initial data in componentDidMount function. For my it is not intuitive because we could do it sooner in componentWillMount (first function from React component life cycle). In general I think we should start AJAX calls us soon us possible so user doesn't have to wait for them. So why do we have to wait until component is rendered?
My questions are:
Are there any problems with using AJAX in componentWillMount?
Are there any benefits of using AJAX in componentDidMount?
say you do AJAX on componentWillMount
componentWillMount(){
this.serverRequest = $.get(...);
}
Now you have a pending AJAX request. Its a good practice to cancel this request when the component is unmounted
componentWillUnmount: function() {
this.serverRequest.abort();
}
but lets say for whatever reason the component did not mount. you still have your pending ajax request which can not be cancelled anywhere (since component is not mounted, componentWillUnmount won't be reached) thus creating a memory leak.
If you had put the ajax request on componentDidMount you had a guarantee that the componentWillUnmount will fire since component is mounted allowing you to cleanup your request safely
Simply create the component when you have the data and pass it through props. Have the parent component (if you have one) to do the request.
It depends on your task. for example I have used an ajax request in componentWillReceiveProps here. what is your concern exactly? what does your ajax?

Resources