Page MenuHomeWildfire Games

[POC] Remove Engine.PopGuiPage
Needs ReviewPublic

Authored by phosit on May 20 2024, 12:46 PM.
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Summary

To easily reason about a program one should be able to treat a function like a blackbox: It only has access to the arguments. It completes with a return-value or an exception. -> Structured Programming.
But when the function calls Engine.PopGuiPage it doens't complete with a return-value or an exception but it shuts down the whole ScriptInterface / page. Don't get me started on Engine.SwitchGuiPage which is as powerfull as goto.

Whith structured code exception work again. Exceptions can propagate to the parrent page. Error can't be serialized but they should.

Sometimes the page want's to do something before closing itself. Composing the return value or save some data. Previously one would have to do that in every place Engine.PopGuiPage is called or one has to call an intermediate function.

The init function of the page has to return a Promise. (async functions implicitly return a Promise) When the Promise is settlet the page gets closed. The value (or the exception / reason) of the Promise get's propagated to the parrent page.
Some pages never "return to the parrent page" (like the main menue) so they can return a promise that never settles: new Promise(() => {});

The easy way to adapt woud be to pass the resolver to where it will be called (likely a onPress function). As I did in the lobby and summary.
The much nicer way would be to rewrite the whole page to be an async function. As I did with SavegameLoader and SavegameWriter.

Test Plan

The tests pass.

One can't switch from structree to civinfo.
Likely there are more defects.

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

phosit requested review of this revision.May 20 2024, 12:46 PM
phosit created this revision.
phosit edited the summary of this revision. (Show Details)May 20 2024, 12:55 PM
Stan added a subscriber: Stan.May 20 2024, 12:57 PM

Can we use enums rather than strings for "switch" and "close" ? Hardcoded string make it harder to track down things in case of refactor, and I suppose (it probably should be profiled that having a pointer to a string comparison, or better using an int is faster)

In D5271#224610, @Stan wrote:

Can we use enums rather than strings for "switch" and "close" ? Hardcoded string make it harder to track down things in case of refactor, and I suppose (it probably should be profiled that having a pointer to a string comparison, or better using an int is faster)

You mean in pregame_mp. Yes thous should be enums. We should care about such detail at a later stage.

First I want comments on:
Is this a direction we want to go for?
How could i split such a big diff?

phosit edited the summary of this revision. (Show Details)May 20 2024, 1:24 PM