-
Notifications
You must be signed in to change notification settings - Fork 2
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
doc(adr): Add non-javascript support adr #1720
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice, just some minor comments!
However, we are now encountering situations where specific features, like the upcoming upload component or the auto-suggest input, require JavaScript to work intuitively. | ||
|
||
Our approach needs to address the balance between rich interactive features (requiring JavaScript) and the core usability for all users. | ||
The GOV.UK Service Manual provides guides on how to best approach this in the governmental area (see [here](https://www.gov.uk/service-manual/technology/designing-for-different-browsers-and-devices) and [here](https://www.gov.uk/service-manual/technology/using-progressive-enhancement)). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this probably shouldn't be included in the context but rather in the decision, including a tiny summary of what they propose (or how it agrees / disagrees with our decision)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved it do decision. But I'm just gonna leave it as resources you can read upon further if you'd like to.
- Improved accessibility for users with disabilities, limited bandwidth, or JavaScript disabled/unavailable. | ||
- Increased resilience to network issues and JavaScript errors. | ||
- Simplified testing of core functionality. | ||
- Alignment with best practices for web development. | ||
|
||
- **Negative:** | ||
|
||
- Increased development effort for implementing features in both a non-JS and JS version (though this is mitigated by focusing on core functionality first). | ||
- Potential limitations on the complexity of interactive features in non-JS mode. | ||
- Requires a consistent and disciplined approach to development and testing to ensure adherence to the progressive enhancement strategy. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Somehow the pro/con framing at the end feels out of place, but I don't know exactly why. Maybe because these aren't concrete consequences
but rather feel like part of the discussion / context.
Since the pros are already mentioned there - maybe move the negative points up as known challenges
and just remove the whole section here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have to say, I like the conciseness of the pro and con arguments here. If someone agrees with you, I'm happy to do what you suggested though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🌟 one question out of curiosity!
|
||
1. **Core Functionality First:** All essential features must be fully functional and accessible without JavaScript. This ensures that every user, regardless of their JavaScript capabilities, can accomplish the primary tasks the application is designed for. | ||
|
||
2. **Enhancement with JavaScript:** JavaScript will be used to _enhance_ the user experience where appropriate. This allows us to add interactive elements, richer interfaces, and improved performance for users with JavaScript enabled. Examples include the auto-suggest input, dynamic form validation, and advanced UI components. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
without JavaScript, what happens when the user enters invalid data? for example, if they enter an option not included in an auto-suggest? or enters an invalid number? is that data saved?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already run the same (or stricter, see post code) validation on the backend before saving (otherwise this would also be a huge security issue).
This also helps with the no-JS case, as rvf consumes the schema violations returned by zod + previously sent data and rebuilds the form. It works so magically that we don't have to think about it..
So: Data is always submitted via POST request on hitting the SUBMIT
button, the server does the schema validation and redirects to a another page. On invalid data without JS, the same page is returned, this time with errors attached to the offending form fields.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
In fact, this ADR only puts in writing what we are already doing for the most part. This is supposed to serve as a reference for future implementations.
If you think anything is not in line with how we're currently developing and/or with what you had in mind how we will be developing in the future, please leave a comment 🙏