One might think the quickest and easiest way to hide a Surface object in Famo.us is to set its opacity to transparent.
While true, you will also have to set its other properties like text color and such which is a hassle. Okay, so if you do not find that a hassle, there is another problem.
All input events like mouse clicks will be absorbed by this surface. So if you intentionally wanted to hide the Surface because the you want the other Surface below it to receive events, it will not work.
What I did was to make use of the Modifier that was used to add the Surface to the View. It has a setOrigin method that you can take advantage of to move this Surface object away from the user’s screen.
Say, setOrigin(0.5, 0.5) moves the Surface object to the center of the screen. You can do setOrigin(-0.5, -0.5) to move it out of the user’s screen making the user think that you actually hid the Surface object when in fact, you just moved it.
To show the Surface object back, just set the values to non-negative. That’s it!
So I was working with an array of ImageSurface that after doing a shuffle procedure, once displayed, the images of the ImageSurface overlapped incorrectly.
I mean, when I created each ImageSurface at startup and added them to the view, it displayed correctly, overlapping each other sequentially in the correct manner.
However, once that shuffle procedure happened the overlapping got messed up. I did not understand what was happening until I came across a post in the StackOverflow forum that said when you instantiate an ImageSurface, regardless if you had not added it to the context or view, it is automatically added in the rendering tree.
So if you do this:
And add these ImageSurface objects to a view like this:
The surface2 object will always be below surface1. So since my case had to do with shuffling the ImageSurface, the solution was to call the setOptions() method and set its z-index order like this:
In this example, surface2 will then always be on top of surface1.