React - A Follow Up

Note: This is a follow-up article to my first experiences working with react.

Shopify is full of many intelligent and skilled developers and, now that I work with them, I've gained the benefit of the experience of those much more experienced with React. We maintain are own React component library called Polaris but, that said, many of us are still novices at writing React apps. Now that I've gained more experience, I have more thoughts to share!

1. App Structure

I thought I'd gotten better at this but many screw ups later I've realized I still have much to learn. Having a src/ directory is standard for React apps but it isn't always clear how to organize the sub-directories. There's also a lesson in writing components that I had to learn.

A components/ directory is create and you can nest components in whatever way works best for you, provided there's sound logic to it, but knowing how to write those components can be pretty confusing for the novice React developer. The key is understanding how to utilize dumb, generic components alongside domain specific components.

A single page application can usually be broken down into separate pages and it makes sense to have a pages/ directory. These pages are typically pretty domain specific and might contain sub-directories for components that only ever relate to that particular page.

Another option might be to create domain specific directories. A blog app could potentially organize different views into directories, like posts/, comments/ and users/.

Continuing the blog example, since you might have a list of comments, a list of users or a list of posts, it stands to reason you should only have one component to display them, wrapped by a domain specific version if necessary. Creating List and ListItem components that are wrapped by CommentList and Comment components respectively, lets you optimize your component usage. It stands to reason that, for the most part, your lists will have some common properties.

2. Per-Component CSS

So, now we have CSS-modules. A blessing and a curse. On one hand, it removes the problem of namespace collisions and unwanted style-sheet cascading issues. It makes your CSS much simpler and removes much of the necessity of depending on SASS or LESS. On the other, it's more of a pain in the ass when you want to override a style. Good structure and organization of your CSS and where you apply certain styles is key.

Overall, I'd call them a net gain but not without their own warts. Regardless, I still highly recommend per-component CSS!

3. Network Communication

As nice as promises and the Fetch API are, I have to say I now prefer Axios. "Fetching" a POST just feels odd. Not being able to catch non-network errors (40x responses) within Promises feels non-intuitive; it requiring extra boilerplate.

Axios just feels more natural. The verbs for performing actions make sense. 40x responses can be caught instead of being checked for. Browser compatibility, if that's a concern, is covered.

And now...

That's about it! Nothing too revolutionary but still, some nice tidy lessons from being in the trenches.

Ta-ta for now!