05 January 2020
Domain Driven Design Structure instead of Type Driven Design
- Organizing projects by function or type works okay in smaller application but as it grows, hundreds of files get created. It then becomes difficult to find dependencies if project is not modularized. Example: /redux/{actions, middleware, reducers, utils}. Instead, it is better to organize by domain.
Use Function-Based components instead of State-less Class-Based ones
- There are some performance optimizations React does when it comes to function-based components. Avoid using class-based components unless you need lifecycle methods.
Keep components small and tied to a specific function - make it predicable and testable
- It’s easier to understand, update, implement performance optimizations, test and helps promote reusability
- Big components tend to become difficult to maintain, debug, test and refactor
- Components with over 200+ lines of code is a big sign that it should be broken up
DRY your code (Don’t Repeat Yourself)
- If you find any patterns or similarities it is possible you are repeating code.
- Mixing the two can lead to complexity. Keep responsibilities small and isolated.
- Keep all files relating to any one component in a single folder, including styling files. It makes hierarchy easy to understand and makes refactoring and navigating codebases easier.
Strict Linting
- Linting will help developers be aware of best and common practices and develop good habits. This also helps unify the style of the codebase.
Do not use Index or Value as a Key
- Key is what React uses to identify elements. If you push an item to the list and the key is same, React assumes that the element represents the same component as before even if it is not. This may break your application or display wrong data
- Each key should be permanent and unique. Generating random numbers is worse because it will re-render the components every time.
- Solution according to official docs is to pass in key in the mapped ListItem component but do not return it
bind() and arrow functions
- .bind() creates a new function each time it is run. This means a new function is being created every time the render function executes. This has performance implications as the app grows.
- Arrow function has the same concern since it’s an anonymous function and can’t be compared.
- Solution? Bind function in constructor lifecycle.
Do not use anonymous functions as handlers
- Anonymous functions cannot be compared. This means that React will always re-render. Pass references only
Only use setState to mutate state. Do not mutate state directly
- If you mutate the state directly, the component will not be re-rendered and the changes will not be reflected. This is because the state is compared shallowly. You should always use setState for changing the value of the state.
Do not use Props as State
- The constructor is only called once. The state won’t be updated if changed. You can this pattern only if you want to seed the state. Otherwise, this leads duplication of source of truth. Use the props directly instead.
Use React.Fragments to Avoid Unnecessary Wrappers Populating the DOM
- Instead of using unnecessary wrappers which populates the DOM such as div, span, etc use React.Fragment or use the more concise syntax of <></>
Avoid spreading unnecessary props on DOM elements
- Instead of doing {…props} be more explicit otherwise it will populate attributes on DOM elements
Avoid using inline styles
- Separate style from component. This will also cause bugs in the future due to CSS specificity and prevent theming, branding, etc.
- Additionally, this causes React to always re-render components regardless if data has changed
- Alternatively can also use React.memo. Might be better to use that.
Use Web Workers for CPU extensive tasks
- Web Workers make it possible to run operations in the background thread, separate from the main thread. It helps prevent UI blocking or slowing
Use Optional Chaining
- Prevents crashes when accessing a child property without guard checks
Do not use export default - be explicit instead
- This makes refactoring harder on larger files and also slows down intellisense on larger codebases. Seems like a minor code styling preference, but it starts becoming a problem on larger codebases
Use shouldComponentUpdate to compensate for shallow comparison on arrays, functions, objects, etc
- Side Note: can be used to fix some of the major performance issues in a hacky but temporary way
Virtualize long lists
- If you have long lists, rendering all elements including hidden ones can cause performance problems and stuttering. Use utilities like react-window to virtualize long lists.
Big Refactors / Improvements
- Use React.Memo to cache components. Use it for functional components.
- Memoized functions are faster because if called with the same values as the previous call, it will fetch return values from cache.
- If you have several components that rarely change state, you should consider caching them. It’s as easy as export default React.memo(ProfileView)
- Use Reselect to cache Redux selectors
- CSS Architecture
- Naming Consistency
- Structure Consistency
- Lazy Loading of Components (later)
09 April 2017
Hopefully you have enjoyed some of the articles I posted here throughout the years. I geared it more as a personal reference for myself and yet, it has gained a good amount of views. At this point, I will be refocusing and rebranding this blog into topics like entrepreneurship, product creation and growth, as this is now my main focus. Until then, this blog will be under construction.
Future topics will include:
- “How to properly market-validate your idea?”
- “How to go from idea to product?”
- “Don’t write a line of code before you do these things”
Reminiscing on my most visited blog posts:
08 February 2017
This year (2017) is when container orchestration and technology will be standard and clear winners for different use cases will rise. Here are my personal notes on common paas technology, comparing Dokku vs Flynn vs Deis vs Kubernetes vs Docker Swarm.
tldr: Easy but no H/A? Dokku. Easy with H/A? Flynn. Easy with H/A and native out-of-the-box solution? Docker Swarm. Complex, but mature and scales infinitely - the big dawg? Kubernetes. Want to make the big dawg less scary but still use the big dawg? Deis Workflow.
Hacker News Discussion: https://news.ycombinator.com/item?id=14531883
06 February 2017
Here’s a quick reference / cheat sheet for SQL language. The CRUD are platform agnostic. Just copy-paste this in your SQL editor like MySQL Workbench and you can step through it. Enjoy!
05 February 2017
Both Golang and MongoDB are a perfect pair for rapid application development and
building things for scale. They both have native features that allows you to
focus on your application. When choosing a database, make sure that MongoDB fits
your requirements as it is not a one-size-fits all solution. Read the official
docs on its design and use cases. In this post, we’ll go from Installation to
building a CRUD.
03 February 2017
I dabbled a bit of Go programming before, and after two years of not writing Go code, I decided to check it out. Alas, I fell in love, again. Why? Simply put, it is simple, yet complete. With so many layers, stacks, frameworks, libraries and opionionated “best practices” out there, there is strong cry from most of us that calls for a tool that is simple, yet complete.
03 February 2017
Let’s use a toolkit from one of Go’s standard libraries: database/sql. It is an abstraction and you need to import a database driver also. We will be as simple and “down to the metal” as possible. Not a fan of ORMs, so this should be fun. Whatever SQL database you use, code should be similar or the same. Read my quick start post on the actual databases themselves MySQL and PostgreSQL to get started with either.
02 February 2017
Although my favorite SQL database is PostgreSQL due to its feature-rich capabilities and amazing performance, MySQL still has its benefits, especially in the replication side. In fact, Google Cloud SQL is only compatible with MySQL right now. If they offered PostgreSQL, I would not be writing this. But I’ll stop now on opinions. Let’s do a quick start, and compile a cheat sheet afterwards. Also, check out some tips I learned including some best practices.
01 February 2017
Vespa is one of the simplest and straightforward control panels in the market. Best of all, it is open source! Why did I choose it? I played around with 3 control panels and this did the job out of the box, without bugs or failures. Here’s a quick way to install it in your Ubuntu server. For more features, I suggest ISPConfig. If you want to go for paid? cPanel is awesome. Before you continue, check out my guide on how to secure your linux server.
30 January 2017
So, you have your own server? Setting up a firewall on your server is very important once it is up and running. Thanks to ufw, doing this is fairly easy! Don’t even think about making your server public without a firewall! Check out my previous post on securing your server to add more protection.
20 January 2017
Don’t let your server get hacked and lose all your hard work. Here’s a step by step way to harden and secure your Linux server - from networking, to permissions. For simple deployments and tests, check out Digital Ocean, my favorite platforms. Can’t beat $5/mo servers that deploy in less than a minute! By signing up through my link, you are helping extend the life of my servers. Thank you.
15 January 2017
Typically, to send email, you would need an smtp server or connect to one. Let’s use Postfix to bypass that need. Basically, Postfix is a free and open-source mail transfer agent (MTA) that routes and delivers electronic mail. Let’s start.
10 January 2017
I will show you a very quick and easy way to properly run your process in the background. You should not use this workflow in production, but for development and quick tests, this is perfectly suitable for you.
04 January 2017
To do this, we use the command git rebase. Typically, it is used to:
- Edit previous commit messages
- Combine multiple commits into one
- Delete or revert commits that are no longer necessary
Let’s work through an example.
28 December 2016
Naming in programming is hard sometimes. I typically think about the future of the app, some “what ifs”, conventions and if it truly gives a good context for other developers or users. In the end, as long as everyone involved in the project is consistent and better yet, have things documented, then that typically outweighs hardlined rules. But here is a simple guide to help make your decisions.
20 December 2016
This debate has been labeled as the “Vietnam of Computer Engineering” and deservingly so. Here are some pros and cons I have learned.
19 December 2016
Here is a 1500+ lines of PostgreSQL goodness. Want to add or change something? Create a pull request. I hope this helps!
15 December 2016
I’m building a “cheat sheet” on finding files, monitoring and everything related to that in Linux. Here’s some of them.
12 December 2016
For almost a year, I’ve been writing git commits in a more structured way. It has improved code reviews and skimming through code history. Inspired by angular commit messages, I adopted their commit message guidelines. Here’s are examples
06 December 2016
Currently, Docker does not have a command to do this so we will have to do some good old fashioned command piping.