[UI/UX] Replace native dialogs

[BrettCleary]

This refactors native error and message dialog boxes into modals.

The GlobalState ContextProvider now has showDialogModal and dialogModalOptions. Any frontend component can call showDialogModal to show a dialog. This is achieved with the DialogHandler component which uses dialogModalOptions to determine what dialog to show. The DialogHanlder also listens for dialogs that the backend requests to show.

Before:

After:

---

Use the following Checklist if you have changed something on the Backend or Frontend:

• Tested the feature and it's working on a current and clean install.
• Tested the main App features and they are still working on a current and clean install. (Login, Install, Play, Uninstall, Move games, etc.)
• Created / Updated Tests (If necessary)
• Created / Updated documentation (If necessary)

[flavioislima]

so far is looking pretty good, just a few comments on the current state on Linux:
You can see on the video below that when uninstalling a windows game on linux it shows the uninstall dialog without the checkbox to delete the prefix and then the checkbox appears. So maybe we could delay the checkbox first or check if it is not a native game and is linux, then show the checkbox by default.

simplescreenrecorder-2022-10-11_14.24.53.mp4

And after clicking uninstall the dialog doesn't close until the action is complete, which makes Heroic hang for a few seconds. So perhaps adding or an indicator that the operation is ongoing or closing the dialog without waiting for the promise to be fulfilled. Other than that looks cool 👍🏽

[Nocccer]

Looks really promising. I left some suggestions i find useful.
Even if we even not have a single error dialog with actions at the moment, maybe we need one in the future where we provide actions on a error dialog, which mostly comes from the backend.

[BrettCleary]

Looks really promising. I left some suggestions i find useful. Even if we even not have a single error dialog with actions at the moment, maybe we need one in the future where we provide actions on a error dialog, which mostly comes from the backend.

Thanks. Appreciate the comments. Really helpful.

Yeah. Honestly the ErrorDialog and MessageBoxModal components are both very similar codewise. I think I'll combine them and pass the DialogType enum as a prop. That way we can support actions on error dialogs and don't have to duplicate code.

[BrettCleary]

so far is looking pretty good, just a few comments on the current state on Linux: You can see on the video below that when uninstalling a windows game on linux it shows the uninstall dialog without the checkbox to delete the prefix and then the checkbox appears. So maybe we could delay the checkbox first or check if it is not a native game and is linux, then show the checkbox by default.

And after clicking uninstall the dialog doesn't close until the action is complete, which makes Heroic hang for a few seconds. So perhaps adding or an indicator that the operation is ongoing or closing the dialog without waiting for the promise to be fulfilled. Other than that looks cool 👍🏽

This is fixed now. Closes immediately. Also uses the context provider to get the platform instead of awaiting for it. Doesn't show the dialog until it checks this so no re-render now

[BrettCleary]

I am having an issue with absolute imports now though

[vite]: Rollup failed to resolve import "common/types" from "src/backend/main.ts".

Relative imports are working fine and it seems to only be common/types after I added a couple types to it.

[BrettCleary]

Okay so adding an enum in the common/types module breaks all the imports.

In troubleshooting this, I went deep into the rabbit hole regarding absolute imports and managed to get it working for the frontend and backend without the vite-tsconfig-paths plugin. Before, we could only use imports in the frontend.

The prefix alias is @@/ which maps to the src directory.

[BrettCleary]

This is working for me and tests are updated so I'll take it out of draft now

[BrettCleary]

I think we might be able to add backend common and frontend as aliases instead of @@ now too to keep the same style absolute imports everywhere. I'll test this

[flavioislima]

Testing here and now the Linux dialog for uninstalling looks good. Maybe just add a limit to the size of the dialogs in general, this one is huge, for instance:

[BrettCleary]

Testing here and now the Linux dialog for uninstalling looks good. Maybe just add a limit to the size of the dialogs in general, this one is huge, for instance:

done.

[flavioislima]

Looks great. Thanks for doing this ⚔️

Comments have been addressed

[biliesilva]

Testing here and now the Linux dialog for uninstalling looks good. Maybe just add a limit to the size of the dialogs in general, this one is huge, for instance:

done.

It's important to differentiate the buttons No and YES, because this can confuse the user. The button that has more importance has to be all filled with color. Also is better to reduce the size of the box as you said.

[flavioislima]

@biliesilva the size was fixed. But yes, that is a good point about the colors.
I think we will need to open a new Issue here on GH so we can fix that.

@BrettCleary
I think we can add a new prop to the dialog to choose which button is important or not.
Or maybe just highlight the first (or last) button by default with a different color.

[BrettCleary]

@biliesilva the size was fixed. But yes, that is a good point about the colors. I think we will need to open a new Issue here on GH so we can fix that.

@BrettCleary I think we can add a new prop to the dialog to choose which button is important or not. Or maybe just highlight the first (or last) button by default with a different color.

We can add a style enum or string type to the ButtonOptions type in src/common/types for buttonStyle and then have predefined css styles for each value applied in the DialogHandler component to the button