Famous / famous-angular

Bring structure to your Famo.us apps with the power of AngularJS. Famo.us/Angular integrates seamlessly with existing Angular and Famo.us apps.
https://famo.us/angular
Mozilla Public License 2.0
1.92k stars 275 forks source link

fa-scroll-view doesn't appear to support 'true' sizing of elements #239

Closed steveblue closed 7 years ago

steveblue commented 9 years ago

famo.us 0.3.0 has the following in the changelog: Scrollview can now handle "true" sized elements

Although this behavior doesn't seem to be working in famo.us / angular. When I set the size of sequenced fa-view encapsulating fa-surface to [undefined,true] the scrollview doesn't get the correct height and it collapses the fa-views on top of one another. When I give the views a height value that is a number the views are sequenced just fine.

Looking further into this, when the fa-size of a surface is modified with true the deployed surface doesn't have the 'height' set.

pasine commented 9 years ago

I have the same problem.

joemusashi commented 9 years ago

Same here.

stukennedy commented 9 years ago

same problem here @steveblue can you explain how you worked around this? I didn't understand your setting height value explanation.

steveblue commented 9 years ago

@continuata 'true' sizing works as prescribed outside of a layout, but is broken in scrollview and possibly other layouts. Basically, the issue as I inspected it was the child .fa-surface of a doesn't have width and height set to auto by default, which enables the true sizing to work. These elements also aren't reporting their clientHeight correctly to the Scrollview, which has a method on it to calculate height. Possibly F/A still needs to track some changes in the Scrollview made in famous 0.3.

I set up a service in our web app that all fa-surface can reference as a temporary solution until this is fixed. What the service does is set the size on the fa-surface using the clientHeight of the child .fa-surface element. Size all famous elements recalculate size on resize, this fix works even after $compile. Here is the stackoverflow: http://stackoverflow.com/questions/26445552/scroll-view-not-scrolling-with-surface-fa-size-undefined-true/26534407?noredirect=1#comment41718130_26534407

stukennedy commented 9 years ago

@steveblue thanks Steve, setting fa-size explicitly on the surface seemed to do the trick for me

steveblue commented 9 years ago

I'm stuck again on this issue, trying to make a horizontal scrollview with images of varied widths. The fix I came up with previously doesn't work in the context I am now working in. @zackbrown it would be really nice if true sizing just worked.

zackbrown commented 9 years ago

Hey Steve—I just checked with the platform team on this. It does not look like this is an F/A issue, but rather that the size value true on a View does not do what you're expecting here. It does not compute the bounding size of its children. From what I gather, that change log entry could have been written more precisely as "Scrollview can now handle "true" sized Surfaces".

If you're working with individual Surfaces as children, you should be able to just expose that Surface directly as the Scrollview's child. If you're working with something more complex, e.g. multiple Surfaces inside of a view, it sounds like you're going to have to do some calculations/math to handle sizing. I'd also recommend sticking with using sizes on Modifiers instead of Views (the size property of a View is quite a bit less robust than the size property of a Modifier.)

steveblue commented 9 years ago

I would think eliminating views from being sequenced inside a scrollview is an anti-pattern that doesn't allow elements to be ordered inside the scrollview using fa-index. This is a handicap. We overcame this issue by implementing a service that calculates the size of the scroller. This ideally would happen automatically, possibly through a F/A provider. Here is a link to the fix: http://stackoverflow.com/questions/26445552/scroll-view-not-scrolling-with-surface-fa-size-undefined-true/26534407#26534407

DSRoden commented 9 years ago

Hi, I think I have a related issue and was hoping to get some clarity on what's going on here if anyone has a moment, thanks in advance. I'm using famo.us/angular for the first time, so sorry if the code is novice.

The task: I am trying to implement an fa-scroll-view that repeats on an array of views. Each view has one image property and one text property. not all images are the same size

The problem: Images and text are rendered ok, but when scrolling to the bottom the surfaces can be scrolled completely out of view, and if they are they cannot be retrieved without a page refresh. I have tried to prevent this by giving fa-view that contains all the surfaces an fa-size. However, I'm finding it difficult to add a dynamic height value, one that will adjust to the size of the surfaces in the ng-repeat. Am I approaching this incorrectly. Can anyone suggest a way to prevent surfaces from scrolling out of view and becoming irretrievable?

fa-app(ng-controller='HomeCtrl') fa-scroll-view#main-scrollview(fa-pipe-from='myEventHandler' fa-options='options.container') fa-view(fa-size='[getPageWidth(), <how to get the height of all the surfaces dynamically?>]) fa-modifier(ng-repeat='view in views track by $index' fa-size='[getPageWidth(), null]') fa-image-surface.relative-image(fa-image-url="{{view.image}}" fa-pipe-to='myEventHandler') fa-surface.relative-text(fa-size='[getPageWidth(), 100]' fa-pipe-to='myEventHandler') .content(ng-if="view.text") {{view.text}}

Thanks again!