Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design structure for submitting form data #41

Open
Venefilyn opened this issue Sep 6, 2018 · 0 comments
Open

Design structure for submitting form data #41

Venefilyn opened this issue Sep 6, 2018 · 0 comments
Labels
Back-end For working with Laravel Front-end Issues for Vue, bundler, linter, styling. help wanted
Milestone

Comments

@Venefilyn
Copy link
Member

We need a way to retrieve, format, and submit form data to the server, as well as handling server response to display success or errors.

In live v2 Botwinder we are sending the whole form to keep everything in sync, with the redesign we want to only send config values that have changed. This means keeping track of the original value and new value. Currently we utilize Config singleton which has a list of ConfigData instances. The ConfigData class has the fields id, value, original_value, and error_data for a ConfigErrors model. The config class apart from a list of ConfigData also has an array of ConfigErrors under errors.

When submitting we want to compare all values within Config whether the value and original_value has changed and submit this to the server. Server should be able to handle this and make sure all relevant data for nested ConfigData exist.

With dynamic lists of ConfigData where we create new data from user input I would suggest to create a NoValue class for original_value to be able to always include the data when submitting in case value is null or empty.

When receiving a 200 or a 204 code from server, display a notification saying config was saved and reset all original_value with the current value for all ConfigData in Config. That way if they change something else we will know exactly if it changed or not. This should include those for dynamic lists.

For lists of ConfigData, such as roles, channels, or public groups, we should include a deleted field in some manner to be able to determine whether it has been deleted. This can be a Deleted class which is extending ConfigData and added to the array of ConfigData instances for a specific data object.

When receiving config errors, this should be parsed together with #32, associated with Config errors field as well as each ConfigData that has an error, which should be added to error_data field.

@Venefilyn Venefilyn added Front-end Issues for Vue, bundler, linter, styling. Back-end For working with Laravel labels Sep 6, 2018
@Venefilyn Venefilyn added this to the Redesign v3.0 milestone Sep 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Back-end For working with Laravel Front-end Issues for Vue, bundler, linter, styling. help wanted
Projects
None yet
Development

No branches or pull requests

1 participant