DEV Community: Udayan Maurya

Engineering for Product market fit

Udayan Maurya — Mon, 13 May 2024 13:57:27 +0000

Product market fit is the only north start that you early stage startup should be chasing. Engineer your product to support you in that journey.

Do not get in your own way with overly complex engineering. Keep it simple!

1. Journey of product market fit

a) Research

Market is the most important component of product market fit journey. Market is alive even if your product is not, vice versa is not true. While building your product you'll research the market throughly. Come up with ideas and hypotheses to serve some unserved need and keep doing it over and over again until a fit is found.

b) Experiment

This journey involves a lot of experimentation and hypothesis testing. Your rounds of user interviews, sales calls and analyses will result in product specifications. These product specifications are your bets on things that can close the identified gap in the market.

c) Grind

You then need to develop this product and actually test your theories in the market. On real user testing:

Your hypotheses can be proven wrong
You might need to make adjustments to product
Try a new product direction
Seek an entirely new market

The grind is inevitable and it is costly. Unfortunately, you can make your life harder by doing unfit engineering.

Unfit engineering: Engineering practices that are not suitable for this grind.

In a nutshell job of engineering is to:

Develop on product specifications, fast
Change directions quickly
Let go of artifacts completely, if required

2. How to engineer for product market fit

Objective for engineering is to create a software to test your product theories quickly.
Objective for engineering is not to support millions of imaginary users.

As your understanding of problem space changes, the shape of your product will change drastically. This will result in running many experiments and iterations of developing product and testing with users.

Your aim, through these iterations, should be to test out your hypotheses about market as precisely as possible.

When market rejects your product you should have conclusive answer to following questions:

Why my product failed?
What should be my next move to improve things?
What does not work in this market?

You should have business answers to all these questions and none of the answers point to the flaws in your engineering. Using market feedback to learn engineering practices is prohibitively expensive!

Therefore, it is crucial to map product specifications for each iteration precisely to code. So that product failures reveal the lack of understanding of market rather than poor engineering.

You should not end up in a position that your product is so bad that user could not use it at all. Leaving you without answers: whether your insight of market is right or if user could try the product to produce reliable data points.

Write throw away code

Do not carry any tech debt between product iterations. Write throw away functional code that is loosely coupled such that it is easy to delete large parts of code. If you do not remove unused code between iterations it'll get harder and harder to map new product specifications to code, which greatly diminishes the quality of your product testing.

Steer clear of object oriented programming. OOP has an inherent disadvantage at this stage of product. OOP requires developers to create mappings and relations within application data. However, it cannot be adequately done because real relations in the problem space are yet to be discovered.

Avoid creating complex data mappings in your data graphs and API contracts. These inaccurate mappings get in the way when you want to change things quickly and many of previously created relationships are proven incorrect.

When stuck with bad data mappings or inheritance structures, developers start to cut corners and start to project their code's poor representation of world back on to the world, which results in disastrous user testing and inconclusive understanding of problem space.

Bonus: Read Avoid Hasty Abstractions by Kent C. Dodds.

Golden rule: Engineering chases Product Spec, and Product Spec chases Market

This relationship should never be inverted, otherwise you are in trouble!

Use commonplace technology

New technology is unproven and adds needless uncertainty in your quest to product market fit. Your success should not hinge on whether a new technology or framework succeeds, it is simply foolish.

Using commonplace technology is awesome! You will not have to work on unproven things to make things barely work. Librating your attention span to focus just on finding your product market fit.

Additionally, you'll reap following benefits:

Support:
- Plethora of libraries and packages to choose from
- Your questions have many hits on StackOverflow/GPTs
Access to large talent pool for hiring
Standardized engineering patterns to follow

Follow best practices

Your job as an engineer is write maintainable code that serves business needs.
Your job is not to use all the features of programming languages. Many features tend to be bad features.

Q. Why do bad parts exist in programming languages and frameworks?

A. Because they are created by humans! Humans tend to do mistakes.

Create features that do not deliver on promise
Do not solve any real problem
Lead to bad programming patterns

