I have a rather big form which I post to an API backend. The form has about 17-20 fields, depending on the status of a checkbox.
My plan is that after the user fills out the form I will validate it using Vuelidate and then display a summary of the data to give the user the possibility of reviewing their data. After the user reviews the data and considers that is correct, it posts the form to the backend API.
To do this, I plan on using Vuex to store the form object, and use the store to display the fields in the form and also on the summary page.
Is this a good approach, to store the form object in Vuex? If so, where I define the validation rules in store.js?
Thank you very much for your feedback!
You don't really need Vuex for this.
You can keep your form validation rules in your component itself. If you have something of a form builder or a different component that takes care of your form, you can keep your validation rules there or accept the entire form model through prop from the Component where you want to use the form.
Once the submission is done, you can pass the data to your Summary page via route itself. Check this out - https://router.vuejs.org/guide/essentials/passing-props.html
Whenever you think about Vuex or any state management solution think about the lifecycle of that data. How long is it needed to persist. In most cases, you'll find that it belongs to one view or two.
Vuex is good for cases where you need a piece of data to persist for way longer, possibly entire duration of the app. Example - User Details, Theme Settings, Experience Configuration etc.
Let me know how it goes.
Related
In the app I'm working on it's a fairly big codebase and components/pages are sometimes based on user roles. Admins will be able to see certain buttons or sections while regular users are not.
I need to modify a lot of the existing pages/components to accommodate a new role that's being added, which is view-only-admin.
This role will only be able to see everything including calendars, tasks, etc. but they are not allowed to make any sort of updates.
It would be a tremendous amount of work to go through the template of each component and file and look for v-if admin and also add a view-only-admin as well as make every single button or submit/click method behave differently for a view-only-admin role.
What would be the best way to handle this for the entire app? Re-writing and modifying v-if and submit methods seem like a bad use of time.
I've only been working with Vue/Nuxt for a few months, but I have read Mixins are pieces of code that you can reuse.
Would it be possible to write a mixin so that if the role is "view-only-admin" and there's an action that is a put/Post call, then they are not able to perform those API calls and presented with an error message?
I'm not sure how to go about properly implementing this feature. If I am able to stop all PUT/POST calls using a mixin, it would just redirect to a 404 right?
Thoughts?
If you are using axios for POST/PUT methods, then you should definitely check Interceptors.
But if you add only an interceptors without UI updates - your users may be confused why some buttons exist but doesn't work as expected.
I wanted to make add and edit operation for an entity suppose Post. There are same fields on both add/edit form. So I wanted to ask can I make the form as a separate component and use it in add.vue and edit.vue? Is it the best way to do that kind of thing in VueJS?
I am asking this because I had visited a lot of codes on the internet where the authors didn't follow that approach and they are making separate forms for add/edit.
Sure you can use same component for both operations.
You just need to handle data flow (call correct api / graphql mutation / form action)
if you have a form that most of its components are not the same use it in Form.vue and add.vue edit.vue create a base component if it`s reusable
make sure to control the data correctly/state.
You should use one component, as you dont want to duplicate code. It's crucial to pass the id of the entity. If the backend receives the entity without the ID then it know it's the add operation (perform an INSERT in a DB). If the ID is set then the backend knows it has to update.
How to refresh the interface after you add a strip of data to the backend database in Vue.js?
I mean, if I add a item data to the database. there are two case for refresh the interface.
refresh the list api to get the page data.
append the added item data to local list.
what is the best way to do this?
I think both the solutions are valid it depends on what kind of write operation we are planning to do. Given that you do all the validations on the front-end which leaves lesser chance for errors on the backend. I do the following based on the use case.
Add/Update the item locally and then based on the response from the server I remove it again in case of an error. This is an optimistic technique used by a lot of websites and worls really well for CRUD kind of operations.
Let's say that your new operating is going to creaate a new user in a 3rd party api. So doing an optimistic thing might not be the best. So what I do is make the request, show a toast/alert that the request is happening, and then use sockets or long polling to get the changes. When the request is finally done show the data. In the meanwhile you can insert a dummy item showing loading.
I am trying to make my first Vue.js CRUD application with Vuex, and I am running into a struggle with how to properly load state.
I have a route that lists all accounts /accounts and I am easily loading accounts state for all accounts in a list form.
My challenge/question, how can I effectively use state to view/update an individual record in another route? (ie. /accounts/1). If the user refreshes the browser on /accounts/1 I have no state. What is the best strategy to manage state for both a collection of things, and an individual record in that collection?
You can have a look on https://github.com/JiriChara/vuex-crud. It creates Restful Vuex modules with all actions: CRETE, READ, UPDATE, DELETE. The source code is pretty straightforward, so you can have a look how state is designed and modified.
If you want to retain state after a hard reload you might want to make sure state is saved in localstorage then make sure you are using getters to load the data appropriately via lifecycle hooks. Try vue-localstorage
I'm having a bit of a trouble understanding how to fit a particular design flow I have into a proper REST architecture. Let me explain the flow:
I'm creating technical support website where users can submit ProblemRequests. On the front page, the user selects all the categories he's having trouble with and clicks "get help," which then redirects him to the next page where he fills out some forms to submit his request. Here are the pages:
Page 1 - Select Problem Categories
Page 2 - Fill out Problem Request
Page 2 basically acts like the NEW action for a ProblemRequest. The thing is each ProblemRequest depends on multiple ProblemCategories, so a nested route isn't going to work here. The next thing that comes to mind is sending in all relevant ProblemCategories ids as an GET param for the NEW ProblemRequest action, but I would rather not expose the IDs in the URL.
A Multi-Part form sort of comes to mind, but that involves making ProblemRequests have state, where some would be complete and others incomplete. I don't want to deal with the implications, because in reality this is a one page submission, not a very long-winded process.
What would work ideally is to override the NEW action for the ProblemRequests controller to respond to POST operations, but I don't know if this is considered bad programming practice. Is this a cardinal sin? Is it okay for me to change the NEW action to respond to POST instead of GET?
Please advise,
Thanks in advance.
Keep it simple. Is there any reason for the round-trip to the server? I'd just make the two "pages" a single page and maintain the state of the selected categories client-side.
Use a multi-step form: http://railscasts.com/episodes/217-multistep-forms
You can save the IDs in the session, and the model won't get saved in the DB until you are finished filling out the info. Works great for simple 2 or 3 step forms.
For more complex wizards you could use a gem like https://github.com/schneems/wicked