Forms: Untangle the blocks from the shortcodes

[talldan]

This is a summary of a previous discussion: p1739433998885779-slack-C086RGTJT1D

Problem

Currently the Jetpack plugin provides a set of form blocks and shortcodes. These arcitecture of the blocks and shortcodes are intertwined. Forms in jetpack were originally implemented as shortcodes. When the project came to implementing form blocks, the decision was to leverage the existing shortcode feature set, and so the blocks output shortcodes on the frontend of a user's site, which are then processed from shortcodes to html.

This architecture leads to some difficulties:

• Developing anything new for forms is more complicated and takes longer. Both blocks and shortcodes should be tested. More complexity/scope means more blind spots and opportunity for bugs.
• New block features must also work for shortcodes, so this constraint limits possibilities.
• Some block functionality requires that blocks output HTML and not shortcode syntax. For example, particular block styles expect to be able to add classnames to block html (using the HTML Tag Processor)

Proposal

The proposal is to incrementally stop development on the shortcodes in favour of only developing the blocks. The shortcodes enter a sort of maintenance mode, where they can still be used, and might receive bug fixes, but perhaps users are encouraged to switch to blocks. The dependency the blocks have on shortcodes is severed and future development largely occurs on the blocks, especially when it comes to feature development.

How

I think it's worth trying to migrate one block at a time away from using shortcodes, hopefully starting with form fields, but there may be a need to wrangle some aspects of the form itself. The first block attempted can serve as a feasibility test. If it's not possible to take this approach, it'll be something that we quickly find out!

By doing it this way, hopefully it won't impact writing new features or fixing bugs for forms as much as undertaking a big re-write in one go.

Something else that I think will be worth tackling at the same time - currently all the form field blocks share a lot of code and are all registered in the same files. I think it'd be a good idea to implement each one more idiomatically in its self-contained folder, each with it's own block.json, registration and rendering code. This might require unDRYing some parts (introducing some duplication), but I think that's ok.

This can hopefully help as a signal for other devs - if a form block is in its own folder, it's been migrated and doesn't depend on shortcodes any longer.

[ntsekouras]

Thanks for the issue Dan! The current situation limits and hinders the development and evolution of the form blocks, so I totally agree and the proposed approach to do this iterative sounds like a very good plan to me!

Something else that I think will be worth tackling at the same time - currently all the form field blocks share a lot of code and are all registered in the same files. I think it'd be a good idea to implement each one more idiomatically in its self-contained folder, each with it's own block.json, registration and rendering code. This might require unDRYing some parts (introducing some duplication), but I think that's ok.

Agreed!

[talldan]

Made quite a bit of progress on this for the text field, but the hard parts are replicating how the shortcodes handle the form id, form hash, and the field ids. I just about have the form id and hash working via block context. The field ids are next to understand.

Part of me is also wondering why all the field ids are the way they are and not UUIDs. This is something I might have to consider changing as dynamically rendered blocks don't really have the concept of an instance, rendering is just running the render function over the parsed block data. This means the field id really needs to be stored in attributes and a UUID is best to avoid clashes.

There's also quite a bit of interplay between the various classes, the Contact_Form_Field class keeps a reference to its parent Contact_Form instance, and Contact_Form_Shortcode also has references to all the fields and their ids. Then another interesting aspect is how Contact_Form_Field and Contact_Form also extend Contact_Form_Shortcode. Both composition and inheritance at the same time. 🤔

There's also some code that stashes the form in post meta. I haven't quite gotten a handle on that yet, but hopefully because we're not changing the form itself until last it won't really need any changes.