Hotswitch into core code#

If some pattern that is useful for building apps is hard to express in a declarative way, we will provide an imperative API for it. If we want to deprecate a pattern that we don’t like, it is our responsibility to consider all existing use cases for it and educate the community about the alternatives before we deprecate it. While it is influenced by some paradigms that are not yet fully mainstream such as functional programming, staying accessible to a wide range of developers with different skills and experience levels is an explicit goal of the project. It is driven by the needs of the products written at Facebook. You can find some of those discussions by the “big picture” label on the React issue tracker. We always discuss such improvement proposals with the community. State, lifecycle methods, cross-browser event normalization are good examples of this. When we do it, it’s because we are confident that raising the abstraction level benefits the whole ecosystem. If we notice that many components implement a certain feature in incompatible or inefficient ways, we might prefer to bake it into React. This is why sometimes we add features to React itself. It has to work with the lowest common denominator. When there are multiple abstractions competing, React can’t enforce or take advantage of the properties of either of them. However, there are exceptions to this.įor example, if React didn’t provide support for local state or lifecycle methods, people would create custom abstractions for them. We don’t want to bloat your apps with useless library code. In general we resist adding features that can be implemented in userland. It is possible that those ideas might make it back into React too in some form.

Some external libraries like Relay augment components with other responsibilities such as describing data dependencies. In React, components describe any composable behavior, and this includes rendering, lifecycle, and state. We might enable more functional patterns in the future, but both local state and lifecycle methods will be a part of that model.Ĭomponents are often described as “just functions” but in our view they need to be more than that to be useful. On the contrary, we think they are integral parts of what makes React useful. Like any powerful feature, they should be used in moderation, but we have no intention to remove them.

There is nothing “bad” about using state or lifecycle methods in components.

Hotswitch into core code#

Similarly, it should be possible to add some initialization and teardown code to any component when necessary. It is important to us that you can add functionality to a component without causing rippling changes throughout the codebase.įor example, it should be possible to introduce some local state into a component without changing any of the components using it.

Components written by different people should work well together. The key feature of React is composition of components. It describes the design principles of React itself, not React components or applications.įor an introduction to React, check out Thinking in React instead. This document assumes a strong understanding of React. While we are excited to see community contributions, we are not likely to choose a path that violates one or more of these principles. We wrote this document so that you have a better idea of how we decide what React does and what React doesn’t do, and what our development philosophy is like.