Hacker News Reader

Comment by Termina1 | Hacker News Reader

I think that author is completely right about the part, that React has the only one reactive part — its render function. But I don't see why it makes React bad. I think it is great, fast and easy to use.

By the way, virtual-dom is a little bit early to use for production application. For example, if you have some elements in your vdom, that are changing after you render it (i.e. like buttons, embeded posts, etc.), virtual-dom will be totally confused and unpredictable. For example, it can duplicate some elements on the page.

I believe it happens because vdom depends on its internal index to traverse real dom nodes. It is still a remarkably good piece of software.

View on HN

>By the way, virtual-dom is a little bit early to use for production application. For example, if you have some elements in your vdom, that are changing after you render it (i.e. like buttons, embeded posts, etc.), virtual-dom will be totally confused and unpredictable.

On the one hand, yes, and on the other hand, I have never in practice had this happen when it was not my fault. I've also never had it be my fault unless I fell back on some old jQuery plugin or Google Maps or something that directly manipulates the DOM because I'm trying not to reinvent the wheel.

However, you can deal with these things gracefully by diligently recognizing these instances in which you, for one reason or another, need to directly manipulate the DOM. React's lifecycle methods like `componentDidMount`, `componentWillUpdate`, and `componentWillUnmount` are the place to deal with those kinds of issues.

It definitely takes you out of the React philosophy and forces you to manage your own state carefully. But that's generally confined to a single component, so if you get the component innards right, everything that calls it can be ignorant of the ugly stuff inside.

Unless you're talking about something else entirely that I've just been lucky to never encounter.

For example, embedded FB post. In React you can deal with it using componentShouldUpdate and others. I don't know how to deal with it in virtual-dom (package), without going deep into patching algorithm.

Ah, my mistake. I didn't realize the distinction there. Makes more sense now.

Also, React goes with Flux, and Flux is a reactive architecture. So, if you treat React a separate module, the whole flux architecture is pretty reactive.

Yeah, I agree. It doesn't necessarily make React bad. And, after years of Backbone and Marionette, having an hierarchical structure in which parents "pass down" methods and data makes more sense than events, which can be hard to manage, test and visualise. And I really, really, really want to be able to visualise the structure and interactions between components when developing.

>For example, if you have some elements in your vdom, that are changing after you render it (i.e. like buttons, embeded posts, etc.), virtual-dom will be totally confused and unpredictable.

I can't think of a reason that someone would use react and still bypass it do their own dom modifications.

Sometimes you have no choice, in case of embeddable objects

This usually happens when you want to use 3rd party libraries (e.g. jQuery draggables, Bootstrap tooltips, or anything that polyfills an unsupported DOM element)

I agree that maintaining external plugins is pain in React..but still there are ways you can manage them in React..

> I think that author is completely right about the part, that React has the only one reactive part — its render function. But I don't see why it makes React bad. I think it is great, fast and easy to use.

And you forgot fun.

2x (it's --> its)

Reply on news.ycombinator.com