Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React v15.5.0

facebook.github.io

Post reply on HN
Print view View original

111–120 of 209 posts

Re: React v15.5.0

#111

Post by asdfgadsfgasfdg »

baron816 wrote: post #58
nostrademons wrote: post #47

Earlier quoted context omitted.

This is the RevealingModulePattern that Crockford used to advocate back in the day, except assigning to an object that React creates instead of one you create.. http://javascript.crockford.com/private.html https://addyosmani.com/resources/essentialjsdesignpatterns/b... Be aware that memory usage can quickly balloon with this pattern, because the GC needs to keep alive anything referenced from inside the closure, incl…

Sorry, I was getting down voted a lot. I restored the code. I'm pretty sure Crockford still pushes this. https://weblogs.asp.net/bleroy/crockford%E2%80%99s-2014-obje... It does eat up more memory, but as Crockford says, memory is cheap. It's not likely that it'll cause a problem.

Memory is not cheap for your users. If your webapp (or worse webpage) burns through their memory they will come to regard it as slow, bloated and heavy and close the tab never to return.

Re: React v15.5.0

#112

Post by sjellis »

debaserab2 wrote: post #59
Silhouette wrote: post #55

Earlier quoted context omitted.

All current browsers support ES6. That's debatable, particularly when you factor in bugs. However, even if they did, it seems unwise to assume that all relevant users for all or even most projects will be on the latest evergreen browsers. Several large groups, including business users on IE and mobile users on slightly older devices, probably won't be. I know there's a certain type of web developer who would love for…

This is a common theme I'm noticing a lot lately. Meanwhile, I check my product's browser breakdown and IE9/10 is still too significant to ignore. There's just no way our customers would be okay with this. Many are still locked on older IE versions due to (bad) corporate policies. I can't strongarm them into upgrading. Which leads me to wonder: are developers that are so willing to advocate breaking compatibility wit…

I think that there is a real split between consumer and corporate at this point (certainly in the West). Some managed corporate setups are definitely still on old versions of IE, but for everyone else, the path of least resistance has been auto-updated platforms for a while now (Windows 10 + Edge, iOS, Chrome, Firefox).

Recently, I updated the browser support docs for my employer, and was surprised to note that IE11 is now the oldest browser with standard vendor support, so everybody on older versions of IE is either working for a company with specific extended support contracts with Microsoft, or they are running with no support at all.

Re: React v15.5.0

#113

Post by spicyj »

wesleytodd wrote: post #91
STRML wrote: post #25

This is a big deal to deprecate `createClass` and `propTypes`. PropTypes' deprecation is not difficult to handle, but the removal of createClass means one of two things for library maintainers: (1). They'll depend on the `create-class` shim package, or, (2). They must now depend on an entire babel toolchain to ensure that their classes can run in ES5 environments, which is the de-facto environment that npm modules ex…

I agree, I am really concerned about this change. But unfortunatly I do not think my feedback via twitter was well taken: https://twitter.com/wesleytodd/status/850550711804989440 EDIT: I should add, that I didn't want to say that I completely disagree with the change to remvoe this api entirely on twitter to the maintainers. I am sure they get enough crap from people.

Thanks for the feedback, we do appreciate it.

Re: React v15.5.0

#114

Post by jozan »

tekacs wrote: post #100
STRML wrote: post #26

Earlier quoted context omitted.

I was in awe the entire time Lin was speaking. Not a single "um" or other verbal tic; she's an incredible speaker and was admirably lucid throughout that entire talk. That's so difficult to do. And style aside, she made understanding Fiber incredibly simple. Just wanted to express my admiration for her work and gratitude for making this information public, available, and free.

As someone who talks quite (very?) fast and has to carefully slow down for public speaking... ... I found Lin's style of speaking very difficult to listen to. I appreciate the professionalism of the approach (if that's what it is), but if only by a small margin (perhaps 10-20%), I found her speaking too slow to the point that I wanted to skip forward constantly and would have found it difficult to pay attention to in…

Youtube player has a setting for playback speed. I almost always watch YT videos in 2x speed or more.

Re: React v15.5.0

#115

Post by skrebbel »

STRML wrote: post #44
fiatjaf wrote: post #35

Earlier quoted context omitted.

Are you afraid of Babel monopoly? I recommend trying https://buble.surge.sh/ . My life is much better after I started using Buble and bubleify instead of this mess that is Babel.

Come on. Buble is Babel, just with a few presets hardcoded. Yeah, it's better usability, until you need to run a production application.

Why do you lie?

Re: React v15.5.0

#116

Post by domlebo70 »

STRML wrote: post #34
ggregoire wrote: post #4

For those still using propTypes, I'd recommend to take a look at Flow as replacement. https://flow.org/en/docs/frameworks/react

