flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ent <p...@adobe.com>
Subject Re: [FlexJS] About Component Cycle and Events
Date Wed, 14 Dec 2016 15:16:29 GMT
My experience with bead-writing is that if your bead has no dependencies
on other beads, then doing your set up in the strand-setting is the
easiest. 

If your bead needs to know another bead exists, typically a view bead,
then in the strand-setter, ask for that bead using strand.getBeadByType().
If it comes back, then you are good to proceed, but if you get null, then
set up an event listener for viewChanged (or whatever event makes sense
for you). Then in the deferred setup, continue as you would now that the
bead you seek is present.

You don't know - or should not assume to know - the order beads are added
to their strand. For that reason, I think beads should do as much as
possible in their strand-settings and if there are dependencies, wait for
all the beads to be added and then complete the set up.

The other tricky part, especially for view beads, is to know when the size
of anything is true. For the JS side, this is known earlier, just after an
element is displayed; it might not be the final size, but you should have
a valid size. The SWF side is often 0x0 until a couple of rendering passes.

For this reason, setting up a sizeChanged event listener is important in
view beads and in that function you can lay out component elements in the
strand's space.

Its not 100% perfect yet, but its getting there.

‹peter

On 12/13/16, 6:32 PM, "Alex Harui" <aharui@adobe.com> wrote:

>
>
>On 12/13/16, 1:14 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
><carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
>wrote:
>
>>Hi Alex,
>>
>>I'm trying to get a mental picture of the overall structure, events and
>>when to expect to have data.
>>As you see, my problem with data was in item renderers. I see I have
>>available in set data method (overriding it).
>>Maybe in others components I don't have problem right now.
>
>You can override set data(), or in MXMLItemRenderer there is now a
>dataChange event.  The override is more efficient, but dataChange might be
>easier to work with.
>
>IMO, there will be fewer events because we don't have to stop to let the
>player render.  Events were important in asynchronous code, but in the
>browser, you can just run code that updates the UI and it generally
>happens immediately.
>
>The LifeCycle is much simpler:  Instantiate, (optionally set properties),
>addChild.  On addChild, lots of things happen in the child's
>addedToParent: some default beads get placed on the strand, the element is
>placed in the DOM causing styles to be rendered by the browser.  But then
>the component should be done, and some components send out an initComplete
>event.
>
>>
>>Another scenario I'm dealing with are beads, it seems we can do all
>>things
>>in set strand method, but not in getter/setters. the next step in MDL
>>library, now that we have the right HTML structure created, is check that
>>events and changes are working right. This right now is not true in the
>>global set, and would be the next thing to do. For example, the click in
>>buttons is working, but as we see the slider was not dispatching the
>>valueChanged event (then Peter fixed it in HTML and as I have some time
>>I'll come back to MDL slider).
>
>Beads have a different lifecycle, but it is similar:  Instantiate,
>(optionally set properties), addBead.  On addBead, the strand setter is
>called, that's a good time to do most work because the host strand should
>be in the DOM at that point.
>
>If that's not a good time, then you have to listen for some events.  There
>might be more events needed, but we aren't dispatching very many
>"just-in-case" events.  Again, in PAYG, you should be able to replace any
>instance with an instance that dispatches a useful event.
>
>HTH,
>-Alex
>


Mime
View raw message