We Keep Coding

Should/Can I organize data in React? [closed]

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 2 years ago.
Improve this question
Should I organize data in my React app or have it organized before react accesses the data?
I currently have an app that gets data from an API, in this case a list. I want to iterate this list and count how many items there are in each value range. The final goal is to create a histogram. Should this data already be in the proper format before being saved to the api?
const Histogram = (props) => {
const data = props.data
const max = Math.max(...data)
const min = Math.min(...data)
for (var i; i<data.length; i++){
var value = data[i]
//logic to count how many in each value section
const chunk1 = numberInChunk1
const chunk2 = numberInChunk2
//create histogram
}
}

Question is too broad but if you are asking about the application architecture than you should just follow a simple rules of the data separation and abstraction.
You API should be frontend independent and abstract as much as it's possible. Sometimes it's hard to achieve such separation because of the business needs, performance, legacy code and etc. But if you are implementing new application, than try to think what can be reused and what is strictly UI responsibility? If it's a heavy computation, than probably it's an API responsibility.
But also ask yourself a question whether you can
reuse this data in another application if it will prepared on a server side?
What if stakeholders will ask you to change react component and display this data in another format, can this lead to another change on server side?
If answer is yes, than your API is not abstract enough to handle various usecases.

In single page application how to reload api without reloading page when new data is entered in VueJs [closed]

Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 3 years ago.
Improve this question
I actually have made a single page application for school management where there are multiple records of the student and when data is entered , data are changed in database but doesn't affect other component until I reload the page.
I have used API to fetch the data from database.How to solve this problem in VueJs.

Suppoue you have the students data on dataStudent:[] now you entered a new data on same table where from dataStudent:[] came, when you enter data to database subbpouse you have data on formValue:{} which is object and all the data from formValue added on database now after successfully added you have to push these data to the array,
like: dataStudent.push(formValue);

Generate fake data that don't change [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I'm creating a temporary GraphQL backend, that should serve mocked data.
E.g. I need ~500 objects of the model Person (with firstName, lastName, email, country, etc), where the properties shouldn't change on each request.
Is there any library where it's possible to get fake data always created in the same order?

You can easily create your custom JSON with https://next.json-generator.com/ which allows using internal scripts for data generation
Here is an example of generating a list of names: https://next.json-generator.com/Vk95XL5mv

Not sure if this is exactly what you want, but I discovered this site: https://crudpi.io/ this weekend, you can mock some data in a JSON file and use it for your API. I guess that it's limited to 100 objects or something, but if you need the same data, you can copy it 5 times I guess. Hope it helps!
I wish that I could write this as a comment but I don't have enough reputation yet.

Here's an API. https://uinames.com/api/?amount=500
You should easily just create a script, add the data you got from this to a temp-database.

You can use a generator like https://randomuser.me/
Make a loop to create your object then keep the result in a file to ensure the data will be the same.
You can get an exemple here : https://gist.github.com/Yexan/cb8b79390e01272a4912fb4d6773ee1a
I used https://randomuser.me/api/?results=500

Creating a room with Firebase for a web app [closed]

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
Im currently building a web app based in firebase and want users the ability to create and join game rooms. Currently i am having an issue trying to figure out how to create the room where others can join. I was wondering if anyone can help me get started on this issue. Just an FYI each user who will be creating and joining the room will have their own account with unique ID if that matters

Firebase doesn't have any concept of rooms. There are parent and child nodes which are code wise handled through key: value pairs, very similar to a Dictionary.
There are also no users in Firebase either, other than the user id's (uid) and associated data that are created when new user is created in Firebase and stored internally on the server. That data is used for authentication. If other data needs to be stored about a user, a name perhaps, it's done within the database itself.
Keeping it simple, let's say we want to store information about users and rooms.
users
uid_0
name: "Bill"
uid_1
name: "Ted"
uid_27
name: "The Doctor"
The uid's are the ones that are created when a new user creates an account in Firebase. Your app will collect the uid that Firebase provides and write it and any other user data to the users node; in this case the users name.
Then the rooms
rooms
room_0
room_name: "Phone Booth"
description: "Time travelling in style; Excellent!"
uid_0: true
uid_1: true
room_1
room_name: "Tardis"
description: "It's bigger on the inside"
uid_27: true
In this case room_0, the Phone Booth, has both Bill and Ted in it and room_1 has The Doctor in it.
This is not the only way to structure the data and your structure may vary from this a lot, but it's a place to start.
Note: key names should almost always be created with push(). I used room_0 etc as a placeholder. Best practice is to disassociate main parent key names from the data it contains. i.e. don't hard code key names with something like an email address - that's bad news.

