Mixing Flux with in-component requests - reactjs

I am building a react app with altjs as flux implementation. Currently I am making an image uploader component. The component takes an image, uploads it to the cloud and puts the url in the response in an input. The image url is sent within the form. It is also possible to skip the uploading process and type in the url manually.
The image upload process is as follows:
Component makes a request to the server, gets a signature.
The signature and the file is sent to the cloud storage and an url for the uploaded image is returned.
The url is set to the value of an input field.
I think this process will be easier if I make the requests in the component (in click handler function) without using flux. I do not need a flux store at all. I believe this is a better approach because this way I can put the component in any app and have it working. If I were to use flux, I would also need to transfer the action file and modify it a bit
It is generally said that every api request should go through flux as a good practice.
Is this a good practice or can I implement it in a better way using flux?

I think what you should do there is separate the concern of displaying the variables (image url), the button etc from the concern of the uploaded image and the signature you need as well.
Separated the components for having an image upload become very easy to handle and duplicate into almost any project, while the responsibility for uploading the image etc (which generally differs more per backing store / API ) is in a higher component. You can then choose per project if you choose to use flux for it or if you let the higher component execute with the data coming from the uploader and setting the props.
My suggestion would be to do the above with flux, but that's just because I feel really comfortable with the data flow in the whole application to be the same.

Related

React + SSR: Correct way to handle a component that needs to fetch data first

I currently have a React app that I'd like to use SSR with. All but one component is pretty much static content, making SSR super easy. Everything but the component is rendered just fine and well right now.
My question is how do I go about rendering this component that needs to first get data? Because it's a complex SVG that gets rendered my line of thinking is that having it "update" once data comes in is a bad move, and it would be better for it to just not exist in the absence of data (with an error message).
So here's my plan: I can add a prop to the component to pass in data from a parent rather than keep it as internal state only. So if data is passed, no fetch request in the component is necessary. From there what I can do is take the static bundle output of the app and, when the page is requested, the server will request the proper data just as the component would. Once the data is received, the server can grab the component from the bundle with regex, add the data as a prop, render the component, and stick it back in with the rest of the already rendered static content.
Is this the correct way to do this? It feels a bit complicated, but that might just be how it's done. I'm not sure.
Your intuitions are correct. In current React (17.0), it's quite cumbersome to do SSR with data-fetching inside components.
What needs to be achieved on a conceptual level is that all data dependencies need to be known upfront, ie. before calling ReactDOM's render. This way, one can access the data in a synchronous manner which allows to do one-pass render on a server.
I don't quite follow your idea to "grap the component from the bundle with regex". One way of solving the data dependency problem is to inject the data into React tree from the root component (ie. ReactDOM.renderToString(<App componentStaticData={data} />)) and make the data-dependent component aware of the fact that it can just grab the data from there instead of doing (asynchronous) call. It's important to note that useEffects are not executed on the server.
Another idea to grab all the data dependencies is to do two-pass render. First one is used as a way to collect all resources used, then we await their completion and inject them as static data into send pass.
Third way is to use one of the React frameworks that provide SSR out of the box. You can have a look at (among many others) Next.js or Gatsby. Depending on your setup, this might be easiest or the hardest way to achieve SSR.

React | working with remote data advise ( a conversation )