Language builders go through their own journey of product market fit. In this journey, just like yours, they create messes.

Unfortunately, none of the bad parts can be removed due to backwards compatibility - all the code written using bad parts need to be supported.

Fortunately, you can choose not to use any of the bad parts and steer clear of the mess and focus on what really matters - your quest of product market fit.

3. Advice for good engineering

a) Constantly learn - In 2008, Douglas Crockford wrote "Javascript - The Good Parts", which is a valuable resource. However, as languages and frameworks grow they continue to add several new bad parts. The onus is on you to keep separating the good parts from the bad ones and only use the good parts in you business software.

To do so, keep learning from good/authentic resources. Focus on finding out how things actually work and use those principles.

Use side projects to experiment with new technologies to identify and validate rising stars, but only use proven ones in software of business significance.

b) Do not do speculative coding - Do not abstract because you may need it in at other time. Abstract functionality only when 2nd usage is encountered. You will avoid writing extra code and your abstractions will be better mapping of real world.
Do not create columns in database because you may need them some day. Spoiler alert - you won't!

c) Refactor your code - After any sprint, ensure that you have mapped real world to code. Additionally, ensure you are not projecting relations of your code or data on to the world - that is you are not trying to fit market to your product.

Clean the code:

for good mapping of world/problem-space to the code.
to ensure you are using only good parts of languages and frameworks.
so that it is easy read, because you'll need to remove a lot of it in for the next iteration.

Overall simplicity is your friend when you want to move fast. Therefore, slow down and simplify passionately before starting the next sprint!

d) Readable code is better than Optimal code - In programming world it is a common advice that readable code is better than optimal code. Though for an early stage startup this relationship is super amplified. Something like:

Readable/maintainable code >>>> Optimal code

There is no point in optimizing a code that will not last more than one week. Therefore, optimization efforts are waste of precious resources - time and energy.

Readable and loosely coupled code provides you best leverage on your scarce resources. You can iterate fast and stay focused on what really matters - product market fit!

Good parts for good business

Udayan Maurya — Sun, 05 May 2024 23:49:23 +0000

Why bad parts exist?
Bad psychology:
Use all features
Feel swag in writing cryptic/magic code

Change title to:
Engineering for Product market fit

https://excalidraw.com/#json=4uUA0hRxIpvuSSymw_S5v,nnQBwwkFyUBy4KfDHb3FFg

Typescript Generics - What are they doing

Udayan Maurya — Mon, 13 Nov 2023 02:56:25 +0000

Generics are usually considered most confusing part of Typescript. In this post I'll try to explain intuition behind generics and hopefully make them easier to use!

Common beginner confusions

(1) Generics will do some type interpretation at runtime

No - Typescript is only available at compile time and not runtime!

(2) Generics map to input arguments

No - Generic types can map to any input arguments as designed by developer.

const mapped = someFunction<T, U>(a, b)

// Type of a -> T and type of b -> U -- NO!

(3) Generics make my code look ugly 😖

No magic bullet to solve this. However, if you leverage typescript's inference properly you can minimize this problem.

What problem generics solve

Let's say we have an identity function

const identityFunction = (t) => t

And we want:

Function should accept any type of input
Function's return type should match input's type

How can we type this function to achieve both objectives?

Naive solution

Statically type the input to be unknown type. unknown is top type in typescript's type system and every other type can be assigned to unknown.

const identityFunction = (t: unknown) => t

However, this approach fails to achieve second objective that is type of function's return value is always unknown regardless of the type of input.

let str = identityFunction('hello');
//  ^? unknown

let num = identityFunction(785);
//  ^? unknown

So ideally we want the type of function's input to be inferred when we use the function.

Typescript has such inference mechanism as we use it all the time:

let strBasic = "world";
//  ^? string

let numBasic = 7856;
//  ^? number

If there was a technique to leverage this Typescript's inference mechanism to infer the type of a function's input at usage we can solve our problem.

And that technique is Generic types 🎉

Generic types deploys typescript's inference mechanism to infer type of a function's input at usage 🔥

Generic definition and breakdown

So if we redefine the identity function using generic type it looks like:

