I created an App for projects and To Do lists. It consists of one HTML page, which only has an "add To Do list"-button.
The user can click on that button and create a To Do list, in this list he can create tasks.
The lists and tasks are dynamically generated HTML Elements.
Is there a way to just store everything, the dynamically generated DOM and all its elements and their functions? I searched for an answer for hours and all I found was a method to store data locally with localStorage: http://docs.phonegap.com/en/1.2.0/phonegap_storage_storage.md.html#localStorage
Since my elements contain a lot of js functions, it would be very complicated to store everything with this method...
Is there no way of storing "the whole thing"?
Thanks in advance!
Your question require a very large explanation, anyway I would tell you some tips you can use to step forward since I worked on a similar app last year.
Think about a database structure for your app. I got a table "Tasks" in which I stored both tasks and subtasks (task inside other tasks). I also stored alarms (if a task need an alarm), texts, checked/unchecked, archived flag, deleted flag, and so on. Everything you can associate to a task, you need a column for it.
Think about your data amount globally. If you plan to store a large amount of data (more or less 5MB) you better choose SQLite approach. If you think your data will not reach this edge, think about LocalStorage. You can google both to manage their use.
When the user fill the DOM to create a task and click on "create" (or something similar), you have to "scan" the DOM, acquire all info for the task created and put them into your DB
When the user want to update/modify a task, you have to find it in the DB, fetch related data, create the DOM's structures you need to show data, fill the structures with data
These are more or less few tips I can give you on your long way. Good luck
Related
I'm working on a vue app that uses vuex and gets objects from an api. The tables have paging and fetch batches of objects from the api, sometimes including related entities as nested objects. The UI allows some editing via inputs in a table, and adds via modals.
When the user wants to save all changes, I have a problem: how do I know what to patch via the api?
Idea 1: capture every change on every input and mark the object being edited as dirty
Idea 2: make a deep copy of the data after the fetch, and do a deep comparison to find out what's dirty
Idea 3: this is my question: please tell me that idea 3 exists and it's better than 1 or 2!
If the answer isn't idea 3, I'm really hoping it's not idea 1. There are so many inputs to attach change handlers to, and if the user edits something, then re-edits back to its original value, I'll have marked something dirty that really isn't.
The deep copy / deep compare at least isolates the problem to two places in code, but my sense is that there must be a better way. If this is the answer (also hoping not), do I build the deep copy / deep compare myself, or is there a package for it?
It looks like you have the final state on the UI and want to persist it on the server. Instead of sending over the delta - I would just send over the full final state and overwrite whatever there was on server side
So if you have user settings - instead of sending what settings were toggled - just send over the "this is what the new set of settings is"
Heavy stuff needs to be done on the server rather than the client most of the time. So I'll follow the answer given by Asad. You're not supposed to make huge objects diffs, it's 2022 so we need to think about performance.
Of course, it also depends of your app, what this is all about. Maybe your API guy is opposed to it for a specific reason (not only related to performance). Setup a meeting with your team/PO and check what is feasible.
You can always make something on your side too, looping on all inputs should be feasible without manually doing that yourself.
TLDR: this needs to be a discussion in your company with your very specific constrains/limitations. All "reasonable solutions" are already listed and you will probably not be able to go further because those kind of "opinion based" questions are not allowed anyway on SO.
I am building a survey-like rails application. The survey has several particular sections (several views) and in each section there are multiple questions. The user will answer those question (free text) and at the bottom of every section view there should be one submit button that saves all entries.
The model for the user answers is:
user_answers(id:integer, user_answer:string, user_project_id:integer, question_id:integer).
The user_answers have a user_project_id to associate it with their created project and a question_id for a an answer. That way the answers later can be directly associated to the right user project and the corresponding question.
What is best practice to save multiple entries/form_for :user_answers with one submit button at the end of the page?
I read about the javascript method Submit two forms with one button, but I fear if the entries are not saved asynchronously it could lead to errors
Sidekiq could be used to do the jobs asynchronously in the background.
Are there maybe other easier ways to do it?
Thank you in advance!
I actually found out that both are not applicable and the answer to my question was server-side rendering with fields_for.
Before I explain fields_for I want to answer why my strategies from above are not relevant.
Submit two forms with one button works, but renders everything client-side. That means it worked on my local machine, but as soon as I deployed the app on heroku and tried it, the javascript would not save all the records because the browser would terminate the JS after the first (or the first few) submit() actions.
is just a service to outsource workload. That would not solve the problem of inconsistent database records.
So I needed to find a way to process the records server-side, and that is fields_for: https://apidock.com/rails/ActionView/Helpers/FormHelper/fields_for.
It allows you to save multiple nested objects by putting it into a "parent"-form_for.
Here is a good tutorial to get a look and feel: https://www.youtube.com/watch?v=PYYwjTlcoa4
In my case, I made a "shell" form_for as a container around the fields_for. The fields_for in my code were dynamically generated according to the number of questions in the database. By submitting the shell form_for, I was able to process all fields_for answers to my survey server-side with one click.
I'm creating an events app with react native. I just wanted some advice on which would be the better more performant and scalable way to structure my data model in firestore.
I have 2 collections Events and Users.
A user creates an event which goes into the Event collection, In my app users can then go onto the main page and view a list of events from the events collection.
I also want to have a second page in the app a "users profile" page where users can view a list of their own events, update and delete them.
My question is which would be better:
to store the event's key in an array in users/user1
store basically a duplicate event in a subcollection called events in users/user1
I feel that option 1, might be better just to store a reference to the doc in an array, So I don't have duplicates of the event and if the user has to update the event, only 1 write has to be made to the actual event in the events collections.
the event is likely to have more fields come onto it in the future, like a comments field etc, so I feel by just going with option 1 I dont have to keep doing double work, although I might have to read twice i.e read users/user1- > (then array) events:[event:{dockey}], then use that key to get the actual event doc in the events collection.
Thank you for any feedback and advice
There is no simple right or wrong answer when you need to choose between these two options. Data duplication is the key to faster reads, not just in Firebase Realtime Database or Cloud Firestore, but in general. Any time you add the same data to a different location, you're duplicating data in favor of faster read performance. Unfortunately in return, you have a more complex update and higher storage/memory usage. But you need to note that extra calls in the Firebase Realtime Database are not expensive, in Firestore are. How much duplication data versus extra database calls is optimal for you, depends on your needs and your willingness to let go of the "Single Point of Definition mindset", which can be also called very subjective.
After finishing a few Firebase projects, I find that my reading code gets drastically simpler if I duplicate data. But of course the writing code gets more complex at the same time. It's a trade-off between these two and your needs that determines the optimal solution for your app.
Please also take a look at my answer from this post where I have explained more about collections, maps and arrays in Firestore.
If I need to save a user’s data on which buttons they clicked while they visited our website, and without uploading a database would these be some of the ways? The problem is any array I have at that moment is reset everytime the user is redirected from the page.
Disclaimer: I’m new to PHP
PHP class. Create necessary push/pop features for an array and pass that class instance throughout the code. I tried this before but was having the issue of the array being reset no matter where I placed the code. Originally I had it on the header that is at the top of all pages but again this wasn’t the solution.
Localstorags through JavaScript. Haven’t used this yet as there has to be a better solution.
Upload to database Again, haven’t used this but there has to be a better solution as multiple MySQLi queries will surely be taxing.
Cheers!
Not sure why you don't want to use localStorage.setItem('clicks', JSON.stringify(array));
Depends on how big your array gets but should not be a problem for some clicks really.
I am trying to create a car make/model form using Javascript or AJAX, problem is that I don't have a lot of experience with either, but here it goes. . .
I need to create a form that has a car make and model drop down list in it, and when a user chooses a specific make, the model drop down will be populated with all of the models for that make, now I have a few ideas on how to accomplish that, but I would like some input on what the best way would be to approach this, to cut down on dev time.
I was thinking of creating an array within an array, one with the makes, and within each "make" array have the models array in there, so when the user clicks on a make, a AJAX/Javascript function will fire which will take the value of the current field and use that to get the location of the make in the array, which will then traverse through the inner models array and generate the drop down menu for that specific make.
Now I am not sure if this is a sound idea, or if there is a better way of doing it, but I have very little time to test, so process of elimination is out of the question, so could someone please point me in the general direction I need to go in, or maybe point me to a ready made script? as my understanding of Javascript syntax is little to none at the moment!
Thanx in advance!
The key decision is whether you want to load all of the information at the beginning (in which case the user may experience a delay while you load all of the models for the makes that they don't care about) or whether you want to retrieve the models as they choose a make. The answer will depend on
how much data there's likely to be
how fast you need the page to be
how much load will be on the server
etc.
Basically, can you afford the performance impact of loading all of the models at the beginning?
If you decide that you can afford to load everything at the beginning, I think the approach you describe is reasonable, although I wouldn't actually use an array for the outer container. I'd do this:
var models = {
Audi: ["Quattro","A4", ...],
BMW: ["M3", "M6", ...],
...
};
The thing stored in the "models" variable is actually a javascript object, although people do sometimes call it an "associative array".
Note that in this scenario you aren't really doing "AJAX", as you aren't retrieving data from the server on-the-fly.
The alternative scenario is that you set up a URL where you can query it with a model, and it will respond with a list of makes. Then you fire off the query when the user selects a model. That's AJAX.