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
http://about.me/carlosrovira