const identityFunction = <T>(t: T) => t

Generic definition

Generic function will infer the type of input at usage. But we still need a way to reference that type in our function body while defining the function.
This type cannot be any static type such as any or unknown it needs to be dynamically inferred. Therefore, we need a special typescript variable T to store this dynamic type.

Generic assignment and inference

Just like static type assignment

let v1: string // v1 is assigned type string

we use : to assign type of input.

Additionally, in case of generics, type of input gets inferred at this step and is stored in variable T.

Type inference only happens at the level of arguments within parentheses () and no where else in function body.

Image by Arek Socha from Pixabay

How to structure Typescript project

Udayan Maurya — Sat, 18 Feb 2023 03:37:08 +0000

Typescript is an amazing tool to provide static type safety to you large Javascript applications. Type definitions can act as documentation for new team members, provide useful hints about what can break the software, and have an addictive code completion!

However, Typescript is no magic wand and to derive all the aforementioned benefits Typescript project should be structured properly. Otherwise, Typescript can be nightmarish. More like: Where is this TS error coming from !?, why is this not assignable!!, man TS is a headache this would be shipped by now with just JS 🤦

In this blog I'll describe how to structure Typescript project for a RESTful client-side web application for:

Readable and maintainable code
Pivotable codebase
True type safety!

We will use a sample HR application to discuss all the examples.

Application has 2 pages
Page 1: List of all employees
- API to fetch the data: GET /employees
- Response schema

[
  {
    id: number,
    firstName: string,
    lastName: string,
    role: string,
    department: string
  },
  ...
]

Page 2: Employee profile details page
- API to fetch the data: GET /employees/{empId}
- Response schema

{
  id: number,
  firstName: string,
  lastName: string,
  role: string,
  department: string,
  emailAddress: string,
  phoneNumber: string,
  address: string,
  manager: string,
  favoritePokemon: string
}

Common Typescript problems

Problem 1: Schema mapping

Unfortunately, many large projects suffer from this problem.

In a client side application it is common to describe the response schema as follows:

export interface EmployeeShortResponse {
  id: number,
  firstName: string,
  lastName: string,
  role: string,
  department: string
}

// Bad: Equivalent to NoSql schema design
export interface EmployeeLongResponse extends EmployeeShortResponse {
  emailAddress: string,
  phoneNumber: string,
  address: string,
  manager: string,
  favoritePokemon: string
}

export const employeesAPI = (): Promise<EmployeeShortResponse[]> =>
  fetch("/employees");

export const employeesDetailsAPI = (
  id: number
): Promise<EmployeeLongResponse> => fetch(`/employees/${id}`);

Problems with this approach

Extending API responses results in a document DB like schema design of the application data.
The schema does not provide much value on client side.
Schema creates synthetic relationship between independent REST APIs.

For instance if employeesAPI is updated to return one more property: region.
The EmployeeShortResponse will update like:

export interface EmployeeShortResponse {
  id: number,
  firstName: string,
  lastName: string,
  role: string,
  department: string,
+ region: string
}

This in turn will automatically update the response type of employeesDetailsAPI while there is no guarantee that response of employeesDetailsAPI has changed 😳

Mapping relations of application data on client side results in confusing, hard to track and unhelpful type errors. Front end application has no means to enforce the relations in application data. For best separation of concerns application data relations should be managed only at one place in the system: database of the application.

Problem 2: Expanding API response type beyond API

Let's say, in our example, we have a component to display "Favorite Pokemon" defined like

// EmployeeLongResponse defined as in Problem 1

type FavoritePokemonProps = {pokemon: EmployeeLongResponse['favoritePokemon']};

const FavoritePokemon = ({pokemon}: FavoritePokemonProps) => {
  if (pokemon.length > 0) {
    return <p>Favorite Pokemon: {pokemon}</p>
  }
  return null;
}

// Example usage:
// apiResponse.favoritePokemon = 'pikachu'
<FavoritePokemon pokemon={apiResponse.favoritePokemon}/>

But really, who has only one favorite pokemon? So the application requirements change to return list of favorite pokemons in API response for GET /employees/{empId}. Response schema updates like:

