Summer project: Update NZSL Share to use Hotwire stack (Stimulus/Turbo)

[joshmcarthur]

This pull request is not ready to merge, but just reflects my progress so far.

Motivation

NZSL Share predated the techniques that Hotwire has popularised, but tried to add it's own implementation of very similar operations - there's plenty of .js.erb responses in this codebase which perform DOM manipulations that Hotwire is perfectly capable of doing itself.

My hope is to reduce the amount of frontend code in this application that is replicating features offered by Hotwire, particularly Turbo. This should make the application easier to work on immediately and contribute to stabilising the test suite. In the longer term, using Hotwire provides a flexible framework to incorporate new features into the codebase, and improve existing functionality by taking advantage of the built-in support Turbo has in particular for streaming and broadcasts.

Progress

Since I've fitted in this work around the usual commitments this time of year, I haven't quite made the progress I hoped to, but I have a much better understanding of the work that is done, and what remains now. The main technical holdup I had was getting Foundation's dropdown JS to properly re-bind itself when a Turbo frame update occurred (either due to navigation, or in response to a stream action). I found that because Foundation keeps it's own state on the element about it's initialisation, it was genuinely quite hard to get Foundation to actually attempt to set up the dropdown again so that events were re-bound. I ended up implementing a Stimulus controller specifically for this behaviour, since Stimulus is much better at recognising when DOM updates have occurred.

I've replaced the 'main' features that were using Turbo-like JS code:

• Voting
• Folder management (add/remove sign to/from a folder)
• Comments

There's a few pieces left to go:

• create-sign-form.js- needs to be replaced by a Stimulus controller to implement "submit-on-event" functionality.
• edit-sign-form.js - attachment removal can be done with a Turbo response (remove the DOM element) - the other JS is specific to file upload, which I'm reluctant to change until we implement multiple file upload. The save-on-enter for the attachment description can probably be done by wrapping the element in a form, otherwise a Stimulus controller will be needed.
• file-upload.js - As I said above, I don't want to touch this until we have implemented multi-file upload. Most of this JS would stay anyway - it's basically subbing out different DOM content based on frontend events. It could be implemented by Stimulus, but I suspect a lot of it will go away anyway.
• header.js - Working around Foundation. Stimulus controller.
• hero-unit.js - Hiding and showing the navbar search bar. Stimulus controller.
• option-other.js - classic Stimulus controller.
• sign-comments.js- needs to be replaced with a couple of Stimulus controllers to hide and show elements based on a select input changing.
• toggle-truthy- Stimulus controller
• video-comment.js - basically the same code as edit-sign-form.js - parts can be replaced by Turbo, the rest is likely to change based on upload changign.
• video.js - Stimulus

And some .js.erb responses:

• signs/new..js.erb- I expect this could work just with a turbo frame wrapped around #sign-upload-errors
• signs/index.js.erb- this is the same sort of pagination implementation for comments, and just needs a turbo stream template.
• collaborations/new.js.erb, folders/new.js.erb, folders/edit.js.erb- slightly daunting since it's a Foundation modal, but can probably follow patterns from previous projects to connect a Stimulus controller to the DOM element being rendered to open the modal.
• sign_comments/video_metadata - pretty sure this just needs to be rewritten as a stream response from the form.

---

Worth noting that at this stage, I haven't really kept up with tests. I don't expect we'll need more tests, but by reducing the amount of work the custom JS is doing, I'm hoping to remove some of the custom wait stuff we have. I'm also expecting that some responses won't need to be run through chromedriver to work.

[joshmcarthur]

ca1b407, 71fd364 and ee7d480 all fix legit pain points. If we don't move forward with this overall change, we might consider backporting these.