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.
Related
I'm starting a new project with Meteor and I would like to use the --full architecture when creating the project: meteor create myApp --full
However, I don't really understand the purpose and differences of some folders in imports/ui/ :
components
layouts
pages
Especially the difference between layouts and pages. What type of code should they contain ?
It actually becomes clear as soon as you try to master React. However, its also very valuable to understand it in regards to Blaze.
Components
These are react components or blaze templates that are self-contained. This means that they are not bounded to anything else in the application. Meteor describes 2 types of components: Reusable and Smart. Reusable components are generic, reusable and don't contain any business logic. They receive their data via parent components.
Smart components typically don't contain too much UI related logics, but simply act as a layer between the data and the reusable components. These smart components contain business logic and push data to reusable components.
Layouts
Literally just layouts. The structure of your app's user interface is a layout. It should not contain any logics. Layouts contain mostly references to react smart components that in their turn load reusable components.
Pages
Same as layouts, but on a page level. Each page contains a layout and references components.
A better explanation can be found here:
https://guide.meteor.com/ui-ux.html
I am starting a developement of a big project and I need to know if to use ViewEncapsulation None or Emulated.
From some reason the default is Emulated but I noticed that Angualr2 Material uses None.
We need to have reusable widgets within the projects and have different styles and also dynamic themes.
I know it's can be done with Emulated but is seems more difficult to manage and not as simple as using CSS rules or override.
What should be the recommended mode for such a project?
The benefits of using 'Emulated' option is, that You will be able to create encapsulated components(styles, template, etc.). Also it will help You to not only create component once(dropdown, table, popup) and reuse it within your current project, but also it can be used in different projects later or being open-sourced, if You will.
The recommended way is using the Emulated option.
It will give you the ability to encapsulate your component, not only the HTML template, but also the styles.
This is the future. It is called web components and I strongly advise you to read about it. For more details, see:
Modular future web components
Shadow DOM strategies in Angular 2
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.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What are the downsides to using Spark over Halo in Flex?
What is the difference between Halo and Spark in Flex3 and Flex4?
A lot of other answers focus on the themes; and while Halo and Spark do have default themes; I think that is like saying comparing a Honda Civic to a Porsche and focusing on the tires.
The main difference between Spark and Halo really get at the underlying architecture used for building components. Halo is the Flex 2[and 3] architecture and has methods like createChildren(), commitProperties(), measure(), and updateDisplayList(). To build components, you will override these methods in your own component, which extends UIComponent somewhere in the class hierarchy. Sometimes this is called the MX Architecture.
In the Halo approach, all visual design and business logic were combined into the same class file. The Spark architecture is a new architecture introduced in Flex 4 that allows for greater flexibility when skinning and building components. It uses a two class system, with one class being the component class that will contain business logic and the other class being the skin class which will perform the visual display.
Spark components have a new parent component, named SkinnableComponent. SkinnableComponent actually extends UIComponent, so the original lifecycle methods are still there; but SkinnableComponent provides new hooks so we create components differently. Instead of overriding createChildren() we would override partAdded() or partRemoved(), for instance. All updateDisplayList() and measure() code is moved into the skin class as another example.
Additionally, there is a separate set of UI components for Halo and Spark. Spark components are known for being lighter and more flexible, but they also have less features. A Spark Combobox does not have the same API as the Halo Combobox for example.
Tooling around the relative component ecosystem is also a consideration. Flash Catalyst will only work with Spark components, for example.
Spark is a new theme introduced (in addition to Halo) with Flash builder 4 (Flex4). These two themes support different kinds of styles. With Flex4, you can choose which one you want to use depending on design considerations for your application. Spark is more convenient if you want to use custom skins on your components; Halo, on the other hand, has more built-in styles for components.
Read Adobe's documentation on the subject:
http://www.adobe.com/devnet/flex/articles/flex3and4_differences.html
The differences in state threw me for a loop at first.
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.