{
  id: number,
  firstName: string,
  lastName: string,
  role: string,
  department: string,
  emailAddress: string,
  phoneNumber: string,
  address: string,
  manager: string,
 - favoritePokemon: string
 + favoritePokemon: string[]
}

// Example usage:
// New apiResponse.favoritePokemon = ['pikachu', 'squirtle']
<FavoritePokemon pokemon={apiResponse.favoritePokemon}/>

To this change FavoritePokemon component will not throw any type error. However, at runtime FavoritePokemon will render something like:

Now that is a shock no one wants ⚡💦😵‍💫

How to structure Typescript code

Let's first breakdown the purpose of client side web application. Client side application needs to

Receive data from server
Consume the data and display meaningful UI
Manage state of user interactions
Capture permanent changes to application data and send it to server

And the purpose of typescript is to establish a contract in the program which determines the set of values that can be assigned to a variable. PS highly recommended read TypeScript and Set Theory.

Most important thing, from code design perspective, is to identify what are appropriate places to establish this contract.

Few principles to keep in mind to get most out of typescript:

Follow the flow of data across application
Keep isolated pisces of code isolated
Typescript helps in gluing the isolated pisces, that is inform users when they try to flow data across incompatible pisces

Problem 1: [Solution] No NoSQL on Frontend

Through typescript code we should not emphasize relationships in application data. REST APIs are meant to be independent and we should keep them that way.
Following this principle the example of HR application will update like this:

export interface EmployeeShortResponse {
  id: number,
  firstName: string,
  lastName: string,
  role: string,
  department: string
}

// Redundantly define all response types!
export interface EmployeeLongResponse {
  id: number,
  firstName: string,
  lastName: string,
  role: string,
  department: string,
  emailAddress: string,
  phoneNumber: string,
  address: string,
  manager: string,
  favoritePokemon: string
}

export const employeesAPI = (): Promise<EmployeeShortResponse[]> =>
  fetch("/employees");

export const employeesDetailsAPI = (
  id: number
): Promise<EmployeeLongResponse> => fetch(`/employees/${id}`);

Now there won't be any surprises in working with response of one API while other API's responses may change. Though this approach involves redundant typing, it adheres to the purpose of client side application. Generally, redundancy in code is not a bad thing if it results in more useful abstractions. Refer AHA Programming by Kent C. Dodds.

Problem 2: [Solution] Isolated pisces isolated

Flow of data on client side: Once data is received from server it will flow through state, props and utility functions. All these artifacts should be typed independently. So that whenever they are used with incompatible data typescript can inform us: Type safety!

So now we will define FavoritePokemon component like:

// EmployeeLongResponse defined as in Problem 1

type FavoritePokemonProps = {pokemon: string};

const FavoritePokemon = ({pokemon}: FavoritePokemonProps) => {
  if (pokemon.length > 0) {
    return <p>Favorite Pokemon: {pokemon}</p>
  }
  return null;
}

// Example usage:
// apiResponse.favoritePokemon = 'pikachu'
<FavoritePokemon pokemon={apiResponse.favoritePokemon}/>

Now as the /employees/{empId} API changes to respond with a list of pokemons:

{
  id: number,
  firstName: string,
  lastName: string,
  role: string,
  department: string,
  emailAddress: string,
  phoneNumber: string,
  address: string,
  manager: string,
 - favoritePokemon: string
 + favoritePokemon: string[]
}

// Example usage:
// New apiResponse.favoritePokemon = ['pikachu', 'squirtle']
<FavoritePokemon pokemon={apiResponse.favoritePokemon}/>  // Error

Typescript will yell at us right away with error: 'string[]' is not assignable to type 'string'

Now as a developer we can decide:

Do we want to expand FavoritePokemon so it work with both string and string[].
Or do we want to create a totally different component display multiple pokemons.

Conclusion

Writing type definitions along the flow of data in application results in following benefits:

REST APIs remain independent, the way they are meant to be!
Easier to follow code. Type definitions won't result in rabbit holes.
No need to manage data relations on client side. Client side code was never meant to do that.
Better type safety and more meaningful type errors!

