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
successMessages vs errorMessages #37
Comments
Starting to get through backlog. This sudden announcement by MDG that they're ending the free So, yeah... this is sort of how I originally envisioned things would work. Only one variable is needed for login, and two variables creates opportunities for indeterminate states.... where things are succeeding and failing at the same time. With only a single variable, we just decide what the default state is... are people assumed to be logged in by default, in which case we check for errors; or are people assumed to be denied access by default, in which case we check for credentialed success. At this point, I would be prone to completing the refactor, switching to successMessages, and dropping errorMessages altogether if possible. We started down this path, so might as well finish it. |
Keeping only one variable is the best, checking more than one variable is painful. The confusing part for me is how we can store and check success/error messages in one variable. Because we need to show the errors to user if Sign In or Sign Up is failed. Besides that, we need a success message if a reset link mail is sent when the user forgot the password. I need your suggestion to achieve a mechanism like that? |
Ignore the reset link for now. That should be in a separate issue, and we'll get to it next. The benefit of having the errorMessage is that it can catch and display any error. The benefit of the successMessage is that we can check off the exact requirements for successful login. Lets just assume that the user is denied access by default (because HIPAA and other security stuff), and that successMessage keeps reverting back to Narrow down the errorMessage variable so that the only thing it does is display data to the UI, and isn't involved in the login flow. |
That makes sense. What about converging on the UI above? Should we replace the existed UI with the new? |
We have to think about that, and give some design consideration to it. The UI is currently pretty good, albeit plain. One thing to keep in mind is that buttons don't move around on mobile when error messages are displayed. Changing layout dynamically is bad. Otherwise, we'll just need to figure out someplace to put the extra GUI elements. |
I think so. It is clear now. Thanks! |
We were setting errorMessages even if input value is validated but I think errorMessages should include only errors. I created successMessages to store result of validation but we are not using successMessages except activeEntryTests.js. We might set errorMessages as false if validation is acceptable and check whether keys of errorMessages are false or not. What do you think?
The text was updated successfully, but these errors were encountered: