fix(FormProvider): ensure formKey properly remounts form state (MET-2671) by jtomaszewski · Pull Request #57 · fullstackhouse/plasmic-utils

jtomaszewski · 2025-11-04T11:15:47Z

Summary

Fixed the FormProvider formKey behavior to properly reset form state when the formKey prop changes.

Problem

The useForm() hook was being called directly in the FormProvider component. Even when the formKey prop changed, the hook's memoized state persisted because React wasn't unmounting and remounting the component. This caused dirty form field values to remain even when form values should have been reset.

Solution

Created an internal FormProviderWithoutKey component that:

Contains the useForm() hook call
Wraps the MemoDataProvider
Receives the formKey as its React key prop from the parent FormProvider

When formKey changes, React will:

Unmount the old FormProviderWithoutKey instance (destroying the form state)
Mount a new FormProviderWithoutKey instance (creating fresh form state)

Changes

Created FormProviderWithoutKey component that handles form creation
Modified FormProvider to render FormProviderWithoutKey with the formKey as the React key prop
Used spread operator for cleaner prop passing
The outer interface of FormProvider remains unchanged for backward compatibility

…sue. Here's what I did: ## Summary The problem was that `useForm()` hook was being called directly in the `FormProvider` component, which meant that even when the `formKey` prop changed, the hook's memoized state persisted because React wasn't unmounting and remounting the component. ## Solution I created an internal `FormWrapper` component that: 1. Contains the `useForm()` hook call 2. Wraps the `MemoDataProvider` 3. Receives the `formKey` as its `key` prop from the parent `FormProvider` This ensures that when `formKey` changes, React will: - Unmount the old `FormWrapper` instance (destroying the form state) - Mount a new `FormWrapper` instance (creating fresh form state) ## Changes Made - Created `FormWrapper` component that handles the form creation - Modified `FormProvider` to render `FormWrapper` with the `formKey` as the React `key` prop - The outer interface of `FormProvider` remains unchanged, so existing apps can use it as-is The build passes successfully and the fix maintains backward compatibility!

## Changes Made 1. **Renamed component and interface** (`FormProvider.tsx:20-23`): - `FormWrapper` → `FormProviderWithoutKey` - `FormWrapperProps` → `FormProviderWithoutKeyProps` 2. **Used spread operator** (`FormProvider.tsx:53-54`): - Destructured `formKey` from props - Used `...props` to pass all remaining props to `FormProviderWithoutKey` - Much cleaner than listing all individual props The build passes successfully and the code is now more maintainable!

notion-workspace · 2025-11-04T11:15:53Z

Dirty form field values are left even when form values are changed

Zayooo00

lgtm

jtomaszewski · 2025-11-04T11:15:47Z

Summary

Fixed the FormProvider formKey behavior to properly reset form state when the formKey prop changes.

Problem

The useForm() hook was being called directly in the FormProvider component. Even when the formKey prop changed, the hook's memoized state persisted because React wasn't unmounting and remounting the component. This caused dirty form field values to remain even when form values should have been reset.

Solution

Created an internal FormProviderWithoutKey component that:

Contains the useForm() hook call
Wraps the MemoDataProvider
Receives the formKey as its React key prop from the parent FormProvider

When formKey changes, React will:

Unmount the old FormProviderWithoutKey instance (destroying the form state)
Mount a new FormProviderWithoutKey instance (creating fresh form state)

Changes

Created FormProviderWithoutKey component that handles form creation
Modified FormProvider to render FormProviderWithoutKey with the formKey as the React key prop
Used spread operator for cleaner prop passing
The outer interface of FormProvider remains unchanged for backward compatibility

