9 ms·

What Are the React Team Principles?

121 points by danabramov 7y ago

danabramov 7y ago
I’d be really curious to hear principles from other teams. They’re not always explicit, but I found that teams working on something for a long term often have some. One interesting thing Sophie mentioned is that principles should be disagreeable, i.e. not universally accepted truisms. For example, I can flip around most of these and they would still represent a legit (but very different) approach to building a UI framework.
- Waterluvian 7y ago
  To me it's about getting everyone in a boat to row in the same direction. Every boat can row in different, equally valid directions, given they may have different goals. To stretch this analogy, the less disagreeable "truisms/rules" that need to be followed are things like, the boat needs to be buoyant, you need to bring paddles, don't stand up, etc. I'm probably referring to the presence of documentation, reviews, testing, etc.
- solidist 7y ago
  E.g. yes, What is the self correction method of said principles of teams? One of struggle :) I haven't seen many teams write down their philosophies (principles), but the force is there. From this write, it is very obvious this is a very mature team. Most of what I've experienced is tribal knowledge and shared conversations. Decisions are weighed at design time and code review and shared this way. The principles I've seen are generally known to engineers without the team knowledge. For instance in one team they built apis weighed against principle of least privledge. It would be good to investigate further. Maybe encourge the team to write down the philosophies and re-review after some interval, business change, or if new members join.
- jghn 7y ago
  Similar to your disagreeable point, I like to see contradictions within a set of principles. This helps to capture the reality that nothing is perfect and one is always just trying to optimize for multiple competing variables. Over optimize for one variable and you're making another worse.
  - dwohnitmok 7y ago
    Eh... Contradictions by themselves often times end up devolving into "undisagreeable" principles very easily. Principles are a tool precisely for arbitrating among multiple, competing "good" things. They are how you solve contradictions. Indeed I have often seen good principles framed as choosing A over B when they conflict with each other where A and B are both things people reasonably want. For example, "We value code quality while also balancing practical velocity." Well yes I'd imagine every single team in the world agrees with that. That doesn't tell me very much. "We focus on code quality over practical velocity." Interesting; I now have a valuable piece of information as to whether I want to work with you, depending on other specifics of the project. "We focus on practical velocity over code quality." Also interesting and very informative for me and a good indicator of whether I want to work with you. Now you might argue that no team will phrase things in such stark terms, because this oversimplifies things. That's a good indication that maybe these aren't fundamental principles you should commit to writing and instead you should look at others. Alternatively maybe you just need to add a bit of nuance. "We're willing to commit months to getting a new feature right from a technical perspective but not years" vs "We aren't willing to commit any more than a span of a few weeks at most" is more nuanced but still has great information value. It's also worth pointing out your principles can't cover everything. The occasional "yes I know we generally value code quality but we just really need to ship this now" or "yes I know we generally value velocity but this feature needs to be done absolutely right" is okay as long as it's truly occasional. Sometimes you have to just go with some set of unwritten rules, otherwise you'll fall into the trap of "principles lawyering." The point of having disagreeable principles is that they give valuable information and insight. Principles that everyone agrees with basically amount to "we try to be good at things not bad at things" which doesn't help anything. If this happens in management this becomes the bland mission statements and culture statements I'm sure everyone has seen before. We value integrity and transparency in the workplace! And exactly who is ever going to publicly announce the opposite (on the other hand this makes the opposite statement a very very valuable principle, albeit one that probably will cause very few people to want to work with you)? We strongly value transparency over social comfort in the workplace, to the point that we publicize within our company all performance reviews, formal reprimands, pay raises and current salary of everyone in the company. Well that's a way more interesting principle. Agree with it or not, it tells me so much more. If your principles don't make some set of reasonable people say "nope that's not for me" then they probably aren't very useful.
- pcmaffey 7y ago
  Yes, one of my principles is “dev before design” which is a slightly different vector than UI before API, but a similar enough reversal that demonstrates your very good point about flipping / disagreeable principles.
- closed 7y ago
  You might be interested in the design principals of the tidyverse, a group of R packages built to support data analysis. https://design.tidyverse.org/unifying-principles.html https://design.tidyverse.org/unifying-principles.html One emphasis of theirs that I find really powerful is the "pit of success", where the least effort action moves toward a positive outcome. Broader overview of tidyverse here: https://tidyverse.tidyverse.org/articles/paper.html https://tidyverse.tidyverse.org/articles/paper.html
