Rebuild / Bind

[heapsio]

Rebuild / Bind

[rcstuber]

What's the status of this? I see there is an implementation for @rebuild, but @bind logic is still missing. Any suggestions how to handle data-binding with DomKit?

EDIT: I'm currently working on an implementation for @Bind, which supports both component-centric "global" binding as well as binding to single members of data-models within assignments, which expose themselves as "bind-functions" in that they accept a callback of signature Void->Void – for triggering a rebuild – and return the members current value immediately. I'm evaluating possible edge cases before opening a PR for discussion

[ncannasse]

Sorry for the answer delay ;)
You're correct that @rebuild is correctly implemented and @bind is not.

The code I'm using @rebuild is the following:

@:uiInitFunction(rebuild) @:uiNoComponent
class BaseComponent extends h2d.Object {
	var bindList : Array<Void->Void> = [];

	function registerCheckRebuild<T>( f : Void -> T ) : T {
		var value = f();
		registerBind(() -> {
			var value2 = f();
			var arr2 = Std.downcast((value2:Dynamic),Array);
			if( arr2 != null ) {
				var arr1 = Std.downcast((value:Dynamic),Array);
				if( arr1 == null || arr1.length != arr2.length ) {
					rebuild();
					return;
				}
				for( i in 0...arr1.length )
					if( arr1[i] != arr2[i] ) {
						rebuild();
						return;
					}
			} else {
				if( value != value2 ) {
					rebuild();
					return;
				}
			}
		});
		return value;
	}

	function registerBind( f : Void -> Void ) {
		bindList.push(f);
		f();
	}

	override function sync(ctx) {
		var cur = bindList;
		for( f in cur ) {
			f();
			if( bindList != cur ) {
				dom.applyStyle(ui.style, true);
				break; // was rebuilt
			}
		}
		super.sync(ctx);
	}

	public function rebuild() {
		bindList = [];
		removeChildren();
        }
}

The idea is that each app/framework can decide itself what it means by "data has been modified and needs rebuild", thus not requiring domkit to make strong assumptions on specific things.

[rcstuber]

Thanks, finally I get a clearer picture of how this should work. I see a few issues with this for my use-case though:

• Requires polling for changes, potentially checking a lot of unnecessary expressions before finding a change
• Rebuilds the entire component, even if only parts of it require changes
• Re-renders entire lists if items get added/removed, potentially causing flickering or lag

Please have a look at my PR for @bind logic (#31). It allows for expressions to only re-evaluate if a variable's value within it has changed, being more of an event-driven solution. I made it so that it also makes no assumptions of how the actual binding looks like and thus is very data-layer agnostic.

Maybe something similar could be added for binding if-conditions & for-loops; along-side the current approach that is.

[ncannasse]

• Polling : sure, but I'm not sure how we can do that without polling
• Entire rebuild : please note that it's only the case for @rebuild, and this should only be used when you have an if or for loop in domkit that changes its content
• there should not be any flickering, and we do use rebuilds in our games without perceptive lag

[rcstuber]

• Polling : sure, but I'm not sure how we can do that without polling

Could be done like my @bind implementation, where if parts of an expression change the entire expression is re-evaluated (event-driven)

• Entire rebuild : please note that it's only the case for @rebuild, and this should only be used when you have an if or for loop in domkit that changes its content

Yes, I understand that only @rebuild annotated expressions are affected, but a component may have several of those and the entire component gets rebuild if any of those change, because there is no reference as to which sub-tree the expression refers to

• there should not be any flickering, and we do use rebuilds in our games without perceptive lag

I have some lists where the dom.active property (and styling) gets lost if an entire list gets re-rendered if any element changes

I saw that the UI in Northgard and Darksburg are looking fine ;-) But UI in my game is currently a flickering nightmare due to the lack of data-binding and minimalistic updates, because I have a lot going on in terms of realtime data

[ncannasse]

I added @Bind support