React v15.6.0 Released

https://facebook.github.io/react/blog/2017/06/13/react-v15.6.0.html

by petercooper • 9 years ago

130 81 9 years ago

facebook.github.io

ljoshua• 9 years ago

Downgrading the deprecation warnings to console.warn instead of console.error will be nice until all the third-party libraries catch up with the changes in v15.5. It's the small things.

BigJono2• 9 years ago

Using console.error for warnings was silly in the first place. The solution to people ignoring warnings is to change that mindset, not to reduce the granularity of information and make everything red. I see the same thing with ESLint a lot.

jankassens• 9 years ago

For a long time, console.error had a stack trace in the Chrome devtools while console.warn didn't. I believe this was the main motivation to use console.error.

cycomachead• 9 years ago

I ran into this a lot with propType validations, which don't seem to be changing. But I'm in the camp that are "warning" should be displayed as a warning, so this is a welcome change. :)

beefsack• 9 years ago

This is a very minor release, mainly just covering some bug fixes and deprecation warnings. It's not terribly noteworthy.

Strom• 9 years ago

Some of those IE11 input bugs have been annoying me for a long time. Glad to see them fixed.

usuallybaffled• 9 years ago

Do they follow semantic versioning? If so, does that mean there have been 15 releases with major breaking changes?

vizzier• 9 years ago

They switched from 0.14 to 15.0 to reflect react being production ready. See here: https://facebook.github.io/react/blog/2016/02/19/new-version...

AgentME• 9 years ago

Something interesting to note: usually code written for one version of React is compatible with the next version of React as long as no deprecated features are used. Usually React's breaking changes between major versions are restricted to breaking deprecated things and making new stuff deprecated.

Sacho• 9 years ago

I think it was open sourced as version 0.8 or something along those lines, so that would be 8 major releases.

pcmaffey• 9 years ago

I noticed Fiber is now passing all it's tests. Anyone have an idea when release is planned?

faitswulff• 9 years ago

Huh, seems like only yesterday there was a good number of red tests: http://isfiberreadyyet.com/

felipeko• 9 years ago

According to a member of the dev team: 'We are aiming for sometime in the second half of the year. There's still a few details to work out beyond just feature parity with 15. '

https://www.reddit.com/r/reactjs/comments/6g3e98/react_fiber...

davidpelayo• 9 years ago

it's awesome the whole refactoring process they have done in such a short period of time. Short, relatively, but short.

grizzles• 9 years ago

Just curious, what do react folks think about this blog post:http://joonhachu.blogspot.com.au/2015/12/dont-use-flux-or-re...

To me, the application wide bus paradigm is elegant, and find it surprising that redux is currently more fashionable than this approach.

Thoughts?

nemothekid• 9 years ago

If your application is small enough where a global event emitter is makes your code clear enough to get the point across and wont make you pull your hair out - I'd argue that React, forget Redux, is probably overkill anyways. There are better frameworks (or just not using one at all), that are more fitted for this and won't have you spending the first 3 hours setting up webpack.

sfifs• 9 years ago

create-react-app works out of the box for small applications and automatically sets up webpack to sane configurations. I've found that setup ideal for small apps.

It's only on the larger apps with more complex customization where I have found the need to use anything other than the default webpack configurations other than the default create-react-app ones.

acemarke7• 9 years ago

I'm a Redux maintainer, so I'll address the Redux side of things.

The author of that post primarily claims that the main reason to use Redux is about keeping state in sync. That's _a_ reason to use Redux, but not the _only_ reason. Having a single store allows use of a middleware pipeline for centralization of things like logging, API calls, data transformations, and much much more. Having a single state tree and serializable plain object actions allows powerful developer capabilities like time-travel debugging, state persistence, and even synchronization of remote stores via transmitted actions. Use of "pure function" reducers is also key for time-travel debugging, as well as making it straightforward to trace where state changes came from, and are generally easier to test.

The author _is_ correct that a centralized store does make encapsulation harder to work with. That's a deliberate tradeoff. (Encapsulation isn't _impossible_ with Redux, but it definitely takes more work.)

