DEV Community: Mansoor Omrani

Bring only changed files to production, efficient way

Mansoor Omrani — Mon, 05 May 2025 08:40:25 +0000

In this post, I want to share with you @puya/fh, a small cli utility we developed at our company Puyasoft in nodejs that we think is helpful in keeping a folder in sync with another folder by copying only changed files.

TL;DR

Jump right to Too Long, Didn't Read section.

Introduction

The main usage of @puya/fh is helping in syncing content of a folder based on its differences with another folder, no matter where they are located (same machine or different machines).

The tool does not perform the sync job itself when the two folders are located in separate machines. It provides features though that helps in creating a changeset out of the changes.

The next step (transferring and extracting the changeset onto target folder) is easy - can be performed manually or by any automation tool or script.

Story

Traditional/Legacy Application Update

Troubles of manual application update by bringing dev changes to production is a similar memory.

No matter how attentively we track the files we change during development, we find ourselves end up creating a zip, transfer it to production and extract it there.

We always asked ourselves at the end of the day, "Couldn't be there a tool using which we could copy/transfer only the changed files, not the whole local publish folder?"

@puya/fh is a tool that facilitates this job.

Modern way: Docker/Containerization

Docker is the modern automated way of bringing a feature to production. It has proved itself as a mandatory non-removable ingredient in ci/cd applications.

The benefits of docker are non-disputable. The only drawback is, even a tiny change results in a large impact, requiring the containers being restarted and waste of time/resource/traffic/space.

If there could be a tool by which we could copy only changed files into a running container and update the app inside that, there wouldn't be a need to restart the container.

Are we hearing blasphemy or is this a joke? Not only are containers immutable and no one is ever allowed to change them, an update may change dependencies or configuration.

Well. If we are careful about what we do in certain situations, we can cross red lines safely.

I believe, the end result is as rewarding as it worth it to give it a try.

The end result is gaining a huge optimization in fixing bugs or even releasing application updates: less time, space, traffic, latency, response time, and faster release.

If the new update does not require infrastructural change, like dependency change (installing new packages), we may be able to bypass docker and put our files directly in the container.

Target Audience

Any developer in any technology, php, java, .net, nodejs, python, etc.
DevOps engineers
Support teams

@puya/fh is not limited to tech environments or software production. It can be used by anyone who intends to make a folder in sync with another folder.

How does it work?

The way @puya/fh works is simple. It navigates a folder, checks its files and sub-folders recursively and generates a final .json file.

It writes names of the files/sub-folders into the generated .json, together with their hash in a nested parent/child hierarchy.

The hash of a file is generated based on its md5.

For sub-folders, the hash is generated based on the hash of its files/sub-folders.

It is this hash that will be later used to compare folders together.

Features

@puya/fh is able to ...

Generate a json for a folder
compare two folders (based on their paths or json)
produce a report based on the differences between two folders
create a batch file (to copy changes manually)
copy the changes directly
create a zip file for changes

Installation

npm i @puya/fh -g

How to use

Generate `.json` for a folder

Example 1: current directory

> fh hash

Example 2: another directory

> fh hash -d /path/to/my/dir

Note that, it doesn't matter where current directory is. @puya/fh produces the same result for the generated json.

By default @puya/fh uses a list of excluded folders and files such as node_modules, .git, etc. to prevent copying not-necessary items or folder/files that should be ignored based on our discretion. These lists can be customized. This is explained a little further.

Compare folders

The main job is comparing two folders. This is done through diff and apply commands.

diff is used to report changes or generate a batch file to copy changes
apply is used to copy changes directly to another folder or create a zip archive for them.

The way comparison is performed is the same between these two commands.

Compare by paths

> fh diff -f /path/to/source -t /path/to/target

Here, source folder is the folder containing new changes that we intend to copy to target folder.

Compare by path and json

As it was said, source and target folders are not necessarily required to be located physically on the same machine.

If target is located on another machine, we can generate its json on the target machine, bring the json to source machine and perform comparison.

> fh diff -f /path/to/source -t /path/to/target.json

Compare by json

We can perform comparison solely based on json files.

