From be5d06714809c63e26bfc94671c3430c82cb1c2f Mon Sep 17 00:00:00 2001 From: Jake McDermott Date: Tue, 7 Apr 2020 17:30:03 -0400 Subject: [PATCH] Add note to docs about async form behavior --- awx/ui_next/CONTRIBUTING.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/awx/ui_next/CONTRIBUTING.md b/awx/ui_next/CONTRIBUTING.md index 9c8cc5bb60..b798168584 100644 --- a/awx/ui_next/CONTRIBUTING.md +++ b/awx/ui_next/CONTRIBUTING.md @@ -14,6 +14,7 @@ Have questions about this document or anything not covered here? Feel free to re * [Accessing the AWX web interface](#accessing-the-awx-web-interface) * [AWX REST API Interaction](#awx-rest-api-interaction) * [Handling API Errors](#handling-api-errors) +* [Forms](#forms) * [Working with React](#working-with-react) * [App structure](#app-structure) * [Naming files](#naming-files) @@ -124,6 +125,9 @@ API requests can and will fail occasionally so they should include explicit erro - **other errors** - Most errors will fall into the first two categories, but for miscellaneous actions like toggling notifications, deleting a list item, etc. we display an alert modal to notify the user that their requested action couldn't be performed. +## Forms +Our forms should have a known, consistent, and fully-resolved starting state before it is possible for a user, keyboard-mouse, screen reader, or automated test to interact with them. If multiple network calls are needed to populate a form, resolve them all before displaying the form or showing a content error. When multiple requests are needed to create or update the resources represented by a form, resolve them all before transitioning the ui to a success or failure state. + ## Working with React ### App structure