Rework to support multiple front-end implementations

Created on 23 October 2023, over 1 year ago

Problem/Motivation

Due to the current architecure of this module which works alongside/in addition to sending vanilla HTML responses, it's fairly easy to bypass/disable the existing 8.x-1.x Ajax-powered code. We can use this to our advantage to rework the back-end logic to allow swapping front-end implementations via plug-ins. We can then move the existing Ajax implementation to an optional sub-module, and create a Hotwire Turbo sub-module; this will also potentially make it possible to support an htmx implementation down the road, for example, and others we haven't even thought of yet.

Steps to reproduce

👀

Proposed resolution

  1. Move the exisisting Ajax implementation to its own sub-module. No plug-ins just yet, just the JavaScript and Ajax commands.
  2. Start work on implementing Hotwire Turbo in a sub-module; see 📌 Hotwire Turbo minimum viable implementation Active and 🌱 META: Incorporate Symfony UX Turbo Into Module Active
  3. Once the Turbo implementation is starting to take shape and we get a clearer view of what back-end code should remain in the base module and what's implementation specific, start on the larger architecture changes outlined above.

Remaining tasks

Do stuff.

User interface changes

Probably none.

API changes

Stuff gets moved. JavaScript API lives in sub-module for now.

Data model changes

We don't currently store any data so none.

📌 Task
Status

Active

Version

2.0

Component

Code

Created by

🇨🇦Canada ambient.impact Toronto

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Production build 0.71.5 2024