So I have a JSON tree for users data, but when a new user is created how do I make a copy of the default data for a new user to save their individual settings for?
Also related to this, if I wanted to add a new item to the data in the future, how would I do that and be able to update all existing users with the new line item from the update?
What I mean for example is, in the screenshot below if I wanted to add a new item called “Move” to go under “Build” how would I be able to do that so all the EXISTING users get that new item, but without disturbing any of their saved items from prior to the update.
I hope that isn’t too confusing, I couldn’t find anything similar to this question in the forums already
I deal with this situation all of the time. My strategy is to use 2 nested loops. The outer loop iterates through the default->task node(drive, clean, build). For each task, do a second nested loop through each user. If they have the outer loop task (e.g. drive) in their personal task object, do nothing. If they do not have the task, set the user task to the outer loop task.
You can use this solution to address both new users and new task.
Oh that’s great, do you have an example already in a thread for how to iterate? I don’t quite understand “how to iterate” through nodes.
I suppose once I knew how to do that I would next need to know how to check if they have the outer loop.
Edit: I believe this is a “for each item j” but what to do after that, and how to store it I’m lost
Do you do this upon initial sign in? Personally I would prefer to wait until the email was confirmed just to prevent spam and additional unwanted data. Am I correct in my thinking?
First and foremost when working with complex JSON trees, use a lot of debugging code and test at each step BEFORE going to the next step. Ask me why I do it this way…
Next create a for each loop for each PROPERTY in the MasterTaskObject. Notice that the value in defaultTask is the NAME of the child object, not the object itself.
I agree, you should not create a new username until there has been a successful SIGN IN. Again I would strongly recommend you use the Firebase UserID for the child nodes under username. You can then add a property for userHandle under the child. That will eliminate the problems with multiple jimbo’s using your app.
P.P.S.
Don’t try to re-create these blocks by hand. Open the remix project and save screen1 to MyScreens. Then open your project and add this screen to your existing project. Then copy the button1 Click event into any existing screen. You can then tweak the cloud path as necessary to work for your project.
This is great, thank you for this. The ‘when screen 1 starts’ components are just because this isn’t tied to an actual FB DB right? Those components I don’t actually need once it’s connected?
This needs to be inside my sign in screen right? Because then I can more easily put my Firebase ID for the child node?
I was referring to creating the object of the database keys. The loops will stay the same and you will need to put some default values for each new user the same way @drted suggested.
After the userID and / you need to have the key “task”.
Dear @overshield,
I advise you to follow the instructions of @drted. He clearly told you to remix the project and test it. One good start for testing is to create a new user in your database and then run the project to see if the default values will be automatically inserted in the database.
When this step is successful, then you can start modifying the code to get your changes inserted in the project.
Yes I have, sorry I should have explained that too. We’ve both tried for a while with several different techniques at this point. I have also tried adding a new user manually in the DB and then tried to update it’s properties but still no success.
Thanks anyway though, if you come up with anymore ideas please share.
Wait I have a question @drted
Are these exact components required for all of this to work?
Or can I replace this with my FBDB?
My final default DB has 151 objects, with 2 properties each.
These block create a sample tree in Firebase. You don’t NEED to use them, but the graphically illustrate the hierarchy. Since this tree has the root node of Overshield, you can just run this project and look at what it does in Firebase without messing with your existing project. Try adding and deleting nodes either in Thunkable or firebase and see how those changes affect the button click event.
correct, there aren’t any blocks to do that, but you can add them. You’ll need to play around with it. As a rule, to remove a node, set the cloud variable VALUE = NULL.