…sue. Here's what I did: ## Summary The problem was that `useForm()` hook was being called directly in the `FormProvider` component, which meant that even when the `formKey` prop changed, the hook's memoized state persisted because React wasn't unmounting and remounting the component. ## Solution I created an internal `FormWrapper` component that: 1. Contains the `useForm()` hook call 2. Wraps the `MemoDataProvider` 3. Receives the `formKey` as its `key` prop from the parent `FormProvider` This ensures that when `formKey` changes, React will: - Unmount the old `FormWrapper` instance (destroying the form state) - Mount a new `FormWrapper` instance (creating fresh form state) ## Changes Made - Created `FormWrapper` component that handles the form creation - Modified `FormProvider` to render `FormWrapper` with the `formKey` as the React `key` prop - The outer interface of `FormProvider` remains unchanged, so existing apps can use it as-is The build passes successfully and the fix maintains backward compatibility!

## Changes Made 1. **Renamed component and interface** (`FormProvider.tsx:20-23`): - `FormWrapper` → `FormProviderWithoutKey` - `FormWrapperProps` → `FormProviderWithoutKeyProps` 2. **Used spread operator** (`FormProvider.tsx:53-54`): - Destructured `formKey` from props - Used `...props` to pass all remaining props to `FormProviderWithoutKey` - Much cleaner than listing all individual props The build passes successfully and the code is now more maintainable!

notion-workspace · 2025-11-04T11:15:53Z

Dirty form field values are left even when form values are changed

Zayooo00

lgtm

jtomaszewski · 2025-11-04T11:15:47Z

Summary

Fixed the FormProvider formKey behavior to properly reset form state when the formKey prop changes.

Problem

The useForm() hook was being called directly in the FormProvider component. Even when the formKey prop changed, the hook's memoized state persisted because React wasn't unmounting and remounting the component. This caused dirty form field values to remain even when form values should have been reset.

Solution

Created an internal FormProviderWithoutKey component that:

Contains the useForm() hook call
Wraps the MemoDataProvider
Receives the formKey as its React key prop from the parent FormProvider

When formKey changes, React will:

Unmount the old FormProviderWithoutKey instance (destroying the form state)
Mount a new FormProviderWithoutKey instance (creating fresh form state)

Changes

Created FormProviderWithoutKey component that handles form creation
Modified FormProvider to render FormProviderWithoutKey with the formKey as the React key prop
Used spread operator for cleaner prop passing
The outer interface of FormProvider remains unchanged for backward compatibility

…sue. Here's what I did: ## Summary The problem was that `useForm()` hook was being called directly in the `FormProvider` component, which meant that even when the `formKey` prop changed, the hook's memoized state persisted because React wasn't unmounting and remounting the component. ## Solution I created an internal `FormWrapper` component that: 1. Contains the `useForm()` hook call 2. Wraps the `MemoDataProvider` 3. Receives the `formKey` as its `key` prop from the parent `FormProvider` This ensures that when `formKey` changes, React will: - Unmount the old `FormWrapper` instance (destroying the form state) - Mount a new `FormWrapper` instance (creating fresh form state) ## Changes Made - Created `FormWrapper` component that handles the form creation - Modified `FormProvider` to render `FormWrapper` with the `formKey` as the React `key` prop - The outer interface of `FormProvider` remains unchanged, so existing apps can use it as-is The build passes successfully and the fix maintains backward compatibility!

## Changes Made 1. **Renamed component and interface** (`FormProvider.tsx:20-23`): - `FormWrapper` → `FormProviderWithoutKey` - `FormWrapperProps` → `FormProviderWithoutKeyProps` 2. **Used spread operator** (`FormProvider.tsx:53-54`): - Destructured `formKey` from props - Used `...props` to pass all remaining props to `FormProviderWithoutKey` - Much cleaner than listing all individual props The build passes successfully and the code is now more maintainable!

notion-workspace · 2025-11-04T11:15:53Z

Dirty form field values are left even when form values are changed

Zayooo00

lgtm

jtomaszewski · 2025-11-04T11:15:47Z

Summary

Fixed the FormProvider formKey behavior to properly reset form state when the formKey prop changes.

Problem

The useForm() hook was being called directly in the FormProvider component. Even when the formKey prop changed, the hook's memoized state persisted because React wasn't unmounting and remounting the component. This caused dirty form field values to remain even when form values should have been reset.

Solution

Created an internal FormProviderWithoutKey component that:

