The Need for Reorganization

Oct 13, 2025 by talynt.org 100 views

Forms: Reorganize existing Jetpack form field blocks for improved maintainability and extensibility

Introduction

The current Jetpack Form Field blocks are defined in a monolithic, hard-to-maintain structure. Some blocks reuse a shared attributes array, while others define their own attributes, settings, and edit/save implementations. This issue aims to reorganize these blocks to follow Gutenberg conventions: each block in its own folder with clear definitions (metadata, attributes, edit/save components, etc.) and optional shared logic or attributes imported from a central, shared location.

The Need for Reorganization

The current structure of the Jetpack Form Field blocks is not only hard to maintain but also makes it difficult for contributors to navigate and modify the code. By reorganizing the existing block structure without altering current functionality, we’ll establish a more maintainable codebase that sets the stage for seamlessly migrating to inner blocks, incrementally untangling shortcode rendering, and adding new field types in the future.

Scope & Requirements

The scope of this issue is to reorganize the existing block structure to follow Gutenberg conventions. The requirements are as follows:

Each form field block (e.g., text, email, radio, checkbox) should live in its own dedicated folder, containing relevant files (e.g., block.json, edit.js, save.js, deprecations.js).
Shared configurations or attributes should be extracted into reusable modules (e.g., a shared/ directory) rather than existing in a single monolithic array or file.
Functionality must remain consistent; we’re not changing user-facing behavior or migrating to inner blocks yet.
The updated structure should align with standard Gutenberg block organization, making it easier for contributors to navigate and modify.

Tasks

The tasks involved in reorganizing the existing block structure are as follows:

Create Dedicated Folders for Each Block

Establish a folder per field block (e.g., jetpack/extensions/blocks/contact-form/text-field, .../email-field, etc.).
Migrate code from the monolithic arrays/definitions into each respective folder.
Ensure each folder includes necessary files: index.js, block.json, edit.js, save.js, etc.

Centralize Shared Logic

If certain attributes or utility functions are common across multiple fields, move them into a shared/ folder or utility module.
Update all blocks to import from this shared module instead of redefining or mutating global arrays.

Maintain Functional Equivalence

Confirm there are no user-facing regressions by running existing tests and manual checks.
Verify that each reorganized block still registers in the editor as expected, with the same attributes, edit UI, and frontend output.

Note: This refactor does not involve migrating to inner blocks. The blocks should remain fully functional in their “legacy” format but reorganized for clarity and maintainability.

Benefits of Reorganization

The reorganization of the existing block structure will bring several benefits, including:

Improved maintainability: The codebase will be easier to navigate and modify, making it easier for contributors to make changes and fix issues.
Increased extensibility: The reorganized structure will make it easier to add new field types and features, allowing for more flexibility and customization.
Better alignment with Gutenberg conventions: The updated structure will align with standard Gutenberg block organization, making it easier for contributors to understand and work with the code.

Conclusion

The reorganization of the existing Jetpack Form Field blocks is a crucial step in improving the maintainability and extensibility of the codebase. By following Gutenberg conventions and creating dedicated folders for each block, we can establish a more maintainable codebase that sets the stage for seamless migration to inner blocks, incremental untangling of shortcode rendering, and addition of new field types in the future.
Forms: Reorganize existing Jetpack form field blocks for improved maintainability and extensibility

Q&A

Q: What is the current structure of the Jetpack Form Field blocks?

A: The current structure of the Jetpack Form Field blocks is defined in a monolithic, hard-to-maintain structure. Some blocks reuse a shared attributes array, while others define their own attributes, settings, and edit/save implementations.

Q: Why is the current structure a problem?

A: The current structure is not only hard to maintain but also makes it difficult for contributors to navigate and modify the code. This can lead to errors, bugs, and a slower development process.

Q: What are the benefits of reorganizing the existing block structure?

A: The reorganization of the existing block structure will bring several benefits, including:

Improved maintainability: The codebase will be easier to navigate and modify, making it easier for contributors to make changes and fix issues.
Increased extensibility: The reorganized structure will make it easier to add new field types and features, allowing for more flexibility and customization.
Better alignment with Gutenberg conventions: The updated structure will align with standard Gutenberg block organization, making it easier for contributors to understand and work with the code.

Q: What are the requirements for reorganizing the existing block structure?

A: The requirements are as follows:

Each form field block (e.g., text, email, radio, checkbox) should live in its own dedicated folder, containing relevant files (e.g., block.json, edit.js, save.js, deprecations.js).
Shared configurations or attributes should be extracted into reusable modules (e.g., a shared/ directory) rather than existing in a single monolithic array or file.
Functionality must remain consistent; we’re not changing user-facing behavior or migrating to inner blocks yet.
The updated structure should align with standard Gutenberg block organization, making it easier for contributors to navigate and modify.

Q: What are the tasks involved in reorganizing the existing block structure?

A: The tasks involved in reorganizing the existing block structure are as follows:

Create Dedicated Folders for Each Block

Establish a folder per field block (e.g., jetpack/extensions/blocks/contact-form/text-field, .../email-field, etc.).
Migrate code from the monolithic arrays/definitions into each respective folder.
Ensure each folder includes necessary files: index.js, block.json, edit.js, save.js, etc.

Centralize Shared Logic

If certain attributes or utility functions are common across multiple fields, move them into a shared/ folder or utility module.
Update all blocks to import from this shared module instead of redefining or mutating global arrays.

Maintain Functional Equivalence

Confirm there are no user-facing regressions by running existing tests and manual checks.
Verify that each reorganized block still registers in the editor as expected, with the same attributes, edit UI, and frontend output.

Q: What is the timeline for this refactor?

A: The timeline for this refactor is still being determined. We will provide updates on the project thread as more information becomes available.

Q: How can I contribute to this project?

A: If you are interested in contributing to this project, please join the project thread and let us know how you would like to help. We are always looking for contributors to help with testing, coding, and other tasks.

Q: What are the next steps for this project?

A: The next steps for this project are to create dedicated folders for each block, centralize shared logic, and maintain functional equivalence. We will provide updates on the project thread as more information becomes available.