Patrick’s Blog — Web development

10 habits I borrowed from python that I use in React (Part I)

Best practices that I believe should carry over from python to JavaScript, specifically in React

Image for post
Image for post
Do you see the similarities between my python code and my JavaScript code? (Image source: self-made.)

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

I came to write this article because I came across the Zen of Python while talking to my colleagues, and it made me realize how much of my JavaScript habits came from subconsciously following my habits that came from the Zen of Python. I believe it has gotten a lot of ideas right that should be used in any language!

Choose your variable names carefully (Beautiful is better than ugly)

It’s easy to name a component “Container” or “Wrapper”. But that makes naming conflicts really hard to figure out, and more technically, it really annoys someone doing a search through the repository to see where are the other instances of that “Wrapper” for a search-and-replace task. Giving a more specific, context-relevant name to a variable makes it easier to read and to work with. Give it some thought!

Make your code as obvious as possible, but don’t exaggerate (Explicit is better than implicit)

One way that I like to do this (that aligns with the previous point) is to use the power of React Hooks that allows us to isolate functionality. One problem that always shows up is tracking some binary object, which can easily be done with a boolean. So what do you always end up doing? useState. It looks something like this:

An example of a perfectly valid use of useState to track some binary state.

Working code isn’t enough: simplify your code! (Simple is better than complex.)

One typical of that is when I see the following happen in a React component: you work with a large component that has a lot of building blocks, you try to make something work, so you make props move around until you figure it out, and in the end, you see a situation like this:

Observe the very complicated process used just to inject the count in a template literal. It works, but…!
See how the CountingButton component is much simple now without the useState and useEffect?

Don’t make complex things more complicated than they need to be (Complex is better than complicated.)

I think this one doesn’t need an example, it would be “too complicated”. If you’ve ever written anything in JavaScript, you’ve seen a codebase somewhere with a 1000 lines long script of meaningless repetitions with slight changes every 10 lines or so, where someone just didn’t bother to refactor. There are some rules that I try to follow to avoid very large and unreadable scripts in React/styled-components:

  • Using the above rule, only put one component per module (not counting the styled-components). If you put more than one component in the same file and someone knows of a problem with one of the two components, how are they supposed to look for that component in your repository? If you name your module after one of the two (or more) components, then you can’t find the other one(s) easily (you could have to do a global search… imagine if your second component was always called “Wrapper!”). Having each component in its own file helps a lot when debugging! Sometimes the filename is all you can get!
  • Using the above rules, if you add a unit test in its componentName.test.js file, and maybe some stories via the fantastic Storybook library in a componentName.stories.js file, and some subcomponents that you put in their own files or even maybe subfolders next to your component… you quickly end up with a lot of files. So I do myself a favor and always default export my component in its file reserved for it, and when I need my component outside of its folder, I expose it to the rest of my repository through an index.js file. So creating a component ends up leading to a folder with a tree structure like this:
...
├── Button
│ ├── Button.js
│ ├── Button.test.js
│ ├── index.js
| ...
| ├── stories.js
| └── styles.js
...

Use a 4-spaces indent to easily detect ‘callback hell’ (Flat is better than nested.)

Before I say anything, I am not getting in the eternal debate of tabs vs. spaces (I’m a tabs guy). My point is only about the width of such tabs/spaces.

CTO @ Staiy | Accelerating the transition towards sustainable fashion

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store