Feature: Dynamic Dialog Opening Based on Radio Button Selection

[Codehagen]

Type of feature

💡 Feature

Current behavior

Currently, users can select different options (including "Real estate") through radio buttons in the <AddAssetButton> component to add various types of assets.

You can find the component under the /dashboard

However, there is no functionality to directly open another related dialog (such as <AddRealEstateButton>) based on the selection made (e.g., when "Real estate" is selected).

Suggested solution

I propose implementing a mechanism to dynamically open the <AddRealEstateButton> dialog when the "Real estate" radio button is selected in the <AddAssetButton> component.

This would likely involve the use of a state management solution (e.g., useState) within a common ancestor component or a global state (if necessary) to control the dialog visibility based on user interaction.

Steps to Implement (If you have better or other suggestions im open for everything)

1. Manage Dialog Visibility: Use useState in a parent component that contains both <AddAssetButton> and <AddRealEstateButton> dialogs. This state will control whether the <AddRealEstateButton> dialog is shown.

2. Trigger Dialog Open: Inside <AddAssetButton>, when the "Real estate" radio button is selected, trigger a function passed down from the parent component. This function should change the state to show the <AddRealEstateButton> dialog.

3. Implement Back Option (Optional): In the <AddRealEstateButton> dialog, add a "Back" button that, when clicked, hides the <AddRealEstateButton> dialog and shows the previous dialog or screen. This might involve updating the state in the parent component to manage which dialog is visible. The first dialog is going to be closed, when its clicked. Then display the second

Implementation Details

• State in Parent Component: Create a boolean state in the parent component (e.g., isRealEstateDialogOpen) to manage the visibility of the <AddRealEstateButton> dialog.
• Callback Function: Define a function in the parent component that toggles isRealEstateDialogOpen. Pass this function to <AddAssetButton>.
• Open <AddRealEstateButton>: In <AddAssetButton>, call the passed function when the "Real estate" option is selected, setting isRealEstateDialogOpen to true.
• Back Functionality: If implementing, ensure the "Back" button in <AddRealEstateButton> toggles the visibility state to return to the previous view.

Additional context

This feature request aims to enhance user experience by streamlining the process of adding specific types of assets, starting with real estate, and potentially incorporating a more flexible navigation flow within the application. This approach not only makes the application more intuitive but also demonstrates a thoughtful consideration of user needs and scenarios.

[ousszizou]

.take

[github-actions[bot]]

Thanks for taking this issue! Let us know if you have any questions!

[Codehagen]

Cant wait for this @ousszizou ✨

[ousszizou]

The current approach with nested dialogs involves opening additional dialogs within the main dialog. Users navigate through multiple layers of dialogs, potentially causing confusion and clutter. This increases the interactions needed to return to the primary flow. In contrast, with just one dialog, users focus on one task at a time, simplifying the experience. This reduces confusion and clutter while minimizing the interactions needed to return to the primary flow.

Based on your response to my (2) questions on Discord:

• Are those group items fixed, or maybe they can be expanded later?

• Is the content of each item totally different, or can they have shared inputs? If so, how much? (If you already have an idea about their content).

those are my 2 suggestions:

• Simply include both types & form inputs in one modal and display the different inputs conditionally based on the selected Account Type. In this modal, the user interacts only once.
• this approach is still one modal but with steps "fall within infinite modal", user first need to select an Account Type then based on the selected one will show the form inputs "in animated way". In this modal, the user interacts 2 times.

As an optional idea if we'll go with the 2nd approach, sometimes users may need to enter many records for the same or different Account types. After a successful operation, I believe it's better to provide an easy and quick solution to allow the user to repeat the "Adding" operation again. Instead of closing the modal after adding a new record and requiring the user to open it again, which would require two interactions each time, my solution is to keep the modal open after adding a new record and provide a button that returns the user directly to the form content when clicked.

[Codehagen]

I've just gone through the suggestions, and honestly, I'm quite excited about what's on the table. The idea of merging both types and form inputs into a single modal, with the content dynamically adjusting based on the selected Account Type, really resonates with me. It simplifies the user journey in a way that I think we were always aiming for.

