The Design Behind Kebab-Case-ing Our React Apps

Anyways, building UI is a cherry on-top of designing a new design system for a product, and React is what enables me to do that. It completes the process for me, and both skills help inform each other super well.

We use kebab-case when naming our git repositories, and folder directories in our React apps. I hadn’t really given it a ton of thought as to why we do this, or even if it could be better, until a couple of days ago talking to Very’s own master of men’s shoe swag, David Hunt .

Aside from David’s amazing fashion sense, he had a good question about why the repo from the first react-native project I had stumbled through ² was structured the way it was. I remember the feeling of the tiny pit that ripped open in my heart when he asked me something about the repo I consider to be right around the time things really started to begin to make sense. I didn’t have an answer aside from that’s how it was set up when I got there.

Then I completely forgot about the interaction for a week.

The reason we do this, I’ve found out, is actually because of an issue with git. Apparently people like this³ can be found all the way back to 2013. TLDR, git can sometimes change the capitalization of file names as they travel through the inter-tubez.

To non-engineers including, and especially my mom, when this happens it’s a very bad, no-touchy codey thingy. I suggest asking an engineer, because we are all really just baby giraffes learning to walk in code.

Should this happen, this would surely wreak havoc on any person’s repo. And because of that, we have a very compelling reason to not use what’s currently on the React file structure recommended but not actually recommended file structures page. React is described as a framework that doesn’t have opinions on how you put files into folders⁴.

React is really about one thing when the designer is also building the UI, thinking once… And then maybe once more right before you’re done.

React affords us the opportunity to think really, really hard about something a couple of times, and then reuse whatever we thought about over-and-over again in different contexts, which is the same idea behind evolving design systems. We seek to do something in the most thoughtful way for the fewest amount of times not because it is “good enough,” but because it is important to never assume that a function will be the exact same tomorrow as exists today. It’s important that we build the things-we-design with the objective of a shelf life longer than one iteration so we can maintain the integrity of the entire product experience. It’s a tricky situation trying to figure out what to optimize and when, but that is always a fun additional challenge to overcome. Maintaining context throughout a changing form is crucial, and can be a design problem to solve in its own.

Products tend to have their own types of rolling scales to compensate for when optimizing a design system, and it can be an awful lot to keep track of when hopping between design, and the front-end. Finding a more intelligent way to have more thoughts with less effort is rad, and since React really boils down to that paradigm, we should explore what a pattern like that for our file structures would actually improve upon. Let’s define the structure that is mixed casings, and certified git safe.

 // my-cool-component
    // // my-cool-component.tsx

    return (
      <MyCoolComponent />
    )

OK, not the worst. Only two nearly identical names to remember (my-cool-component and MyCoolComponent). Let’s compare to this example of an all PascalCase file directory, a component file, and component usage:

    // MyCoolComponent
    // // MyCoolComponent.tsx
    
    return (
      <MyCoolComponent />
    )
  

It may be a minor optimization, but we only have one name to remember in this structure, MyCoolComponent. A small victory is still a victory, and there’s actually some extra prizes that go along with something like this.

React is all about pattern recognition and reusability, which isn’t just 1s and 0s like it might seem. Code⁵ ⁶ is also super visual if you let it be. When you start to look for visual patterns in the editor UI, the difference in managing 10 different components with two names each vs. one name each is potentially increasing the speed at which you recognize visual symbols⁷ by a factor of 2! Anything to help carry the load by focusing the visual feedback you receive. Minimizing the amount of mental overhead is always a good thing, especially when maintaining design systems, inside and outside of React apps simultaneously.

This file structure and naming convention is specifically appealing to me because it ties very close with how I name my symbols in Sketch when designing. The less I have to translate between the two sides of my brain the better; I can infer more at a much quicker pace. The more I can figure out in design, the quicker I make maintainable decisions in code.

I’m always aiming for a more unified mental model when jamming on design or the front-end. This feels incredibly React-y in the sense of patterns. Making the switch to PascalCase in 2019 probably isn’t going to do anything bad, but it’s still an extra variable we can account for in the event of repo armageddon. I’ll check back in a bit.

KEEP READING: Find out how Very partnered with Koller Products to develop the world’s first internet-connected desktop aquarium and cross-platform mobile app using React Native.

Footnotes

¹ I bet some of you read that as “my role is very multifaceted” — we didn’t user test the company name lol
² Thanks to all who are like Dave for seeing designers as more than a just a sketchbook that knows how to html 
³ Example is from 2013, but my point is still solid?
⁴  React’s official stance on how to structure a React app. https://reactjs.org/docs/faq-structure.html
⁵ Noun
⁶ The code editor
⁷ The word is the form of the symbol in this case