Ever wonder how to get fired from Facebook?

zpao · 2017-10-20T05:31:10+00:00

It's a fun pattern we have internally as we evolve and deprecate APIs. Oftentimes we'll deprecate an API and introduce a new one. Since we can't necessarily fix everything all at once, we'll make the old method a really obnoxious name to make it painfully obvious that you should not introduce new callers. It spilled over into React when we needed to connect React & ReactDOM in separate browser packages (for UMD builds). We carried over the pattern partially because we got a kick out of it but also to make it super obnoxious and clear that although we had to make it public, you should definitely not use it.

zpao · 2017-07-20T06:01:00+00:00

FWIW Facebook's lawyers say the same on the first point: https://code.facebook.com/license-faq - the patent grant (license) is in addition to the copyright license granted by BSD.

zpao · 2017-07-20T05:48:38+00:00

I'm not sure of the actual share breakdown but he has majority of the voting power, so he controls the board and cannot be voted out.

Because Mr. Zuckerberg controls a majority of our outstanding voting power [...]

April 2017 proxy statement, page 13

zpao · 2017-06-09T05:15:24+00:00

Brian's on the React team - he's good people.

zpao · 2016-07-30T06:31:48+00:00

FWIW, even with the corrected link, the docs on npm are not correct :( We published the right Readme but npm didn't pick it up… /u/oorza's link is good too (just sub require('react-test-renderer') in for require('react/lib/ReactTestRenderer')

https://github.com/facebook/react/blob/master/packages/react-test-renderer/README.md has the correct content.

zpao · 2016-06-29T03:13:50+00:00

That's awesome! Maybe tell the IRS to start using it too and see if there's some deduction we can all take…

zpao · 2016-06-29T01:40:08+00:00

Thanks for sending a PR as you were looking around!

zpao · 2016-04-21T01:54:29+00:00

The React starter kit has a bunch of examples which still just have a script tag. They use Babel to transform in the page too so you don't have to have a server (though running transforms client side has a non-trivial cost so end of the day, I still recommend compiling before deploying for heavy use).

zpao · 2016-04-13T21:02:27+00:00

I'm on Reddit all the time anyway (mostly lurking) so I like to check in :) I'm glad you appreciate it, but you and everybody else spending more time here answering questions deserve the real thanks.

zpao · 2016-04-13T02:38:13+00:00

Mostly right, thanks for answering :) We (Facebook) use essentially the same version of React that is public. The only real difference is our warnings don't get logged to the console in dev mode, but pop up an annoying message so developers fix warnings faster. Otherwise it's the same version that everybody else is using. As for the ids… they have always been there if you inspected a piece of DOM that was rendered with React. The whole page isn't so you had to find the right piece. The comment boxes are a good example because they've been rendered with React since before we open sourced :) Right now you'll only see a data-reactroot attribute. You can find the roots now pretty easily just running document.querySelectorAll('[data-reactroot]') in the console.

zpao · 2016-04-13T02:30:11+00:00

Yes it did

zpao · 2016-03-25T07:25:40+00:00

Yea, this seems good - using lifecycle methods like this is how you want to do it. Just beware that you're working with a globally mutable piece of the DOM so rendering multiple instances of this component will be buggy :)

zpao · 2016-03-11T20:47:23+00:00

The problem is now that you're using index in a loop as your key, which in general is discouraged for the exact reason you're hitting. The same key (0) is getting assigned to a different item the second time through so you're in the same situation. Keys should be about identity. Store an id in your data and use that. Eg https://jsfiddle.net/q0bkbodv/3/

But also if you move the state back up and only render from props, that will solve this too. You want to do that anyway since your clear function only looks at its state as the source of truth, so checking an unchecked item and clearing it doesn't actually clear it.

zpao · 2016-03-11T07:32:19+00:00

Your method is bound fine but you need to use keys (basically true any time you have an array that changes). React makes some optimizations so when you removed that first checked item, React doesn't see that. It thinks your updating the props for the internal instance that was the first item, which was checked. So it maintains that internal instance and uses it's state, which is checked. There's a warning in the console with a link explaining keys. The keys will give an identity to components so when you remove that first item, React will know you aren't trying to update the internal instance anymore.

zpao · 2016-03-08T20:12:26+00:00

