
What Are the React Team Principles? - danabramov
https://overreacted.io/what-are-the-react-team-principles/
======
danabramov
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.

~~~
jghn
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.

~~~
GordonS
I'm not sure I'd go as far as to put it as you do, but I take your meaning: a
couple of the principles I like to espouse are "no dogma" and "just because
you can, doesn't mean you should".

~~~
dwohnitmok
FWIW the second principle especially seems like a nondisagreeable principle. I
find it hard to think how a person would support the opposite. "Whenever you
can do something you should do that thing."

I suspect the motivation behind your statement is to trade this off against
experimentation, in which case a more disagreeable version of this statement
might be "we value conservatism of design over experimentation."

~~~
Viliam1234
> I find it hard to think how a person would support the opposite. "Whenever
> you can do something you should do that thing."

The person would probably phrase it like "you should always do the right
thing", and then argue why some things need to be done in a way other people
consider too complicated, because (1) it's possible to do it in a way that
satisfies some abstract principle, and (2) following the abstract principle is
the right thing.

For example "whenever it is possible to make a unit test for something, you
should do it", even in situations where team members would scream that you
really don't need a unit test to verify that 2+2=4. This would make sense as
an antidote towards the attitude that you don't really need to test simple
things, where the definition of "simple things" keeps expanding until almost
everything is considered a simple thing.

------
2Pacalypse-
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.

~~~
sb8244
I feel that hooks make it easy to go from functional component (simplest way
to get started) to stateful component without "rewriting" it to the class.
It's easy to do that rewrite, but painful when you have to do it back and
forth as you're playing around with component design.

That's represented in one of these principles.

~~~
ben_jones
I've found several "subtle" benefits from hooks in the way they can influence
more idiomatic code structure, for example "code smell" becomes more intense
and dictates more actions because when a function is > 100 lines of code it
sticks out like a sore thumb. It's also influenced us to put more business
logic into redux where (arguably) it belongs.

~~~
sb8244
My coworker showed me that hooks are just functions, so you can still pull
apart your functional components hooks into a bunch of imported or defined
functions.

Of course that doesn't help if you're still pulling in a lot of hooks, since
it's 1 line per hook minimum.

------
meesterdude
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
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
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
"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.

