Can you suggest me when to use states and when to use custom components? The advantages and disadvantages of using these too methods?
One problem I see using states in Flex 4.5 is, the includeIn property will be cumbersome if there are many states and needs to be set for individual container/controllers.
Thanks
Anji
Doesn't the use of states groups solve your problem and clarify all the combersome mess?
States and customs components are not hostile alternatives. They can be used together. It is not very clear form your questions what exact kind of components do you mean and why they solve includeIn problem.
You can refer to ActionScript and MXML visual classes as visual components. And one of the purposes of producing of such components is to reduce complexity. So if you have very complex states logic in some visual component (in MXML) it is very good to extract some subcomponents with corresponding states into separate components. These extracted components can be MXML components and can contain states with includeIn/excludeFrom logic. Or they can be ActionScript components with skin states.
States and extracting components can live together easily. One of developer's main goals is to reduce complexity. And common sense is the best weapon to do that.
Related
It seems that a standard has been built around theming in Polymer 1.0. For example, all paper elements use CSS variables such as --default-primary-color and --primary-background-color. Ideally all custom material design components should follow this standard, but I'm having trouble finding any reference for it other than the individual elements themselves. Is there any reference out there?
I think what you're after is the paper-styles "component", which all of the paper elements use for their design, typography, colors, etc.
https://github.com/PolymerElements/paper-styles
It should provide a pretty good example of how to organize a multi-component styling architecture.
Oh, I may have misunderstood your question. It seems like what you're looking for is a standard method for styling a myriad of existing components which you've imported into an application or site.
Unfortunately this is up to each component author to develop and provide themselves. In many Polymer tutorials they recommend exporting such things as --my-component-header or --my-component-button to make this easier, but if they are not provided then you will have to rely on /deep/, which I think is getting replaced in upcoming standards updates.
Edit: A simpler phrasing of this question would be...
Can't I build a full fledged enyo app with readable code while only using Controls to take the place of Components, Kinds, Models, and Collections?
..
I'm learning EnyoJS and I have yet to find a clear comparison between Components, Kinds, Controls, Collections, and Models.
I understand that for example a Control is a Component that by convention refers to a visible DOM element that the user interacts with directly...but so many of these differences among the aforementioned types seem to be by convention rather than enforced by the framework. It seems that any given idea can be expressed as a Component or a Collection or a Model or...
Can you clearly explain the API differences between these types?
Can you show how certain functionality is truly missing from any one of them but present in another?
Wow. That's a big question.
With regards to controls and components, it's not just convention that differentiates the two. Controls are an Enyo Kind that inherits from the Component Enyo Kind. Controls actually contain methods and properties (specifically for dealing with the DOM) that just don't exist in Components. They're not interchangeable.
The documentation on the Enyo web site does a very good job of explaining the difference between Kinds, Components and Controls.
http://enyojs.com/docs/2.4.0/
There's also the API reference, which breaks out for you the various properties, so you can see for yourself all of the properties that exist (and don't exist) in Kinds, Components and Controls.
http://enyojs.com/docs/2.4.0/api.html#enyo.Control
And finally, since Enyo is open source, you can look at the actual source code to see the differences.
Collections and Models are fairly new to Enyo, starting with Enyo 2.4. Their job is to hold data (A Collection is a group of one or more instances of a Model). Models usually contain JavaScript or Enyo Objects, not Components or Controls.
Components make up the skeleton of your app, Controls are the UI for your app and Models contain the data for your app.
Expanding a bit on Art's answer: You can certainly build a fully functional and maintainable app without Models and Collections. Those kinds help with the data binding infrastructure in version 2.4. If you don't wish to use those features, you can build on version 2.2 and only use Controls and its subkinds (e.g. enyo.Input).
Regarding Components, you could easily build an enyo without creating your own Component but you can't avoid using them because it's part of Control's prototype hierarchy. As Art said, the difference between Component and Control is more than convention. The Component kind facilitates the composition of instances of components. Control extends that to support rendering into the DOM and its containment hierarchy. See post from my Enyo Daily series for some (slightly dated) details.
More concretely, if you don't need to render anything into the DOM but you want to encapsulate some logic into something module-like, use Component. If you need a DOM node, use Control or one of its derivatives.
I think I'm overusing the Flex states model. The way the Spark architecture teaches it, states should mainly be used for changing the visual appearance of a certain component. However, being overly excited about the simplicity of using Flex states, and also willing to reuse existing object instances at runtime, I made my components really "thick", injecting different view models, as well as other stuff, based on a certain state change. This created a bunch of problems with synchronization, so I decided to subclass and specialize instead of relying on states that much.
In general, as a rule of thumb, where should the boundary between states and subclassing be put?
Well, from what I understand, you have a huge view that you now want to use inheritance to split it up? Won't that still make your component heavy and hard to manage?
The better solution here is to use composition, not inheritance. Create new, self-managing and small components that come as a whole into a larger one. There really shouldn't be a 'boundary between states and subclassing' because they do 2 completely different things. One is for view based changes while the other is to add functionality.
I think you're just really mixing up your OOP concepts and should really stop what you're doing and go over the theory a bit before continuing. If you continue on your current path, you'll end up where you're heading; spaghetti code.
is there a standard rule or best practice which dictates when a custom class/library should be a used/distributed as a component or remain simply as a class/library?
what's the definition of a component?
I often use component as synonymous with "Class". Any class is a component.
Many people refer to components, specifically, as UI Components. In the context of Flex, this is probably any component that extends UIComponent.
You should put a component it in a separate class library if you want to use the component across multiple projects. Or when you want to distribute the component to other developers independent of an application.
In some cases, you may consider using components for parallel development purposes, so that two developers can build different pieces of the same application in isolation of each other.
I have a project where we are trying to skin Spark components from a third party library that are built up from the drawing API primitives. Our first attempt involved creating a Flex skin (SWC) in Illustrator/Flash and applying that skin to the Spark components via CSS. We found that even with only a single instance of one of the components skinned in this way on stage, the application was brought to it's knees. For example, it failed to respond in repaint scenarios in a timely manner, and exhibited all the symptoms of being hung.
Our next approach will be to recreate the same skin artifacts in MXML classes that are in turn associated with the third-party components. Although the complexity of some of the skins leads me to believe that we might not avoid performance problems with this approach either.
My question is the following: Is there a correct or recommended way to apply either a SWC or based skin to a component that is built up from the Spark drawing API to begin with? Even as I ask the question I recognize that the approach means using the Spark drawing API in two places and will probably have unexpected consequences.
I've had good luck building the skins using MXML skin classes that inherit from s:Skin in terms of rendering performance. The recommended method (from Adobe) is to start by copying an existing skin file from the SDK and modifying the MXML to suit your needs. Regarding drawing, FXG works very well for defining how you want the skin to be drawn. FXG is XML based, so you don't need to write ActionScript to do your drawing, like we used to do for Flex 3 programmatic skins. You can also create skins using Adobe Catalyst. I have not used Catalyst, so I can't speak to its effectiveness, but many people seem to like it. Hope that helps.