Title image by Joshua Woroniecki from Pixabay

TypeScript: type vs interface

Udayan Maurya — Mon, 23 Jan 2023 00:56:20 +0000

Let's resolve this forever outstanding question:
Should I use type or interface?

Spoiler: It's called "TypeScript" not "InterfaceScript" 😉

Why a resolution is needed?

Typescript documentation is itself vague about which one should be used. However, vagueness is not helpful while creating a reliable software.

Most programming languages contain good parts and bad parts. I discovered that I could be a better programmer by using only the good parts and avoiding the bad parts. After all, how can you build something good out of bad parts?

Douglas Crockford

In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.

Zen of Python

type - Good, interface - Bad

1. `interface` is mutable

Redeclaring an interface appends to existing definition:

interface MyInterface {
  name: string
}

interface MyInterface {
  phone: number
}

let variable : MyInterface = {
  name: 'MyName',
  phone: 123456789
}

This opens a can of worms (bugs)! In a project of significant size. Types are declared in several files, and some types are declared globally. However, if interface definition can be extended in any file, users cannot be really sure what the type is going to be at usage. Also, these bugs can be extremely challenging to locate.

On the other hand types can only be created once:

// Error: Duplicate identifier 'MyType'.
type MyType = {
  name: string
}

type MyType = {
    phone: number
}

Mutability of interfaces is a bad feature: Value proposition of Typescript is to provide guard rails to validate types of variables in your program. Utility of Typescript is compromised if a programmer cannot be sure of what the type of interface is going to be at usage.

2. `interface` has unusual syntax

types naturally extend the syntax of declaring variables in JavaScript while interfaces have their own syntax which causes needless complexity.

// Variable creation rule
// Construct Name = Value; 
var x = 1;
let y = 2;
const z = 3;

// Types creation rule
// Construct Name = Value; 
type MyType = string | number;


// Interface creation rule
// Construct Name {Value}; 🤔
interface MyInterface {
  name: string
}

3. `extends` on double duty

extends in Typescript has dual purpose:

Extending an interface: More properties can be added to an interface using extends keyword.

interface Animal {
  name: string
}

interface Bear extends Animal {
  honey: boolean
}

Conditional type checking: For inputs to a Generic extends keyword is used to validate type at usage. Additionally, for conditional types extends keyword functions as a condition checker for a type being subset of another type.

const firstChar = <T extends string>(input: T) => {
  return input[0];
}

// Works!!
firstChar('abc')

// Error: Argument of type 'string[]' is not assignable to parameter of type 'string'.
firstChar(['abc'])

The dual usage for keyword extends is a source of lots of confusion. It makes it difficult for new users to adapt advanced TypeScript features.
However, we can do better! By not using interface at all we can remove this confusion as extends will be left with only one usage.

PS: Special thanks to Iván Ovejero for writing TypeScript and Set Theory

4. `interface` only works with objects

Now what's up with that 🤷‍♂️. In my opinion this is the origin of problem. interface was designed to make it easier to work with objects, which resulted in creation of two almost similar features and endless conversation of "type vs interface".
Software languages, libraries and frameworks follow principles of evolution. Like in any evolutionary system many species and initiatives take place to address specific needs and fill certain gaps.
However, not all initiatives successfully manage to address real problems, and sometimes can have detrimental effects on overall structure of program. Unfortunately, unsuccessful experiments cannot be removed from a language due to backwards compatibility.

It is rarely possible for standards committees to remove imperfections from a language because doing so would cause the breakage of all of the bad programs that depend on those bad parts.

Douglas Crockford

But we as developers can separate good parts from bad parts and only use good parts to make our softwares great!

Event Driven Architecture for Redux

Udayan Maurya — Sun, 25 Jul 2021 17:10:46 +0000

This article elaborates one of the Redux best practices. This best practice has helped me a ton in writing better code and avoiding problems. Many thanks to the Redux team!

Redux provides powerful way to store state data for client-side applications. Any part of application can send data, through actions, to be stored in redux then data becomes available to entire application.

