After reviewing the new designs and studying a bit ActionCable and Turbo/Hotwire my preference would be to go a step further than a simple javascript polling and integrate a solution with ActionCable.

The main reason is because the implementation will be a bit more complex that just rendering polls and questions inside the meeting page, but also having an admin UI (see video for more details)

In that regard, ActionCable using the Postgres async driver seems a solution that will work out-of-the-box for existing Decidim installations.

IMHO Turbo should be discarded because the elements are totally coupled, so you can't use TurboStreams without using TurboDrive (the old Turbolinks) and that will cause some issues with the existing javascripts.

After reviewing Turbo code implementation of TurboStreams the behaviour can be easily replicated, at least for a first iteration with plain Ruby and Javascript, and in that sense ActionCable gives you enough tools and abstractions to integrate the current requirements. In the future the code could be migrated to Turbo without much effort.

The implementation plan of the basic stream (a question is broadcasted to a meeting is quite simple). This is a list of high level steps:

activate gem
create cable.yml
create base connection class with user session authentication
create channel for meeting (in Ruby, emits a poll associated to a meeting)
create consumers (JS)
broadcast from the meeting/decidim-form service to the channels
- load user specific content, identified by the user_id in the channel and the meeting ID (and the questionnaire id if we allow more than one questionnaire per meeting)
- use ERB and ajax to stream templates to the view? (it seems affordable picking some of the code from TurboStreams)

Uh oh!

Polls in meetings: Research tech #7895

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions