Hacker News Reader

Comment by nojvek | Hacker News Reader

I don’t get the whole trend of jamming state in functions. hooks use closures for state and if you call hooks in wrong order you get the wrong values back. In this instance, this.refresh is magical.

One hard lesson I’ve learnt after doing 15 years of frontend is to avoid too much magic. As you build more complex things, it should be easy to bring in new devs and they should be able to simulate the system in their heads without expecting too many surprises. Or being laser diligent that a silly mistake could blow things up.

That’s what I like about original react. It was super duper simple idea. Classes are meant to have state. The state object is called state. Render function returns a view of state.

While generators are cool, all of this could be simply achieved with existing paradigms. That’s why I prefer preact over react. It’s way smaller than react, less bloated and equally fast.

View on HN

While I tend to agree, IMHO your example is off - it is a "state" property because the class is newly instantiated each time a render is going on, and then the property is magically re-populated for you so you can still treat the class like a class, not because "classes are meant to have state" - you would use class properties directly as your state if that was the case. Hooks are exactly the same magic (the state property is populated the same way as the useState hook works), only accessed differently.

> the class is newly instantiated each time a render is going on

No, it's not? Where do you think the state goes, if the instance doesn't hold it?

It's stored internally in React. The instance of your component does not hold the state, just a reference to the state object which is repopulated each render (just like useState, it's the exact same mechanism), and after the render is done, the instance is destroyed.

More here: https://reactjs.org/blog/2015/12/18/react-components-element...

The instance of the class isn’t destroyed every render... you can keep other state on it too that is persisted between renders, changing it just won’t trigger a render.

You are right. I tried it here, for others: https://codesandbox.io/s/crazy-bush-cg2i0?file=/src/App.js

Sure that is the way it works now. Is that a guarantee of React though or implicit behavior that could change in the future?

It's just an implementation detail.

I don’t know how this library or React work, but you could pass the state as an argument to itself - then what GP said makes sense.

I’m not sure how Crank is more “magical” than any other framework. All `this.refresh` does is make the current component execute again. For function components, this means the component gets executed again, and for generator components, this means the generator instance gets stepped through again. I think once you get the hang of generator functions and how yield work it might sort of click what Crank is doing under the hood.

Isn't the point that it's less magical - stuff goes where you expect it and does what you expect, not where the framework magically and by convention places it?

I believe bikeshaving's point above is that you learn the semantics of generator functions in JavaScript and that's your 'magic convention' - one that's not unique to this library because it comes form the languagee

If the OP was saying that Crank is less magical then I agree. Although it always made me sad that we measure APIs based on how little magic they bring. Like go to Disney World or something.

What if there’s no class in the language?

The ‘original React’ as you mentioned for example, was modeled in standard ML. There’s no class in the language and it is okay to model the state in function.

Why is this important? Especially in regards to the author's point about keeping frontend development simple?

Because class is neither simple nor mandatory.

And people have to do massive meaningless things like swapping between class and function components every day, because of the introduction and elimination of states.

There was OOP in JavaScript before classes existed via prototype.

> hooks use closures for state and if you call hooks in wrong order you get the wrong values back.

Calling hooks in wrong order gets the wrong value back? Can you explain this one?

Hooks rely on a persistent call index. Here are a few posts that explain in more detail:

https://overreacted.io/why-do-hooks-rely-on-call-order/

https://github.com/reactjs/rfcs/pull/68#issuecomment-4393148...

But why would you even change the order? I don't understand how can this be an issue if you treat it as a static declaration which it simulates.

What if you wanted to return early in the component? E.g. a hook has returned a certain value and you now want to stop all other execution and return null. With hooks you can't as that would change the order.

Yeah but you also wouldn't try to return in the middle of function argument declarations. I know it's a little weird, but just treat it as a declaration block and you won't have any problems, what you're proposing is impossible with react architecture as a whole anyways (because the next component would get wrong state cells, it's a stack).

The annoying thing with function purity fanaticism is that it is out of touch with reality.

State. Exists.

State exists, so let’s deal with it with the tools that the language provides, instead of pretending it does not exist, just to realize later that it does and jamming as hoc answers to this initial oversight.

A UI component is fundamentally “something that generates values (view objects) asynchronously (over human-scale timeframes)”. That’s the definition of an async generator!

> The annoying thing with function purity fanaticism is that it is out of touch with reality. State. Exists.

It’s the opposite of all-state fanaticism, where nothing can be done or calculated without first 1. Creating classes, 2. Mutating their states, and often 3. Mutating global state.

And then... magic!

Both kinds of fanaticism are bad, and a middle-ground is probably best. Keep it simple. Use the best tool for the job, etc.

That said, having worked with lots of code deeply inflected with global state, I’m more lenient to accept function-purity fanaticism over all-state fanaticism because at least then you only need to understand this one local oddity, not how it depends on the entirety of the rest of the codebase.

I agree with that and I personally dislike OOP a lot and am much more on the FP side. But sometimes as you say a middle ground is best, especially when the thing is intrinsically stateful.

But I have to say Dan Abramov does a good job of explaining why they need that purity here and it makes sense https://www.reddit.com/r/javascript/comments/g1zj87/crankjs_...

I think the state monad in F# makes a lot of sense - I'm now on the functional side after (finally) understanding it.

Parent was arguing against putting state in functions when classes exist. They weren’t arguing against state full code.

Generators will likely be a new paradigm. They are too powerful for senior devs to ignore. And so the junior devs will be taught. Like promises were taught.

Wait that doesn't make sense, was generators in the language before Promises, actually isn't await based on generators? How is that a new paradigm?

Promises and generators were ES6, so around the same time. Although people were using promises long before it became an official feature in ES6. I remember using promises as far back as 2012 or earlier - jquery had them. ES6 was 2015.

Await and async came after in ES7 and can be considered to use yield[1]. So there you go - that's a perfect example of the power of generators. Promises used to be more difficult until they were simplified using generators.

[1] https://stackoverflow.com/questions/36196608/difference-betw...

I prefer to avoid them. Debugging can be way harder. Remember good old days when you could understand minified JS relatively easily? Look at webpack bundle + babel with generators. Horror to work with.

Yeah, I know sourcemaps and all that, but even sourcemaps workflow is impacted; setting breakpoints can be weird, debuggers are still not perfect.

I think you are mixing up concerns. Webpack + babel does make debugging harder in general. Because you are looking at the output of a compiler.

But what does that have to do with generators? Do you have a specific concern about how Babel "compiles" generator functions using switch? Again, I tend not to look at compiled code, but I think the babel output for a generator function is easy to read.

Generators are great and I love them. So are promises. Yes, they do take a while to understand the underlying mechanics of iterators but I wouldn't call generators per say magic.

The magic is "this.render". What is "this" in a function ? If we're storing any sort of state in this, then I expect to see "new <something>()", which creates a new this.

By default functions inherit the this as window, and it's frowned upon to use "this" in pure functions. Crank.js breaks the convention where "this" is magically something else. It will also make it hard to typescript type the function.

So now suppose you have mouse event handlers and key event handlers, when their functions get called, their "this" is something else and you have to bind it via either arrow functions or .bind(this).

So my point is, because of unconventional "this", as a developer I have to keep track in my head what this refers to inside a function because it's implicit. If I am working with a team, I have to carefully explain that "this" is unlike what you think it is, it's magically injected.

In javascript "this" is the source of many bugs, because it can be different things based on context. https://www.javascripttutorial.net/javascript-this/

> Classes are meant to have state. The state object is called state.

Except that's not how React works at all. There's no state in the class that lives between renders, it only seems that way due to... magic. The class gets destroyed and created between each render and the state object is automagically recreated with the previous state. You can complain about Hooks but saying they are magical and React classes are not is just wrong.

React classes don’t get destroyed and recreated each render. You can throw a console.log in the constructor, or save variables locally to the class, and see this for yourself.

Set `this.foobar` to something in a React class and you’ll see it persist between renders.

Reply on news.ycombinator.com