Update purpose and scope

[jpomazal]

I recently stumbled upon this project as a result of the pain of using styles in react-native and found it to be extremely useful as is (with a couple fixes). However it is only part of the solution as I ideally want to leverage a bulk of styling assets as well as making it easy to change entire themes gracefully. I was able to throw a quick solution together that is able to somewhat replicate how CSS works in the browser and allow implicit styling of components and pushed it into the 'inheritance' branch. For a quick guide of what it does and how it works, look at https://github.com/sabeurthabti/react-native-css/tree/inheritance/examples.

The question is whether or not to actually include this functionality in this project or to push it entirely into a different project. I'm strongly in favor of keeping it in this project for 2 main reasons: 1) It requires the current code to function, 2) it follows strongly with the name of the project.

Key Updates

1. I've added a flag to the client called 'inherit'. This changes the functionality of the normal transform by doing the following:
   • It keeps classes intact.
   • Text is treated as a special rule and any text properties in parent containers are 'inhertied' into the text property using a special [selector]&inherited key. While this can be referenced directly in the current scheme, it is especially handy when combined with the next change.
2. I've added a component wrapper that looks up matching CSS selectors and automatically injects the corresponding styles into the target component.
   • Component paths are generated via getChildContext implementation.
   • The wrapped component accepts an optional className property, however still responds to just selecting by component name, e.g. 'view > text'.
   • I've created a very lean and simple parser and matcher. Since there is just a small subset of CSS that maps to react-native, I didn't want to bloat runtime code with excess libraries. It works, however I assume several improvements can be made overtime. Styles are highly cached to reduce any performance impact one way or the other.

     Suggested purpose

One of the best and worst things about React is that it is a very un-opinionated framework. In fact their goal is to create a framework that uses pure JavaScript conventions without any special designs. The downside is that they don't offer a good direction for styling projects. The current method is cumbersome for large projects. It is especially bad when you want to leverage choosable themes or you have to create white-labeled versions (not an uncommon practice for me).

I believe that SASS is a far superior way of styling compared to the standard react-native way. Speed, flexibility and features like import and extend make it significantly easier to use and maintain compared to the JS styles. Additionally the ability to share partials with traditional web projects is a huge plus. Fundamentally I see these as a more than fair tradeoff compared to the small performance hit of implementing the styling.

Along these lines I propose expanding the scope of the project to incorporate this new line. Additionally this architecture can allow for adding things like media query support or even special properties that can map to non-style properties, ios#shadow would be a good example of this.

@sabeurthabti Let me know if you're open to this change or would prefer I move it to a separate project and just use this as a dependency. My only qualm with that is the name here is so good.

[thabti]

@jpomazal I am impressed. This is awesome and I want to thank you for the much needed life. I have emailed you, if you didn't receive an email me email at thabti.sabeur[at]gmail.com or http://m.me/sabeurthabti so we can discuss this more.

I am open to the changes and extending this project, I can move the project into an organisation so we can have spin-off projects.

if FB messenger works for you, please contact http://m.me/sabeurthabti.