Redux: Redux docs are telling people to use ternary operators in inline styles.

[openSourceBugs]

[markerikson]

Seems like quite the over-reaction. You're complaining about a one-line snippet, in a TodoMVC example, in a training doc, for a state management library that isn't even trying to teach the view library itself. Beyond that:

• CSS in the React community is still a very open topic of discussion, and inline styles are a perfectly valid way to do CSS
• The focus of the example is hooking together the various pieces that make up a Redux + React app, not trying to illustrate absolute best practices
• As it happens, that is a _presentational_ component, and literally its only purpose is to render a Todo item. Some other part of the code is determining whether that Todo is completed or not, and its job its to render it visually appropriately.
• And no, the point of these TodoMVC-type apps is to demonstrate how various _client-side_ toolkits would handle basic CRUD logic, but without actually having any backend persistence.
• Finally, not introducing actual separated CSS into this example means there's one less file type and snippet that has to be defined in there.

So yeah, you seem to be raising a whole lot of fuss over something that's not a problem to begin with, and not a sample project that's worth getting bent out of shape over anyway.

[openSourceBugs]

To say that inline css with ternary operators is "acceptable" is a bit of a stretch here. This is official documentation. Are you ok with people saying "look guys, the official docs say if else is fine inline on a JSX (html really) attribute"?

[openSourceBugs]

May I quote this in the future?
"...inline styles are a perfectly valid way to do CSS"

[openSourceBugs]

It's just that. It's a training doc. Is it intended to have people train the wrong way?

[markerikson]

I'm really failing to see why you're complaining about the use of inline styles or a ternary operator.

[gaearon]

Hi, thanks for letting us know your thoughts.

First of all, this is a documentation for _state management_, not _writing components_. I think the focus of the documentation is very clear: we don’t even discuss this part presuming existing knowledge of React:

These are all normal React components, so we won’t examine them in detail.

This means we don’t take a stance for or against inline styles in React components. We are a state management library, and have no opinions here. We are using inline styles as the easiest way to add styling to the UI.

May I quote this in the future?
"...inline styles are a perfectly valid way to do CSS"

If you think that inline styles are inherently bad, you might have missed the past two years of discussion on the topic. I welcome you to watch CSS in your JS, Inline Styles, and JavaScript StyleSheets. Whether you agree with these ideas or not, many people use inline styles, either directly or via libraries like aphrodite and JSS, and it is indeed a valid way of styling React components, no matter what blog articles in 2000’s used to say.

This can only be tested from an end user's point of view. I must physically open a browser, click around and see if something happens. Logic with persistent state inside presentation can really only be tested heavily via end to end testing since it involves view, model, and controller all in one. But this is only the front end.

I’m not sure what you mean here, but you can use shallow rendering to verify that the returned element has the style you expect, if that helps.

1. Shouldn't "completed" be persisted? This seems like a violation of separation of concerns. Isn't this supposed to be the view layer? Not the Postgres layer?

I don’t understand what you mean. Completed field comes from the todo object from the todos array managed by Redux. If you want to persist it, you can do so separately.

---

Finally, I would like to suggest to turn this discussion to a lighter tone. I don’t feel comfortable responding to you further if you continue to act like you know better than everyone else, and keep sarcastically asserting your opinions rather than ask questions. This is hardly a productive way to have a conversation, especially in an open source project that people volunteer their time to work on.

These things don’t matter as much. Let’s not ruin each other’s days because of them. Thanks!