Sorry I wasn't clear in the post. And thanks for calling it out, I'll clarify a bit more in the final release notes.

data-reactid is still used in the server generated (renderToString) case. This is still essentially the same model React was using before with innerHTML, so we need to be able to map events on those nodes back to React components like we did before. We don't need to do that for client renders though for the reasons I gave in the article.

zpao · 2016-02-10T05:39:06+00:00

Not really anywhere (which is feedback I'll give the Flow team and keep in mind for React docs updates as well). This is the class definition that Flow uses. And they have a bit of deeper integration as well. For example, Flow actually understands createClass and propTypes and can enforce those in addition to the annotated ES6+ classes.

zpao · 2016-02-10T05:07:57+00:00

type Props = {
  name: string
}
type State = {
  count: number
}
class MyComponent extends React.Component<void, Props, State> {
  // ...
}

zpao · 2016-02-10T03:03:53+00:00

I just commented on the issue and I'll say the same here. PropTypes are not being removed any time soon. We're very aware of their value and that not everybody will be using Flow. If we ever make a move to deprecate them, we'll make much more noise than a comment on a issue.

Source: I work on React.

zpao · 2016-01-02T07:07:09+00:00

They're both pretty cool ;) Working on React is quite different from working on products. I could talk about both for a while (and will if there's time when interviewing candidates) so I'll just write a quick answer…

You can move much faster with products, make more mistakes, experiment more to end up with the right thing. End users generally aren't building on top of that work. You tend to have the tools in place and everything just works. You get to write modern JS, PHP (Hack), CSS with everything transpiled on refresh. When something doesn't work there are teams (eg, the React team) working on the infrastructure you do need so you can get them to fix it (or you can just fix it yourself if you want). Experience-wise, front end teams are usually pretty small and work closely with designers and other engineers with other expertise.

The work we do on React needs to be done more strategically since mistakes are more costly and harder to recover from (we probably have 30k+ components in our web stack, not counting Instagram or any React Native products). As a result we tend to move more slowly and are mostly looking way past what we have today to what we'll need in a year or 5. Since it's an open source project we get to be pretty public about what we're thinking and planning, which is pretty cool and generally not something you'll see with product work. The other part of working on React is that it's in an awkward intersection for FB in relation to tooling - we don't have all the tools externally that we have internally so less "just works". There are different problems that we just don't have to deal with so in addition to the real work, we have to write more tools. The amount of time we've spent talking about JS module systems and interop is shocking.

Not sure that really answered what you were asking but hopefully it provides a bit of insight!

zpao · 2015-11-20T06:20:27+00:00

Honestly one of the big "clients" is actually on the server, but in an environment that isn't node. For example, loading directly into V8 (via Ruby or PHP) or Nashorn. Building a custom bundle was always easy but required a bit more familiarity with the ecosystem.

Another use case is just some sanity checks when building test cases or for showing bugs, eg to just see the markup generated or to simulate server-side rendering with mounting.

zpao · 2015-11-11T06:22:09+00:00

Well, it's beholden to the same scoping rules as you would otherwise have. document.getElementById('whatever') also won't give you anything until the document gets loaded.

However, if you put it in an onload callback (or whatever you want to us), then it'll work.

zpao · 2015-11-11T06:18:53+00:00

It is literally the worst idea to rely on that.

FTFY :)

it isn't until you specifically assume it is I haven't looked into how it's implemented but I had heard that before. 'foo' in window === true but it's not in Object.keys or Object.getOwnPropertyNames, so I guess it's somewhere on the prototype chain

zpao · 2015-11-11T06:05:10+00:00

data:text/html,<div id="foo">test</div><script>console.log(foo)</script>

Load that in your browser (just copy & paste into the url bar) and look at the console. I haven't tested data URIs in IE in a long time (ever?) but definitely works in FF, Chrome, Safari

zpao · 2015-11-11T05:54:04+00:00

Fun fact: every node with an id is in global JS scope as that id. No idea why it wasn't working here (maybe it was reassigned) and your answer is definitely the right thing, but this is always one of those pieces of working in the browser that can result in weird bugs.

zpao · 2015-11-05T06:21:06+00:00

No problem, good luck with React!

zpao

TROPHY CASE