Cultural Differences in Naming
This blog examines the cultural differences in naming between Facebook and the outside community. It also looks at the use of 'isomorphic' code and the implications of 'reducers'.
дэн
the results are always perfect
-
this hack is funny to me because it illustrates a cultural difference in naming at FB and outside. (tiny thread) https://t.co/ciT8hdhp7F
— дэн (@dan_abramov) March 16, 2023 -
in the community, this hack is called useIsomorphicLayoutEffect. this sounds science-y and convoluted, which of course perfectly matches the less charitable view of our community (for another example, i think andrew and i are both sorry for the “reducers” :)
— дэн (@dan_abramov) March 16, 2023 -
when running same JS on the server and the client (SSR) was getting popular, someone called that “isomorphic” (~ same-shaped) code, and people rolled with it for a while. but it’s a confusing word, so there was an attempt to rebrand it as “universal”. https://t.co/FAmySMs6e8
— дэн (@dan_abramov) March 16, 2023 -
both terms have stuck. with time, it got frustrating enough to still use both terms at the same time (just in case!), i feel like we’ve collectively decided to memory-hole these terms and pretend they never happened. pic.twitter.com/MH3ADoEFUr
— дэн (@dan_abramov) March 16, 2023 -
so that’s why someone called it useIsomorphicLayoutEffect. it’s like useEffect, but it won’t shout at you for running on the server, so it’s kind of “isomorphic”. or universal. one of those. i bet for many people these days, this Hook in stack traces is first exposure to the term
— дэн (@dan_abramov) March 16, 2023 -
at FB, we have a hack like this too. but it’s called differently. it’s called useLayoutEffect_SAFE_FOR_SSR.
— дэн (@dan_abramov) March 16, 2023
here, too, the intentions did not match the reality. -
the idea for calling it this way was to make it clear that when you use it, you’re claiming: “yes, this particular call is safe for SSR” (e.g. because it does not affect the visual result — and so it won’t cause a difference between what the user sees in HTML and after JS load).
— дэн (@dan_abramov) March 16, 2023 -
however, the way people read this was that it is exactly like useLayoutEffect, except it is somehow “safe for SSR”. that is — that you can use it absolutely for everything. which is how we kept getting more and more usages that weren’t all, actually, “safe”.
— дэн (@dan_abramov) March 16, 2023 -
it seems like this is probably a lost battle, and that’s why Rick put up a PR to remove the warning. if merged, this would make both of these Hooks unnecessary. (it would be harder to find the bugs it’s supposed to catch, but still seems worth it for false positives.)
— дэн (@dan_abramov) March 16, 2023 -
this is why people say that naming is one of the most difficult problems in the computer science.
— дэн (@dan_abramov) March 16, 2023 -
now, a bit about the cultural part at FB. suffixes like _SAFE_FOR_SSR or _SLOW or _OLD and so on are a common thing at FB. i think it’s a pretty awesome part of the engineering culture and i’d love to see it in more places. (this one was confusing but generally they’re helpful)
— дэн (@dan_abramov) March 16, 2023 -
i know in many places people treat names and conventions very seriously. like adding a suffix feels “unclean”. but it’s a great way to call attention! call something _SLOW or _DANGEROUS, and people take notice. i know a constant called SUPPRESS_WARNINGS_I_HAVE_A_GOOD_REASON.
— дэн (@dan_abramov) March 16, 2023 -
this exactly: https://t.co/JwRlrLW4I1
— дэн (@dan_abramov) March 16, 2023 -
on the topic of naming, https://t.co/SWBFey69Wq
— дэн (@dan_abramov) March 16, 2023