Hi all. I feel like the solution to this is something simple but I cannot seem to figure it out.
I have an app where the user can create a new project but am struggling with making temporary data.
I want it to be able to display a list that will only show up here and then add it to the parent data later on however I am not sure how to make the list exclusive to this page since if I constrain it by created user, when then they make a new entry, they will see all of the former entries they made for other projects.
Hi there, @TayzCLSBubble… if I understand your video correctly, what you are describing, in my experience, is actually not all that simple. If I have it right, you are trying to create a list of roles, and you want to associate the roles in the list with a thing (job) that hasn’t been created yet. Because a role is “complicated” in that it has multiple fields that need to be filled out, you can’t really use custom states to temporarily create the roles, so you are creating them in a custom data type despite the fact that their parent job doesn’t exist yet.
So, do I have all of that correct? If so, I would likely go down the custom data type path, too, and I would deal with the situation where roles were created for a job that a user decided not to submit by “cleaning up” the roles in real time. Exactly how I would clean up (delete) the roles in real time would be dependent upon the details of the app, but again, that is probably the way I would go.
Do I have it right that everything else for the job is saved in custom states, and if the user decides not to submit the job, they would just leave the page and everything would be lost? If that is the case, maybe you need a way that is more explicit when it comes to canceling a job submission, and then you could tie the deletion of the roles to the explicit cancel action.
Anyway, I don’t know if any of that makes sense, but I hope it’s helpful even if it’s just food for thought.
Best…
Mike
Thank you very much for responding.
You are pretty much on the dot. I wanted to display the data so that the user could overview the roles for the project before finalising the process by pressing the “submit” button. I considered creating the project as they start the process but worried about bloat and possible issues when it comes to bringing this data to other users to see.
Everything is saved in a custom state, data is set in a way that if the process is not finished then the data will not be saved.
If i understand correctly, your suggestion is to create the project once the user starts the process and then if it is not completed (could add a yes/no data type that allows me to see finished vs unfinished) then delete the project and “clean up” that way?
I might give that a try but will I need to run that through the backend since its a automated function?
1 Like
That wasn’t necessarily my suggestion, but I like it. 
Creating the project at the beginning would simplify things, and I like the idea of having the yes/no field to make it explicit that the creation of the project has been completed (or not). And yes, I would do any sort of clean up on the backend, and that process could be automated (run at a certain time every day or multiple times a day) or manual (press a button to kick it off), depending on your needs.
One alternative that you could use, which I’ve used to good effect, is to have duplicate data type(s) and write directly to them as you take the user through the input process (rather than writing to custom states). I would add a tilde ~ to the beginning of the type name(s) to identify them as temporary data types and also pushes them to the bottom of the list of data types for selections. Have a Yes/No field for “Saved” as an example, with No as the Default value and when the user selects to finally save, change that field to Yes. Then have backend DB triggers which recognise that the Saved field has changed to Yes and you can then have a backend workflow to translate the temporary data to the live data types and delete the records from the temporary type once completed. This way you don’t have worry about temporary data polluting your main, live data types. Also the side benefit is that you have a draft of entries being made which can optionally be retrieved for the user later.
Hope that gives you food for thought as an alternative method to store temporary data.
oh haha misunderstood you but got a potential solution anyway. I’ll see if I can incorporate that now and let you know if I still need help.
For Curiosity sake though would you be able to go a little bit more in detail about your solution? Might help for next time in case this is not an option for whatever reason
ahh this is not a bad idea especially with your naming convention and the potential to bring it back. Might use something like this next time. Really helpful thank you
I stopped short in my initial response of suggesting that you create the project at the beginning because I figured you didn’t want to do that for one reason or another. Without having a project with which the roles can be associated, you could still do a similar clean up on the roles by looking for and deleting roles that aren’t in the list of roles on any projects. Better yet (and almost certainly more performant), you could add a project field to the Role data type and then just look for roles where that field is empty. No shortage of ways to go here, of course, and it really just comes down to what works best for your app.
Yeah i was a bit averse to it but was open to trying it. It seems to work just fine so far so really wanted to thank you and @gazinhio Saved me a lot of time from having to figure this out solo. 
2 Likes
This topic was automatically closed after 70 days. New replies are no longer allowed.