Of these three methods, which is the best one to implement a voting system? [closed]

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 4 years ago.
Improve this question
I'm implementing a small voting system on my website. I came up with three implementation methods that I would like your feedback on.
I want to give my users the ability to cast several types of votes on some user generated content. It's micro Q&A about games, not unlike SO's and their vote system, on a much smaller and specialized scale.
After toying with the following methods I can't decide which is best.
Method 1: Uses URL params and forms
Method 2: Uses URL params and jQuery
Method 3: Uses ether one of the above, but retrieves its info from the database
The schema assumes both Q's and A's are a post object with a different postTypeId, and the following two tables:
voteTypes(id, voteTypeId, voteName)
votes(id, postId, parentId, userId, ownerUserId, voteTypeId)
parentId represents the id of the
parent post. If the post being voted
on is an answer post, it is used to
ensure a question post (postTypeId=1)
can have only one accepted answer.
ownerUserId represents the userId of
the post's (being vote on) owner. It
is compared against the userId, which
comes from the session, to ensure a
user can't vote on his or her own
posts.
userId comes from the session and represents the person casting the
vote.
Method 1 Create a vote form in the view as the query loops over each post. Use hidden fields to capture the data:
<input type="hidden" value="#voteTypeId" etc...
The postId, parentId, and ownerUserId will come from the query being output to the view. The userId will come from the session.
Disadvantages:
1. Users can manipulate data. A user can accept an answer to a question he did not ask since ownerUserId is set at the view level.
2. Cumbersome: I would have to create as many forms as there are posts in the view. Each post will have 4 forms. A page with 10 posts can have 40 forms.
Advantages:
1. It's simple.
Method 2 Use anchors with custom data tags and jQuery to construct the vote URL.
<a data-vote-type-id="#voteTypeId" data-post-id="#postId" etc...
The ownerUserId, postId, parentId, voteTypeId will come from the URL. The userId from the session.
Advantages
1. Light weight and no forms. One jQuery call to submit any vote, as such:
var data = 'voteTypeId='$(this).data("vote-type-id") etc. Submitted over ajax!
Disadvantages:
1. JS disabled = no vote.
2. Data can be manipulated since it's being sent through the URL.
Method 3 Submit only the voteTypeId and the postId over URL, using either methods 1 or 2. Use the postId to query the db and verify the post object being voted on exists. This way I can also verify the ownerUserId and parentId of the post.
If the post is an object, create a newVote object.
The userId will come from the session. The postId and voteTypeId will come from the URL.
The parentId and ownerUserId will come from the post object I queried for.
Advantages:
1. Data shielded from user manipulation as the presence of the post can be verified, and so can be it's ownerUserId and parentId.
Disadvantages:
1. Laborious. Asking the database to find the post and retrieve details already available at the view level seems unnecessary.
2. The data is denormalized in some instances, so after a successful vote (an up vote, for example) I have to increment the posts table via object callbacks (add +1 to the existing number of up votes, for example), which is yet another call to the database with information that was already available at the view, and then the controller levels.
Other things I have not considered:
1. Finding if a vote already exists and toggling it, which will require yet another query. 2. Validation combinations are a nightmare.
I'm looking for feedback or additional ideas. So please share!
Many thanks!

I'd go with Method 2, but with some changes.
Server side
Hooks for casting a vote, changing a vote etc. those return simply true or false depending on the success.
Input PostID, VoteTypeID, UserID etc. you can't leave this out, if this is your bottleneck rethink the database model (if you can't fit it into a relational DB use noSQL stuff).
If you leave validation out, I'm gonna personally down rank your site into oblivion, do server side validation.
ALWAYS.
Client side
The Client gets the information from the view, then it can issue the specific calls to the server, we assume a non-malicious user here, if that's not the case he will simply fail at the back end.
As soon as someone casts/toggles we do the following things:
Check whether this action is possible by using the data available in the view
Update the UI to reflect the change
Send the request to the server
If that request returns false we undo the action and give an error message
Benefits of this approach:
Security, I can't do impossible things just by sending some http requests
Users get a fast response and a decent feedback on errors
Since errors are unlikely to occur for non-malicious users we don't need endless amounts of checks here
Malicious users, well there fault if the UI fails, we don't care out backend is secure.