I'm first going to answer Greg's question from the other thread since it is
probably wise to rename this thread.
Greg asked: "Am I right in interpreting what you say as being that there should
be more
event types for binding at the component level? (not just 'change', but
selectedIndexChanged, and selectedItemChanged as well?)"
I would say yes, as long as we are careful about PAYG. As with any change we
want to look at how much code gets added "just-in-case". What I mean by that
is that we don't want to go through the code and blindly add more change
events. Let's look at the actual implementation patterns:
-IMO, the "change" interaction event (or similarly named event) should be
dispatched by a Controller, not the model.
-A model is not required to dispatch change events. The simplest "dumbest"
model will take an array of strings that is not supplied "late" by a server and
thus the lifecycle can promise that the model is ready to go when the view
needs it, and will not change at runtime.
-Other models can change at runtime and should dispatch binding change events
if needed. By default, that would be "somePropertyChanged" (note that Flex
used "somePropertyChange", I personally don't care about the tense) but not all
properties must fire a uniquely named event. SelectedItem and SelectedIndex
are usually related so a single "selectionChange" event should be dispatched.
There may be other situations where a bunch of properties change and then there
is some final property change that "commits" it, and maybe only that property
needs to dispatch an event. We don't want to dispatch a ton of events
just-in-case if we can avoid it. Nor do we want to carry code around that
dispatches those events. The pattern of using hasEventListener can be used but
doesn't seem lightweight enough to be used everywhere. Because everything is
replaceable in Royale, if someone needs a model that dispatches more events,
they can always create such a model. We want to find the balance between
handling the right percentage of cases for the right amount of code. The Flex
philosophy was more about trying to handle nearly 100% of case by adding as
much code as we had time for. But that results in too much just-in-case code.
So that's where the code goes, but then you need [Bindable("eventName")]
metadata. The cost of Bindable metadata in JS is significant, but it all ends
up in a data structure that can be removed from the code by Closure Compiler.
But if it any code in a compilation needs the Metadata, then all of it is kept
in every class in the compilation. But if you already have one metadata on an
API, adding a second isn't much more expensive than adding that string to the
output. So I think it shouldn't be a huge impact to add both "selectionChange"
and "change" as metadata on an API.
OK, now to Carlos's questions:
1) What error do you get with null/undefined in renderers? 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. 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).
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.
HTH,
-Alex
On 12/12/18, 2:19 PM, "Carlos Rovira" <[email protected]> wrote:
Hi Alex,
regarding Binding Events, our experience is that is a bit more hard to work
with them in Royale than in Flex. The main issues we are experiencing are:
1.- In almost all renderers we need to check for null/undefined while in
flex is not needed:
text="{optionPack ? optionPack.description : ''}"
the getter in that renderer is
[Bindable(event="dataChange")]
public function get optionPack():Base7OptionPack
{
return data as Base7OptionPack;
}
migrated from Flex 100% equal
I expect to bind in the following way:
text="{optionPack.description}"
I think our user code will be more PAYG if renderers consider it self the
nulls/undefineds, instead to make users to make consider in almost any
binding.
2.- Level of nested bindings
I think the maximum level of nested properties accessed in a binding is
around 3.
So {foo.woo.zoo} can work but {foo.woo.zoo.noo} will not, while in flex
workd
I think that's the two main issue we see in this real world Apache Royale
project we are immerse now.
Thanks
El mié., 12 dic. 2018 a las 22:54, Alex Harui (<[email protected]>)
escribió:
> I may have missed something, and DispatchChangeOnStartup is a proper bead,
> especially for a first attempt, but theoretically, it shouldn't be needed.
>
> There are different categories of events in Flex and Royale. I'm not sure
> there is a complete list of categories, but ones that pop to mind are:
>
> 1) Low-level interaction events
> 2) Higher-level interaction events
> 3) Binding events.
>
> Things like mouseDown and mouseUp are low-level interaction events. CLICK
> and CHANGE are higher-level interaction events. They imply that some
> series of interactions occurred (CLICK= mouseDown+mouseUp). ITEM_CLICK is
> even higher level, it implies that a click occurred on an ItemRenderer and
> not, say, the scrollbar button in a List. Thus, writing code to dispatch
> CHANGE events outside of controller logic is roughly equivalent to faking
> mouse and keyboard events. Sometimes you gotta do it, but usually it
> implies that something else isn't quite right.
>
> Sometimes it helps to think about whether such a thing was needed in Flex
> and how similar setups worked there. It could be Royale is missing
> something, or something isn't quite right yet. In fact, the Royale
binding
> system is trying to be less aggressive and thus have less overhead than
> Flex, but theoretically, the flow of binding events should propagate
> properly to all concerned, so it would be interesting to really understand
> why such a thing was needed. Maybe something is truly only needed at
> startup, but often these things end up being needed elsewhere "later" like
> on state changes or module loads.
>
> The binding system in Royale can handle multiple events. Models are PAYG,
> so some models expect runtime changes and simpler ones don't to save on
> cost. But for models that expect runtime changes (required for any model
> representing asynchronous data loading), the binding events should
> propagate appropriately. Flex used (or maybe overused) VALUE_COMMIT
> events. We can do that, but right now the pattern is to make a unique
> event name. So selectedIndex should dispatch selectedIndexChanged no
> matter how it got changed and that should propagate through other
> bindings. When the dataProvider changes, if that affects the
> selectedIndex, then the model should set the selectedIndex and dispatch
> selectedIndexChanged. There shouldn't be a need to dispatch "change"
until
> someone interacts with the component. Differentiating between the two
> usually helps make setup code simpler. You can assign initial values to
> things without reacting everywhere to the change.
>
> Of course, I could be wrong.
> HTH,
> -Alex
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C845fdb43a0214bc4cce908d6607fda10%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802499588879997&sdata=vpjGbNp1WeCJ2gziDUrZRBWzRv%2FcKAvdlPUt5oPiwTk%3D&reserved=0