We use Flow everywhere now and love it. It's not perfect by any means but it's a lot easier to use than Java's static typing and a lot more expressive to boot. I can't overstate how great it is to be able to strongly type your modules and ensure you don't send the wrong input or receive the wrong input from them. In fact, Flow allows us to confidently implement APIs that would just be cumbersome otherwise; we can use…

> This has the incredible effect of making it a type error if you try to execute an action that doesn't exist.

I don't want to start a "JavaScript is bad" flamewar, but it's sad that there is an entire class of problems that we as software developers are solving, where simple type checking seems amazing

Re: React v15.5.0

#117

Post by peterhunt »

thatswrong0 wrote: post #48
nodesocket wrote: post #2

Big news seems to be removal of `React.createClass()` in favor of: class HelloWorld extends React.Component { }

Mild rant: I'm not convinced ES6 classes are better than components created the old way. First, the lack of autobinding callback functions for child props is not ideal. I don't even have to think about it with createClass, and it requires at least one extra step with ES6. It's less convenient. Second, I don't think HOCs are necessarily easier to reason about than mixins in many situations. React is already quite defi…

I was the guy who came up with autobinding in older Reacts and I'm glad to see it gone. It might save you a few keystrokes but it allocates functions that'll never be called in 90% of cases and has noticeable performance degradation. Getting rid of autobinding is a good thing.

Re: React v15.5.0

#118

Post by peterhunt »

thatswrong0 wrote: post #48
nodesocket wrote: post #2

Big news seems to be removal of `React.createClass()` in favor of: class HelloWorld extends React.Component { }

Mild rant: I'm not convinced ES6 classes are better than components created the old way. First, the lack of autobinding callback functions for child props is not ideal. I don't even have to think about it with createClass, and it requires at least one extra step with ES6. It's less convenient. Second, I don't think HOCs are necessarily easier to reason about than mixins in many situations. React is already quite defi…

w.r.t. mixins vs HOCs

Mixins don't compose safely and were always kind of a hack.

HOCs are also kind of a hack, but at least they behave predictably (i.e. they do compose).

I don't really get the argument that React lacks testing infra. I know a lot of people say this but no one has talked me through an example yet.

Re: React v15.5.0

#119

Post by cormacrelf »

linkmotif wrote: post #81
fiatjaf wrote: post #36

Earlier quoted context omitted.

Yeah, in the beggining there wasn't autobinding, if you remember well. Then comes autobinding, now there's no autobinding anymore.

Yeah I still use `React.createClass({})` because... autobinding. Also wish someone would explain the draw of ES6 classes. React is about composition, not inheritance. Have never seen a `React.Component` extended.

Basically nobody does this, as far as I know. I think some of the big component authors like Wijmo do, but not most people, it's way too messy.

The composition is usually in the form of higher order components. It's very simple to wrap a function with another one, with more or different functionality. Classes just make it equally as simple when the wrapped component has its own state to manage.

Point is, nobody really cares whether they're ES6 or createClass, because nobody's actually doing inheritance. It's just that we JS devs like to stay on the bleeding edge, and we like to think that we're converging on standards even if that's a silly dream.

Example: show a spinner for 1 second before displaying.

    const F = (props) => {props.content};

    class C extends React.Component {
      state = { initial: "state" };
      render = () => {this.state.initial};
    }

    function delayWithSpinner(WrappedComponent) {
      return class extends React.Component {
        state = { showSpinner: true };
        stop = () {
          this.setState({ showSpinner: false });
        }
        render() {
          return this.state.showSpinner
            ? 
            : 
        }
      }
    }

    // exactly the same composition pattern for
    // both classes and functions.
    const SlowC = delayWithSpinner(C);
    const SlowF = delayWithSpinner(F);

Re: React v15.5.0

#120

Post by algesten »

gavinpc wrote: post #71
thatswrong0 wrote: post #48

Earlier quoted context omitted.

Mild rant: I'm not convinced ES6 classes are better than components created the old way. First, the lack of autobinding callback functions for child props is not ideal. I don't even have to think about it with createClass, and it requires at least one extra step with ES6. It's less convenient. Second, I don't think HOCs are necessarily easier to reason about than mixins in many situations. React is already quite defi…

I felt the same way and avoided `class` for mostly the same reasons. For better or worse, there are many ways to make pseudo-classes using Javascript. Is prototype configurable? Writable? Enumerable? What about the properties of prototype? Are they configurable? Enumerable? Writable? And there are still people who clobber the default prototype, killing its `constructor` and changing the above. And that's just one lev…

I'm one of those people that still use coffeescript (if I'm going to transpile anyway, I'd rather use a language I like).

I use coffeescript classes as components without any problem and that inserts an "extends" function into every compiled .js-file that has a class.

I suspect people that need ES5/ES6 compatibility that currently rely on React.createClass as a peer dependency can switch to maintaining their own createClass function local to the project. Suboptimal, but not a lot of code.

Post reply on HN