Hi Carlos, The binding system in Flex and Royale has always relied on caught exceptions, so when debugging you often have to turn off "Pause on caught exceptions" which can make things challenging if you are trying to catch some other caught exception. It would be an interesting question to see the cost of adding null checks in all binding generated code. The null check might be faster than the catch.
There are always times when binding works despite the compiler warning. The warning is just saying there is at least one scenario where your binding won't work right and if you don't encounter that scenario you are fine. But it will be true in Royale JS output that there are more scenarios where it won't work than in SWF. -Alex On 12/13/18, 1:33 AM, "Carlos Rovira" <[email protected]> wrote: Hi Alex El jue., 13 dic. 2018 a las 2:00, Alex Harui (<[email protected]>) escribió: > > 1) What error do you get with null/undefined in renderers? Really, the error doesn't show clearly on browsers. I could see that in Google Chrome going to Sources and in the right panel check "Pause on caught exceptions" I fixed this in Tour De Jewel (JewelExample), so to see that again you can go to NavigationIconLinkItemRenderer.mxml And in the bindings remove: <js:FontIcon text="{navlink ? navlink.icon : ''}" material="true" visible="{navlink ? navlink.icon != null : false}"/> <html:Span text="{navlink ? navlink.label : ''}"/> remove the ternaries and left as it should be Running that in the old state and checking the before mentioned option in chrome will make Tour de Jewel stops at the beginning as each renderer is instantiated and throwing an error. The binding subsystem should have try/catch blocks in the appropriate > places. Maybe we are missing something, or maybe there is a bug, or maybe > there is such a huge cost to automatically protecting against > null/undefined that it is worth folks being a bit more careful about that > in Royale. In the case above, I'm taking care, but IMHO, from a user point of view, I should not have to write a safeguard in each binding. If that's is always required *always*, it seems frameworks responsibility, saving lots of safeguards in users code. This seems to me more PAYG. > Flex did try to evaluate binding expression often whereas Royale will > apply binding at different times to improve performance. Item renderers > are a classic example. In Flex, bindings were evaluated twice before the > data property ever set and a third time when the data finally got set. In > Royale, if you use ItemRendererDataBinding, it only gets evaluated once. > So dig into this a bit more and show us the stack trace (assuming that's > the issue). > Yes, I think is the right way to go, don't thing this issue is a problem with the how many times Royale should check the data, but just how to deal with nulls/undefined. > > 2) There is no limitation in Royale on the maximum level of nested > bindings, but you are probably right that things might work in Flex that > don't work in Royale, again because Flex evaluated binding expressions > quite often, which we don't want to do in Royale for performance reasons. > However, in Flex, and Royale, there is always a chance that you could > change something deep "too late" and then it wouldn't work. But if you > have your change events propagating properly, you can bind to any level in > Royale. If you have a failure case let's take a look at that as well. The > compiler should be telling you that it can't bind to something. > > That's right, I though it was a nested limitation. Knowing is not that is a huge help. I can check in other ways. I'll be warned when I get the next binding issue and we can check it. In the other hand, I remember to see few days ago some bugs in bindings, I think was the compiler warn about a binding that could not be done, but was working, or something like that. Can't remember right now. Again I'll be alert and report here where I find something similar. I think there's still some final little bugs to address in bindings, Maybe Greg could give us more detail on this, if he has some time. I think we're a month to work hard in our app to finish, so maybe at the middle of January we can share more here about our experience and what things we found through our journey so we can think fixes to that -- Carlos Rovira https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc154f8b23bda4728346108d660de072c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802904085592501&sdata=LCQ%2Fd%2BGtT86gyV0qw7Ptfge8LSzvweGudkf%2Bz2AgnLA%3D&reserved=0