Dan Abramov's article "You Might Not Need Redux" [0] discusses many of the common complaints about use of Redux, and the tradeoffs that Redux asks for and gives you. Also, my recent two-part post "The Tao of Redux, Part 1 - Implementation and Intent" [1] and "The Tao of Redux, Part 2 - Practice and Philosophy" [2] goes into detail on what actual technical limitations Redux requires and why, why common Redux usage patterns exist, and my opinions on the pros and cons of many "variations" in how Redux _can_ be used. (In particular, it's entirely up to you how much abstraction you apply, how you structure your codebase, and how much "boilerplate" you are comfortable with.)

Redux is certainly not the perfect solution for every problem, and it's generally not going to be the solution with the fewest LOC. However, it _is_ a powerful and useful tool for organizing your state and logic, and there _are_ valid reasons why its constraints and common use patterns exist (and complaints about those patterns rarely take those reasons into consideration).

[0] https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

[1] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...

[2] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...

petilon• 9 years ago

You can have a centralized store in MVC. Here's a simple MVC framework (less than 500 lines) that works with React: https://github.com/rajeev-k/mvc-router In this framework the Application object holds the centralized store. No need for MVVM, Redux etc. React is the V in MVC.

ng12• 9 years ago

I've become a big believer in separately managed state. Even if something would convince me to move away from Redux I would still stick to the pattern of dividing code into three stacks: data/state management, components, and stateful glue code (AKA reducers, components, and containers in the React universe). Redux is most useful in that it keeps you honest to this paradigm and that it provides some nice dev tools -- the library itself doesn't really matter. I don't think there's anything wrong with a global event bus in theory but in practice it often lends itself to abuse. In fact, I'm currently moving a legacy application to React/Redux and found that the global event buses were a good idea in theory, a spaghetti factory in practice.

Matthias247• 9 years ago

I also think seperating state from the view components is a great idea. But I don't see that a Redux-like approach is needed for that. What I deployed successfully in a larger app was just some normal kind of MVVM architecture: I implemented service components (in form of Typescript/ES6 classes) which store the state they care about and expose getters for the current state and mutating functions for changing the state. These are basically the M(model) parts of MVVM. The view components (Angular2 viewmodels as well as React components) get the services injected and use the latest data from the services in order to render it into the view (oneway data binding). If realtime updates from the service to the view are required then the services can expose their state as Observables, to which the ViewModels can subscribe. I like the approach, because it allows the data-consumers (view-components) to see the sources (models / services) just as a domain specific strongly typed interface, which allows to change the state and retrieve it with normal object-oriented patterns. Dispatching some non-strongly typed action into an eventbus and hoping that anybody will care about it seems less type-safe approach to me.

PettyAdm• 9 years ago

