Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#9242: migrate unsaved standalone mod components in the Page Editor #9246

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

twschiller
Copy link
Contributor

@twschiller twschiller commented Oct 7, 2024

What does this PR do?

Reviewer Notes

Future Work

  • Migrate ModComponent type to require _recipe/modMetadata

For more information on our expectations for the PR process, see the
code review principles doc

@twschiller twschiller self-assigned this Oct 7, 2024
@twschiller twschiller changed the title #9242: migrate unsaved standalone mod components in the Page Editor #9242: [WIP] migrate unsaved standalone mod components in the Page Editor Oct 7, 2024
@twschiller twschiller requested review from grahamlangford and removed request for grahamlangford and mnholtz October 7, 2024 01:20
);
for (const formState of modComponentFormStates) {
formState.modMetadata = modMetadata;
}
},
addModComponentFormStateToMod(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Drop unused action

@@ -670,53 +628,6 @@ export const editorSlice = createSlice({
state.visibleModalKey = ModalKey.MOVE_COPY_TO_MOD;
state.keepLocalCopyOnCreateMod = moveOrCopy === "copy";
},
removeModComponentFormStateFromMod(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Drop unused action

* The mod metadata for the mod component
* @see createNewUnsavedModMetadata
*/
modMetadata: ModMetadata;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Main type change: require modMetadata

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of Except, would SetRequired be better here?

Copy link
Contributor Author

@twschiller twschiller Oct 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure - I'll make the change. I think the end result is the same? I agree SetRequired is probably more readable

Copy link
Contributor Author

@twschiller twschiller Oct 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like we can't use it since SetRequired seems to operate on "?" and not types where the prop exists but the value might be set to undefined

export function migrateEditorStateV8(
state: EditorStateV8 & PersistedState,
): EditorStateV9 & PersistedState {
return produce(state, (draft) => {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Slice migration code

@twschiller twschiller added this to the 2.1.4 milestone Oct 7, 2024
@twschiller twschiller added the do not merge Merging of this PR is blocked by another one label Oct 7, 2024
@grahamlangford
Copy link
Collaborator

grahamlangford commented Oct 7, 2024

@grahamlangford I don't think I understand the sketch here: https://www.notion.so/pixiebrix/Re-Slicing-Eliminate-Standalone-mods-from-UI-694e4c85e61441809e14aec18f6b6109?pvs=4#10a43b21a253801a93e5e7e0cabb0b4d. UnsavedModDefinition is not how the Page Editor tracks mods/components. So there isn't really a way to convert standalone mod components to UnsavedModDefinition

If the user has any unsaved standalone mod components in their Page Editor, then we need to change them (structurally and visually) to match the new behavior when you create a new mod but don't save it via the dropdown (pushing metadata down with the @inner id, etc.

This is so we can get rid of the UI affordances for standalone mod components entirely

@grahamlangford do you remember the context behind why the sketch indicated we have to keep useMigrateStandaloneComponentsToMods? https://www.notion.so/pixiebrix/Re-Slicing-Eliminate-Standalone-mods-from-UI-694e4c85e61441809e14aec18f6b6109?pvs=4#10a43b21a25380e4974ae924d03f3fc5?. That hook loops over standalone mod component form states. So, if the Page Editor migrates those, the set of those would always be empty by the time it hits the hook

Sure, the idea is to be defensive:

  1. I am on an older version of the Extension (either before useMigrateStandaloneComponentsToMods was added or if it's more recent, I haven't opened the Page Editor since before)
  2. I have saved standalone mods that have been converted on the backend but not in the Extension. (because my previous version was too old or because I haven't opened the Page Editor in several versions
  3. I update my Extension to 2.1.4
  4. I open my Page Editor
  5. I need my persisted standalone mod components to be converted or I will probably experience UI errors (depending on how we handle removing the affordances for standalone mod components)

@twschiller twschiller force-pushed the feature/9244-move-copy-mod-component branch from 99f9601 to 9c49084 Compare October 7, 2024 18:27
Comment on lines 57 to 59
modComponentActions.UNSAFE_setModComponents(
array(activatedModComponentFactory, 3)(),
),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot about that helper. There are so many places that would be useful

Comment on lines 27 to 28
// FIXME: why is this hook still required?
// See comment: https://www.notion.so/pixiebrix/Re-Slicing-Eliminate-Standalone-mods-from-UI-694e4c85e61441809e14aec18f6b6109?pvs=4#10a43b21a25380e4974ae924d03f3fc5
Copy link
Collaborator

@grahamlangford grahamlangford Oct 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As noted on the PR comment, it's purely for backwards compatibility in case the user skipped multiple versions or didn't open the Page Editor in the time since the hook was added. We could consider other options as well (have redux-persist migrations delete any still-existing standalone mod components from both the options and editor stores?)

Copy link
Contributor Author

@twschiller twschiller Oct 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the hook is a NOP though given the migration in this PR. Given the migration, standaloneComponentFormStates will always be an empty array

I agree there's a corner case for someone on 1/ a version of PixieBrix without the mod component slice migration, 2/ an unsaved standalone mod form state. They could get into a case where a different mod id is assigned to the form state vs. the mod component, but the mod id component will be the same

Personally, I don't think we need to account for people with unsaved standalone mod component who haven't opened the Page Editor in 2+ releases. They can recover just by saving deleting the unsaved mod from the Page Editor and recreating it

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point. Though in that case we could end up in a situation where the App converted a persisted standalone mod component into a mod definition and the Extension converted the same persisted standalone mod component into an UnsavedMod.

I'll leave it to you to determine how defensive we want to be. It might be that the correct thing to do in that case is to update the hook to find mod components that have a temporary registry id instead of nullish metadata instead of removing it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point. Though in that case we could end up in a situation where the App converted a persisted standalone mod component into a mod definition and the Extension converted the same persisted standalone mod component into an UnsavedMod.

Yep - that's the corner case.

I'll leave it to you to determine how defensive we want to be

My strong preference is to just drop the code given that it's over a month/2+ releases away, outside our enterprise support window, and a recoverable issue

url,
modMetadata,
starterBrickMetadata,
element,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: I agree that button is the wrong name for this, but perhaps selectionResult would read better?

Copy link
Contributor Author

@twschiller twschiller Oct 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's using "element" because of the method name fromNativeElement. That's the "element" it's being created from. So if we wanted to use selectionResult, we'd probably want to rename the whole method in the adapter protocol

Leaving off of this PR

const modComponentFormState =
action.payload as Draft<ModComponentFormState>;
// Ensure the form state is writeable for normalization
const modComponentFormState = cloneDeep(action.payload);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious if we should consider switching to structuredClone

Copy link
Contributor Author

@twschiller twschiller Oct 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤷 Not sure. Initial Google search/chatter indicates structuredClone might be slower?

@twschiller twschiller force-pushed the feature/9242-migrate-unsaved-standalone branch from 1040c91 to 666f093 Compare October 7, 2024 21:13
Base automatically changed from feature/9244-move-copy-mod-component to main October 7, 2024 21:20
@twschiller twschiller removed the do not merge Merging of this PR is blocked by another one label Oct 7, 2024
Fixup for _recipe/modMetadata

Revert cross-cutting refactoring

Revert cross-cutting refactoring
Copy link

github-actions bot commented Oct 7, 2024

Playwright test results

passed  134 passed
flaky  4 flaky
skipped  4 skipped

Details

report  Open report ↗︎
stats  142 tests across 46 suites
duration  12 minutes, 57 seconds
commit  8ff757f
info  For more information on how to debug and view this report, see our readme

Flaky tests

msedge-setup › setup/unaffiliated.setup.ts › authenticate with unaffiliated user
chrome › tests/pageEditor/addStarterBrick.spec.ts › Add new mod with different starter brick components
chrome › tests/pageEditor/addStarterBrick.spec.ts › Add starter brick to mod
msedge › tests/pageEditor/addStarterBrick.spec.ts › Add starter brick to mod

Skipped tests

chrome › tests/regressions/doNotCloseSidebarOnPageEditorSave.spec.ts › #8104: Do not automatically close the sidebar when saving in the Page Editor
msedge › tests/regressions/doNotCloseSidebarOnPageEditorSave.spec.ts › #8104: Do not automatically close the sidebar when saving in the Page Editor
chrome › tests/runtime/googleSheetsIntegration.spec.ts › can activate a google spreadsheet mod with config options
msedge › tests/runtime/googleSheetsIntegration.spec.ts › can activate a google spreadsheet mod with config options

@twschiller twschiller changed the title #9242: [WIP] migrate unsaved standalone mod components in the Page Editor #9242: migrate unsaved standalone mod components in the Page Editor Oct 8, 2024
@twschiller twschiller marked this pull request as ready for review October 8, 2024 01:16
Copy link

codecov bot commented Oct 8, 2024

Codecov Report

Attention: Patch coverage is 78.48101% with 17 lines in your changes missing coverage. Please review.

Project coverage is 75.09%. Comparing base (8318d74) to head (8ff757f).
Report is 345 commits behind head on main.

Files with missing lines Patch % Lines
...itor/modListingPanel/DraftModComponentListItem.tsx 60.00% 4 Missing ⚠️
src/pageEditor/hooks/useAddNewModComponent.ts 0.00% 3 Missing ⚠️
src/pageEditor/starterBricks/base.ts 71.42% 2 Missing ⚠️
src/pageEditor/starterBricks/dynamicQuickBar.ts 0.00% 2 Missing ⚠️
src/pageEditor/hooks/useClearModChanges.ts 0.00% 1 Missing ⚠️
...geEditor/modListingPanel/modals/CreateModModal.tsx 0.00% 1 Missing ⚠️
src/pageEditor/store/analysisManager.ts 50.00% 1 Missing ⚠️
src/pageEditor/store/editor/editorSlice.ts 66.66% 1 Missing ⚠️
src/pageEditor/utils.ts 0.00% 1 Missing ⚠️
src/store/editorMigrations.ts 85.71% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #9246      +/-   ##
==========================================
+ Coverage   74.24%   75.09%   +0.84%     
==========================================
  Files        1332     1370      +38     
  Lines       40817    42278    +1461     
  Branches     7634     7888     +254     
==========================================
+ Hits        30306    31748    +1442     
- Misses      10511    10530      +19     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants