
## Introduction

In today's digital age, it is crucial for websites and applications to be
responsive and adapt to various screen sizes.
Mobile responsiveness ensures that users can access and navigate through content
seamlessly, regardless of the device they are using.

<br />
When designing for specific breakpoints, it is essential to focus on the amount of
screen space available to your app rather than the screen size itself. This blog
post will explore the concept of mobile responsiveness and provide recommendations
for designing at different breakpoints.

<img
  src='https://i.postimg.cc/wj7P7rzX/responsiveness.png'
  alt='Responsiveness'
  width={'100%'}
/>

## Small: Designing for Screens Smaller than 640px

The small breakpoint refers to screens that are smaller than 640px.
When targeting this breakpoint, it is important to create a visual separation
between the left and right edges of the app window. One way to achieve this is
by <mark className="highlight">setting the left and right window margins to 12px.</mark>

This slight margin creates a clear distinction between the content and the edges of the screen.
By implementing this recommendation, users will have a comfortable viewing
experience on smaller devices, allowing them to focus on the app's content
without feeling overwhelmed by the limited screen space.

## Medium: Designing for Screens Between 641px and 1007px

The medium breakpoint encompasses screens ranging from 641px to 1007px.
At this size, it is crucial to maintain a consistent and visually pleasing layout.
To achieve this, it is recommended to <mark className="highlight">set the left and right window margins to 24px.</mark>

This increased margin size provides a more spacious and balanced look, ensuring
that the content is well-organized and easily readable. By giving the app's
elements room to breathe, users will have a better user experience, allowing
them to navigate through the app effortlessly.

## Large: Designing for Screens 1008px and Larger

For screens that are 1008px and larger, the large breakpoint, it is important to
utilize the available screen space effectively. Similar to the medium breakpoint,
it is recommended to <mark className="highlight">set the left and right window margins to 24px.</mark>

This margin size creates a visual separation between the app's content and the
edges of the screen, enhancing the overall user experience. By implementing this
recommendation, users will perceive the app as more organized and professional,
ensuring that they can easily interact with the content and features.

## TLDR

<table className='md_table'>
  <thead>
    <tr>
      <th style={{ width: 112 }}>Size class</th>
      <th>Breakpoints</th>
      <th style={{ width: 190 }}>Typical screen size (diagonal)</th>
      <th>Devices</th>
      <th>Window sizes</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Small</td>
      <td>640px or less</td>
      <td>4" to 6"; 20" to 65"</td>
      <td>Phones, TVs</td>
      <td>320x569, 360x640, 480x854</td>
    </tr>
    <tr>
      <td>Medium</td>
      <td>641px to 1007px</td>
      <td>7" to 12"</td>
      <td>Phablets, tablets</td>
      <td>960x540</td>
    </tr>
    <tr>
      <td>Large</td>
      <td>1008px or greater</td>
      <td>13" and larger</td>
      <td>PCs, laptops, Surface Hubs</td>
      <td>1024x640, 1366x768, 1920x1080</td>
    </tr>
  </tbody>
</table>

A helper utility to check screen breakpoints in JS based application to handle responsiveness.

```jsx
const SCREEN = {
  large1920: window.innerWidth <= 1920,
  large1600: window.innerWidth <= 1600,
  large1536: window.innerWidth <= 1536,
  large1366: window.innerWidth <= 1366,
  large1440: window.innerWidth <= 1440,
  large1280: window.innerWidth <= 1280,
  large1024: window.innerWidth <= 1024,
  medium962: window.innerWidth <= 962,
  medium810: window.innerWidth <= 810,
  medium800: window.innerWidth <= 800,
  medium768: window.innerWidth <= 768,
  medium700: window.innerWidth <= 700,
  medium600: window.innerWidth <= 600,
  small414: window.innerWidth <= 414,
  small375: window.innerWidth <= 375,
  small360: window.innerWidth <= 360,
};

export { SCREEN };
```

## Conclusion

Mobile responsiveness is crucial in today's digital landscape.
Designing for specific breakpoints allows apps and websites to adapt to different screen sizes,
ensuring a seamless user experience.

Whether designing for small, medium, or large screens,
it is important to consider the available screen space and create visual separations using appropriate window margins.
By following these recommendations, developers and designers can
create mobile-responsive interfaces that cater to the needs of their users, regardless of their device.



## When and why we get this type error?
If you use input or any HTML tag with HTML data attributes while working with react with typescript,
you will undoubtedly encounter this error in your event handler functions.

This is one of those cases where typescript is helpless, and we must assist the type system by providing some additional information.
This short post will go over how to handle this properly.

Let's start by creating a custom dataset generic type that extends the native dataset type.

