Error triggered before data-binding

General
1

Hi,

it looks like the data-binding sometimes happens “too late”, letting time for errors to be triggered. Let’s point out three different examples.

First example : I have a PageControl with a dynamic number of pages (depending on a JS object). Let’s say 3, named “page0”, “page1” and “page2”. And I want page1 to be the Active one at the beginning. The code would looks something like :

<PageControl Active="page1">
    <Each Items="pages">
        <Page ux:Name="{name}">
            ...
        </Page>
    </Each>
</PageControl>

which fails because “No node has name page1”.

Second example : I want an AddingAnimation to move an object of a distance determined by a JS variable, named “position”.

<Move Y="{position}" Duration="0.3" Easing="QuadraticInOut" />

Then the fuse preview command fails. I have to comment this line, launch fuse preview, then save again this file and wait for the live refresh.

Third example : This one doesn’t triggered an error and has an easy workaround, but it shows well how we have to be vigilant with databinding and espacially <Each/>. I want a header, a (dynamic) list of elements and a footer. This code :

<Header/>
<Each Items="elts">
    <Text Value="{title}"/>
</Each>
<Footer/>

will put the footer before my elements, cause the Footer element is added to the parent before Text elements are computed. (Of course wrapping the Each in a Panel fixes it, not a real problem this time).

How can I fix this (espacially example 1 and 2) ?

Thanks :slight_smile:

2

Unfortunately I don’t have a solution for point 1 at the moment. You can instead bind to a JS value Active={activePage} but this will still not have the correct order and may end up not switching. I’m adding an issue to find a way to get this done.

For point 2 I thought we had an example of doing such a thing… I’m looking for it now.

Using a wrapping panel is the correct approach now for point3. We have a pending feature request that will provide better ordering options in the future. the reason it happen is because Each is a behaviour, and all children added by the behaviour just get added to the end of the list.

3

We appear to have some issues doing the binding X="{pos}" as well. I’ve added an issue for that.

In the meantime I’ve come up with a kind of wonky workaround:

<Panel>
    <Text Alignment="Left" Value="{name}"/>
    <Panel Width="{position}" ux:Name="Dummy"/>
    <AddingAnimation>
        <Move X="1" RelativeTo="Size" RelativeNode="Dummy" Duration="0.3"/>
    </AddingAnimation>
</Panel>

This creates a panel (with no visuals) that has the width of the desire offset. The AddingAnimation then moves relative to the size of that panel.

4

Thanks for this feedback and for this trick. The most annoying one is probably the first one. Glad to see you can reproduce the problem !

Good luck on this one :slight_smile:

5

I think if found the fix to the first problem :

  • We need to put Active="{firstPage}" (with firstPage = Observable('firstPage')), or it fails
  • We need to put <Page Name="firstPage"> in the <Each> and not <Page ux:Name="firstPage"> !

Not sure why yet, any explanation is welcomed :slight_smile: