flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FlexJS] Translation from framework to JS
Date Mon, 10 Oct 2016 21:43:01 GMT

On 10/10/16, 12:05 PM, "carlos.rovira@gmail.com on behalf of Carlos
Rovira" <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>

>I'm in the process of trying to see how integrate a CSS library (like
>In order to get it, I need to know more about the process of converting a
>FlexJS component to JS.
>For example, a js:Container, should translate to a <div> or something like
>that, is that right?
>(I see js:ContainerBase but not js:Container, where's that class?)
>or a js:Button is finaly a button tag?

js:Container is org.apache.flex.html.Container, in the HTML.swc and wraps
a <div>
js:Button is a <button>

>If is that...I see using className work to assign some MDL css classes
>Do you know if there's more points of integration that I should know in
>order to get a successful integration.

The way it works now is that the JS version of any component should be
able to have its className and id property set, which will set the same
properties on the HTMLElement, which should, in theory, allow lots of CSS
to "just work".  The SWF version is supposed to emulate what CSS will do.
It works ok, but I'm sure it needs fine tuning.

In addition, because Flex allowed for custom type selectors, which AFAICT,
CSS does not allow, you can specify in the FlexJS CSS non-standard type
selectors like TextInput, Container, DataGrid, etc.  On the SWF side,
these get factored into the CSS lookup much like it did in regular Flex.
On the JS side, we want each component to specify a "typeName" property
which is appended to the className via framework code.  The FlexJS
compiler "translates" TextInput to .TextInput thus making the lookup work
the same.  This allows an extensible type selector model to specify
default styles for various components without collisions from the class
selector "className" property.

>As I get more knowledge on this, I think w could discuss, if we could get
>MDL library to expose MDL look'n feel directly on FlexJS
>Or I you think there's a better approach.

IMO, there are at least two valid approaches.  I honestly don't favor one
over the other.

1) Custom Component Set.  This is sort of what we tried in Flat.swc.  We
created subclasses of existing components and customized some CSS (based
on the FlatUI css files) to get the look and feel we wanted.  In doing so,
for now at least, we "dumbed-down" the CSS to what FlexJS is currently
capable of (simple class and id selectors).  There are no advanced
selectors.  Anything requiring advanced selectors was skipped, or was
re-engineered via subclassing and the extensible type selector model I
mentioned above.  The important takeaway is that by doing "more work", you
can probably create any look and feel you want today in FlexJS
2) CSS as Theme.  At some point in time, I think we want to allow someone
to build out their UI in MXML, set className and id properties, and then
drop in an existing third-party CSS file and it would "just work" just
like if you switched the css file out on an equivalent .html file.  Or
maybe you'd have to thinly-wrap the third-party code, I don't know.  The
JS side is probably mostly ready to do this, but it would require a lot of
work on the SWF side to handle a CSS lookup that is essentially
standards-compliant.  The SWF side code would have to handle all advanced
CSS selectors and directives since in my brief tour of Flat and BootStrap,
they leverage a lot of fancy CSS.

In sum, if you've got time, we could probably fashion a set of components
that look like they follow MDL.  But the dream is that we would thinly
wrap an existing 3rd-party library and it would "just work".  That is
currently more work today, but someday, that might be the preferred path.

>I think this is one of the main things we need, to start spreading the
>of FlexJS in a more engaging way, since visuals is what people first look
>to choose us
>(then comes the technology behind, but if and amazing technology doesn't
>look at first glance attractive....is difficult to bring people on board)

For sure, better look and feel of our examples would certainly help.
Peter is polishing up a new "Mobile Stocks" demo and it would be nice to
have help making it really look good.  I can even imagine trying to
publish it to the app stores.  More on that when Peter declares he is done
with the first phase, hopefully in a few days.


View raw message