perf: conditionally use hooks based on activeness of field row

[foochifa]

Problem

Despite #6189 improving performance of dragging and updating field rows slightly, users can still face significant lags when attempting to:

1. Create new field
2. Edit fields
3. Dragging / reordering fields

This is because of existing hooks still causing re-renders of all field rows from various user actions.

Closes #6045

Solution

Currently, all of the field rows are too 'smart' and knows a lot of unnecessary global states/contexts, such as field builder states, entire form data (just to compute attachment size limits), and mutation methods to duplicate/delete fields.

Firstly, we identify properties that all field rows must know. These properties are mostly used in the logic for handleFieldClick in FieldRowContainer.

There are specifically two properties that all fields need to keep track of:

1. handleBuilderClick: As the builder must be displayed upon click, thus, non-active fields must also have the correct/updated method to display the Builder
2. isDirty: This is to ensure if user click to another field, upon any existing unsaved changes, the dirty modal will still be registered and displayed.

Except for the two above, all the other properties can be conditionally called based on isActive

Steps done in this PR to abstract unnecessary properties out of FieldRowContainer

1. Currently the Collapse-isble button group containing Edit (in mobile), Duplicate, and Delete, always exists for ALL field rows even if they are not displayed. This button group will only be displayed upon a field being selected (active). Hence, will conditionally render this button group based on whether the field row is active
2. As many of the hooks (such as useDuplicateFieldMutation) are being used for handleDuplicateClick and handleDeleteClick, we can abstract out the entire button group as its own component. Then move these hooks into that specific component. As this component will ONLY be rendered for one field (the active field), all re-renders from these hooks will be isolated to this FieldRowButtonGroup component for only one FieldRowContainer.
3. Additionally, as fieldBuilderState of the FieldRowContainer is primarily used when the field is active, have made it into an optional prop. This will prevent unnecessary re-renders from the updating of fieldBuilderState, hence making most of the fields more 'stupid'.
4. Lastly, we are currently passing isDraggingOver to all field rows, however, from testing it seems that it only impacts the active field. Hence, have made it tied to activeness of the field. Allowing for faster start and drop of dragging action, as only the field being activated will be re-rendered

Other optimizations:

1. Shifting isDirty hook to BuilderFields, for better debugging of prop changes. Now all major re-renders of FieldRowContainers should be seen from the change in props at the React profiler. Allowing for easier debugging of performance issues in the future
2. Shifting colorTheme hook to BuilderFields, as the underlying logic uses useCreateTabForm that causes re-renders upon any form definition changes (such as saving a field), despite the value remaining static without any design tab changes

Remaining re-renders that cannot be trivially solved:

1. Upon selecting any field (opening drawer)
2. First changes to a field (isDirty)
3. Saving a field (isDirty and drawer change)
4. Deleting a field (index changes, drawer change)
5. Dropping a field (index changes)

On why I did not conditionally render the drag icon:

1. Too little time saving, the chakra drag button is a lot cheaper than the button group
2. Causes issues with the formatting -> will need conditional changes to display an empty component to mimic the hidden component, as Fade keeps the margins of the hidden component.

There is likely no more trivial improvements we can make to field rows performance after this PR

Breaking Changes

• No - this PR is backwards compatible

Before & After Screenshots

Video capture performing a simple process of:

1. Creating a new field
2. Reordering the field
3. Editing the field
4. Deleting the field

BEFORE:

takes 1min

Screen.Recording.2023-05-15.at.11.49.22.AM.mov

AFTER:

takes 35seconds

Screen.Recording.2023-05-15.at.11.58.25.AM.mov

Tests

To ensure no regression issues
All the behaviours below should work as intended

• create a new field, delete it
• create a new field, save the field details
• create a new field by dragging from builder to preview
• edit a new field, the field in the preview content should update as well
• edit a new field, do not save, attempt to select another field. Dirty modal should display
• edit a new field, do not save, attempt to refresh, browser should prompt that it is dirty
• edit a new field, save, builder should go back to the list of fields. And the preview content should reflect the edits
• delete a field, the delete modal should show up, you should be able to delete the field
• duplicate a field
• drag a field, the field should hover over the potential droppable locations
• drop the field, all affected fields should have their question numbers updated
• add logic that conditionally displays the field. The fields hidden by logic should be translucent
• the fields hidden by logic can be edited successfully
• the fields hidden by logic can be dragged and dropped successfully
• preview the form, all your changes should be reflected in the preview

On mobile

• repeat the tests (except dragging from builder & selecting another field while editing)

[foochifa]

Changes are current on staging-alt can use this form use-template to test (300 fields)

[timotheeg]

Thanks a lot for that @foochifa !! 💪

[timotheeg]

LGTM! The readability stuff I was mentioning are minor, we can push this first and get the perf improvements sooner rather than later.

[timotheeg]

LGTM!

(assuming that having isDraggingOver:undefined and fieldBuilderState:undefined for the non-active fields does not cause problem down the nested elements)