I've taken the program at Udacity for react and react native, and it taught me well id say.
Now that I am equipped with the skills and have a good knowledge of the environment and redux etc. Im trying to build my first test app that handles data living remotely.
In the React tutorials we would use local mock data, and try to fetch it and even simulating the delay with a setTimeout call. But the problem is the tutorials worked excellent only for the types of apps they were building. I'll get to this in a bit...
My app description:
At the moment i'm making a test app and so far I can : retrieve a collection of food items ( remote data), render the data, and press "LIKE" on anyone. After pressing Like that food item URL gets saved into another remote file under the authedUser's account under a "favorites" property.
The food data at the moment is in a json file hosted on a github repository.
and so is the users account data.
The thing I noticed in the react course was, Data would be received into the redux store.
from there anytime you dispatched an action which involved data changes like "Favoriting" something, the app would first dispatch an action to server. Once that resolves it would dispatch to the redux store and affect it there.
Now from what I understand... this is a way to keep the data in sync? Is this how other applications do it? or is it when data is changed, you only dispatch the change to the server, and request/fetch the new data into redux once the action resolves? The tutorials would receive the initial data, and like this it would be set and stone and then rely on the dispatches to keep it in sync. would it be better to simply use local state, fetch the data we want. vs using the store?
Im not exactly sure whats best, but to me the idea of receiving the entire data file into the app seems not scalable? like when you use instagram for example, your phone doesn't download the entire instagram database. Im thinking it downloads only your profile? and url's to your friends? etc?
so for this test app that I am trying to make ( described in italic font above ^ )
I'm not sure how to go about it. I definitely don't think its appropriate to receive the entire data file. I know that I want the user to receive food items onto the screen, but only a handful at a time, maybe through a search it modifies the results on screen. then the user can like a food item.
This is the first time i'm working on an application of this sort, and I do think i'm missing something.
It would be a good idea to not integrate Redux at first. Just build the application in plain React.
Now talking about your app. As you said, is a bad idea to download the entire database. When you have to fetch a lot of data a common pattern is to use pagination. It works like this: your app asks for 10 food items. The server returns those 10 and tells you that there is more data and you should make another request if you want to fetch more. It doesn't make sense to fetch 1000 products if the user can see only 10 at a time, right ?
Let's say you like a food item. After you press "like" it is not enough to update your app state, you also need to make the change on the server. How you do this ? Usually you have a food item id(let's say 123) and you maybe you make a POST to https://server.com/like/123. Now that request may fail for various reasons and the server will not register your like. This is way you update the local state only after you successfully updated in the database. In addition you may want to update the number of the likes(maybe other users liked that food item since you fetch) so the server will return the updated number of likes.
Where does Redux fit here ? In React every component has its own state. They can share data between them using props. But this doesn't scale and you will usually end up in a situation called Prop Drilling. Redux store is some kind of global state. For instance:
<FoodItems>
<FoodItem key=1/>
<FoodItem key=2/>
</FoodItems>
Let's say somehow you update the description for the first FoodItem. How do you tell that to other components ? In Redux you dispatch an action and modify the store. Now other components can connect to the store and get the value from there.

Is making heavy use of localstorage a good practice?

I'm currently making a REACT web app, and I've made heavy use of localStorage to keep track of data without having to make more api calls, i'll provide a quick explanation of what i'm doing and would like to know if it's a good practice or if there's a better way.
I am working on a blog app and need to have access to some data in other components (such as the username of the currently connected user.)
So each time I make an api call, and receive data that I know I will need in other components (especially if it's not a child component of the one receiving the data), I store it in the localstorage so I can access it easily.
Is making use of the local storage everytime I need it for convenience good ?
Do you have any guidelines regarding when to query data instead of relying on localStorage ?
Thanks for your answer.
Remember that localstorage is persistent data. So it should be used for data that is required when the user leaves your app and comes back to it again.
On the other hand, sharing data between components while your app is running should be done with other mechanisms, typically passing props from a parent component to child components. Also, you can use React context or Redux or similar APIs to store data that is required globally while your app is running.
I would say "it depends"
If you are not accessing data in localStorage way too often, data inside of it are not changing frequently. Then it is OK. (still you need to have fallback for any other storage, try safari in anonymous window there localStorage does not work, old mobiles have limits how much data can be stored etc. etc.)
Otherwise it would be better use other means of storing data locally. Like IndexedDB, WebSQL. You can use some lib for managing those like for indexDB dexie, idb or any other.
If you are using localStorage just to ease your work with react props drilling, then rather use React.context, flux, redux... or any other state managment lib.

Loading dynamic layout in react from a remote API response

How do I setup my react components in order to get the layout loaded from a remote rest based API? (I want the layout to be stored in a db so that it may be changed by the user whenever needed)
The API is a dot net core based API. It might be slightly difficult doing server side rendering. (Although that may be considered as well if there are no other options)
I essentially want to know if there is a way to send the jsx from the API. Is there then a way to return this jsx that I have received as the response from my component.

HTTP request outside of redux actions

I am working on react app + redux.
I have some HTTP requests that I don't think that should be in the state of my app. (for example : in case of autocomplete, I fetch only relevant data, I don't have to use this data anywhere but in the specific input).
Is it a bad practice to have folder of "statless services" inside an react-redux app?
Do I have to keep every request result in the state?
What about POST and PUT requests?
Thank you.
Speaking broadly is not bad to keep something out of the state if it's not relevant or shouldn't influence render or state.
Take for example a live graph that updates every second. You don't want it to trigger a re render every time it updates.
Or some external service for example Google Maps Auto Complete. It takes control of the dom, does external calls and so on but at the end of the day what you want for your app is the location when the user perform some action.
All the several state changes that it does on the map and on the info until the user decide that there is his location is not relevant and shouldn't be a part of your state.
This could be opinion based... It's a bad practice, that's transient state no one else is interested in.
I suggest you to use https://redux-saga.js.org/ to avoid pollute your logic with side effects and take care of this common transient states.

Resources