> fh diff -f /path/to/source.json -t /path/to/target.json

`diff`: report or generate batch

diff does not copy anything. It is used to report the changes or create a batch file for copying them. The behavior is specified through -k argument.

report: report changes to console (default)
cmd: generate a windows .bat file.
bash: generate a linux .sh file.

`apply`: copy changes or create a zip archive for them

There are 3 usecases that can happen for apply command.

Copy changes directly to target folder This is only applicable if the two folders are located on the same machine.

> fh apply -f /path/to/source -t /path/to/target

Copy changes to a temp directory on source machine We can then refer to the temp directory and do whatever we want to that.

> fh apply -f /path/to/source -t /path/to/target -rt /path/to/temp

Create a zip archive Using -c or --compress argument, we can create a zip archive instead of copying the changes.

> fh apply -f /path/to/source -t /path/to/target -c

It is evident that, no matter what usecase we are using, the apply command should have access to source folder to read changed files to either copy them or create an archive.

source/target path accommodation

When using diff and apply commands, since source and target folders can reside in different locations, we may need to accommodate paths, so that the copy process or the created batch file works correctly.

This is done through -rf and -rt arguments for adapting source and target paths respectively.

> fh apply -f source -t target -rf /path/to/source -rt /path/to/target

Specifying Exclude/Include folder/files

By default, @puya/fh uses a list of excluded files and folders as below:

Excluded folders:

node_modules
.git
tests
__tests__
packages
wwwroot
coverage
.vscode
.idea
build
publish
.vs

Excluded files:

thumbs.db
package.json
packages.config
.env
.gitignore
.ds_store
*.log
*.test.js
*.spec.js
*.bak
*.tmp
sync.bat
sync.sh

These lists can be customized through the following arguments:

-ed or --exclude-dirs: specify excluded directories
-id or --include-dirs: specify included directories
-ef or --exclude-files: specify excluded files
-if or --include-files: specify included files

The list should be provided as a comma separated list.

> fh -ed ".git,node_modules"

If the value starts with comma, the list is added to the default list:

> fh -ed ",my-excluded-dir1,my-excluded-dir2"

Bringing changes to production

Traditional way

Run @puya/fh on production where target folder is located.
Bring target's json to the source machine.
Compare target json with source folder and create a changeset archive.
Transfer the changeset to production.
Extract it there at the root of target folder.

Modern way: docker/container

step 1: run @puya/fh inside the container (assuming @puya/fh is already installed in the container)

docker exec my_container fh -d /app

step 2: copy app.json to the host

docker cp my_container:/app.json ./app.json

step 3: compare app.json with the new version of the app and create a changeset archive

fh apply -f ./app -t app.json -c -o changeset.zip

step 4: copy changeset into the container:

docker cp changeset.zip my_container:/app

step 5: extract changeset inside the container (assume unzip is installed already inside container)

docker exec my_container unzip /app/changeset.zip -d .

These commands can be put in a pipeline script and are activated conditionally based on our decision.

Now, when we have a small mild change that we know does not require say, dependency change, we can directly update our app inside our running container without restarting it.

Too Long, Didn't Read

@puya/fh is a cli tool by which we can copy new changes from a source folder to a target folder or create a zip archive out of the changes, so that we apply (transfer/extract) the changes to target manually.

The latter is useful when the two folders are not located on the same machine.

Usecase 1: copy changes from source to target

fh apply -f source -t target

Usecase 2: create archive out of changes

step 1: create a json for target folder

fh -d /target

step 2: bring target.json to source machine.
step 3: create a zip changeset based on changes between source and target

fh apply -f /source -t target.json -c -o changeset.zip

step 4: transfer changes.zip to target machine.
step 5: extract changes.zip in target folder.

step 2, 4 and 5 can be done manually or using any tool/command.

Making React Context easier to work with: A dynamic approach

Mansoor Omrani — Mon, 27 Jan 2025 11:17:56 +0000

Abstract

Context is a useful and common way to provide a global state in a react app, like current language, theme or user. In this article, we will introduce a helper class that eases creating and working with contexts in React applications.

TL;DR

Go to the bottom of the page. :)