```tsx
export type DatasetInjector<T, D extends DOMStringMap> = T & {
  dataset: D;
};
```
## How does it work?
In **DatasetInjector**, the generic `T` specifies the HTML typescript type, such as `HTMLInputElement` or `HTMLTextAreaElement`.
The second generic `D` is used to provide missing information about data attributes of input tag (or any other HTML tag).

## Example
Here we are adding the data attribute `inputId` for HTMLInputElement
```tsx
// ChangeEventHandler<DatasetInjector<HTMLInputElement, { inputId: string }>>

export type DatasetInjector<HTMLInputElement, D extends DOMStringMap> = HTMLInputElement & {
  dataset: D; // D -> { inputId: string }
};
```

## Usage in real world
Following example uses a simple Inputs component to demonstrate the custom generic helper in action.
I have two inputs with a custom attribute `inputId`.
This is used to determine which input was called the `onChange` handler when the password or confirm password was entered.

```tsx
import React, { ChangeEventHandler, useState } from 'react';

const Inputs = () => {
  const [value, setValue] = useState({
    password: '',
    confirmPassword: '',
  });

  const changeHandler: ChangeEventHandler<
    DatasetInjector<HTMLInputElement, { inputId: string }>
  > = (e) => {
    setValue((prevState) => ({
      ...prevState,
      [e.target.dataset.inputId]: e.target.value,
    }));
  };

  const textareaChangeHandler: ChangeEventHandler<
    DatasetInjector<HTMLTextAreaElement, { inputId: string }>
    > = (e) => {
    setValue((prevState) => ({
      ...prevState,
      [e.target.dataset.inputId]: e.target.value,
    }));
  };

  return (
    <>
      <input
        data-input-id='password'
        onChange={changeHandler}
        value={value.password}
      />
      <textarea
        data-input-id='confirmPassword'
        onChange={textareaChangeHandler}
        value={value.confirmPassword}
      />
    </>
  );
};
```
With this custom generic type in place, the type system will be pleased because it will receive all the missing information required to provide type safety.

That's all there is to this code-block; Go ahead and give it a shot.

If you enjoyed the article, please spread the word and keep an eye out for future updates!
See you in the next article 😊



Whether you are working on a small prototype or a big enterprise product, having a workflow for code releases is very important and fundamental. It just makes our life much easier and saves us from nightmares like prod rollbacks and code reverts.

And before we talk about the elephant in the room. Here are some obvious things from our dev workflow

- We use GIT on local for source control
- GitHub on the cloud for central source control
- Heroku for deployments

## Our old release strategy

1. `dev` was our source of truth and base for any new task/feature/topic
2. We use to create a new branch from a `dev` for this new task/feature/topic

- `git checkout -b feature/new-feature dev`

3. We would work on the changes for the task and upon task completion, we would **raise a PR against dev**
4. This new feature would undergo QA testing
5. And would get merged in dev on QA sign-off

- `git merge --no-ff origin/dev` on branch `feature/new-feature`

6. Finally, it would get deployed on prod via dev branch

### Pro

- Easy to understand and with fewer checks involved in prod release

### Con

<img
  src='https://media.giphy.com/media/cFkiFMDg3iFoI/giphy.gif'
  alt='Merge'
  width={'100%'}
/>

- There was a high possibility that a change that was merged was not ready for prod deployment/release and now because of that `dev` branch becomes
  - blocker in releasing an urgent hotfix/priority change
  - as any new change released directly via `dev`→ **break the prod** because of dependent change from the BE

<img
  src='https://media.giphy.com/media/143vPc6b08locw/giphy.gif'
  alt='Revert'
  width={'100%'}
/>

- Creates a revert situation and possibility of code loss in the process of reverting the changes
- Creates diverged history and code conflict situation, for other people's from the team if they have taken a pull from dev prior code revert
- now they have to revert the changes in their respective branches, accidental loss of unpublished code viz hard to recover

So as a solution, we came up with the idea of sprint branches for every sprint release

## Release strategy with sprint branches

<aside>
  😎 Now instead of merging the code directly in `dev`, we will merge it in the
  `sprint-branch` and that will be merged in `dev`
</aside>

### Pro

- All the benefits as before and this solved most of the cons mentioned earlier

### Con

- As we tend to decide in advance, in every spring meeting - what features will go in the sprint. There is a high possibility - TBH it was 9 out of 10 times that, some feature would delay the sprint and we won’t merge/release the sprint branch on decided date and time.

This created another set of issues,

- We put a hold on creating any branch for the upcoming sprint
- people are not sure where to point new features as the old sprint branch is still hanging in the middle of nowhere
- some features/fixes get directly merged into dev meanwhile which can be missed if not tracked carefully

With all this, **managing the sprint branch becomes a task on its own** that -

- It has not diverged from dev
- It has correct changes
- It doesn’t have any new changes which got merged recently to name a few

## Solution and new release workflow

<aside>💡 Avoid the sprint branches and use the release branches</aside>

By adding a few simple changes which are as follows,

- For prod releases `main` will be used
- Every feature must branch off from the **dev**
- Every feature must get merged back into the **dev** with **PR to** `dev`
- Every feature will be **merged and released in** `main` **via release/feature release branch** with only one condition
  - They are tested by dev and QA
  - verified End to end
  - 80% stable
  - And has no pending BE dependency (the only exception is where, both FE and BE will go at the same time)
- Naming convention: **feature/feature-name**
- Flow: `feature/cart-ux` → `dev` → `release-12-12-21-00` → `main` → merge `main` to `dev`

With this new change now we will have mainly three types of the branches -

1. Main branches
1. `main`
1. `dev`
1. Supporting branches
1. `feature branches`
1. `release branches`
1. `hotfix branches`

To expand these branches, see the following git flow graphs

## Main branches

<a href='https://postimg.cc/WhrJg1qK'>
  <img
    src='https://i.postimg.cc/zX2SmLzJ/main-branch.png'
    alt='main branches'
    height={204}
    width={'80%'}
  />
</a>

**main**

- Point of source for Prod releases
- Point of source for Prod hotfix branches (more on this on hotfix branches)
  **dev**

- Dev always have the latest development changes (QA verified and approved for prod deployment) for the future releases
- Every **new feature** should **branch off** **from the** `dev` → (git checkout -b feature/new-feature dev)
- After completion **feature** must **merge back into** → `dev` → `release-branch` → `main` → merge

## Supporting branches

### Feature branches

Point of source for feature development

<a href='https://postimg.cc/jCDfqXxR'>
  <img
    src='https://i.postimg.cc/HW292ZF8/feature.png'
    alt='feature branches'
    height={204}
    width={'80%'}
  />
</a>

- Every feature must branch off from the **dev**
- Every feature must get merge back into the **dev** with **PR to dev**
- Should be released via release branch to the **main**
- Naming convention: **feature/feature-name**
- Flow: feature/holds → **`dev`** → `release-12-12-21-00` → `main` → merge main to **`dev`**

### Release branches

Point of source for feature release from dev to main

<a href='https://postimg.cc/Z0XdWdnp'>
  <img
    src='https://i.postimg.cc/Wb16fmPW/release.png'
    alt='release branches'
    height={204}
    width={'80%'}
  />
</a>

- Every release must branch out from **dev**
- Must get merged into **main**
- Naming convention: **release-dd-mm-yy-xx**
  - xx is no of releases done on same day
  - e.g. release-12-12-21-00 is first release on 12th Dec, whereas release-12-12-21-01 is 2nd release on 12th Dec
- Git Flow : `git checkout -b release-12-12-21-00 dev` → merge **release-12-12-21-00** → **main** → merge main to **dev**

### Hotfix branches

Prod hotfix release branch

<a href='https://postimg.cc/FkkkP9WY'>
  <img
    src='https://i.postimg.cc/Y0bNC0Qz/hotfix.png'
    alt='hotfix branches'
    height={204}
    width={'80%'}
  />
</a>

- Hotfix must branch off from the `main`
- Hotfix branch must get merged back into the `main`
- The Hotfix should be **verified on pre-prod (alpha)** → then only it should get deployed on main (prod)
- main should be merged into `dev` for syncing the history back

---

> **It’s not the thing itself, but how you use it —** A.D. Aliwat, [In Limbo](https://www.goodreads.com/work/quotes/88160386)

---

This workflow is not a rule of thumb that one need to follow. This is like a simple guideline if followed will make the team collaboration smooth and more like a simple routine.

<img
  src='https://media.giphy.com/media/I1U9DTjCqOF3i/giphy.gif'
  alt='https://media.giphy.com/media/I1U9DTjCqOF3i/giphy.gif'
  width={'80%'}
/>

So discuss with this among your team and see if this make sense for your need. And as always for more interesting reads keep an eye for future updates.



As a growing startup with a strong focus on moving fast — adding new features and extending existing product services
are part of our daily routine and vital to growth.

<img
  src='https://media.giphy.com/media/2zdnl4CB3OygOHe1kX/giphy.gif'
  alt='https://media.giphy.com/media/2zdnl4CB3OygOHe1kX/giphy.gif'
  _mstalt='2408133'
  style={{ textAlign: 'left', width: '100%' }}
/>

But with every new addition, there is always one thing that never changes, **the possibility of breaking the product or
service**. For this, we plan and design every new feature meticulously to make the development phase smoother and reduce
the probability of introducing a breaking change.

And let’s face it! Breaking changes will become one of the factors affecting the goals and morale of the team if these
are frequent. So this becomes a big question...

## How a feature becomes a breaking change?

There could be _an ‘n’_ number of factors that can turn a new feature or related code into breaking change. It could be —

- An infrastructure issue or bottleneck
- unreviewed or poorly written code
- lack of basic error handling
- untested or missed areas in the feature during the QA cycle
- OR simply a human error — _To error is Human!_

Irrespective of factors having a plan to mitigate and minimize the breaking change becomes integral to delivering any
feature successfully on time.

So we start by stating the obvious —

## What is a breaking change?

<img
  src='https://media.giphy.com/media/wGEymBvo6FUlR9bbda/giphy-downsized-large.gif'
  alt='https://media.giphy.com/media/wGEymBvo6FUlR9bbda/giphy-downsized-large.gif'
  _mstalt='3968172'
  style={{ textAlign: 'left', width: 'auto', height: 280, marginTop: 12 }}
/>

Knowing what can result in breaking change is the first step to weed out the
breaking changes during the development and code review phase.

Most of the time these factors are closely related to fundamentals of technology - frontend or backend, tools that are
used for writing the feature or code. To name a few following are some examples -

### Common examples for backend include:

- Removing a resolver or field resolver
- Removing a response field
- Updating a resource or method URI
- Updating a field name
- Updating _required_ query parameters/inputs
- Updating authorization

### Common examples for backend include:

- Removing a resolver or field resolver
- Removing a response field
- Updating a resource or method URI
- Updating a field name
- Updating _required_ query parameters/inputs
- Updating authorization

## What is not a breaking change?

![https://media.giphy.com/media/zOvBKUUEERdNm/giphy.gif](https://media.giphy.com/media/zOvBKUUEERdNm/giphy.gif)

Just as knowing _what is a breaking change?_ It is equally important to know _what is not a breaking change?_

This is important for code reviewers along with independent contributors as this gives confidence that a newly written
block isn’t a breaking change, and we can ship it on time.

### Common examples of additive, non-breaking changes include:

- Adding a new resolver or field resolver
- Adding a new response field
- Adding optional query parameters / inputs

Some exceptions - adding _required_ query parameters/inputs to an **existing endpoint** — are breaking change.

## Measures to prevent breaking changes

Once we know - what is and what is not a breaking change, we can come up with a list of rules which can be included in
our development workflows from the very start till the end of delivery of the feature.

1. Take some time to plan the feature and identify the changes that may turn it in the breaking change. Once identified
   categorize the nature of breaking change —

- Low risk
- Medium risk
- High risk

and start working towards the possible solution to fix it.

2. Discuss and **communicate new change with original code author(s)** before starting the feature**.** To make sure we
   don't break or remove something from existing feature.
3. Always try to **request and get a review from the original author** and people who know about the area which is
   impacted by the introduction of the new feature.
4. Test your change for accidental breaking changes before pushing it to staging environment.(worst case prod). Ideally
   one should only **push the change after verifying the Happy flow** of the feature.
5. Along with introducing the new feature, **provide support for the old feature for a set period** to allow smooth
   transition to new feature. By,

- Using `Breaking Change` as a tag for pull requests with GitHub, similarly `Breaking-Change` with JIRA and tag
  stakeholder dev’s for better visibility.

<a href='https://postimg.cc/Y4zfG3CG'>
  <img
    src='https://i.postimg.cc/wBSWr4KV/github.png'
    alt='Github tags'
    height={204}
    style={{ marginBottom: 12, width: '100%' }}
  />
</a>

<a href='https://postimg.cc/3yTFx6YQ'>
  <img
    src='https://i.postimg.cc/YS4nbKP0/jira.png'
    alt='Jira tags'
    height={204}
    style={{ marginBottom: 12, width: '100%' }}
  />
</a>

- Using `@deprecated` header/badge/tag to give clients (web or app) more time to react.
- Communicate all the consumers, If there are multiple clients consuming the service to make avoid last moment rollbacks or fixes.

6. Set **clear timelines** and have **clear communication**

That said above points will only be useful if everyone from the team knows about the feature and changes _ahead of time_
so that it gets reviewed, tested correctly, and finally makes to prod happily.

<img
  src='https://media.giphy.com/media/MT5UUV1d4CXE2A37Dg/giphy.gif'
  alt='https://media.giphy.com/media/MT5UUV1d4CXE2A37Dg/giphy.gif'
  style={{ marginBottom: 12, width: 'auto', height: 280 }}
/>

And as a part of the process, we keep tinkering with this approach to make feature deliveries smooth and perfect
so keep an eye for future updates!


Recently Published

Mobile Responsiveness - Designing for Different Screen Sizes

Property dataset does not exist react typescript error

How to release the features - GIT flow

Breaking Change mitigation

Post Categories

Trending Content