How to make a step-by-step form with data entry in the database?

Question

JavaScript

There is a task to write a registration form with several steps. Just like on this site: https://babules.com.ua/ The

key points are that the data entered at each stage is recorded separately. If the client left after some stage, then the completed data was saved and can be used. And when a person returns, he gets to the stage where he left off.

Tell me where to look for a solution? Where to store form data? At me the variant arises - to write down in a DB. Am I thinking right?

Answer 1

There is a lot written about sessions and yes, this is the correct approach when the basic registration is not completed.
But if you already have a username and pass in the database, which you can use to log in. Or linking to a social network, then triggers in the database in the form of boolean values ​​will help. Let's say:
user is an entity with columns:
1. is_active - this is how you can do lazy deletion.
2. is_confirmed - confirmed the mail.
Etc. So, you can check the current state in the route and, depending on the scenario, let it go in one direction or another. For example, if is_confirmed == false → instead of LC send to the page with the button "send the key again".
I think you've seen this on services.

Answer 2

There are several options. I am not an expert (only an amateur), so I do not claim that at least one of them is really correct.
Option 1. Creating a session on the server side, saving the data from the form in the session itself.
Option 2. Creating a session, but saving the data in the database. We assign a unique ID to the user (as a rule, the AUTO_INCREMENT attribute in the database decides for us) and only this id is stored in the session. When the user opens the form again, we take his id from the session, look for it in the database, and if there are form fields already filled in by him, then we substitute these values ​​into the form.
Option 3. Without a server and a database. We save all the entered data using js in LocalStorage. When the client enters again, we simply look to see if the data entered by him is in the storage, and if so, we substitute it in the form. But if the form has fields with file uploads, then in this case, you will need to store them, for example, in base64.
In the first and third options, it is assumed that after filling in all the form fields, all data will still be written to the database.
UPD: it depends on the specific case. If, for example, at the first stage, the user enters his E-mail, and you will need it, for example, for mailings, regardless of whether he filled out the form completely or not, then the second option is better. If you do not need the user's data until he fills in all the fields, then the third option will be easier and better. Well, the first option in this case is also suitable.

Answer 3

You can write to localStorage. When the client decides to proceed with the registration, we simply substitute the values ​​from the store. Thus, we reduce traffic and do not store data in the database, which may never be required.

Answer 4

Through session it can be implemented. Please correct me if I'm wrong on this one. You can implement the session through php.

Answer 5

Based on your description of the problem, I can advise several options:
1. DB. The option is good, BUT what to do with "broken", unfinished accounts. They will simply litter the database, because already at the first stage of registration you will have to create a user.
2. Session. The option is bad, if only because it is a thing that is short-lived. Usually, a session lasts a couple of hours at most (depending on the application settings).
3. Cookies. The variant is better than the session, because you can set the lifetime yourself and they are stored on the client side.
4.local storage. A variant comparable to cookies. It does not have a lifetime, so it is durable and also stored on the client side.
The last two options are very good for your purposes, but not very safe, it's up to you which one to use anyway. There may be other ways, but that's all I came up with on the fly.