2Pacalypse- 7y ago
I'd be interested to hear a practical example of these principles applied. For example, how do these principles lead to the creation of hooks API? I'm not trying to say they don't, just genuinely curious. As someone who has been using React for five years and especially liked it for its simple class API to write components, I was a bit taken aback by the introduction of a new powerful API that is incompatible with the simple class API.
- acemarke 7y ago
  The primary point of hooks was to give function components the same capabilities that classes already had. In that respect, letting classes use hooks would have been superfluous. At the same time, the React team _could_ have chosen to implement support for hooks in classes, but chose not to, both for simplicity and as a carrot to encourage folks to use function components where possible. Based on the discussions and examples I've seen, capabilities like Concurrent Mode and Fast Refresh work better with function components because there's fewer edge cases to worry about. While classes aren't going away in the foreseeable future, there's valid reasons to try to get the community to adopt function components more.
  - 2Pacalypse- 7y ago
    Well, as far as my understanding of hooks go, and please do correct me if I'm wrong, hooks are not just about giving functional component an option to use state and lifecycle methods. They are also a much more powerful and flexible replacement of mixins and offer an (arguably better) alternative to use certain design patterns, like render props. I did assume that hooks were not supported in classes because it would be too complex to support that use-case, but the linked article specifically has an "Absorb the Complexity" principle, so it seemed a bit weird to me. Also, I understand the decision to try to motivate the community to use function components more, but is this the trend that we can expect to continue seeing in React? Certain APIs being phased out until they finally become deprecated. I know it has happened a few times already in React, but not on the level of something like a class API.
- sb8244 7y ago
meesterdude 7y ago
I prefer the rails doctrine https://rubyonrails.org/doctrine/ https://rubyonrails.org/doctrine/ for both the original perspectives it holds, and because they are deeply ingrained in the framework - not just platitudes.
Ididntdothis 7y ago
I like the paragraph "Trust the Theory". I know long term planning is totally unfashionable these days but I always find it pleasant to have a rough idea where I want to be in a few years. It's so much easier to make short term or mid term design decisions if you know the long term plan. Add: I think the whole article is very good for teams that work on a framework and how to evolve it long term. I am usually not a friend of Javscript but the section about hacks made me think that Javascript is actually a good language too enable hacks. this is much more difficult in a C++ environment where you tend to be very strict.
- yazaddaruvala 7y ago
  I’m torn about “Trust the theory” as it’s currently written. I think the spirit of it is correct but the way it is currently written is missing the part about when/how to reevaluate. While an idea can be perfect, it might still be the wrong timing. Theory can sometimes become a dream instead and chasing a dream could waste a lot of time and the project can get left behind. As it is currently written, that principle could ruin a project.
  - Ididntdothis 7y ago
    "I think the spirit of it is correct but the way it is currently written is missing the part about when/how to reevaluate." I guess we should add "Use common sense, be self critical and have taste". that's the one thing that bothers me about today's development practices. They all seem to want 100% bullet proof instructions what to do when. There is no such thing.

121 points by danabramov 7y ago

I’d be really curious to hear principles from other teams. They’re not always explicit, but I found that teams working on something for a long term often have some. One interesting thing Sophie mentioned is that principles should be disagreeable, i.e. not universally accepted truisms. For example, I can flip around most of these and they would still represent a legit (but very different) approach to building a UI framework.

Waterluvian 7y ago
To me it's about getting everyone in a boat to row in the same direction. Every boat can row in different, equally valid directions, given they may have different goals. To stretch this analogy, the less disagreeable "truisms/rules" that need to be followed are things like, the boat needs to be buoyant, you need to bring paddles, don't stand up, etc. I'm probably referring to the presence of documentation, reviews, testing, etc.
solidist 7y ago
E.g. yes, What is the self correction method of said principles of teams? One of struggle :) I haven't seen many teams write down their philosophies (principles), but the force is there. From this write, it is very obvious this is a very mature team. Most of what I've experienced is tribal knowledge and shared conversations. Decisions are weighed at design time and code review and shared this way. The principles I've seen are generally known to engineers without the team knowledge. For instance in one team they built apis weighed against principle of least privledge. It would be good to investigate further. Maybe encourge the team to write down the philosophies and re-review after some interval, business change, or if new members join.
jghn 7y ago
Similar to your disagreeable point, I like to see contradictions within a set of principles. This helps to capture the reality that nothing is perfect and one is always just trying to optimize for multiple competing variables. Over optimize for one variable and you're making another worse.
- dwohnitmok 7y ago
  Eh... Contradictions by themselves often times end up devolving into "undisagreeable" principles very easily. Principles are a tool precisely for arbitrating among multiple, competing "good" things. They are how you solve contradictions. Indeed I have often seen good principles framed as choosing A over B when they conflict with each other where A and B are both things people reasonably want. For example, "We value code quality while also balancing practical velocity." Well yes I'd imagine every single team in the world agrees with that. That doesn't tell me very much. "We focus on code quality over practical velocity." Interesting; I now have a valuable piece of information as to whether I want to work with you, depending on other specifics of the project. "We focus on practical velocity over code quality." Also interesting and very informative for me and a good indicator of whether I want to work with you. Now you might argue that no team will phrase things in such stark terms, because this oversimplifies things. That's a good indication that maybe these aren't fundamental principles you should commit to writing and instead you should look at others. Alternatively maybe you just need to add a bit of nuance. "We're willing to commit months to getting a new feature right from a technical perspective but not years" vs "We aren't willing to commit any more than a span of a few weeks at most" is more nuanced but still has great information value. It's also worth pointing out your principles can't cover everything. The occasional "yes I know we generally value code quality but we just really need to ship this now" or "yes I know we generally value velocity but this feature needs to be done absolutely right" is okay as long as it's truly occasional. Sometimes you have to just go with some set of unwritten rules, otherwise you'll fall into the trap of "principles lawyering." The point of having disagreeable principles is that they give valuable information and insight. Principles that everyone agrees with basically amount to "we try to be good at things not bad at things" which doesn't help anything. If this happens in management this becomes the bland mission statements and culture statements I'm sure everyone has seen before. We value integrity and transparency in the workplace! And exactly who is ever going to publicly announce the opposite (on the other hand this makes the opposite statement a very very valuable principle, albeit one that probably will cause very few people to want to work with you)? We strongly value transparency over social comfort in the workplace, to the point that we publicize within our company all performance reviews, formal reprimands, pay raises and current salary of everyone in the company. Well that's a way more interesting principle. Agree with it or not, it tells me so much more. If your principles don't make some set of reasonable people say "nope that's not for me" then they probably aren't very useful.
