HaxeUI v1.5 Released!


Heres my “every 6 months haxeui release cross post”, enjoy! :slight_smile:



Hey Ian,

This looks awesome, I may need to take another look at HaxeUI.

I’ve got two thoughts though:

  1. The payload of the examples page is pretty enormous and could benefit from some kind of lazy loading.
  2. The scrollbars feel very odd. I’m not quite sure what is going on here, but are you programmatically handling the scroll instead of allowing the browser to handle it?

New release and he snags a wife to boot. Good job and congrats!

Yeah, ive got some idea about splitting it up in the “views” and only loading them (as semi self contained .js files), but ill need to have a play with it… the idea should also work for other haxe targets (like cppia for example)… Ive run some tests and i can defo load things externally, just just little bits of code. Ill need haxeui externs to give the tires a real nice kick (externs which dont exist yet, so ill need to generate them).

So yeah, scrollviews are essentially handled internally by haxeui, this is the nature of the composite views. Any chance you can expand on what feels wrong about them? (feel free to move this to the haxeui community or the haxeui channel on the haxe discord :slight_smile: )


It looks like the DOM is being treated as a drawing surface of sorts and all positioning is being done programmatically with Javascript. What triggers the handleSize, handlePosition, and handleClipRect functions? Is it the process() function in ValidationManager?

Are there docs on the lifecycle of a component?

Essentially, yeah, so you mark a component as invalid, in various ways, layouts for example might changes it size, etc. This add its to the invalidation queue, this queue gets processed every frame if its not empty (via CallLater, which is requestAnimationFrame on html5), this calls validate on the various invalid components, these components, eventually end up calling handlSize for example, which lives in the backend.

1 Like