brianvaughn

7 ms·

1.
by brianvaughn 7y ago
Thank you for elaborating.
2.
by brianvaughn 7y ago
Glad the tutorial is helpful! :) It was a last minute idea and I'm excited about how it turned out.
3.
by brianvaughn 7y ago
That's definitely not the intent.
4.
by brianvaughn 7y ago
It's a little scary to upload a completely new version, when you know there's that many weekly active users that are going to be hammering away on it soon.
5.
by brianvaughn 7y ago
> but Facebook is the last company I'd want to have the obscene privileges that extensions have. reply Sounds like you're talking about extensions in general , but for what it's worth- React DevTools doesn't require
6.
by brianvaughn 7y ago
You might still check out DevTools at some point :) They do a lot of small things that can be nice.
7.
by brianvaughn 7y ago
Doesn't sound like it. React DevTools uses the `postMessage` API to communicate, not websockets.
8.
by brianvaughn 8y ago
Sunil has also worked at Yahoo on maps.yahoo.com, specifically on tooling to manage styling.
9.
by brianvaughn 8y ago
> s everybody knows about the implicit context(s) that also affect component behavior. Just in case there's any misunderstanding- (I don't think there is, but just being safe)- context isn't implicit. You have to opt into
10.
by brianvaughn 8y ago
Yes, but then that prop would need to be passed down explicitly through every component. This would require a _lot_ of boilerplate.
11.
by brianvaughn 8y ago
> In your experience, what are the kind of things that people do in `componentWillMount` that they shouldn't be doing? The biggest one is probably adding event listeners or setting up subscriptions (which can cause memory leaks). He
12.
by brianvaughn 8y ago
I'm not sure why you would need to upgrade your app in that case. Is the problem that our documentation only reflects the latest release?
13.
by brianvaughn 8y ago
Upgrading any project after 3 years of inactivity would be difficult, regardless of framework. I did not mean to imply that you would need to step through every minor version though. I was just saying that- if you were using e.g. 15, update
14.
by brianvaughn 8y ago
> Well, I tend to make a lot of very small stateless components. If a component is 1-6 JSX tags, the new context API represents a boilerplate overhead of between 100 and ~17%. Not if you use a HOC (e.g. `withContext(Component)`) like a c
15.
by brianvaughn 8y ago
I'm curious why the theme example I mentioned in my earlier comment- (and showed in the docs)- doesn't qualify as "useful" to you. Another example would be using context to share the selected language/locale between
16.
by brianvaughn 8y ago
> I guess I should start using componentDidUpdate instead? Sounds like it, based on your description! > The other case of componentWillReceiveProps usage I see is where there is computationally expensive derived state, but for some re
17.
by brianvaughn 8y ago
Lifecycles aren't mandatory in React. Pure functional components don't use them. Stateful class components don't necessarily need them either (although they _can_ be useful, particularly when interfacing with imperative APIs
18.
by brianvaughn 8y ago
I don't think we know enough about where compilation will end up to comment much. I wouldn't expect TypeScript to be negatively affected though (since it compiles to JavaScript). So far, the problems we're noticing are from c
19.
by brianvaughn 8y ago
The `withTheme` HOC uses `createContext` and `forwardRef`. I don't think it's contrived. :) https://reactjs.org/blog/2018/03/29/react-v-16-3.html#forwar...
20.
by brianvaughn 8y ago
> From the outside, having seen Fiber slated for release in 16.0.0 and, being pushed back to an unknown 16.x release, and then being pushed back to 17.0.0, it seems like you had not anticipated the extent to which the core React API had
21.
by brianvaughn 8y ago
> However, the amount of large internal changes indicates that as you improve and (most likely) shed unneeded complexity, that there must have been complexity to shed. The v16 rewrite (dubbed "fiber") wasn't just about cle
22.
by brianvaughn 8y ago
No, but you could do it in a similar way as the "Dynamic Context" example [1] - store the authenticated user/status in component `state` and pass it down via a AuthenticationContext.Provider. Then anything that needs to know
23.
by brianvaughn 8y ago
Our upgrade process is very gradual. As long as you've fixed all of the dev warnings for the last minor release of a given version, you should be able to upgrade to the next major without any problem.
24.
by brianvaughn 8y ago
Would you elaborate on what you find clunky about the new context API? :)
25.
by brianvaughn 8y ago
The purpose of componentWillReceiveProps was to update state in response to props changes. (This is also the purpose of getDerivedStateFromProps.) What you're describing sounds more like you're updating something external (e.g. yo
26.
by brianvaughn 8y ago
HOCs are widely used (and for good reason– they can be very useful). Hopefully forwardRef will make their usage more consistent and predictable. If anything, I think the new context API (and even forwardRef itself) are endorsements of the r
27.
React v16.3.0: New lifecycles and context API(reactjs.org)
241 points by brianvaughn 8y ago|129 comments
28.
by brianvaughn 8y ago
We are trying to strike a balance between supporting huge legacy apps that cannot be rewritten- (something Facebook has a lot of)- and encouraging safe/bug-free coding practices for future apps. In this case, we felt the right balance
29.
by brianvaughn 8y ago
One of the main focuses of 16.3 is to enable open source libraries to update their code in advance of deprecation warnings. (We're trying to go one step beyond SEMVER- so that application developers don't have to be bothered by wa
30.
by brianvaughn 8y ago
This was implied but not explicitly covered in the blog post. I updated it this morning to be more explicit [1]! > You may notice in the example above that props.currentRow is mirrored in state (as state.lastRow). This enables getDerived

More ›