Dodge HaxeFoundation/Haxe#11338 by also looking at imported types

[kLabz]

See HaxeFoundation/haxe#11338

[yuxiaomao]

Seems good now for Shiro's projects.

[kLabz]

What is the minimum Haxe version supported by domkit? This PR uses a Haxe 4.3.0 feature (?? operator)

[ncannasse]

Can you tell me which cases this is trying to solve ? It seems a bit overly complex.

[Simn]

The problem is that domkit abused HaxeFoundation/haxe#9150 by importing some.ComponentCollection to make its types available as some.Component. This no longer works after HaxeFoundation/haxe#11338, so a different solution is needed.

[kLabz]

There are more subtlety that I need to list and detail after reconstructing the failing cases (the ones from when I opened this PR but also the ones I found later that this PR didn't fix).

[kLabz]

Can repro the initial issue with dune:

 ERROR  src/ui/GameUI.hx:58: characters 4-21

 58 |   <spectator-top-bar/>
    |    ^^^^^^^^^^^^^^^^^
    | Could not load component 'spectator-top-bar'

Init macros add this as components path:

domkit.Macros.registerComponentsPath("ui.hud.$UI");

Module src/ui/hud/SpectatorUI.hx also defines component SpectatorTopBarUI which we want to resolve here. This used to work because there is import ui.hud.SpectatorUI in GameUI.hx, so SpectatorUI module is loaded and SpectatorTopBarUI could be resolved through ui.hud.SpectatorTopBarUI.

We cannot resolve ui.hud.SpectatorTopBarUI directly anymore, but SpectatorTopBarUI is available locally thanks to the import. This is what Context.resolveComplexType handles here (it also compares packages to be sure this is not resolving some unrelated component that would have the same name).

---

There is also this case:

domkit.Macros.registerComponentsPath("h2d.domkit.BaseComponents.$Comp");

For which I added the name vs sub handling.

---

As to why I replaced Context.getType(path) with Context.resolveType(TPath(tpath), pos); there.. I'm not sure anymore tbh, my current guess is that it's mostly a remnant of the early stages of that PR, where I was manipulating a type path instead of a string. I think the two actual differences there are ParamSpawnMonos vs ParamNormal and exceptions being String vs Dynamic (but it was already catching Dynamic anyway) edit: that part of the docs seems wrong.

[kLabz]

If we don't care about checking packages there (should be very niche issue, but still technically possible), this can be reduced to:

var path = p.split("$").join(uname);
// Note: might be nice to expose such a tool (dotpath => type path) in our macro API, if that's not already available..
var tpath = {pack: [], name: "", sub: null};
for (p in path.split(".")) {
	if (p.charCodeAt(0) >= 'a'.code && p.charCodeAt(0) <= 'z'.code) {
		tpath.pack.push(p);
	} else {
		if (tpath.name == "") tpath.name = p;
		else if (tpath.sub == null) tpath.sub = p;
	}
}

var t = try {
	Context.getType(path);
} catch(e:Dynamic) {
	try Context.getType(tpath.sub ?? tpath.name) catch(e:Dynamic) continue;
}

[ncannasse]

@kLabz thanks for the description of the issue in relation to the actual code involved.
However I think this should be resolved by having "$" component path registered so when we have an import we can load its components using the name itself. In that case we wouldn't need to change the domkit code at all ?
Can you confirm that @yuxiaomao ?

[kLabz]

That wouldn't work here either because $ would resolve to SpectatorTopBar, not SpectatorTopBarUI

[ncannasse]

Yeah I meant "$UI" Le sam. 18 janv. 2025, 13:24, Rudy Ges ***@***.***> a écrit :

…

That wouldn't work here either because $ would resolve to SpectatorTopBar, not SpectatorTopBarUI — Reply to this email directly, view it on GitHub <#62 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHZXQHTJ4MNRONVBI3TFU32LJBWZAVCNFSM6AAAAABS5MNWY6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJZGY4TKOJQGU> . You are receiving this because you commented.Message ID: ***@***.***>

[kLabz]

Seems to work indeed for dune 👍