I have a three step form to add a story in database
When user fills the step one form, all the step one data will be added to the story table and the user will be redirected to step two. I have written three views for step one, two, three.
My question is how should i manage step two view and step three view? How should i update the story in step two and step three? Should i send id back to front end and store it in redux? And then send that id to the backend for step two and step three?
Also how should i reuse this form in react for update?
I can provide more details if want
I believe there is no "fits all" solution, but in general your thoughts are correct. If there is data that backend knows and your frontend doesn't, you send it back as a response. So this would be like this:
Send form to backend
Backend responses with either "OK" plus the data frontend needs to know about, or with errors if something went wrong
Proceed to next step and to 1 until finished
You can also just store all the data from all three steps on frontend and then send it in one piece - in this case you don't end up with partially filled data in DB, but then you will have to think about navigation to errored fields/steps if something will go wrong and it will complicate things.
As to components reuse I have opinion: if you can keep component maintainable and replaceable - reuse it.
Edit: If you are using react you might not need to redirect user via backend, but only switch step via react (either with client-side router or with plain "step" value in state), depending on your needs.
Related
I am new to react and developing the react application, where I want that user can save his/her selected values on the frontend and later on can also see those values via clicking a button and user can see what values have been selected previously. now the question is how to provide this functionality, I have studied that either it could be done by local-storage or by the data binding concept in react, but I have no clue which one is best to implement in my scenario.
Let me explain to you with the help of a diagram.
(The first Image with Indicator Generation)This is the main page of my React Application, under the section of "Question & Indicator" there is a thing called Associated Indicator, these are the values which user have select itself on the Frontend side.
(The second image with detailed user-controls) This is the page where all the user-controls are defined, here user can select the values and at the end when user clicked "Associate" it will be associated and the values have been shown under the section of Associated Indicators, from that user when clicking any of the associated indicators it will show all the values selected by user on front end.
Cheers.
Preserving data in a web app is not related to React -or any other front end technology specifically.
Data binding is a concept on how to update your views when certain data changes, and it is not related at all to how data should be saved. But related to how modern front end technologies like react and angular render your components.
You can save data in a web app using different methods, each one is suitable for certain use cases - and so you should use the one that suits you.
For example you can use any of the following:
Cookies: old way of saving data on the front end, can stay infinitely but can also be deleted if the user decided to delete them or clear data from his browser. Cookies Get send to the server-side with each request done with the browser, has limitations with size.
IndexedDB: This one is literally like a database inside the browser, really fast when querying data, also has bigger Size limitations than both Cookies, and LocalStorage. However, this is a really low level API. Won't recommend to use it, unless you really need its features. Can also stay infinitely, and can also be deleted by user.
LocalStorage: New browser API to persist data, much more easier to handle than Cookies And IndexedDB, Can stay infinitely, but can also be deleted by the user. Has bigger size limits than Cookies, but less than IndexedDb.
SessionStorage: Data saved for each tab, and data cleared when page session ends.
Finally If You want data that persist for forever and the user can't delete it, you have to do your own solution in the backend.
I have a form that is four pages. The user clicks next and this leads them to the next page of the form. On the fourth page the form is complete.
What is the best practice?
Do I do a POST after each page, so 4 different times, or should I do one big POST on the last and final page pushing all the user data to the database?
Each page posts to a different endpoint.
My form is created using redux-form and react.
Either works, the main advantages I see are:
Sending one complete form - advantages:
No database pollution
Less network overhead
Sending 4 partial forms - advantages:
You can see where each user stopped - this may be useful data if they
are purchasing a service or signing up for an account. Do a lot of
people fill out the first two sections only to see the third and
navigate away?
You can use this to save the form server-side for people to complete
later. You can also do this with Redux / Local Storage for session /
browser storage, but you may want the functionality of a user
starting a form on one device and completing it on another, requiring
server-side storage of the form.
If you don't plan to implement the functionality of server-side storage, and if you don't need the extra analytic data of where they stop on the form - just go right ahead and send it all at once. I would suggest at a minimum, you try to save the form to Local Storage to make it easy for the user to pick up where they left off.
I want to say it depends on your database model and the data you are fetching from the form. It may be that the data retrieved from the first form is enough to do a desired database modification; in that case, it may be nicer to immediately send the POST data. However, if that data may be needed in a future query, it might be better to send it all at the end to avoid re-sending old data. Some may also argue that doing multiple posts is worse in terms of network usage
Note: most importantly try to avoid sending duplicate data
I have a table having millions of records. I am using Sails js as my server side code , React js to render data in view and Mysql as my DBMS. So what is the best method to retrieve the data in faster manner.
Like the end user does not feel like getting a huge amount of data which affects UI as well.
Shall I bring only 50 records first and show the pagination in bottom using pagination logic and then using socket.io fetch the rest in background ?
Or any good way of handling it ?
This really depends on how you expect your user to go through the data.
You will probably want an API call for getting only the first page of data (likely in such a way that you can fetch any page: api/my-data/<pagesize>/<pagenumber>).
Then it depends on what you expect your user to do. Is he going to click through every page to see all the data? In that case, it seems ok to load all the others as well as you mentioned. This seems unlikely to me, however.
If you expect your user to only view a few pages, you could load the data for the next page in the background (api/my-data/<pagesize>/<currentpage+1>), and then load the next page every time the user navigates.
Then you probably still need to support jumping to a certain page number, where you will need to check if you have the data or not, and then show a loading state (or nothing) while the data is being fetched.
All this said I don't see why you would need socket.io instead of normal requests (you really only need socket.io if the server needs to be abled to make 'requests' to the client so to speak)
I had the idea to make a SPA application using angularJS and then just sending AJAX updates to the server when I need.
My initial idea would be make the client application fly, but if I have to do an AJAX round trip to the server, I think the time would be approximately the same as to request a single web page.
Requesting a page just has more bytes of data, is not like I'm requesting 20 resources like in this article: https://community.compuwareapm.com/community/display/PUB/Best+Practices+on+Network+Requests+and+Roundtrips
I would be requesting a page or resource per request.
So in the end even if I create my client side application as a SPA using angularJS, these requests (would have to be synchronous and show a please wait message while they don't return, as I don't want to user to take more actions before I make sure his request passes validation and is processed correctly) would take some time and make user wait, just about the same time as requesting a full page.
I think SPA pages would be very useful if I have like a wizard on my app with multiple pages/steps and at the end, submit the results of wizard, to the server, which I don't.
Also found this article:
https://help.optimizely.com/hc/en-us/articles/203326524-AngularJS-Backbone-js-and-other-Single-Page-Applications
One of the biggest advantages of Single Page Apps is that they reduce
data transfer. As a result, pages after the initial loading usually
can be displayed faster and seem more interactive.
But I don't believe this last quote is really true.
Am I right, or is there a way that I'm not seeing to build an application that would look like it's executing locally?
I know how guys will start saying "depends on what you want", but lets focus on this scenario where there's no wizards.
What ever you said is right. But most of the frameworks(Angular,BackBone) you take they are going to cache the templates of html on the browser so the rendering would be pretty fast compared to the normal applications. Traditional apps will have to fetch the html from the server for each request which is a time consuming one.
Hope this helps you!!!
If you are wanting to go through that syncronous server side validation step for each page request, then there is probably no big advantage to using AngularJS.
If you are requesting a page and then manipulating that page's contents once it's loaded you might want to consider AngularJS. A good example would be requesting a page that displays a list of items. Now let's say we want to search that list or order it in different ways. Rather than using AJAX to call the server to filter the list and then re-render it, it could be much faster to user AngularJS to filter and re-render the list without making any further requests to the server.
I'm looking to make a step by step form for an "instant quote" type of thing on my website. I made the following image on photoshop, it's pretty self-explanatory that I want the user to enter information at each step of the form and ultimately submit the form at step 3 (going to the next step should be seamless, without a page reload).
Can someone please give me some general pointers how I should go about this? This is my first project using backbone.js and it would really help to have a high level overview of whats the best way to approach this particular widget.
Thanks
I would structure it as follows:
1. Implement model for data to be collected
Have a single model which collects the data across the stages. Implement storage of this model, and allow partially-completed data. (You'll probably want to store this at each stage, so the user can come back at a later date).
2. Implement a generic 'multi-stage' view
This should be responsible for rendering the tabs/stages at the top, rendering navigation elements for backwards/forwards, and for rendering a sub-view.
3. Implement specific sub-views for each stage
These should operate on bits of the above model.
4. Implement routing
You might want different URL routes for each sub-view, or you might want the same URL for the whole multi-stage process. Either way, the router needs to create the outer multi-stage view and the inner sub-view (or views), and connect them together, together with the appropriate model.
5. Hint: make use of pub/sub
Don't couple your views tightly. Use some form of pub/sub to raise and listen to custom events. (For example: http://lostechies.com/derickbailey/2011/07/19/references-routing-and-the-event-aggregator-coordinating-views-in-backbone-js/)
To addition to stusmith, I just made an example of a backbone js multistep form. Feel free to have a look and copy it.
https://github.com/michaelkoper/backbone-multistep-form