Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm trying to build an application which will be formed by several CRUD and several graphic tables (similar to excel and containing hundreds of rows) which will be editable by users.
I've already created a CRUD with react and redux, now I'm wondering if the tables should be implemented with redux as well or not.
Thinking about it a jsx row of a table is like an element of CRUD, in fact I need to be able to Create a new row, Read, Update and Delete it.
Is it correct to use redux (and so create all the logic needed, reducers actions ..)for editable tables? Is there a best practice or a standard approach for this case ?
You should take a look on Material Table. It has built-in feature for table editing.
About the connection Redux-Table, it totally up to you. If the data displayed in the table come from the store and you want to keep them there (to not call an api, if any, to get updated data) you should write all the redux stuff (reducer, actions...).
Hope it helps.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I'm currently developing a side-project and trying to learn some general API things.
The user can access a list of projects by going to /projects and I'll get
all of the projects as a list. The user can also click an Edit button that goes to
edit/{project_id} and was wondering whether I should pass the project object to the component or just do a separate request to the API with the ID of the project to only get that project.
The first one is good because it's easier and also, I won't have to send all information about the project objects because I can't show all of them in the table (in /project) and this will save some data (ex. the list will show name of project and created date only). However, the second way is good because there will be less requests to the server.
My question here is, what is the preferred way?
Sidenote: I've tried searching for a question like this but didn't know how to phrase it, so this might be a duplicate.
In this situation, I would advocate for the separate API request. With a list of projects, you really don't want to include everything in your "get all" API call; just enough basic stuff to populate the list. That will make your queries faster and data transfers smaller, which is especially helpful when a large number of projects come into play. However, when you "deep dive" into a single project, then you'll want everything about that single project.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
TechStack:
React Native
Redux
One of my screen in react native app has list of people registered in the application. It can have thousands of rows. I am planning to have a infinite scroll. What i am concerned is how to keep those rows.
Shall i use redux to keep the rows in the state or shall i store them in a simple variable that keeps on updating.
It depends on what kinda features your list has.
if your list is only for display, simply store your list inside useState.
if your list items have a very nested component structure until
using data to display,
redux can help you to prevent prop drilling.
if your data can change from many places and you are worried about losing tracking of data
redux can help you.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Why do NoSQL databases want the data to be as flat as possible? Especially in the case of firebase. Can anyone provide read or write calculations to show the differences in I/O between relatively flat databases and relatively deep, multi-level, databases?
I what comes to Firebase Realtime Database, it's much more than performance, it's about information retrieval strategy.
You are free to save the ids of every liker of a specific post nested in the post structure, but if you feel you don't need to retrieve all this information every time you get a post (let's suppose you query a list of posts only to show as a summary cards), then you won't want to have it nested, but flat under a "post_likes/{postId}" node for example.
Remember that in the Firebase Realtime Database you can't filter out the nodes you don't want to receive. At the moment you retrieve a node, you get it all the way deep down the structure.
Think about the same example now, but for comments. The same thing apply, so we could structure our comments under a "post_comments/{postId}" node and only retrieve it when we are willing to show the comments.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
In my app, some components use different categories of data(clothes, shoes etc.).
Is it better to fetch data from database once and put it to storage? Or i should let every single component fetch data directly from database?
You're looking for Redux (an implementation of flux). Redux gives you a global state to work with that you can connect components into. You can make an api call in one component, and if added to state (using actions + reducers), you can update data from a completely different component. They don't even need a parent/child relationship in your component hierarchy.
So yes, you're looking for "storage", in the form of a global state for your entire React app.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
When relations between tables are created it becomes very difficult to edit tables, drop and re-create them. well I decide to leave creating relations for when the job is done and that time its not easy either and later some tables might need modifying again.
what is the best practice for creating foreign keys, and all other relations?
In big projects that I devide project to several small projects, well sometime in one of the smaller projects I see that I have to make a small change to previous small projects. and this ruins everything.
I always create relations when I create my initial database structure, and because it is normally (sometimes... once was...) designed properly, the relations don't tend to change.
What you may find eases any changes to the tables is to change one of the options
In Tools-Options, choose Designers - Table and Database Designers and clear the checkbox marked Prevent saving changes that require table re-creation