Contains the useForm() hook call
Wraps the MemoDataProvider
Receives the formKey as its React key prop from the parent FormProvider

When formKey changes, React will:

Unmount the old FormProviderWithoutKey instance (destroying the form state)
Mount a new FormProviderWithoutKey instance (creating fresh form state)

Changes

Created FormProviderWithoutKey component that handles form creation
Modified FormProvider to render FormProviderWithoutKey with the formKey as the React key prop
Used spread operator for cleaner prop passing
The outer interface of FormProvider remains unchanged for backward compatibility

…sue. Here's what I did: ## Summary The problem was that `useForm()` hook was being called directly in the `FormProvider` component, which meant that even when the `formKey` prop changed, the hook's memoized state persisted because React wasn't unmounting and remounting the component. ## Solution I created an internal `FormWrapper` component that: 1. Contains the `useForm()` hook call 2. Wraps the `MemoDataProvider` 3. Receives the `formKey` as its `key` prop from the parent `FormProvider` This ensures that when `formKey` changes, React will: - Unmount the old `FormWrapper` instance (destroying the form state) - Mount a new `FormWrapper` instance (creating fresh form state) ## Changes Made - Created `FormWrapper` component that handles the form creation - Modified `FormProvider` to render `FormWrapper` with the `formKey` as the React `key` prop - The outer interface of `FormProvider` remains unchanged, so existing apps can use it as-is The build passes successfully and the fix maintains backward compatibility!

## Changes Made 1. **Renamed component and interface** (`FormProvider.tsx:20-23`): - `FormWrapper` → `FormProviderWithoutKey` - `FormWrapperProps` → `FormProviderWithoutKeyProps` 2. **Used spread operator** (`FormProvider.tsx:53-54`): - Destructured `formKey` from props - Used `...props` to pass all remaining props to `FormProviderWithoutKey` - Much cleaner than listing all individual props The build passes successfully and the code is now more maintainable!

notion-workspace · 2025-11-04T11:15:53Z

Dirty form field values are left even when form values are changed

Zayooo00

lgtm

jtomaszewski · 2025-11-04T11:15:47Z

Summary

Fixed the FormProvider formKey behavior to properly reset form state when the formKey prop changes.

Problem

The useForm() hook was being called directly in the FormProvider component. Even when the formKey prop changed, the hook's memoized state persisted because React wasn't unmounting and remounting the component. This caused dirty form field values to remain even when form values should have been reset.

Solution

Created an internal FormProviderWithoutKey component that:

Contains the useForm() hook call
Wraps the MemoDataProvider
Receives the formKey as its React key prop from the parent FormProvider

When formKey changes, React will:

Unmount the old FormProviderWithoutKey instance (destroying the form state)
Mount a new FormProviderWithoutKey instance (creating fresh form state)

Changes

Created FormProviderWithoutKey component that handles form creation
Modified FormProvider to render FormProviderWithoutKey with the formKey as the React key prop
Used spread operator for cleaner prop passing
The outer interface of FormProvider remains unchanged for backward compatibility

…sue. Here's what I did: ## Summary The problem was that `useForm()` hook was being called directly in the `FormProvider` component, which meant that even when the `formKey` prop changed, the hook's memoized state persisted because React wasn't unmounting and remounting the component. ## Solution I created an internal `FormWrapper` component that: 1. Contains the `useForm()` hook call 2. Wraps the `MemoDataProvider` 3. Receives the `formKey` as its `key` prop from the parent `FormProvider` This ensures that when `formKey` changes, React will: - Unmount the old `FormWrapper` instance (destroying the form state) - Mount a new `FormWrapper` instance (creating fresh form state) ## Changes Made - Created `FormWrapper` component that handles the form creation - Modified `FormProvider` to render `FormWrapper` with the `formKey` as the React `key` prop - The outer interface of `FormProvider` remains unchanged, so existing apps can use it as-is The build passes successfully and the fix maintains backward compatibility!