Story

Suppose we have a multi-language and multi-theme app in which we plan to use context to store current app's language and theme. Also, we use a user context to store currently logged in user's information.

Common Approach

Based on best practices, we are better to create a ./contexts folder and put our contexts there.

Here is the code for our language context.

./contexts/Lang.jsx

import React, { createContext, useState } from "react";

const LangContext = createContext([, (x) => x]);
const Lang = ({ lang, children }) => {
   const [value, setValue] = useState(lang);

   return (
            <LangContext.Provider value={[value, setValue]}>
                {children}
            </LangContext.Provider>
        );
    }

export { LangContext, Lang }

As it is seen, we wrapped our context in a Lang component and used a state in order to store current language. We then used the state and its setter function as the context's value.

Next, we are also better to create a ./hooks folder and put our hooks there.

./hooks/useLang.js

import { useContext } from "react";
import { LangContext } from "../contexts/Lang";

function useLang() {
  const value = useContext(LangContext);

  return value;
}

export default useLang;

The same can be done for Theme and User contexts and their hooks.

./contexts/Theme.jsx

import React, { createContext, useState } from "react";

const ThemeContext = createContext([, (x) => x]);
const Theme = ({ theme, children }) => {
   const [value, setValue] = useState(theme);

   return (
            <ThemeContext.Provider value={[value, setValue]}>
                {children}
            </ThemeContext.Provider>
        );
    }

export { ThemeContext, Theme }

./hooks/useTheme.js

import { useContext } from "react";
import { ThemeContext } from "../contexts/Theme";

function useTheme() {
  const value = useContext(ThemeContext);

  return value;
}

export default useTheme;

./contexts/User.jsx

import React, { createContext, useState } from "react";

const UserContext = createContext([, (x) => x]);
const User = ({ user, children }) => {
   const [value, setValue] = useState(user);

   return (
            <UserContext.Provider value={[value, setValue]}>
                {children}
            </UserContext.Provider>
        );
    }

export { UserContext, User }

./hooks/useUser.js

import { useContext } from "react";
import { UserContext } from "../contexts/User";

function useUser() {
  const value = useContext(UserContext);

  return value;
}

export default useUser;

We also create index.js files inside ./contexts and ./hooks folders to simlifies our imports.

./contexts/index.js

import { Lang, LangContext } from './Lang'
import { Theme, ThemeContext } from './Theme'
import { User, UserContext } from './User'

export {
   Lang, LangContext,
   Theme, ThemeContext,
   User, UserContext
}

./hooks/index.js

import useLang from './useLang'
import useTheme from './useTheme'
import useUser from './useUser'

export {
   useLang,
   useTheme,
   useUser
}

Here is a simple main application component that uses the contexts:

import { Lang, Theme, User } from './contexts';

const App = () => <>
   <Lang lang={'en'}>
      <Theme theme={'blue'}>
         <User user={null}>
            <h1>My App</h1>
            ...
         </User>
      </Theme>
   </Lang>
</>

export default App

Using contexts' hooks

NavBar

Using the contexts is easy. Here is a simple bootstrap navbar with a language and theme drop down.

./components/navbar.jsx

import { useLang, useTheme } from '../hooks';

const langs = ['en', 'de', 'fr', 'es'];
const themes = ['red', 'green', 'blue', 'dark', 'light'];

