Hacker News Reader

Comment by arenaninja | Hacker News Reader

I don't think the `className` argument sticks. `class` is reserved so you can't use it. It's annoying but not a difficult concept

The other points are valid though. Mobx/Redux seems like a solution for big applications, but what's the alternative for small-to-medium React applications that still need to store state?

I agree I had issues following the snippets (and for one snippet I would definitely have to check MDN to decipher ES6 syntax), but I wonder if that's not an issue of style. Just like you can write PHP inline with HTML and you can write JS with HTML in JSX storing snippets of logic in a variable increases readability.

View on HN

The className complaint is a valid complaint - it's a limitation of JSX, which is specific to React here.

> I don't think the `className` argument sticks. `class` is reserved so you can't use it.

But you can use it. JSX nodes get compiled into React.createElement calls with object literals[1], and {class: "foo"} is a perfectly valid object literal in JS, s there's nothing stopping `<div class="foo" />` to get compiled into `React.createElement("div", {class: "foo"})`

In fact, other frameworks that support JSX syntax allow the use of `class` instead of `className`[2], so it's not a limitation of JSX per-se, it's just a design decision on part of React (and an annoying one at that).

[1]: As noted in the first code snippet on the React homepage https://facebook.github.io/react/

[2]: E.g., Mithril https://mithril.js.org/jsx.html#jsx-vs-hyperscript

It's valid. className was a frequent annoyance with React. That's one of the nice things about Vue. I can paste HTML snippets and they just work. I can't say it's the reason I switched, but it was some icing on the cake.

What was the reason?

A few reasons. The render() functions were unweildly. The ecosystem of router/state libraries were in constant incompatible flux. Difficult transition animations. Complex server side rendering setup. Probably some other things I can't remember.

> what's the alternative for small-to-medium React applications that still need to store state?

I've found that with small React apps, you normally organise each component to be responsible for handling its own state.

If you need a global shared state but your app isn't large enough for Redux then lots of people pass callbacks down to child components as parameters. True story.

Yes, that's what I do. Managing the global state in the main component, setting up functions to change the state via the update helper [1] and pass these functions down to the dumb components.

[1]: https://facebook.github.io/react/docs/update.html

Am I doing something wrong on small-to-medium applications by simply using setState? I always worry about this, even if Dan Abramov blessed it.

Sometimes I need some more global stuff, which I have solved in the past using context but I feel like maybe I'll just hook up some small mobX store in the future... Not sure

No, you should be fine. If it starts to get painful to pass around props, investigate Redux or MobX rather than using context by hand.

I don't see what's wrong with redux for medium/small apps?

Reply on news.ycombinator.com