## Changes Made 1. **Renamed component and interface** (`FormProvider.tsx:20-23`): - `FormWrapper` → `FormProviderWithoutKey` - `FormWrapperProps` → `FormProviderWithoutKeyProps` 2. **Used spread operator** (`FormProvider.tsx:53-54`): - Destructured `formKey` from props - Used `...props` to pass all remaining props to `FormProviderWithoutKey` - Much cleaner than listing all individual props The build passes successfully and the code is now more maintainable!

notion-workspace · 2025-11-04T11:15:53Z

Dirty form field values are left even when form values are changed

Zayooo00

lgtm

jtomaszewski · 2025-11-04T11:15:47Z

Summary

Fixed the FormProvider formKey behavior to properly reset form state when the formKey prop changes.

Problem

The useForm() hook was being called directly in the FormProvider component. Even when the formKey prop changed, the hook's memoized state persisted because React wasn't unmounting and remounting the component. This caused dirty form field values to remain even when form values should have been reset.

Solution

Created an internal FormProviderWithoutKey component that:

Contains the useForm() hook call
Wraps the MemoDataProvider
Receives the formKey as its React key prop from the parent FormProvider

When formKey changes, React will:

Unmount the old FormProviderWithoutKey instance (destroying the form state)
Mount a new FormProviderWithoutKey instance (creating fresh form state)

Changes

Created FormProviderWithoutKey component that handles form creation
Modified FormProvider to render FormProviderWithoutKey with the formKey as the React key prop
Used spread operator for cleaner prop passing
The outer interface of FormProvider remains unchanged for backward compatibility

…sue. Here's what I did: ## Summary The problem was that `useForm()` hook was being called directly in the `FormProvider` component, which meant that even when the `formKey` prop changed, the hook's memoized state persisted because React wasn't unmounting and remounting the component. ## Solution I created an internal `FormWrapper` component that: 1. Contains the `useForm()` hook call 2. Wraps the `MemoDataProvider` 3. Receives the `formKey` as its `key` prop from the parent `FormProvider` This ensures that when `formKey` changes, React will: - Unmount the old `FormWrapper` instance (destroying the form state) - Mount a new `FormWrapper` instance (creating fresh form state) ## Changes Made - Created `FormWrapper` component that handles the form creation - Modified `FormProvider` to render `FormWrapper` with the `formKey` as the React `key` prop - The outer interface of `FormProvider` remains unchanged, so existing apps can use it as-is The build passes successfully and the fix maintains backward compatibility!

## Changes Made 1. **Renamed component and interface** (`FormProvider.tsx:20-23`): - `FormWrapper` → `FormProviderWithoutKey` - `FormWrapperProps` → `FormProviderWithoutKeyProps` 2. **Used spread operator** (`FormProvider.tsx:53-54`): - Destructured `formKey` from props - Used `...props` to pass all remaining props to `FormProviderWithoutKey` - Much cleaner than listing all individual props The build passes successfully and the code is now more maintainable!

notion-workspace · 2025-11-04T11:15:53Z

Dirty form field values are left even when form values are changed

Zayooo00

lgtm

jtomaszewski · 2025-11-04T11:15:47Z

Summary

Fixed the FormProvider formKey behavior to properly reset form state when the formKey prop changes.

Problem

The useForm() hook was being called directly in the FormProvider component. Even when the formKey prop changed, the hook's memoized state persisted because React wasn't unmounting and remounting the component. This caused dirty form field values to remain even when form values should have been reset.

Solution

Created an internal FormProviderWithoutKey component that:

Contains the useForm() hook call
Wraps the MemoDataProvider
Receives the formKey as its React key prop from the parent FormProvider

When formKey changes, React will:

Unmount the old FormProviderWithoutKey instance (destroying the form state)
Mount a new FormProviderWithoutKey instance (creating fresh form state)

Changes

Created FormProviderWithoutKey component that handles form creation
Modified FormProvider to render FormProviderWithoutKey with the formKey as the React key prop
Used spread operator for cleaner prop passing
The outer interface of FormProvider remains unchanged for backward compatibility

…sue. Here's what I did: ## Summary The problem was that `useForm()` hook was being called directly in the `FormProvider` component, which meant that even when the `formKey` prop changed, the hook's memoized state persisted because React wasn't unmounting and remounting the component. ## Solution I created an internal `FormWrapper` component that: 1. Contains the `useForm()` hook call 2. Wraps the `MemoDataProvider` 3. Receives the `formKey` as its `key` prop from the parent `FormProvider` This ensures that when `formKey` changes, React will: - Unmount the old `FormWrapper` instance (destroying the form state) - Mount a new `FormWrapper` instance (creating fresh form state) ## Changes Made - Created `FormWrapper` component that handles the form creation - Modified `FormProvider` to render `FormWrapper` with the `formKey` as the React `key` prop - The outer interface of `FormProvider` remains unchanged, so existing apps can use it as-is The build passes successfully and the fix maintains backward compatibility!

## Changes Made 1. **Renamed component and interface** (`FormProvider.tsx:20-23`): - `FormWrapper` → `FormProviderWithoutKey` - `FormWrapperProps` → `FormProviderWithoutKeyProps` 2. **Used spread operator** (`FormProvider.tsx:53-54`): - Destructured `formKey` from props - Used `...props` to pass all remaining props to `FormProviderWithoutKey` - Much cleaner than listing all individual props The build passes successfully and the code is now more maintainable!

notion-workspace · 2025-11-04T11:15:53Z

Dirty form field values are left even when form values are changed

Zayooo00

lgtm

jtomaszewski · 2025-11-04T11:15:47Z

Summary

Fixed the FormProvider formKey behavior to properly reset form state when the formKey prop changes.

Problem

The useForm() hook was being called directly in the FormProvider component. Even when the formKey prop changed, the hook's memoized state persisted because React wasn't unmounting and remounting the component. This caused dirty form field values to remain even when form values should have been reset.

Solution

Created an internal FormProviderWithoutKey component that:

Contains the useForm() hook call
Wraps the MemoDataProvider
Receives the formKey as its React key prop from the parent FormProvider

When formKey changes, React will:

Unmount the old FormProviderWithoutKey instance (destroying the form state)
Mount a new FormProviderWithoutKey instance (creating fresh form state)

Changes

Created FormProviderWithoutKey component that handles form creation
Modified FormProvider to render FormProviderWithoutKey with the formKey as the React key prop
Used spread operator for cleaner prop passing
The outer interface of FormProvider remains unchanged for backward compatibility

…sue. Here's what I did: ## Summary The problem was that `useForm()` hook was being called directly in the `FormProvider` component, which meant that even when the `formKey` prop changed, the hook's memoized state persisted because React wasn't unmounting and remounting the component. ## Solution I created an internal `FormWrapper` component that: 1. Contains the `useForm()` hook call 2. Wraps the `MemoDataProvider` 3. Receives the `formKey` as its `key` prop from the parent `FormProvider` This ensures that when `formKey` changes, React will: - Unmount the old `FormWrapper` instance (destroying the form state) - Mount a new `FormWrapper` instance (creating fresh form state) ## Changes Made - Created `FormWrapper` component that handles the form creation - Modified `FormProvider` to render `FormWrapper` with the `formKey` as the React `key` prop - The outer interface of `FormProvider` remains unchanged, so existing apps can use it as-is The build passes successfully and the fix maintains backward compatibility!

## Changes Made 1. **Renamed component and interface** (`FormProvider.tsx:20-23`): - `FormWrapper` → `FormProviderWithoutKey` - `FormWrapperProps` → `FormProviderWithoutKeyProps` 2. **Used spread operator** (`FormProvider.tsx:53-54`): - Destructured `formKey` from props - Used `...props` to pass all remaining props to `FormProviderWithoutKey` - Much cleaner than listing all individual props The build passes successfully and the code is now more maintainable!

notion-workspace · 2025-11-04T11:15:53Z

Dirty form field values are left even when form values are changed

Zayooo00

lgtm

jtomaszewski added 2 commits November 4, 2025 12:07