However, with great power comes great responsibilities! Poorly designed actions/reducers give away most of redux advantages, and application becomes difficult to understand and debug. While well designed actions/reducers helps in keeping the store logic maintainable and scalable.

What data to store

We have been told that storage is cheap. However, we still cannot store everything. Additionally, memory is actually very expensive.
While designing data storage systems we need to be mindful of what data is worth storing to solve our problems. Generally relevant events result in creation of valuable data. While absence of events does not generate any useful data.

Example: There is no point in keep recording footages of a football stadium when no game is being played.

Similarly, in the world of client-side applications. Useful data, which is required throughout a session of application, is generated when events (user, Web-API, Web-Sockets, etc.) occur. Therefore, designing state tracking system based out of important events result in more maintainable, intuitive, and scalable system.

Setter Actions (Bad Practice)

This a very prevalent approach in many redux applications. Developers create many actions to set state in redux store.

This architecture results in following problems:

Developers need to be careful while designing event handlers and split payload properly as per setter actions.
Dispatch many actions when important events occur. In turn overwhelming actions log, which makes time travel debugging difficult.
Number of actions explodes when more and more data is required to be stored from same event.
Due to developer oversight, residual actions can keep lingering in codebase when data requirements reduce.

Again, expanding on example here. Play around with code here.

Objective: For a food ordering application:

Customer can order any number of pizzas
Customer can order any number of cokes
Once customer selection is complete order is sent (main event)

For setter actions: reducer logic look like (1) and action creators like (2)

const orderSlice = createSlice({
  name: "order",
  initialState: { pizzaOrdered: 0, cokeOrdered: 0 },
  reducers: { // (1) Reducer logic 
    setPizzaOrdered: (state, action) => {
      state.pizzaOrdered = action.payload;
    },
    setCokeOrdered: (state, action) => {
      state.cokeOrdered = action.payload;
    }
  }
});

const {
  actions: { setPizzaOrdered, setCokeOrdered }, // (2) Action creators 
  reducer: orderReducer
} = orderSlice;

Send order event handler looks like (3)

const sendOrder = () => { // (3) Send Order event handler
    dispatch(setPizzaOrdered(pizza));
    dispatch(setCokeOrdered(coke));
  };

(3) is another bad practice

And action log looks like (4)

In sizable application setters action log explodes

Problem 1: Adding fries to menu

New setter action/reducer (setFriesOrdered) needs to be created in (1) and (2).
One more action needs to be dispatched in (3), send order event.
(4) Action log will increase to show one more action order/setFriesOrdered.

Problem 2: Removing coke from menu

Setter action/reducer (setCokeOrdered) should be deleted in (1) and (2). However, this deletion is not necessary. Therefore, developers have tendency to miss out deletion. Also, in large teams they hesitate, thinking someone else might be using this action. Resulting in bloated codebase.
setCokeOrdered action needs to be removed in (3). Application needs to be aware of changing actions. All the imports need to be adequately removed.

Event Based Actions (Do this)

Deriving actions/reducers based out of application events improves the design of redux store significantly. Primarily, due to the fact that data worth storing originates from events.

This architecture has following advantages:

Dispatch only one action per event, resulting in intuitive separation of concerns between application code and redux code.
To store more data from an event: developers need to increase payload for the existing action, while reducer manages the internal state of redux.
To store lesser data from an event: developers need to decrease payload for the existing action, while reducer manages the internal state of redux. No need to manage actions.

Play around with code here.

For food order example: reducer logic looks like (5) and action creator looks like (6)

const orderSlice = createSlice({
  name: "order",
  initialState: { pizzaOrdered: 0, cokeOrdered: 0 },
  reducers: { // (5) Reducer logic
    orderPlaced: (state, action) => {
      state.pizzaOrdered = action.payload.pizza;
      state.cokeOrdered = action.payload.coke;
    }
  }
});

const {
  actions: { orderPlaced }, // (6) Action creator
  reducer: orderReducer
} = orderSlice;

Send order event handler looks like (7)

  const sendOrder = () => { // (7) Send Order event handler
    dispatch(orderPlaced({pizza, coke}));
  };