Initially, my hesitation around adopting this approach stemmed from concerns about potentially complicating the modal with transitions. But, seeing the proposal for a streamlined, stepwise interaction with those sleek animations has completely won me over. It's exactly the kind of user-focused flow that I had in mind for down the line.

This would be an ideal userflow As for the specifics on what each account type needs, the breakdown for Real Estate looks spot-on. For Crypto and Investments, I think a similar structure could work well, tailored to fit the unique aspects of these assets.

To ensure our modal is both efficient and user-friendly, here's a breakdown of the common fields that will be shared across all account types, along with the specific fields that we'll conditionally render based on the selected account type:

Here's a quick rundown of my thoughts on the required fields for each section:

Common Fields Across All Account Types:

• Purchase Date: The date when the asset was acquired.
• Purchase Value: The value of the asset at the time of purchase.
• Current Value: The asset's current market value.

These fields are fundamental, capturing the essential information about the asset's acquisition and valuation over time.

Conditionally Rendered Fields by Account Type:

Real Estate:

• Address
• City
• Country
• Zip Code
• State

Crypto:

• Currency Name
• Wallet Address
• Conversion Rate (at Purchase)
• Current Conversion Rate

Stocks:

• Stock Name/Ticker
• Number of Shares
• Purchase Price per Share
• Current Price per Share (This we could remove, is going to be updated trough API)

Car:

• Name

Misc:

• Name

Input/Manual Transaction Input:

• Item/Asset Name
• Category (dropdown of predefined options and an "Other" option)
• 👆 If we go this way we could take away the Car and Misc category. We need to think about what the best UX would be.)

Concerns

Despite my excitement about the potential improvements to our user interface, I do have some concerns regarding the development timeline.

Specifically, I'm worried that these enhancements, especially the implementation of dynamic content and animated transitions, could extend the development time significantly. This, in turn, might delay users' ability to interact with the application as quickly as we'd hoped. Ensuring that we balance user experience improvements with a reasonable development timeline is crucial.

---

I'm genuinely looking forward to integrating this approach into our project. The proposed animated transitions, in particular, add a dynamic and intuitive element to navigating the modal that I believe will significantly enhance our user experience.

If you're all in for moving forward with this, I'm totally on board and excited to see how it'll play out!

Roadmap for Modal Improvements:

1. Design Phase:

   • [x] Finalize the UI/UX design for the single modal approach, focusing on simplicity and user engagement.
   • [x] Create mockups for conditional content display based on the selected Account Type.
   • [ ] Design the animations for stepwise interaction within the modal.

2. Development Phase: @ousszizou Has lead on this

   • [ ] Implement the single modal structure in the codebase.
   • [ ] Develop the logic for dynamically displaying form inputs based on Account Type.
   • [ ] Integrate animations for transitioning between form steps.
   • [ ] Adjust the data model if necessary to accommodate the unified input structure.

3. Implementation Phase: @alexghirelli or @meglerhagen has lead on this.

   • [ ] Set up tRPC endpoints for handling modal submissions for each Account Type.
   • [ ] Implement tRPC client logic on the frontend to interact with these endpoints.
   • [ ] Ensure data validation and error handling are robust both on the frontend and backend.
   • [ ] Conduct end-to-end testing to validate the integration between the frontend and backend.
   • [ ] Optimize performance and security of the tRPC communication.

4. Testing Phase:

   • [ ] Conduct usability testing with the updated modal to gather user feedback.
   • [ ] Perform integration testing to ensure compatibility with existing application features.
   • [ ] Address any issues identified during testing to refine the user experience.

5. Review & Finalization:

   • [ ] Review the implementation with the team, focusing on performance and user feedback.
   • [ ] Make any necessary adjustments based on team feedback and user testing results.
   • [ ] Finalize documentation to reflect the modal's functionality and usage within the application.

[ousszizou]

I'm in & ready to make these enhancements happen. I'll put in the effort & time needed to bring them to the app ASAP.

[Codehagen]

Looking forward to it! If you have any questions please feel free to contact me ✨