const NavBar = () => {
   const [lang, setLang] = useLang();
   const [theme, setTheme] = useLang();

   return (<nav class="navbar navbar-expand-lg navbar-light">
      <div className="collapse navbar-collapse">
       <ul className="navbar-nav">
         <li className="nav-item active">
           <a className="nav-link" href="/">Home <span class="sr-only">(current)</span></a>
         </li>
         <li className="nav-item dropdown">
           <a className="nav-link dropdown-toggle" href="#" id="navbarDropdown" role="button" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false">
          Language
           </a>
           <div className="dropdown-menu" aria-labelledby="navbarDropdown">
          {langs.map(la => <a key={la} class={`dropdown-item ${la == lang ? 'active': ''}`} onClick={() => setLang(la)}>{la}</a>)
           </div>
         </li>
         <li className="nav-item dropdown">
           <a className="nav-link dropdown-toggle" href="#" id="navbarDropdown" role="button" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false">
          Theme
           </a>
           <div className="dropdown-menu" aria-labelledby="navbarDropdown">
          {themes.map(th => <a key={th} class={`dropdown-item ${th == theme ? 'active': ''}`} onClick={() => setTheme(theme)}>{theme}</a>)
           </div>
         </li>
       </ul>
     </div>
  </nav>)
}

Login

User context is used to store currently logged-in user and provide it for the entire app.

./components/Login.jsx

import { useUser } from '../hooks';

const Login = () => {
    const [user, setUser] = useUser();
    const [username, setUserName] = useState()
    const [password, setPassword] = useState()

    const handleLoginClicked = () => {
      // check user credentials here
      if (username == 'admin' && password == '123') {
         setUser({ username });
      } else {
         alert('Login failed');
      }
    }

    return (<form>
  <div className="form-group">
    <label for="username">Username</label>
    <input type="text" className="form-control" placeholder="Enter username" value={username} onChange={e => setUsername(e.target.value)}>
  </div>
  <div className="form-group">
    <label for="password">Password</label>
    <input type="password" className="form-control" placeholder="Enter password" value={password} onChange={e => setPassword(e.target.value)}>
  </div>
  <button type="submit" className="btn btn-primary" onClick={handleLoginClicked}>Submit</button>
</form>)
}

Discussion

What we saw is the common approach in using contexts. It is straightforward and removes the need to use a third-party state management library like Redux. We all know that.

However, looking back at the code, there are two issues with it.

First, contexts' code seems redundant. Moreover, we need to repeat a similar code in order to add a new context.

Second, adding more contexts, leads to a code-smell known as context hell.

There are solutions to avoid context hell. Again, we all know that.

However, is it possible to enhance our code in a way to resolve the first issue?

If our contexts follow a similar structure, the answer is yes.

Here, all of our contexts use a single internal state and publicize it together with the setter function through context's value.

Solution: `createContext()` helper

We can write a global helper function that is able to create contexts dynamically, once and for all without the need to define them manually.

We name it createContext and put it in a util folder in our app.

./util/createContext.jsx

import React, { createContext, useState, useContext } from "react";

function _createContext(name, state) {
    name = name[0].toUpperCase() + name.substr(1);

    const Context = createContext([state, () => state]);

    const Provider = (props) => {
        const { [name]: _state, children } = props;

        const [value, setValue] = useState(_state || state);

        return (
            <Context.Provider value={[value, setValue]}>
                {children}
            </Context.Provider>
        );
    }

    function use() {
        const value = useContext(Context);

        return value;
    }

    return { [name + 'Context']: Context, [name]: Provider, ['use' + name]: use };
}

export default _createContext;

As it is seen, our helper also creates a hook. So, we don't need to write hooks manually.

Improved Approach-1

Now, creating our Lang, Theme and User contexts will be a little easier.

./contexts/index.js

import createContext from '../util/createContext'

const { Lang, LangContext, useLang } = createContext('Lang')
const { Theme, ThemeContext, useTheme } = createContext('Theme')
const { User, UserContext, useUser } = createContext('User')

export {
   Lang, LangContext, useLang,
   Theme, ThemeContext, useTheme,
   User, UserContext, useUser
}

There is no need to really expose contexts themselves (LangContext, ThemeContext, UserContext). We can work with them through their hooks. Nevertheless, we expose them, so that one may want to use contexts in a class component.

The application code is the same and no change is required:

import { Lang, Theme, User } from './contexts';

const App = () => <>
   <Lang lang={'en'}>
      <Theme theme={'blue'}>
         <User user={null}>
            <h1>My App</h1>
            ...
         </User>
      </Theme>
   </Lang>
</>

export default App

We only need to import hooks through ./contexts, not ./hooks.

./components/NavBar.jsx

import { useLang, useTheme } from '../contexts'

const NavBar = () => {
   ...
}

More Improvement: `AppContext` class

Does the improvement end? No. A second improvement could also be used.

We can create a helper class on top of our createContext and resolve context requirement of our application and any other future application entirely.

./util/AppContext.jsx

import createContext from './createContext';

class AppContext {
    constructor(...names) {
        this.createContexts(...names)
    }
    createContexts(...names) {
        this.contexts = {}
        this.hooks = {}
        this.providers = {}
        this.elements = []

        for (let name of names) {
            const ctx = createContext(name);

            const Provider = ctx[name];
            const context = ctx[name + 'Context'];
            const hook = ctx['use' + name];


            this.elements.push(<Provider />);
            this.providers[name] = Provider;
            this.contexts[name] = context;
            this.hooks['use' + name] = hook
        }
    }

    createApp(child) {
        const _elements = [...this.elements]

        if (child) {
            _elements.push(child);
        }

        const root = _elements.reduceRight((prev, ctx) => React.cloneElement(ctx, {}, prev))

        return () => <>{root}</>;
    }
}

export default AppContext;

This class, provides a createApp() method that merges all contexts together and avoids context hell.

Improved Approach-2

First, let's change our context creation.

./contexts/index.js

import AppContext from '../util/AppContext'

const appContext = new AppContext('Lang', 'Theme', 'User');
const { useLang, useTheme, useUser } = appContext.hooks;

export default appContext
export { useLang, useTheme, useUser }

Next, using createApp() we don't need to manually import and use contexts.

Thus, our App component will be briefed into the following code:

./App.jsx

import appContext from './contexts'

const App = appContext.createApp(<>
      <h1>My App</h1>
      ...
    </>);

export default App;

That's all.

The createApp() method receives a child component and puts it inside the last context. That's where app's body or content go.

Lastly, in order to work with a context's hook, we should import it through our appContext.js.

./components/NavBar.jsx

import { useLang, useTheme } from '../contexts'

const NavBar = () => {
   ...
}

Conclusion

As we saw, using AppContext helper class makes application code simpler regarding context.

In reality, there is no need to create a contexts folder at all. We can create a appContext.js, perhaps at the root of our app, and write our context creation code there.

That file forms our application's context. That's why we name it appContext. A file that holds the app's context.

I hope readers find this approach useful. Feel free to post your comments and thoughts.

P.S.
Final AppContext helper class is put at the following github gist.

AppContext

It also supports inital states for contexts. We just need to pass the context and its inital state as an array to AppContext constructor.

./appContext.js

const appContext = new AppContext(['Lang', 'en'], ['Theme', 'light'], 'User');
...

Furthur thoughts:
If ES6 had supported dynamic export, we could write our context in a more briefed form (not needing to destructure and export the hooks explicitly and manually):

const appContext = new AppContext('Lang', 'Theme', 'User');

export default appContext
export { ...appContext.hooks }

It seems, the reason behind ECMASCript's not to support dynamic export was to provide better tree-shaking.

If we could switch to commonjs, we could make appContext a little simpler.

const appContext = new AppContext('Lang', 'Theme', 'User');

exports = { appContext, ...appContext.hooks }

However, I couldn't put this approach into practice, due to errors happened after that. I will be happy to know if anyone finds a solution for that.

TL;DR

Using the helper AppContext, it is easier to create and work with contexts in react applications.

Instead of explicitly and manually creating separate contexts and hooks, we just need to create a single appContext.js at the root of our project, and create our contexts there.

./appContext.js

import AppContext from '..../AppContext'

const appContext = new AppContext('Lang', 'Theme', 'User');
const { useLang, useTheme, useUser } = appContext.hooks;

export default appContext
export { useLang, useTheme, useUser }

./App.jsx

import appContext from './contexts'

const App = appContext.createApp(<>
      <h1>My App</h1>
      ...
    </>);

export default App;

Not only will the App component be easier, but also we avoid context hell issue forever.

Dev Insight

Mansoor Omrani — Sat, 30 Dec 2023 06:42:04 +0000

Angular is doomed.
React should retire.
Vue is childish.
Css is swamp land.
HTML is a paper map.
JavaScript is too old.
Typescript is shackles.
.NET seeks sovereignty.
EF is a bad sleep.
Blazor is a trap.
SOAP is steam machine.
REST should rest.
OOP is old testament.
Clean Architecture gives a pile of mess.
Monolithic Architecture is elephant.
MicroService architecture is disaster.
TDD is the emperor's new clothes.
DDD is luxurious bureaucracy.
Scrum is ostrich.
ADO is holy.
SQL is Hercules.
NoSql is cripple.
AI is Armageddon.
Git is ants' nest.
Linux is dark world.
Windows is opium.
Android walks on a sword' edge.
iOS is forbidden city.
DevOps is headache.
Python is disease.
Nodejs is Pisa tower.
C# is deviated.
Java is orthodox.
PHP is deathless.
Delphi is zombie.
VB rested in peace.
GoLang is squadron.
Rust is blade.

share and save lives!

react-reduxify, use simpler reduxify() over the cryptic connect()

Mansoor Omrani — Sun, 20 Dec 2020 07:23:05 +0000

Using redux in React class components requires using connect() function from react-redux package.

Example:

import React from 'react';
import { connect} from 'react-redux';
import { increment, rate } from '../actions';

class Product extends React.Component {
 // ...
}

const mapStateToProps = state => ({
   likes: state.likes,
   rate: state.rate
})
const mapDispatchToProps = dispatch => ({
   increment: () => dispatch(increment()),
   rate: (value) => dispatch(rate(value))
});

export default connect(mapStateToProps, mapDispatchToProps)(Product)

react-reduxify can make this a little simpler.

import reduxify from 'react-reduxify';
...
export default reduxify(Product, 'likes,rate', { increment, rate })

There's no need to write mapStateToProps and mapDispatchToProps.

`reduxify` signature:

function reduxify(component, neededStates, neededActions, mergeOptions, options) {
...
}

Parameters

component: React class component to be reduxified (use some states in redux store in that)
neededStates (string, array -of string | object- or object): needed state items from redux store.
neededActions (object): needed actions.
mergeOptions (function): similar to mergeOptions in connect().
options (object): similar to options in connect().

String is the simplest form of using neededStates. It could be a comma separated list of items with the following format:

{name?:}{state_key}{=default_value?}

name and default_value are optional.

Example:

export default reduxify(Product, 'count,lang:config.lang=EN,year:config.current_year=2020')

This is similar to:

const mapStateToProps = state => {
  const props = {
    count: state.count,
    lang: state.config.lang,
    year: state.config.current_year
  }

  if (typeof props.lang == 'undefined') {
    props.lang = 'EN'
  }
  if (typeof props.year == 'undefined') {
    props.year = '2020'
  }

  return props;
}

export default connect(mapStateToProps, null)(Product)

More examples at: react-reduxify

reduxify has its own cons though. For example it's not possible to use expressions in the neededStates, while this is possible when writing a manual mapStateToProps function where you have full control over the state.

Comments and suggestions are welcomed.

DEV Community: Mansoor Omrani

Bring only changed files to production, efficient way

TL;DR

Introduction

Story

Traditional/Legacy Application Update

Modern way: Docker/Containerization

Target Audience

How does it work?

Features

Installation

How to use

Generate .json for a folder

Compare folders

Compare by paths

Compare by path and json

Compare by json

diff: report or generate batch

apply: copy changes or create a zip archive for them

source/target path accommodation

Specifying Exclude/Include folder/files

Bringing changes to production

Traditional way

Modern way: docker/container

Too Long, Didn't Read

Usecase 1: copy changes from source to target

Usecase 2: create archive out of changes

Making React Context easier to work with: A dynamic approach

Abstract

TL;DR

Story

Common Approach

Using contexts' hooks

NavBar

Login

Discussion

Solution: createContext() helper

Improved Approach-1

More Improvement: AppContext class

Improved Approach-2

Conclusion

TL;DR

Dev Insight

react-reduxify, use simpler reduxify() over the cryptic connect()

reduxify signature:

Generate `.json` for a folder

`diff`: report or generate batch

`apply`: copy changes or create a zip archive for them

Solution: `createContext()` helper

More Improvement: `AppContext` class

`reduxify` signature: