prettier: 1.7.0 breaks styled components using react-native

I’m going to close this based on @philpl and @mxstbr’s comments:

So as far as camel cases SC goes, try not to use it! It’s from our side unsupported but does work due to how we transform styles. Since it’s unsupported t might break in the future 😃 - @philpl

This is not because we want people to use it that way though, necessarily. I’m open to discussing about deprecating this by checking for camelCased properties and not passing them through, but that feels slightly weird because why do camelCased properties have a special case/behavior? 😕 - @mxstbr

Styled components expects a css string, and prettier is treating it like a css string. Support for camelcased properties in css string in styled components was unintentional.

Similar library glamorous, react native styles as normal camelCase.

The important difference being: you write styles with objects, not strings, so you don’t have any options. 😉

I really just don’t understand why this is so difficult to understand. We just want Prettier to stop changing my camelCase String literals. That’s that. @iRoachie, how did you change yours over.

@iRoachie Writing a pretty-printer is hard. We just want to make sure the problems fully before jumping into implementation to avoid accidental complexity 😃

@philpl It’s not catering for a specific way of writing things. Camel case is the default way to write styles in react native

It’s like asking everyone that writes css to start using camel case for everything. However, I doubt you’d see it as “catering for a specific way of writing” then.

Similar library glamorous, react native styles as normal camelCase. https://github.com/robinpowered/glamorous-native

More or less a simplified version of what styled-components (specifically the css-to-react-native package) does for ReactNative is this:

// Take this CSS string...
const Styled.View`
  border-color: blue;
`

// ...and turn it into an object to be passed to StyleSheet.create
StyleSheet.create({
  borderColor: blue,
})

As you can see, we also camelCase all dash-cased properties since that’s what ReactNative expects. Now, we don’t have a list of all valid or invalid properties or something like that, we just take whatever the user passes us and we convert it to an object.

This means when you write an invalid property, we also pass it through:

// Take this CSS string...
const Styled.View`
  complete-bullshit: blue;
`

// ...and turn it into an object to be passed to StyleSheet.create
StyleSheet.create({
  completeBullshit: blue,
}) 

As you can see, this is what leads to this behavior of camelCase working in ReactNative. Since we just take whatever the user gives us and convert it to an object camelCase also “works”:

// Take this CSS string...
const Styled.View`
  borderColor: blue;
`

// ...and turn it into an object to be passed to StyleSheet.create
StyleSheet.create({
  borderColor: blue,
}) 

This is not because we want people to use it that way though, necessarily. I’m open to discussing about deprecating this by checking for camelCased properties and not passing them through, but that feels slightly weird because why do camelCased properties have a special case/behavior? 😕

I’m unsure what the right way to go here is, but this should hopefully shed some light on why this works. /cc @jacobp100 @philpl @geelen