Profile Page
Solution Part 1
Let us refactor the conditional logic to be cleaner
Let us look at the code with the problem highlighted:
Separating out the UI
The editMode
state is used to determine whether the form or the display is rendered. Meaning we can create two dedicated components for the form and the display.
Feature Folder
Great! But let us put them in a dedicated feature
folder for better organization.
App.tsx
App.css
main.tsx
index.css
- We will also separate out the
Profile
type to its own file and export it asProfileType
. The suffix ofType
is a convention to indicate that it is a type and helps not cause naming conflicts. - We will then create two files,
profile-display.tsx
andprofile-form.tsx
, which will hold the UI components for the profile page. - Finally, we import them in
App.tsx
and use them accordingly.
Can we improve the code further?
Great, but can we further improve the code?
- Our
App.tsx
file does not need to worry about the formhandleChange
and that logic should be moved to theProfileForm
component. - We can also move the respective
formData
state to theProfileForm
component. - Some minor changes will also be required to match the component APIs.
We made the following changes to the ProfileForm
component:
- It now only takes two props:
initialFormData
andhandleSave
. - The
formData
state is initialized with theinitialFormData
prop. - The
handleSave
prop is updated to pass the form data to the parent component. - The
handleChange
logic is directly moved here.
We made the following changes in the App.tsx
file:
- We removed all the references to the
formData
state. - We removd the
handleChange
logic. - We added the
initialFormData
prop to theProfileForm
component. - The
handleSave
prop is updated to receive the form data from the child component.
Great, in the next chapter we will improve the fake APIs.
At this point, your code should be a good match to the branch of the repository: 1-solution-part-1
Last updated on