And action log looks like (8)

Problem 1: Adding fries to menu

orderPlaced reducer in (5) needs to be adjusted per expanded requirement.
Payload in (7) needs to increase with fries information.
Action log remains same!

Problem 2: Removing coke from menu

orderPlaced reducer in (5) needs to be adjusted per reduced requirement.
Payload in (7) needs to remove coke's information.
Action log remains same!

Mindset change

When I started using redux I used to create setter type actions. Upon reading this best practice I had following apprehensions:

Setters provide me with granular access to redux state and I can dispatch as many actions from wherever in the application per my needs.

Resolution: Actions are only required when events, important to the application, occur.

Setters give me flexibility in adding/removing actions from event handlers as per my needs.

Resolution: Setters are actually tedious because you need to import actions, add them in event handlers and update reducers per changing logic. Managing state changes in event based reducer is easier because you only need to adjust reducer logic and payload.

Frontend Abstractions

Udayan Maurya — Thu, 08 Jul 2021 07:25:45 +0000

Abstract thinking facilities us in solving many problems and solving them efficiently. Ability to say A is like B, helps us cheaply export solutions developed in A to solve B. This further refines the abstract pattern and makes it more robust and reusable (evolution!).

To solve problems in astronomy ancient Greeks developed abstract patterns to study geometry of triangles, Trigonometry. Now trigonometry helps us in solving problems ranging from construction of buildings to measuring current in electrical circuits.

Abstraction in Programming:

One of the primary objectives of programming is to come up with a code to mimic a real world process as precisely as possible. More precision results in bug free code which preforms adequately in most of the circumstances encountered in the process.

Example: Compare two dates to find out which is one earlier than other.

Program 1:

Write dates in string format "YYYY-MM-DD hh:mm:ss"
Do string comparison date1 < date2 to find the answer

Such trivial string comparison is a proxy model for underlying process. Therefore, it has tendency to break when program and process depart from one another (at Y-10k).

Program 2:

Get dates as date object of your favorite programming language
Do required comparison per your programming language

Now we are very precise by doing the date comparison more closely to required process. Besides any technical machine issue (floating points!) mostly we will get right answer.

Abstract patterns in programming provide us with tools/mental models, which are very generic and versatile to precisely model many applications of value. Good abstractions are hard to develop and evolve over a long period of time of combined effort.

In my opinion following are the most prominent abstractions in world of Frontend/UI Development.

1. Event

As history has it, Netscape failed to get other programming languages to work in browser environment. To create a more dynamic web, existing programming languages lacked vital responsiveness to user interactions.

To address the problem Netscape came up with event driven architecture (most powerful aspect of JavaScript to date).
User interactions occur independently of program and act as triggers to various functions of program therefore abstracting these interactions as events for program helped in developing adequate response mechanism for ad-hoc user requests.

Events proved to be incredibly powerful abstraction and is the major driving force for success of JavaScript in web development (both on client and server side). To help machines communicate over unreliable network events provide necessary decoupling, to allow programs to work independently on different machines and respond to requests as and when needed.

Read: How events help in designing Redux store.

2. State

In frontend world, next major development happened on February 18, 2005 with publication of Ajax: A New Approach to Web Applications. In pursuit of developing more responsive web and enhancing user experience it became ample clear that client side of applications need to share more workload.

Additionally, to deliver more intuitive experience to users, applications needed to respond conditionally based on what users expect per their state within application usage interface.

More predictable state management was required to develop more complex and richer client-side. Predictable state management has been the core value proposition of all three major frontend projects: Angular, React and Vue.

3. Effect

Amazing people in React’s development team have discovered the next major abstraction for frontend developer’s toolkit: Effect (useEffect).

Together with state, effects enable developer to develop complex applications with much ease. Hopefully ending the era of complex lifecycle management rules and flowchart diagrams, developers needed to put on their walls to be productive!

Consider following behavior for a conventional select all checkbox scenario (3 checkboxes: Red, Green, and Blue, and 1 Select-All checkbox):

