Tao of React – Software Design, Architecture & Best Practices

Alex Kondov, Tech Lead at Financial Times, has compiled a huge list of best practices when it comes to writing React.

This article is a collection of principles and rules that have proven to be effective for me and the teams I’ve worked with.

I outline good practices about components, application structure, testing, styling, state management and data fetching. Some of the examples are oversimplified so we can focus on the principle not on the implementation.

Although Alex warns that it’s an opinion and not an absolute, the TOC alone — except for the CSS-in-JS part 😛 — already has me nodding along:

  • Components

    • Favor Functional Components
    • Write Consistent Components
    • Name Components
    • Organize Helper Functions
    • Don’t Hardcode Markup
    • Component Length
    • Component Length
    • Write Comments
    • Use Error Boundaries
    • Destructure Props
    • Number of Props
    • Use Objects Instead of Primitives
    • Conditional Rendering
    • Avoid Nested Ternary Operators
    • Move Lists in Components
    • Assign Default Props When Destructuring
    • Avoid Nested Render Functions
    • Prefer Hooks
  • State Management

    • Use Reducers
    • Use Data Fetching Libraries
    • State Management Libraries
  • Component Mental models

    • Container and Presentational
    • Stateless and Stateful
  • Application Structure

    • Group by Route/Module
    • Create a Common Module
    • Use Absolute Paths
    • Wrap External Components
    • Move Components in Folders
  • Performance

    • Don’t Optimize Prematurely
    • Watch Bundle Size
    • Rerenders – Callbacks, Arrays and Objects
  • Testing

    • Don’t Rely on Snapshot Tests
    • Test Correct Rendering
    • Validate State and Events
    • Test Edge Cases
    • Write Integration Tests
  • Styling

    • Use CSS-in-JS
    • Keep Styled Components Together
  • Data Fetching

    • Use a Data Fetching Library

Amazing work, Alex!

Tao of React – Software Design, Architecture & Best Practices →

Via Lode

Best Practices With CSS Grid Layout

Rachel Andrew:

An increasingly common question — now that people are using CSS Grid Layout in production — seems to be “What are the best practices?” The short answer to this question is to use the layout method as defined in the specification. The particular parts of the spec you choose to use, and indeed how you combine Grid with other layout methods such as Flexbox, is down to what works for the patterns you are trying to build and how you and your team want to work.

Worth a read.

Best Practices With CSS Grid Layout →

Hive’s best practices for JavaScript projects

Hive, a UK based technology design studio, have shared their set of best practices for developing JavaScript-based projects.

While developing a new project is like rolling on a green field for you, maintaining it is a potential dark twisted nightmare for someone else. Here’s a list of guidelines we’ve found, written and gathered that (we think) works really well with most JavaScript projects here at hive.

Always interesting to take a peek at other companies their internals. Not only do they cover things such as code style; their list goes further: API Design and a Git usage strategy for example are also covered.

wearehive/project-guidelines

Technical debt 101

Every time you don’t write software based on the best possible practices and understanding of the business domain, you incur it in a technical debt. This debt keeps increasing over time, just like an interest, because whoever has to change something has to deal with the imperfect concepts you codified on the first occasion. If you ignore it long enough, you can go technically bankrupt, where the codified concepts do not reflect anymore the domain you’re working on.

Technical debt 101 →

JS adolescence

For me there was a time that can only be described as adolescence in the field of programming and more specifically JavaScript. This period was characterised by a certain laziness and hubris. I thought I was right. I thought others were wrong. I could see no path but the very strict one that I had boxed myself into through a process in which I longed for certainty and the expulsion of realistic doubt.

Today I present a short list of JavaScript practices that once seemed right but I now deem foolish (in most situations)

JS Adolescence →