3 Ways To Initialize State In React

First things first, this blog post is an extension of the demo project that showcases the 3 ways to initialize state in React Component. This project source code is open-sourced in Github (karthiks/simple-counter-react-demo) for your reference and toying with it.

The 3 ways are:

1. Class Component that uses constructor to initialise state.
2. Class Component that uses static/class property to initialise state.
3. Functional Component (aka Function) that uses React Hook viz. useState to initialise state.

The evolution has been in that order as shown above. With the advent of ES6, react leveraged constructor to initialise component state. This one unified the practices by various teams. However this method has a constraint that the constructor's first statement should be "super(props);", failing which things might not work as expected. To err is human and developers missed this line occassionaly resulting in painful debugging.

But a developer is smart. With the advent of ESLint this issue was resolved. That said, Babel users start to leverage static/class property feature available in Babel, for it is concise and looks cleaner. Note this class property isn't a feature of Javascript as yet and so would result in constructor being generated for you by Babel.

In the mean time, React introduced easier way to define stateless components with just functions. These are called Stateless / Functional Components. And with time React also introduced React Hooks. One of the hooks were useState that hooks state into a component. With the advent of this, the community started to leverage this one over the above methods.

Your mileage and preference may vary. This project is aimed to help you decide the flavor you prefer and start adopting.

The 3 Frontend Code Quality Musketeers - ESLint, Husky And Lint-Staged

Protect your Javascript code quality with the 3 musketeers - ESLint, Husky and Lint-Staged. I often come across projects in my consulting gigs where the team overlooks the importance of Automated Code Quality for the front-end because they feel they have one less thing to worry about. With the three said musketeers configured to act in your project, you will start to experience productivity and peace because you get to fail faster should you compromise on code quality.

Understanding the roles of the 3 musketeers:

1. ESLint : To find and fix problems in your JavaScript code no matter what ECMAScript standards your team has adopted to follow starting from ECMA 3 to ECMA2019. And if you were to use language extensions like JSX, Flow or Typescript, ESLint get your code covered. Lastly, if you are using Babel, which you likely are, you can use the babel-eslint parser and eslint-plugin-babel to use any option available in Babel. This is the Javascript community's best friend when it comes to automated code quality. Go for it!
2. Husky : Husky makes Git hooks simpler to aid its adoption and thus prevent bad code from being pushed to central repository. Instead of expecting your developer to run your ESLint before they commit their changes, you are better off with this being done automatically at the earliest. The earliest that could be here is when the developer commits his code changes to his local branch. You could write a pre-commit Git-hook that gets executed before the commit and successfully commits the changes only if there are no linting errors. This is where Husky comes to the rescue. By installing it as part of your project dependency, you simply configure the Git-hook like below in your package.json file:
3. Lint-Staged : As developer you have this crazy attitude to further your productivity. You wouldn't want to waste your precious time running through the linting process for your entire project repository for every commit of yours when you have only changed a few files at best for the intended commit. You feel better off executing the lint over the modified files that you are about to commit than the entire project as is automated. Lint-Staged comes to aid you and the automation here. With this module, only files of configured pattern that are modified by you are tested against by the linter instead of the entire project source code. 

Below is a sample package.json file configuration where you see how the 3 musketeers are put together for your enhanced productivity:

Bingo!, with just that, you now have much more time to waste elsewhere like on Facebook, Hacker News, Reddit, Quora, Yahoo News and others..without compromising on the code quality.

Are we living in the most chaotic times?

Chaotic Times

I think YES! Don't trust me on this? Pick any one of the items from the following list, think of how you would define it and then go about asking others on their thoughts about it all to see how different your perspective is from theirs..and keep doing this for a while.

• Agile Vs SAFe Vs Scrum Vs <your_enterprise_(fr)agile_methodology>
• DevOps Vs Agile
• DevOps Vs SysOps Vs Infrastructure Automation
• SOA Vs Microservices
• Data Warehouse Or Data Lake or Data Mart or Data Mesh or Data LakeHouse
• Data Science Vs Machine Learning Vs Deep Learning
• Data Analyst Vs Data Scientist Vs Data Engineer
• Project Manager Vs Product Manager Vs Product Owner Vs Engineering Manager
• Prototype Vs MVP
• Serverless Vs Otherwise
• Startup Vs Enterprise
• Hybrid Cloud Or Multi-cloud Or Federated Cloud
• TDD Vs BDD Vs Otherwise
• Message Queue Or Message Broker
• Preacher leadership Or Practioner leadership
• Human Resources Or People
• Jumping Jacks Vs Dated Davids 
• Titles or Roles

Got an item to add to this compilation? Do share your thoughts..

Checklist For Saner AWS Cloud Migration

10 steps to AWSomeness

In my earlier post titled, "The War Of Cloud Adoption / Migration", I had shared my observations of how badly under-prepared the enterprises big and small were for cloud adoption. This post is a follow up on that one to help them in their cloud journey.

IMPORTANT : I would like to state that this post is by no means a substitute to professional guidance of cloud experts but should serve you as a good starting point in your cloud journey before you get the experts on-boarded.

THE WAR Of CLOUD ADOPTION OR MIGRATION

Do you have what it takes to own a beast???

Cloud adoption/migration is akin to festive shopping, where you have innumerable options in terms of variety, cost, speed, durability, quality, etc. 

As first things first, you got to know what your core wants are from the endeavors you are about to carry on.  

Then, if you are desirous of mitigating hard surprises, you should :  

* do planning, and budgeting before you shop,  

* do regular tracking of it all, on the go and

* do keep conversing and getting feedback

to help making better decisions for safe journey and enjoyable destination.