I have this crowded form with some 30-40 fields, and most of them have kinda plex logic. Understandibly I wanted to make these form areas reusable for both create and edit pages since both are identical in terms of form items and fields. I got them to work without much effort, and they work fine for most parts, except the quest for reusability introduced some other challenges and now I am questioning if it's worth it.

For me some of the challenges of using the same forms for both create and edit are:

• Conditionals everywhere. Want to make a field uneditable in edit mode? Extra props to pass in and disable said fields with those props.

• Edit mode needs initial state so forms fields are filled in with existing data but create page does not like that, so even more and even worse conditions like:

const { user } = React.useContext(DetailContext) ?? {}; // I know...
const [userType, setUserType] = useState(user?.user_type ?? null); // yep

At this point I can't even decide how to safely assign and use stuff, and I can't estimate what parts are prone to breaking.

Is this inevitable and fine as is or is this plete silliness? What are some good practices for making form areas or forms reusable? Can I reduce noise without sacrificing reusability?

I have this crowded form with some 30-40 fields, and most of them have kinda plex logic. Understandibly I wanted to make these form areas reusable for both create and edit pages since both are identical in terms of form items and fields. I got them to work without much effort, and they work fine for most parts, except the quest for reusability introduced some other challenges and now I am questioning if it's worth it.

For me some of the challenges of using the same forms for both create and edit are:

• Conditionals everywhere. Want to make a field uneditable in edit mode? Extra props to pass in and disable said fields with those props.

• Edit mode needs initial state so forms fields are filled in with existing data but create page does not like that, so even more and even worse conditions like:

const { user } = React.useContext(DetailContext) ?? {}; // I know...
const [userType, setUserType] = useState(user?.user_type ?? null); // yep

At this point I can't even decide how to safely assign and use stuff, and I can't estimate what parts are prone to breaking.

Is this inevitable and fine as is or is this plete silliness? What are some good practices for making form areas or forms reusable? Can I reduce noise without sacrificing reusability?

• javascript
• reactjs

• I've never run into serious problems using same form ponents for create/edit by setting a high level property value for the use case. Would be a lot easier to help if you provided specific example of such issues you are running into – charlietfl Commented Mar 7, 2021 at 16:36
• There aren't any issues, they work okay but it is challenging to put conditions everywhere to catch edit/create mode specific tasks. I just want to know if there are good practices to negate every possible side effect, to guarantee reliability, and to make development easier – Özenç B. Commented Mar 7, 2021 at 16:39
• Without providing a specific problem - unfortunately this whole question bees too broad and possibly opinionated based on guidelines in the help center – charlietfl Commented Mar 7, 2021 at 16:45

1 Answer 1

The question is indeed kind of broad but a general solution might still help you. There are a couple of main points you need to consider:

1. Are all the fields present in both edit and create mode or there might be situations where not all of them are included in either?
2. Are there fields that are supplied on creation but cannot be edited after that(in edit mode)?
3. Are there initial values for any of the creation form fields?

I would tackle the problem in the following manner:

You'll have a single form ponent which accept field properties as parameter(ponent props). For each field you supply the following information:

1. Initial value, if any (initialValue)
2. If the field should be present in the form at all (isDisplayed)
3. If the field should be present but disabled (isDisabled)

This way you cover all of the previously mentioned points while keeping a single form ponent. Also, you'll supply a parameter like mode with possible values edit/create which guides the form logic and how the form submit would be handled(difference in handling logic, different endpoints and such). Then, in your form ponent you'll have to do some checks based on the provided parameters i.e. should the given form input be disabled if isDisabled is true or if it should be displayed at all - isDisplayed.

It's not a perfect solution, but it is flexible enough to enable you to use the same form template and share most of the handling logic. If, however, you have vast differences in how the edit/create forms are structured, you might be better off to duplicate some logic by introducing two separate ponents but save your sanity and time figuring out how to cover and abstract every single new extenstion you want to introduce in one of them.