Interview with Packt on my new book React Anti-Patterns

As an application grows and more code is added, the initial loading time can become noticeably longer. This delay, sometimes lasting several seconds, can frustrate users. To avoid this, it's essential to optimize loading times.

Juntao Qiu

@JuntaoQiu

6 min read

Over the last seven months, I've collaborated with an incredible team to bring my new book, React Anti-Patterns, to life. This project with Packt Publishing has been a standout experience compared to my past ventures with various publishers.

I'm thrilled to announce that after several revisions, we've successfully published the book this week. The sense of excitement and pride I feel is immense. Recently, I had an insightful interview with Packt where I answered some questions about writing, development processes, and project management. These insights, which I'm sharing here, might be quite valuable for you.

How did you become an author for Packt? Tell us about your journey. What was your motivation for writing this book?

I already had ideas for writing a book about patterns I've observed in React projects of various sizes. When the editor from Packt reached out, I saw it as an excellent opportunity to create a comprehensive guide and share it with my readers. I believe it's important to recognize code smells, bad patterns, and unnecessary complexities in your application. Being aware of these is the first step before applying changes, like refactoring them into a better state.

What kind of research did you do, and how long did you spend researching before beginning the book?

I love writing code and enjoy modifying it or making it easier to change, to adapt to new requirements. I'm proud that even today, most of my time is spent coding, refactoring, identifying patterns in real-world, complex codebases, and improving them. For this particular book, I read a lot, notably Martin Fowler’s Refactoring, Kent Beck’s Implementing Patterns, and my own book, Test-Driven Development with React. I also had numerous conversations with my colleagues at Atlassian. These books and conversations helped me structure the content more effectively and make it more readable.

Did you face any challenges during the writing process? How did you overcome them?

Yes, particularly when I was about two-thirds through the book, I got stuck. I didn't have a suitable example to demonstrate a few patterns. I started with something simple, and halfway through, I realized it might be useful to include another example. But then I found it was too extensive for one chapter. I deleted most of the content and realized it was getting better with the simplified version. Writing, like coding, requires starting small and making incremental changes, one thing at a time, until you get it right.

What's your take on the technologies discussed in the book? Where do you see these technologies heading in the future?

This book primarily focuses on Anti-Patterns in React, or the bad code symptoms you might find in your application. I also tried to apply many established patterns from the software industry, like Single Responsibility Principle, Inversion of Control, and Anti-Corruption Layers, in the React context. I believe these patterns and practices are universal and extremely useful in many other frameworks too.

Why should readers choose this book over others already on the market? How would you differentiate your book from its competition?

One major reason I recommend this book is the examples, many of which are from real-world applications. Additionally, I've structured the book in an easy-to-follow manner. We start with the fundamentals, gradually move to more advanced topics, and end with several complex, end-to-end examples demonstrating the process of TDD and Refactoring as we apply patterns.

What are the key takeaways you want readers to come away with from the book?

You can't learn programming just by reading books; you need to apply the patterns in your codebase and give them a try. There are many details you'll uncover when actually coding, sometimes even discovering new patterns or variations, which are all valuable experiences. So don't just read the book; try to use the patterns and practices, like Test-Driven Development, in your daily work, and see how it goes.

Once you're familiar with the main content, you can use the book as a reference or a dictionary for useful patterns, consulting specific sections when you encounter concrete problems, such as how to use composition or when to extract data models.

What are your favorite tech journals? How do you keep yourself up to date on tech?

I read articles on Medium, where I am both an author and a reader. I particularly follow Kent C. Dodds and Josh Comeau for frontend topics, as well as Martin Fowler’s website and Thoughtworks Insights for general technical subjects. For me, reading is the most efficient way to gain knowledge systematically. I have a preference for long-form articles, as they allow me to delve deeper and thoughtfully consider the issues at hand.

How did you organize, plan, and prioritize your work and write the book?

I use Notion as my primary project management tool. I've experimented with various tools but found that Notion best suits my needs. My setup includes a backlog and several columns (todo, in progress, in review, and done), following a standard project management process. The advantage of Notion is its integrated Markdown capabilities, allowing me to write directly in the tool, which is incredibly convenient.

That being said, Trello is another tool I find effective. Its ease of use and free availability make it a great option as well.

What is that one writing tip that you found most crucial and would like to share with aspiring authors?

As the renowned writing book Bird By Bird suggests, focus on writing one chapter at a time. Start with an example or a topic you’re comfortable with. The key is to complete your first rough draft (remember, no one will see it initially) and then refine it bit by bit. After finishing the first draft, work with your editor to enhance its flow and clarity and to fix common issues. Then, repeat this process for the next chapter. The crucial point here is not to overthink it. Take it one chapter at a time.