Skip to content

Conversation

jviereck
Copy link
Contributor

No description provided.

@jviereck jviereck mentioned this pull request Apr 15, 2015
props.active ? ButtonStyles.activeStyle : null,
state.hover ? ButtonStyles.hoverStyle : null,
state.focus ? ButtonStyles.focusStyle : null
].concat(props.styles);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The next version of React Style will have pseudo classes and should make this code smaller.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for that hint. Out of interest: How will you support pseudo classes in React Styles - using JavaScript to detect the hover and then update the styles or do you plan to emit a piece of CSS to use the browser :hover { ... } selector?

@jviereck
Copy link
Contributor Author

Just pushed a few more changes. These changes move the code further away from react-style. I tried to come up with a good way to solve the problem of extending existing styles like in

<Button styles={[ButtonStyles.error, ApplicationStyles.childStyle]}>

and ended up introducing what I call "composer" functions, such that the above becomes now:

<Button styleDef={ButtonStyles.error(ApplicationStyles.childStyle)]}>

The points 3) onwards in the README.md should hopefully give you and idea about the changes and the last point 7) covers the idea behind the composer functions.

The idea about composer functions is highly inspired by the blog post Mixins Are Dead. Long Live Composition, which talks about the trend in React to move away from mixins and towards composition, and the linearization concept in type systems like Scala. In fact, many of the latest changes came to my mind when thinking about extending CSS classes as a problem in other object oriented programming languages.

As always, if you have any questions or want me to explain details in more depth, please let me know.


Do you think the idea about the "composer functions" is too far fetched or do you think they actually make sense? I personally like the idea very much but I am not sure if my love for type systems makes me biased here.

@jviereck
Copy link
Contributor Author

As always, if you have any questions or want me to explain details in more depth, please let me know.

Aka, if you want, I am happy to write up more about the composer idea and turn it into a blog post :)

@jviereck jviereck force-pushed the 01_wip branch 2 times, most recently from 1388347 to accf64f Compare April 21, 2015 08:04
@jviereck
Copy link
Contributor Author

Two small changes that I've just pushed:

  • renamed :BASE: to !BASE: This is much easier to read (because there are no two colons at the end of the JSON definition)
  • removed the way to specify the inheritance explicit (before done via :INHERIT-PARENT:). This is as this feature complicates the design and for now I want to focus on a simple solution that is easier to prototype first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants