I picked this post to respond to in order to write one response instead of several. Comments Inline...
On 5/17/18, 1:39 PM, "Harbs" <[email protected]> wrote: Snipping relevant pieces to make it more legible… Let me use a concrete example to illustrate what I mean: Try compiling the DateControlsExample. The example does not use ButtonBar in any manner, shape or form. Being so, ButtonBar and all related classes should not be included in the output. However, both the ButtonBar CSS and ButtonBar and associated classes are included in both debug and release code. I think this can only be classified as a bug and this is what we need to fix. It is a bug. In the framework. The defaults.css for Basic has a .DynamicDataGrid in it. It shouldn't have that. (There might be another framework bug where a ClassReference in .DynamicDataGrid referenced DataGrid which bring in DataGridButtonBar which brings in ButtonBar) That's an example of Class Selectors being used instead of Type Selectors. If we created an actual subclass of DataGrid called DynamicDataGrid then the CSS could use a Type Selector instead of a Class Selector and the problem goes away. IMO, we need to decide on some good ways to stop using class selectors or prune class selectors. I don’t understand why the compiler cannot build a list of used classes and drop any CSS references not used. It does have that depending on what you mean by "used". If "used" means referenced by the code, it appears to be working correctly. If you are suggesting that the compiler tracks whether a class is actually instantiated, that's a bit harder mainly because we would need to retain that information in the SWC somewhere and we don't currently store compile-time information elsewhere in the SWC. We could try to prune more in post-processing for JS only. We could search every JS file for "new Button", but even then, I think you'd miss where a className was stored in a variable and then instantiated which is what ValuesManager does. So I'm not sure the compiler can truly know what classes got directly instantiated. I’m not sure we’re talking the same language. The class selector for ImageButton will always be (in HTML css) .ImageButton. So if you have a basic ImageButton and a Jewel ImageButton, there will be CSS conflicts in the compiled HTML CSS. The above statement isn't true. I already mentioned upthread that the HTML css could be .org_apache_royale_basic_ImageButton. I think there is a fundamental disagreement here. I think we should be approximating how Type Selectors work. That is because fully qualified type names are essentially already guaranteed to be unique. The compiler will catch duplicates. IMO, we want to leverage strong typing. It is Royale's technical advantage over all of the manual conventions I see folks having to use in other JS frameworks. I think you want to propose some scheme to use class selectors and not use Type Selectors. This is doable, but requires a manual convention. The component developer theoretically already decided on how to make the fully qualified component name unique by selecting a unique package name. Now you want the component developer to have to identify another unique name to ensure the class selector names don't collide. And those names are going to want to be "friendly" names like "Basic" and "Jewel". I don't get why using QNames is not sufficient. If it is too verbose in the output, maybe we can find a way to shorten it. IMO, uniqueness is probably better handled by tooling instead of manual conventions. Let's make sure we can't use Type Selectors before discussion a scheme for using Class Selectors. Uniqueness is built in to Type Selectors. If one problem is with Type Selectors in Royale inheriting styles from Base Classes, we should discuss ways to manage that. Metadata is possible, but metadata is expensive at runtime. There are two parts to how Type Selectors work. The main concern appears to be the ClassReferences kind of CSS, which is not handled by the Browser. The IValuesImpl has to decide whether to look up the base class and it would have to fetch and parse metadata at runtime to do that. And, as I mentioned earlier, I'm not sure the compiler can know whether the base class is in the output because it was directly instantiated or not. Historically, the only reason Type Selectors inherit from Base Classes in Flex is because of app developer subclassing. For sure, we the framework developers can always take the time to fill out the Type Selectors such that the lookup never goes to the Base Class. But the app devs just want to use a component as the top tag in an MXMLComponent or do a cheap "MyButton extends Button" in AS. And without inheritance, you don't get any defaults and things blow up. We could say to the app devs:: "too bad, in Royale you gotta copy the base class type selector". I would imagine non-Royale folks have to copy HTML Type Selectors in some cases already. We could try to find all subclasses of classes that have Type Selectors that don't have their own Type Selector and have the compiler auto-copy that base class Type Selector (or add the subclass to the list of classes for that selector. My 2 cents, -Alex