pcmaffey 7y ago
Yes, one of my principles is “dev before design” which is a slightly different vector than UI before API, but a similar enough reversal that demonstrates your very good point about flipping / disagreeable principles.
closed 7y ago
You might be interested in the design principals of the tidyverse, a group of R packages built to support data analysis. https://design.tidyverse.org/unifying-principles.html https://design.tidyverse.org/unifying-principles.html One emphasis of theirs that I find really powerful is the "pit of success", where the least effort action moves toward a positive outcome. Broader overview of tidyverse here: https://tidyverse.tidyverse.org/articles/paper.html https://tidyverse.tidyverse.org/articles/paper.html

2Pacalypse- 7y ago

I'd be interested to hear a practical example of these principles applied. For example, how do these principles lead to the creation of hooks API? I'm not trying to say they don't, just genuinely curious. As someone who has been using React for five years and especially liked it for its simple class API to write components, I was a bit taken aback by the introduction of a new powerful API that is incompatible with the simple class API.

acemarke 7y ago
The primary point of hooks was to give function components the same capabilities that classes already had. In that respect, letting classes use hooks would have been superfluous. At the same time, the React team _could_ have chosen to implement support for hooks in classes, but chose not to, both for simplicity and as a carrot to encourage folks to use function components where possible. Based on the discussions and examples I've seen, capabilities like Concurrent Mode and Fast Refresh work better with function components because there's fewer edge cases to worry about. While classes aren't going away in the foreseeable future, there's valid reasons to try to get the community to adopt function components more.
- 2Pacalypse- 7y ago
  Well, as far as my understanding of hooks go, and please do correct me if I'm wrong, hooks are not just about giving functional component an option to use state and lifecycle methods. They are also a much more powerful and flexible replacement of mixins and offer an (arguably better) alternative to use certain design patterns, like render props. I did assume that hooks were not supported in classes because it would be too complex to support that use-case, but the linked article specifically has an "Absorb the Complexity" principle, so it seemed a bit weird to me. Also, I understand the decision to try to motivate the community to use function components more, but is this the trend that we can expect to continue seeing in React? Certain APIs being phased out until they finally become deprecated. I know it has happened a few times already in React, but not on the level of something like a class API.
sb8244 7y ago

meesterdude 7y ago

I prefer the rails doctrine https://rubyonrails.org/doctrine/ https://rubyonrails.org/doctrine/ for both the original perspectives it holds, and because they are deeply ingrained in the framework - not just platitudes.

Ididntdothis 7y ago

I like the paragraph "Trust the Theory". I know long term planning is totally unfashionable these days but I always find it pleasant to have a rough idea where I want to be in a few years. It's so much easier to make short term or mid term design decisions if you know the long term plan. Add: I think the whole article is very good for teams that work on a framework and how to evolve it long term. I am usually not a friend of Javscript but the section about hacks made me think that Javascript is actually a good language too enable hacks. this is much more difficult in a C++ environment where you tend to be very strict.

yazaddaruvala 7y ago
I’m torn about “Trust the theory” as it’s currently written. I think the spirit of it is correct but the way it is currently written is missing the part about when/how to reevaluate. While an idea can be perfect, it might still be the wrong timing. Theory can sometimes become a dream instead and chasing a dream could waste a lot of time and the project can get left behind. As it is currently written, that principle could ruin a project.
- Ididntdothis 7y ago
  "I think the spirit of it is correct but the way it is currently written is missing the part about when/how to reevaluate." I guess we should add "Use common sense, be self critical and have taste". that's the one thing that bothers me about today's development practices. They all seem to want 100% bullet proof instructions what to do when. There is no such thing.