Modular React architecture

On modular architecture

What's modular architecture? Let's go through an example of what it isn't, and
we'll work towards transforming it. By the end you may be convinced of its
merits or that it's a colossal waste of time.

This is a real scenario I growth-mindsetted through at work. Names and details
anonymized, but a real-world example of a common concept should be fun to walk
through, if nothing else.

Requirements, and how to find them

Our site has a button that lives in the site header. It displays how many
V-Bucks the user has left, but also has some business logic baked into it:

• If this is their first time visiting the site, open a popover to welcome them & show something they can do with their V-Bucks
• If they have < 5 V-Bucks remaining, show a popover upselling more
• If they are a Basic user, show one style of button; if SuperDuper user, show another, fancier button

And so on. There are many such cases our product managers and project managers
and design managers and Group V-Bucks Directors have dreamed up that we need to
handle.

Jimbo the intern has been tasked with implementing this because it's just a
button!

He sifts through fifteen conflicting iterations of Figma designs. He finds
requirements in as many separate Word docs as there are PMs. He organizes and
endures seven knowledge transfer sessions with seven teams to uncover the
ancient, proprietary knowledge of which services will provide the data he needs
for user type and V-Bucks count. The content team has reassured him that the
final version of all the strings will be approved by legal and marketing by end
of week, and with that, he's ready to build this button.

The hacker approach

Here's the first iteration of his V-Bucks button, popovers, and relevant
business logic.

Jimbo is pleased with the simple directory structure he's come up with:

/v-bucks-button
├── button.tsx
├── index.ts
└── /v-bucks-popover
│ ├── popover.tsx

So he starts building this button, and it begins innocently enough.

export const VBucksButton: React.FC<VBBProps> = ({ ... }) => {
  // Set up state
  const authConfig    = { ... }
  const { user }      = useAuth({ ...authConfig })
  const { vBucks }    = useGetVBucks({ user })
  const { telemetry } = useTelemetry()
  const { t }         = useTranslation('vBucksButton.content')
  const styles        = useButtonStyles()

  // Derive some state via business logic
  const handleClick = () => { ... }
  const buttonText  = vBucks === ERROR ? '--' : vBucks.toString();
  // About 25 more lines of various button state, error handling,
  // conditional rendering, with comments throughout explaining
  // why we're showing or hiding something or other

  const popoverProps = {
    // About 200 lines of typical popover handling,
    // telemetry, business logic, content to display, etc
  }

  const tooltipProps = {
    // Another 100 lines of the same for tooltip
  }

  return (
    <VBucksPopover
      {...popoverProps}
      trigger={
        <Tooltip {...tooltipProps}>
          <button
            ariaLabel={t('ariaLabel')}
            className={`
              about seven-hundred classnames for responsive design,
              accessibility, conditional premium styles, et cetera`}
            onClick={handleClick}>
            {buttonText}
          </button>
        </Tooltip>
      }
    />
  )
}




<p>He's implemented a first go at it. The VBucksPopover has similarly complex<br>
business logic, error handling, state management, styling, and comments excusing<br>
tech debt in the name of shipping.</p>

<p>At just under 400 lines, this button is trivially simple. Even if the popover is<br>
another 500 lines of spaghetti. Does "cleaning" it up or splitting it up really<br>
benefit us, or our users, in any way? It depends. If this is all we'll need for<br>
this button, who cares. Let's move on!</p>
<p>But two months have passed and a PM and designer from another product team love<br>
your button and want it in their app's header. They have a <em>simple</em> list, no<br>
pressure from their end, of some changes they'd like you to accommodate and if<br>
you could please give an ETA by end of day for LT that'd be great, thanks:</p>

<ul>
<li>Update the button's styling and display text based on the app it's shown in</li>
<li>Show a completely different set of popovers, per app</li>
<li>Open a new company-wide, standard upsell modal when the user's out of V-Bucks,
but only in some regions, and only to users age 16 , and only if they're in
experiment group A</li>
</ul>

<p>Can Jimbo cram all of this new functionality into the same components?<br><br>
Yes. Will splitting or refactoring benefit the users or impress your managers?<br><br>
No. But refactoring has some strong arguments at this level of complexity:</p>

<ul>
<li>Dev sanity</li>
<li>The sanity of the dev who replaces Jimbo when he's PIPed for not refactoring</li>
<li>More reps, so you do better from the start next time</li>
<li>Something to blog about later</li>
</ul>


<h3>
  
  
  The modular architecture approach
</h3>

<p>The morals of the Clean Code initiates, and other anal types who know enough to<br>
answer on Stack Overflow regularly, and even your grandparents, look something<br>
like this:</p>

<ul>
<li>KISS, DRY, & other acronym blankets</li>
<li>Separation of concerns</li>
<li>Atomicity! Decoupling! Onomatopoeia!</li>
</ul>

<p>These are great, and help inform Jimbo's next attempt. He didn't get PIPed after<br>
all, and actually got a promo for delivering ahead of schedule and for sharing<br>
so many meetings and documents.<br><br>
But he's wiser now and learned a cool way to implement those adages. It looks<br>
something like this:<br>
</p>

<div class="code" style="position:relative; padding:0px; margin:0px;"><div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="brush:php;toolbar:false">/v-bucks-button
├── button.tsx
├── index.ts
└── /v-bucks-popover
│ ├── popover.tsx

Copy after login

Copy after login