Are flex items visible in real projects

I just learned about View States in Flex (v3.0), but I'm not entirely sure how widely this is used in real-world applications. Is this the right way to use it? Are there any pitfalls like maintainability, for example?

+2


source to share


3 answers


I started using states in my application (enterprise level) in different places and have refactored all of them since then. Much of my MXML has been replaced with pure AS3 components, and I'm skeptical about the binding and lifecycle of flexible components. There are many handy tricks in the Flex environment that start to feel cumbersome and slow when you actually start using them.



Like everyone else, your own mileage will be different. They can be helpful if you can avoid the β€œit all is a nail” syndrome. Maybe I couldn't.

+1


source


I've also used states in an enterprise-level application. But very easy.

States can be really helpful for cleaning up your code for some cases. There is a performance degradation if the state adds a child, the child will not be removed from the list until you return to that state and add a new child.



I think states can be useful if you need to enable / disable, make visible / invisible many components back and forth (depending on the state). This is the ideal use case for states in Flex.

+2


source


I used states heavily and found them to be a much more graceful solution with a lot of conditional code. Indeed, I initially avoided them for some of the reasons given above, but after the application got very complex with multiple "states" options, I realized that I was struggling with the framework.

To be honest, I would make the same remark about bindings. If you do not understand some of the subtleties, they can be your destruction, this is true. However, writing your own code to achieve the same seems to be a duplication of effort. Have a look at the generated code sometime and also read some of the good deep dives on bindings.

+2


source







All Articles