getSize() from a RenderNode wrapped LayoutController

[gadicc]

This is just a question, I actually don't know famo.us as well as people assume :> In famous-views we wrap everything in RenderNodes, as it was the most consistently reliable pattern. From my experience until now, the RenderNode's getSize() method would always return the same result as the inner node's getSize().

This isn't the case with a RenderNode-wrapped LayoutController, at least when dealing with true-sized Surfaces. layoutController.getSize() returns e.g. [undefined, 2253] and the wrapping renderNode.getSize() returns [undefined, true]. So for my use case (a LayoutController inside a famo.us Scrollview, for now), I had to override this to be able to see the full LayoutController.

Any insight appreciated. Everything is working, but not sure if this was the best way to go about it.

[IjzerenHein]

I've put it on my todo list and get back to you when I have more time. Cheers.

[IjzerenHein]

You're right, LayoutController will not handle that situation correctly. I'm using some trickery inside LayoutController in order to detect whether true-size is used by the view/surface. Unfortunately this information is not properly accessible through the famo.us API. The only method that exists is 'getSize' and this function returns the calculated size if available, and otherwise it returns the configured size. So it basically it is inconsistent in its behaviour. Also, true-size support is poorly implemented in famo.us imho. There are lots of issues that I have ran into, and which I've been trying to workaround. A proper solution would require an API change, so that we can get the configured size from a renderable. If we would have that, then I'd be able to get the configured size (and detect whether true-size is used) all the way through any render-nodes.

[IjzerenHein]

Hey dude. Just a heads up on this topic. I've just added a recursive algorithm which detects true-size Surfaces (and LayoutControllers) wrapped inside RenderNodes. I think this will solve the problem you described. It's currently on the master branch, I'll be releasing it into a new release shortly. Cheers

[gadicc]

@IjzerenHein, thanks for the heads up! Might be a while before I'm actually working on this part again, but that sounds awesome! Good luck to both of us with the new API next week :> P.S. Also unrelated, but I finally did the TabBar wrapper, you can see how it looks in markup/meteor at http://fview-flex.meteor.com/TabBar.

[IjzerenHein]

Wow dude, that is pretty sweet! It even works when you press the back button, niceeee!

Btw, have you seen the new TabBarController: https://github.com/IjzerenHein/famous-flex-tabbarcontroller

cheers

[IjzerenHein]

Hey dude! Hi, I've just released a new version 0.3.3 which should fix the wrapped rendernode issue. Let me know if this resolves the problem, and this issue can be closed. cheers, Hein

[gadicc]

Hey, thanks! I haven't had a chance to look yet but it is on my list... will update accordingly.

And sorry, I had seen the TabBarController... took a while to decide at what level to aim the Meteor integration and eventually decided to go a little lower level so people could tweak as needed on the Meteor side. But didn't rule out doing both if time allowed.

I guess I should note that I'm focused almost exclusively on mixed mode stuff now though.

And yeah, the back button, that's all automatic since we used a router package :) 2015 is the year you get into Meteor!

[IjzerenHein]

Awesome dude, can't wait to see it in action on Meteor :D Do you have any links?

Yeah, same here, I'm focusing on mixed mode as well for new developments. I'm waiting on the famous-platform and BEST before starting the port to mixed-mode for flex. Perhaps it would be a good idea to do some brainstorming together when that moment comes, to see how the components can fit into meteor in the best possible way.