Refactor notes to use Hotwire
Currently, the UI for map notes is built with a JS widget that accesses the API directly.
This is difficult to maintain, as it deviates from Rails conventions and requires a higher grade of JS skills in addition to the default Rails skills. It also creates issues where some app errors are not translated (see https://github.com/openstreetmap/openstreetmap-website/issues/6367) or errors coming from elsewhere in the infrastructure are rendered badly (see https://github.com/openstreetmap/openstreetmap-website/issues/6422).
This issue proposes that the notes UI is refactored to use conventional Rails code. This may or may not involve using Hotwire.
Ideally this would be done in several steps rather than a single big PR. On first approach, it looks like the code to add note comments (app/assets/javascripts/index/note.js) can be refactored separately from the code to create comments (app/assets/javascripts/index/new_note.js). Therefore these could be two separate PRs. Other PRs could be added to provide refactors along the way, if appropriate.
Potential conflicts
The following open PRs intend to make changes to the data model for notes. Therefore they might create conflicts with PRs derived from this issue:
- https://github.com/openstreetmap/openstreetmap-website/pull/5815
- https://github.com/openstreetmap/openstreetmap-website/pull/5904
Edits:
- Reduced the emphasis on Hotwire, as it may not be necessary.
The issue with errors from elsewhere in the infrastructure can be reproduced with this code: https://github.com/openstreetmap/openstreetmap-website/compare/master...pablobm:openstreetmap-website:debug-note-comment-502-error
This issue proposes that the notes UI is refactored to use Hotwire, which would address these issues.
I'm not even sure it needs to use hotwire, it might be possible to be just standard views.
@pablobm Can I pick up this Issue ??
Yes, you can! 🙂 We don't assign issues, so just pick any task you like and go for it. (See the contribution guidelines).
A couple of recommendations:
- Push to Git early and create a draft PR. This helps us seeing that there's activity, and we can use the PR to discuss progress, ask questions, etc.
- Before you start work, consider if it can be split into separate PRs. This makes it easier to deliver and review.
Good luck!