what code was being used to generate this value To do that, you are going to right-click/inspect element and look at it in the browser Then, you’re going to ﬁnd something as unique as possible and grep it on your entire codebase It’s a bit of an hit & miss process, sometimes “todo-count” will give you the right code, sometimes not
tools. This gives you the React component that was used to generate it. Since at Facebook, all the React components are uniquely named, you can directly open the ﬁle and be set. Dev tools are also really nice as you can live update props on state on the right panel
• Backward in time • Jump to updates The issue with debuggers is that they are not really useful for this use case. We are at the end of the execution and we want to know what happened to that variable in the past so that it got assigned this value Also, the debugger is executing every single line, but you want to jump directly to the place the variable got modiﬁed
is a state variable and you are not taking special care, then your search space is basically the entire code base. This was the source of soooo many issues at Facebook that in React we decided to treat it in a special way.
the Component ! 1 ﬁle < 1000 lines We imposed one constraint on state variables is that they belong to a component, and only the component can modify them. This greatly reduce the search space to just one ﬁle
the Component ! 1 ﬁle < 1000 lines getInitialState() setState() ! < 10 lines Still, one ﬁle is pretty big. We restricted state updates further so that you can only modify them via two functions: getInitialState() and setState(). Since there are only a couple of call sites in a ﬁle, it’s now very tractable for a developer
If you are into a normal component, you shouldn’t have more than a couple of call sites, but if you are looking at a core component, then it can get in the dozens or hundreds and become hard to identify which one it is
Automatically inherit props Call sites and their call sites and … . If you have to pass a props from a grand parent to a child, then it starts adding a bit of boilerplate. Many people ask us why we don’t implement props that are automatically inherited like scope in Angular. The reason is that you now have to check all the possible ancestors of your component which can be a —lot— of ﬁles And as a corollary, when you want to update one of the top level ﬁles, it’s really hard to know all the components that depends on it, and therefore test them all to make sure your ﬁx worked
component props It turns out that they both converge into a place where we are typing function arguments. If you think about it, a React component can be seen as a function and its props as arguments. So it actually makes sense to type props
we could support jQuery way of building virtual DOM nodes. We support two DSLs natively and CoffeeScript & ClojureScript communities came up with several others. However, jQuery has a very different property, it doesn’t come with a way to say that the node is completed
modify the element after it was created, then whenever you pass it to a function you have no idea if that function is going to modify it or not. Meaning that you’ve got to check the entire call tree. This was a major source of bug at Facebook
means that if you call a function with an element, if it modiﬁes it, then it needs to return it. Since 99% of the time it doesn’t modify it, then you can skip a large numbers of calls when troubleshooting. This is also a good example of using immutability in JS and not some very different language such as lisp or haskell
before it goes to prod! Conclusion We’ve got a moto at Facebook which is Move fast & break thing. The other side of that sentence is that we invest a lot in detection and once known, we need to be able to ﬁx it fast, and hopefully before the users can see it. Again, we don’t know how to make it faster but we can make it more predictable.
Not introducing another bug with your ﬁx Conclusion The ﬁrst source of unpredictability is ﬁnding the root cause of the bug, but we covered this in the talk. Then, you need to come up with a ﬁx, in practice as engineers this is what we do best. Finally, the worst thing you can do is to come up with a ﬁx that causes another bug. It turns out that all the steps we did to improve tracing back when a variable was modiﬁed also helps when making a change to make sure that it doesn’t introduce unintended side effects