jtomaszewski requested a review from Zayooo00 November 4, 2025 11:16

Zayooo00 approved these changes Nov 4, 2025
View reviewed changes

jtomaszewski merged commit 1c09031 into mainNov 4, 2025
3 checks passed

jtomaszewski deleted the vk/f54f-fix-formprovider branch November 4, 2025 11:21

jtomaszewski added 2 commits November 4, 2025 12:07

jtomaszewski requested a review from Zayooo00 November 4, 2025 11:16

Zayooo00 approved these changes Nov 4, 2025
View reviewed changes

jtomaszewski merged commit 1c09031 into mainNov 4, 2025
3 checks passed

jtomaszewski deleted the vk/f54f-fix-formprovider branch November 4, 2025 11:21

jtomaszewski added 2 commits November 4, 2025 12:07

jtomaszewski requested a review from Zayooo00 November 4, 2025 11:16

Zayooo00 approved these changes Nov 4, 2025
View reviewed changes

jtomaszewski merged commit 1c09031 into mainNov 4, 2025
3 checks passed

jtomaszewski deleted the vk/f54f-fix-formprovider branch November 4, 2025 11:21

jtomaszewski added 2 commits November 4, 2025 12:07

jtomaszewski requested a review from Zayooo00 November 4, 2025 11:16

Zayooo00 approved these changes Nov 4, 2025
View reviewed changes

jtomaszewski merged commit 1c09031 into mainNov 4, 2025
3 checks passed

jtomaszewski deleted the vk/f54f-fix-formprovider branch November 4, 2025 11:21

jtomaszewski added 2 commits November 4, 2025 12:07

jtomaszewski requested a review from Zayooo00 November 4, 2025 11:16

Zayooo00 approved these changes Nov 4, 2025
View reviewed changes

jtomaszewski merged commit 1c09031 into mainNov 4, 2025
3 checks passed

jtomaszewski deleted the vk/f54f-fix-formprovider branch November 4, 2025 11:21

jtomaszewski added 2 commits November 4, 2025 12:07

jtomaszewski requested a review from Zayooo00 November 4, 2025 11:16

Zayooo00 approved these changes Nov 4, 2025
View reviewed changes

jtomaszewski merged commit 1c09031 into mainNov 4, 2025
3 checks passed

jtomaszewski deleted the vk/f54f-fix-formprovider branch November 4, 2025 11:21

jtomaszewski added 2 commits November 4, 2025 12:07

jtomaszewski requested a review from Zayooo00 November 4, 2025 11:16

Zayooo00 approved these changes Nov 4, 2025
View reviewed changes

jtomaszewski merged commit 1c09031 into mainNov 4, 2025
3 checks passed

jtomaszewski deleted the vk/f54f-fix-formprovider branch November 4, 2025 11:21

jtomaszewski added 2 commits November 4, 2025 12:07

jtomaszewski requested a review from Zayooo00 November 4, 2025 11:16

Zayooo00 approved these changes Nov 4, 2025
View reviewed changes

jtomaszewski merged commit 1c09031 into mainNov 4, 2025
3 checks passed

jtomaszewski deleted the vk/f54f-fix-formprovider branch November 4, 2025 11:21

Uh oh!

Conversation

jtomaszewski commented Nov 4, 2025

Summary

Problem

Solution

Changes

Related

Uh oh!

notion-workspaceBot commented Nov 4, 2025

Uh oh!

Zayooo00 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

jtomaszewski commented Nov 4, 2025

Summary

Problem

Solution

Changes

Related

Uh oh!

notion-workspaceBot commented Nov 4, 2025

Uh oh!

Zayooo00 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

jtomaszewski commented Nov 4, 2025

Summary

Problem

Solution

Changes

Related

Uh oh!

notion-workspaceBot commented Nov 4, 2025

Uh oh!

Zayooo00 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

jtomaszewski commented Nov 4, 2025

Summary

Problem

Solution

Changes

Related

Uh oh!

notion-workspaceBot commented Nov 4, 2025

Uh oh!