Have you considered something like Cycle JS (https://cycle.js.org/)? It seems to line up with your aim to maximize separation of concerns and make things predictable.

mhd• 9 years ago

Never mind any paradigms or anything, I believe a lot of the popularity of Redux boiled down to two things:

1. It was there at the right time, when people started getting serious with React and were looking for a way to structure their data flow.

2. Tooling. Soon after it was released, the author demonstrated a pretty neat hot-reloading utility.

So no matter whether you're really into functional purity or are reminded of Win32 event loops, it was a practical solution.

acemarke7• 9 years ago

Per the "Win32 event loop" comment, I suspect you're referring to https://bitquabit.com/post/the-more-things-change/ , where the author points out that Flux+React looks an awful lot like a Win32 WndProc function. (HN discussion thread: https://news.ycombinator.com/item?id=10381015 .)

ngsayjoe4• 9 years ago

I don't use Redux for my website @ https://www.land.plus/ all states are managed locally in the component's instance variable. In some cases a global variable is used within the component file if single page persistency is needed. For inter-components state, i use Javascript CustomEvent & addEventListener instead. Am i doing something wrong for not using Redux?

acemarke7• 9 years ago

No, that's not "wrong". But, it does sound like the kind of case where Redux might be useful.

wry_discontent2• 9 years ago

THe problem I've found with this approach is that it gets very messy very fast. It's hard to track down bugs to their source.

One of my favorite aspects of Redux is how easy it is to follow the flow of data. Whatever you do, you start at a dom element, look at what action creator it calls, and check out the changes in the reducer.

adt2bt• 9 years ago

Well your site works, doesn't it? Can't do something wrong if your site is all right.

_pmf_2• 9 years ago

What irks me about the Flux ecosystem / JS in general is the strange divergence between what is required (immutable data structures) and what new language features provide (ES6 classes). Immutable.js alleviates some of the pain of having to do full copies on state mutation, but this does not work in a satisfactory way with ES6 classes.

If the tendency of the developer community is towards (faux) functional programming, why is the language taking a OO direction (with the community actively discouraging using ES6 classes)? Coming from OO languages, I'd like to use ES6 classes, but I can't because I'm told it's not idiomatic and I don't want my code to stand out like a sore thumb. So, "native" JS devs don't want to use ES6 classes, and OO devs gone JS cannot use ES6 classes without looking like fools; why is the feature there?

vbezhenar• 9 years ago

Store is a dumb JSON object, you don't need methods for it. Actually ES6 has some very handy syntax like `{...old, newProp: newValue}` to support immutability. And React components can and should use ES6 classes.

If you want pure OOP approach, check out mobx. It's a popular alternative to Redux.

allover• 9 years ago

why is the language taking a OO direction

Classes are just sugar over how devs were already doing class-like stuff with prototypes (see backbone/ember/angular etc). So I'd disagree that the language is 'taking an OO direction'.

If the tendency of the developer community is towards (faux) functional programming

Wouldn't agree with that either. Some sub-communities perhaps. But e.g. in React there's a big push back towards using (class-based) Components and good old setState().

I'd like to use ES6 classes, but I can't because I'm told it's not idiomatic

These people need re-informing! React Components and setState() are what Facebook use. In my opinion, setState() plus a router will handle the vast majority of state in your app just fine.

To get more of a feel for this setState() vs Redux kerfuffle:

Ryan Florence (of React Router) is a Components/setState proponent, and great person to follow on Twitter. I like his intro to this talk [1] where he talks about the issue. Also highly recommend reading 'Functional setState is the Future of React' [2]. And of course I think it's already been posted elsewhere in the thread, but Dan Abramov's own 'You might not need Redux' is definitely worth a read [3].

[1] https://www.youtube.com/watch?v=kp-NOggyz54

[2] https://medium.freecodecamp.com/functional-setstate-is-the-f...

[3] https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

coldtea6• 9 years ago

Coming from OO languages, I'd like to use ES6 classes, but I can't because I'm told it's not idiomatic and I don't want my code to stand out like a sore thumb.

Simply, ignore them. That's just noise from the huge influx of JS developers and the immutable/functional cargo cult train. ES6 classes are perfectly fine, they're a sugary layer on top of prototypal inheritance, that merely formalizes how almost everybody was already using it.

Nothing wrong about ES6 classes, and nothing that great about pure prototypal inheritance anyway (which they still are).

cannot use ES6 classes without looking like fools

For one, ES6 classes are the recommended way from the React team.

Second, don't worry about how you "look".

Programming is a discipline, not a cargo cult or pop culture to fear of being "uncool".

acemarke7• 9 years ago

Those are two different things.

React, in its current form, requires classes or something class-like in order to implement stateful components with lifecycles. It also does not require that you handle data immutably - you can run `this.state.someArray.push(newValue); this.setState({someArray : this.state.someArray})`, and React will re-render just fine.

However, React also pushes you in functional programming directions: render methods should be pure functions, performance optimizations with `shouldComponentUpdate` work best if you've handled data immutably, and so on. The React team also plans to investigate a "stateful functional component" API at some point after the React 16 release.

It's also worth noting that React was not the only reason why classes were added to Javascript. There were hundreds of "pseudo-class" implementations out there already (all a little bit different than the others), and there was clearly enough demand for the concept to add it to the language in a standardized way.

Meanwhile, Redux has definitely helped popularize the idea of updating data immutably. The array spread operator was already added in ES6, and the object spread operator is nearing finalization. No, the language doesn't have full-blown immutable data structures, but handling data immutably is absolutely possible. If you don't like dealing with immutable updates yourself, there's Immutable.js (as you said), or dozens of immutable update utility libraries.

Particularly in the case of Redux, use of classes for data is discouraged because of the other constraints Redux asks you to follow. Plain serializable data is needed in order for time-travel debugging and persistence scenarios to work properly.

Overall, your complaints are split across a couple things. Classes exist because some JS devs want to use them. Functional-style approaches exist because some devs want to use them. Languages like C# and C++ have been "everything and the kitchen sink" for a while now, supporting multiple different paradigms in one language - Javascript is now the same way.

hliyan• 9 years ago

Having used both Flux and Redux for fairly large projects for the past two years, I have finally come to the conclusion that I really don't need either. I tried to summarize my alternative here, although I'm sure many will disagree:

http://zen.lk/2017/05/08/you-might-not-need-redux/

thedjinn• 9 years ago

I have been using React Native for a year now on a large project and came to the same conclusion. I find using Redux can quickly lead to over-engineered software.

As goes with every extra dependency: don't use it until you actually need it.

chrshawkes• 9 years ago

I've worked at one fortune 100 and one fortune 500 both using React and Redux. I second the notion that Redux is over complication.

linkmotif2• 9 years ago

I wish "Redux" would go away. It's the worst thing about the React ecosystem. I use quotes because it's not even much of a library. It's like 100 lines that no one needs because the abstraction they provide is leaky to the max (e.g. no support for nested denormalied data). And it comes with pages and pages of documentation that says little or even nothing while tricking newcomers into thinking they're learning something about a useful tool.

It's remarkable to me that real clients like Relay haven't caught on as much while Redux wastes so many peoples' time.

yesimahuman• 9 years ago

It's worked out really well for a large dashboard I'm working on. Compared to what we had before which was a mess of duplicated API calls in views with the same error handling code copy pasta'ed everywhere, with all different flavors of state management. It's not perfect (like the explosion of constants), but is probably 10x easier to maintain than what we had before.

I will say that using it by itself is probably going to be challenging. You'll want to use a connector library (like react-redux in this case), invest in some good API middleware, etc.

foodie_• 9 years ago

I hate to pile on, but we introduced react and redux at my startup and it (the project, not the company) largely failed due to the increased complexity of redux itself, and a coding style of hyper abstraction.

Maybe it works on large teams and code bases, but it is unnecessary on smaller teams where sane code practices are enough.

wildpeaks• 9 years ago

Personally, I kept the concept of unidirectional flow of data, but instead use a Web Worker as storage of state, which emits immutable props to render.

Components can post messages to the worker to request an action on the state that will most likely change its data, but they can't edit the data directly, and props are only emitted if there is really a change in data.

Inside the worker, state is stored as immutable data, and action handlers are only allowed to make one non-async change (because the return value is the modified state). If it needs to do multiple things (e.g. download then process the result), it must schedule another action when it's ready to do the sync operation. This splits into granular easy-to-test operations on the state.

That way, it limits React (or Preact) to rendering (so it can also be used with other libraries, e.g. WebGL), and you can record the messages going through the worker to replay and analyze a scenario.

So far I'm happy with this setup, but I can understand the allure of thirdparty libraries instead.

sb8244• 9 years ago

My use case for redux separates the state and view across a physical process boundary (and not for kicks). The store is crucial there because it gives a place to hook in as both a proxy and as a coordinator between the processes. This use case isn't normal but the recommended approach would not work without me reinventing all of those concepts at the end of the day.

Cymen• 9 years ago

I'm using redux both at my day job and on my side startup. For the day job, right now, it's simple enough we don't really need redux. But it was already in play when I joined and it's not really a bad thing in terms of team communication in code so... On my side startup, I definitely need redux. I have a lot of related data that is rendered in multiple ways and soon I'll be hooking up websockets and emitting changes from server-side that will flow into the client UI via redux to keep some things in sync.

Redux does add complication. But it also cleanly solves a big problem. I've heard good things about mobx instead of redux in terms of reducing boilerplate/total lines of code. So that might be one thing to try if starting a new project today or refactoring.

The purposed solution in the blog is pretty bad. It only works if you have a few things being updated. It might work fine for the author's use case but it's a bad idea to assume it will work well for all use cases. If you want to go this route, please try Backbone.js and come back when you get sick of ghost event listeners (event listeners that didn't get unbound). Obviously, there are ways to work around those issues but it requires understanding them (both by you and any other devs who join the project -- some with less experience might have no idea about these gotchas).

chacham15• 9 years ago

I noticed that fibers tests'[1] are at 100% passing, so I got excited for a second. Looks like this is in preparation of that.

[1] http://isfiberreadyyet.com/

amelius9• 9 years ago

Please consider to stop using/contributing to software of companies, if you don't agree with the way they conduct business or treat their users.

There are various open-source alternatives to React, which are not encumbered with underlying malpractices such as large-scale user-tracking, data silo lock-in, selling of data to advertisers.

coldtea6• 9 years ago

which are not encumbered with underlying malpractices such as large-scale user-tracking, data silo lock-in, selling of data to advertisers.

React is not encumbered by "large-scale user-tracking, data silo lock-in, selling of data to advertisers". Nor it is of any much benefit to Facebook whether devs adopt React or not. In the grand scheme of things, they could not care less.

Perhaps you meant for people to stop using Facebook instead?

Bahamut• 9 years ago

There is a sort of benefit to Facebook - React increases its prestige, which helps recruiting.

amelius9• 9 years ago

React is not encumbered by

Perhaps I should have chosen the words "funded by" instead. It shouldn't make a big difference to a reader willing to understand the true meaning of this appeal.

Nor it is of any much benefit to Facebook whether devs adopt React or not. In the grand scheme of things, they could not care less.

Open-source is not a uni-directional thing. Otherwise, why would companies like Facebook use it in the first place? There are numerous reasons why large companies are leveraging open source. See [1] for a list. Using React equals supporting Facebook.

Perhaps you meant for people to stop using Facebook instead?

That's like asking people to stop using telephone. Facebook has them locked in. There are alternatives to React, but there are no alternatives to Facebook (for most people).

[1] https://www.quora.com/Why-do-huge-profit-oriented-software-c...

eugeneionesco2• 9 years ago

Let me know when those "alternatives" are as good as React.

progx• 9 years ago

vue

voidr2• 9 years ago

Please consider to stop using/contributing to software of companies, if you don't agree with the way they conduct business or treat their users.

I'm of the opinion that we should separate the art from the artist.

If Facebook would discover the cure for all cancer and make it available freely to the world, would you still encourage people to not use it just because Facebook does user tracking(which is covered in their terms that you agree to when you sign up)?

amelius9• 9 years ago

I'm of the opinion that we should separate the art from the artist.

By using and supporting Facebook's open-source projects, you are supporting their bad practices indirectly. Separation is not really possible.

If Facebook would discover the cure for all cancer and make it available freely to the world, would you still encourage people to not use it just because Facebook does user tracking

Facebook does not have a cure for cancer. Perhaps if all the intellectual workforce that is now invoked to track users and please advertisers would be used to search for a cure instead, we would have a cure by now.

As an another analogy (as you brought one up) I'm not supporting banks and financial institutions that support the weapons industry, even if that bank provides the highest interest.

Also, like I said, there are alternatives, and they will become better when more people support them.

cutler• 9 years ago

If you want real state management with immutable data just use Clojurescript and Reagent. Leiningen will also free you from JS tooling hell.

linkmotif2• 9 years ago

What is remarkable is the onChange input event after all these releases is still being improved. This is a testament to how difficult it is to normalize browser differences and not some failing on the part of the React team and contributors. If only people knew how difficult this one little element can be. It's a shame it's so complicated.

minmaxmux• 9 years ago

Minus minus, is that automatic if you dare to criticise facebook ? Do I loose my facebook and instagram now also ?

React v15.6.0 Released

Related Stories