When Select-All is checked all other checkboxes should get checked.
When Select-All is unchecked all other checkboxes should get unchecked.
If checking any Red, Green, and Blue results in a state that all of Red, Green, and Blue are checked, then Select-All should get checked automatically.
When all checkboxes are checked then unchecking any of Red, Green, and Blue should uncheck Select-All.

Following are two approaches to solve this problem:

a. Using only events associated with checking and conditionally performing automatic checking of boxes, which were not clicked.
b. Using effect after any checking event to complete the automatic checking of other boxes.

Select-All click event function is common in both solutions:

On check – Check Select-All, Red, Green, and Blue
On uncheck – Un-check Select-All, Red, Green, and Blue

A. Events abstraction only

Click event for Red checkbox:

We need to overwrite default checking behavior (only check/uncheck the clicked box).
Conditionally test state of other boxes and perform actions accordingly.

Though this code solves the problem it has following issues:

It is hard to maintain: Developer will experience some cognitive stress when reading and understanding this code.
Developer will need to be careful regarding which checkbox (Red, Green, or Blue) they are coding for and adjust code accordingly – again cognitive stress and prone to error.
Developers will need to be very careful when adding new checkbox or removing any checkbox.

B. Using Effect with Events

Click event for Red checkbox:

Default checking behavior (only check/uncheck) Red when Red is clicked.
If using libraries like Formik we get this behavior for free without writing any click event function!

Effect to follow the click event

Test state of all the checkboxes if all are checked, check the Select-All box.
Else uncheck the Select-All box.

Beauty of this solution: this program helps us mimic the problem statement more precisely. On any of interaction with checkboxes, user expects:

Select-All gets checked when all Red, Green and Blue are checked
Select-All gets un-checked when any of Red, Green and Blue are un-checked

This is exactly what Effect has helped us code, thereby increasing precision of our program.
Adding and removing checkboxes in this code is a breeze we just need to add the new checkbox state in the effect function and select-all click event function.

Conclusion – Memoir

While developing a complex form for a client, I was having a lot of challenges fixing legacy code. Also, making changes always resulted in major headaches. Based on many interactions with product owners expected requirements will sound like:

When I click this checkbox, these other fields should appear.
When user has filled these fields, these other fields should be disabled.

Reading (obsessing, actually!) these requirements over and over, it struck me that all the posterior behaviors are in fact effects! And, modeling them as such results in more intuitive, maintainable and bug free code!

Through this article I wanted to highlight the benefits of effectively using effects. Might as well have called titled it Effectively useEffect, or something. However, I took a longer route to place effects on similar footing as other well know major UI abstractions, again this is my own opinion.

Recommendation: While designing your UIs try to word users’ expectations in these 3 buckets:

What event users will fire when using your application.
Maintaining which states are crucial to your business/user experience.
What effects are expected after certain state changes or events.

These steps have helped me in writing much better code, hopefully they will help you too.

DEV Community: Udayan Maurya

Engineering for Product market fit

1. Journey of product market fit

a) Research

b) Experiment

c) Grind

2. How to engineer for product market fit

Write throw away code

Use commonplace technology

Follow best practices

3. Advice for good engineering

Good parts for good business

Typescript Generics - What are they doing

Common beginner confusions

What problem generics solve

Naive solution

Generic definition and breakdown

Generic definition

Generic assignment and inference

How to structure Typescript project

Common Typescript problems

Problem 1: Schema mapping

Problems with this approach

Problem 2: Expanding API response type beyond API

How to structure Typescript code

Problem 1: [Solution] No NoSQL on Frontend

Problem 2: [Solution] Isolated pisces isolated

Conclusion

TypeScript: type vs interface

Why a resolution is needed?

type - Good, interface - Bad

1. interface is mutable

2. interface has unusual syntax

3. extends on double duty

4. interface only works with objects

Event Driven Architecture for Redux

What data to store

Setter Actions (Bad Practice)

Event Based Actions (Do this)

Mindset change

Frontend Abstractions

1. `interface` is mutable

2. `interface` has unusual syntax

3. `extends` on double duty

4. `interface` only works with objects