Live data from Hacker News

React v0.14

facebook.github.io

111–116 of 116 posts

Re: React v0.14

#111

The enthusiasm around React is infectious and I'm thinking about integrating it into one of my projects but I can't quite tell what exactly it's supposed to be used for. Is it only for SPAs or is it reasonable to consider react when you just want to add some interactions and dynamism to a page that was rendered server side? React seems kind of like an all-or-nothing approach. It seems like overkill if you just want t…

I have a slightly different view of the value of React. It's not the code of the library, per se, but the development patterns. These techniques will work anywhere. If you can get yourself to use them, then React (or anything that works the same way) will be a great boon for you. If not, then you might be better off with something else. Please excuse me for this explanation, which you might already be familiar with.

Imagine your data is in a tree. Go to the very lowest nodes on the tree. You should be able to imagine that rendering these nodes is quite easy. It's just simple data. Now move up a node. Rendering this node is just rendering the data at that level and telling the next level to render. Keep doing that until you get to the very top.

The rendering at every node is now very simple. It is also very easy to write tests for: You just need to make sure that the data in the node has been rendered and that the nodes below are present.

Of course, that's just rendering a static tree. How do we deal with dynamism? In it's simplest form, you don't. Instead, any time you want to change some data in your tree, make a new tree and then render that new tree. This has the advantage that it is very simple. You tree of data is immutable, and so you never have to worry about state changing. At every change you just re-render the entire tree.

Of course, that is costly, so we can be clever and notice that we don't have to re-render the entire tree. We just have to compare the first tree with the second and re-render the highest subtrees that have changed. React does this behind the scenes.

If you are trying to do a kind of hybrid approach of using react for some parts and not for others, this is actually one of the easiest ways to do it. If you want to update your data from the server, you simple make an endpoint for the data at the top of your React tree and every time you change something you make an Ajax call from that top node to get the new data. This will cause the tree to re-render fairly efficiently.

Of course, this doesn't solve all your problems, because often you don't want to get new data from your server, you just want to update data around your tree. In this case, you need to image every node as the top of a subtree. If you want to change the data in the subtree, you simply make a request to the top of the subtree to modify the data in that subtree. This causes the entire subtree to re-render.

So the main flow is that you have a tree of data which you render. Anytime you want to modify the data, you need to make a request up the tree (never sideways and almost never downwards).

These requests can be made in many ways, but the simplest is simply by passing a callback down the tree as a piece of data. You decide which node "owns" a piece of data and then you pass a callback for modifying that data down the tree. Anyone below can potentially call that callback, which will modify the data at the top of the tree and re-render the entire tree.

There are other ways of doing it. Passing a whole whack of callbacks can be tiresome. Flux, for instance, sets up a series of singleton objects that anyone can access. You make a request of the object, it creates a new tree of data and updates the top node of the tree. (Note: Highly simplified explanation to the point of being wrong ;-) ).

Anyway, the point of this is to say that, if you want to write code this way, then you should use React or something like it. If not, you should stay away, because you will make a huge mess.

Re: React v0.14

#112

Earlier quoted context omitted.

Seriously, a library that goes out of its way to provide useful deprecation warnings and always keeping deprecated behavior for a version, with versions coming out once in three months, and released with codemods automating the transition for you, cares a little about compatibility? Yes, any library that breaks code written according to documented good practices less than six months earlier only cares a little about…

I think you're misunderstanding React's API surface. It's about 20 core methods, not a giant lib like jQuery. From my experience, a medium sized project is adjusted to the changes in about two hours. Once every three months. Is this a big deal in trade for progress?

Is this a big deal in trade for progress?

It is a big deal any time someone's code works, and then they update a dependency, and then their code doesn't work any more.

Even if the actual code changes required to update the integration are minimal, someone still needs to divert to make those changes and then test everything, which is disruptive at best. Before they can do that, they need to identify what changes are required and perhaps learn how to use any automated updating tools that are available, both of which also take time. If one person on the team wants to upgrade to access some new feature or just get a bug fix, everyone else on the team has to come along, so for example they might start seeing warnings that they'll need to investigate. As I mentioned in another post, there is a nasty hidden cost to breaking the interface of fast-moving but lightly documented libraries, because it will tend to invalidate all the tutorials and example repos and demo videos and so on offered by other contributors or, worse, those resources may become actively misleading.

This is a lesson the web development community will learn in time. Unfortunately today it is a very young part of the industry, obsessed with the appearance of making progress, even though actually web development is almost comically inefficient. The lack of respect for issues like standardisation, compatibility and portability is a major contributing factor in that inefficiency, as is the willingness to build on fragile dependencies in the first place.

Re: React v0.14

#113
Well i think it will take some time for libraries and components to be updated. For me currently at least react router should provide a compatible build with react 0.14

Re: React v0.14

#114

Earlier quoted context omitted.

Interesting you draw the Knockout comparison. I'm pretty new to React, but have done a fair amount with Knockout. I find that I use the two in very similar ways. I know knockout has a large feature set and claims to be a VMMV (whatever that means), but in practice I used it mostly to go between some dynamic JSON and DOM.

MVVM. Model-View-ViewModel. It's a well known design pattern that exists outside of Knockout.

At least, well-known to .Net developers :)

Re: React v0.14

#115
post #49
post #17

Earlier quoted context omitted.

I came in here to comment on this. React sounds exciting from what I've read about it, but I didn't realize it was pre-1.0. To teams who are using it in production, did you talk about this? What are arguments for using it despite it not being 1.0?

Why do you care about an imaginary number? FB (and many other large companies) heavily use this in production, and have to migrate their own apps. FB even goes farther and uses the master branch (well, synced every week or so). That's a far heavier endorsement than whatever side of a decimal a number falls on.

I care because it's a convention. Without knowing too much about Angular 2, I know that it's got major breaking changes compared to Angular 1. Likewise, I know that a 1.15.2 should upgrade from a 1.15.1 fairly trivially, whereas a 1.16.0 might take a little more consideration.

With all that said, the responses to my question are very reasonable, such as "people I know and respect have used it and stated sane upgrades historically." In the absence of this piece of tech in my own social circle, SemVer is a convention that Facebook will have to live up to. 6 months to a year after Facebook switches to it, I can research how reasonable they are with introducing breaking changes and supporting old, stable versions. I believe that more people will be vocal about a major breaking change post 1.0 than pre-1.0.

Re: React v0.14

#116

Earlier quoted context omitted.

My biggest complaints about angular aren't really the dirty checking system that it uses (though one of them is a side effect). My biggest complaint is the weird dependency injection system that makes it difficult to track down where something comes from. It's better in 2, but still not as straight forward as React, where your child components are simply import/require statements that you can follow through to either…

A bit offtopic, but DI (via IoC container) is for managing runtime dependencies, which can get complex as an app grows. DI of the IoC container flavor is never necessary (I would argue that pure DI in itself is only a good thing though for clean separation of code), but one can say many things are not necessary - its existence is for making things simpler when working with complex apps. Without an IoC container, one…

What does one have to pass around? You can `require`/`import` service modules directly... for that matter, with a system like redux/react, you can easily pass anything needed via properties. You can create pretty complex applications without muddying where your services come from...

I've been following Angular2, and while much better than Angular1, still think react+redux as a workflow/render solution with separate state management reducers/handlers is a better workflow... especially as feature count goes up, because complexity doesn't climb as steeply as with Angular.

Post reply on HN