Sorry, I knew I forgot to answer something... Let's make sure we agree on the problem. AIUI, the problem is that if you have:
<body style="width:800px;height:600px"> <div style="width:200px;height:100px" /> </body> And the div is 200x100 because it had come custom layout that didn't allow for use of just plain percentage or FlexBox, how can the div know if the body changes size due to a browser resize? IIRC, there are no change events to watch on the parent elements. So in the original concept of FlexJS/Royale, for PAYG reasons, the layouts weren't going to hook up a listener to every child's width/height getters "just-in-case" that child changed size and even more important, just-in-case that child size change might require another layout. It was up to the user to hookup a watcher for the right event on the right child/parent. That's Basic and PAYG. Most folks will hopefully use browser CSS display styles and will automatically get reflow. For the hopefully few custom layouts, the user can use a LayoutChangeNotifier or something like it to listen for the specific thing they care about (resize on the body or load from a child image) and trigger a re-layout in the few layouts that need it. In Basic, automatically making that happen is not PAYG and thus not a requirement in Basic. The emulation components are probably going to all cache values and propagate changes downward just like Flex did. Again, all we do is encapsulate common patterns. If someone needs custom layout logic in a non-Royale JS app, they also probably hook up to the resize event on the body. My 2 cents, -Alex On 3/26/18, 10:27 AM, "Harbs" <harbs.li...@gmail.com> wrote: >I agree with all of this too (mostly). > >I’m going to to repeat my question for the third time: How can we >structure things so layout can know whether their parent layouts are >“manual children-sized layouts” which need to have resize events and >which have parent layouts which don’t need these events? > >This is the key point here which we need to find the right answer to. I >don’t have the answer to this myself. We need some brainstorming to come >up with the right solution to this problem. > >Harbs > >> On Mar 26, 2018, at 8:18 PM, Alex Harui <aha...@adobe.com.INVALID> >>wrote: >> >> I feel like several independent factors are being mixed together. I >>think >> it is better to address them separately. >> >> Also, IMO, there are two kinds of layout in Royale. One group of >>layouts >> just lets the browser do the layout, like VerticalLayout, >>HorizontalLayout >> and the Layouts that use FlexBox. The other group of layouts tries to >>run >> code to solve layout issues that browsers don't make easy or to emulate >> Apache Flex behavior. This is things like VerticalColumnLayout, >> VerticalLayoutWithPaddingAndGap, and the FlexibleChild layouts, and some >> custom layouts like NumericStepper and the ProductsView layout in >> RoyaleStore example. >> >> When we first started out on FlexJS/Royale six years ago, the only >>browser >> layouts I knew about were setting the display style to "blocK" or >> "inline-block" to get vertical or horizontal layout. So we used it >>where >> we could and wrote other custom layouts to handle other cases in the >> second group. Over time, new display styles have emerged as useful and >> stable. Mainly display="flex" a couple of years ago and now/soon >> display="grid". Slowly but surely, the browsers are solving the pain >> points folks used to workaround. >> >> I agree with Carlos that we really want the browser to run its layout >>code >> instead of us running our layout code where possible. >
