Ibrahim https://ibrahim-blog.iabushammah.now.sh/ Blog RSS Feed

Dealing with bad code

Mon, 20 Jul 2020 22:12:03 GMT

Study the code Base Document when you don’t have documents

Don’t try to change the flow of Data & UI Rewriting parts of the code can sometimes be hard Change only necessary Take one step at time

(This is an article posted to my blog at https://ibrahim-blog.iabushammah.now.sh/. You can read it online by clicking here.)

asynchronous dispatch is now on npm packages!

Fri, 05 Jun 2020 22:12:03 GMT

async-dispatch is a middleware can be added with no time to privilage the asynchronous into your store

For more informatiom about the future of redux-logger, check out the discussion here.

Table of contents
Install
Usage
To Do
License

Install

npm i --save async-dispatch

Usage

import asyncDispatchMiddleware from "async-dispatch";
import { createStore } from "redux";
import { applyMiddleware } from "redux";

const store = createStore(
  rootReducer,
  applyMiddleware(asyncDispatchMiddleware)
);
// Note passing middleware as the third argument requires redux@>=3.1.0

Then applying this middleware is simple as

const LoginReducer = (state = intialState, action) => {
      login(action.userData).then((data) => {
        if (data.error) {
          action.asyncDispatch({
            type: actionTypes.ERROR,
            message: data.error,
          });
        } else {
          action.asyncDispatch({
            type: actionTypes.SUCCESS,
            user: data,
            message: "Logged successfully",
          });
        }
      });
      return { ...state };
})

To Do

Adding typeScript types

License

MIT

(This is an article posted to my blog at https://ibrahim-blog.iabushammah.now.sh/. You can read it online by clicking here.)

Write your own custom asyncDispatch middleware

Fri, 05 Jun 2020 22:12:03 GMT

As the default dispatch provided by react-redux library is a synchronous call I needed to make calls to the server where I don’t want to make changes to the structure to the code base Redux docs suggests writing your own custom middleware instead and it turns out being super easy

//asyncDispatch.js 

const asyncDispatchMiddleware = (store) => (next) => (action) => {
  let syncActivityFinished = false;
  let actionQueue = [];

  function flushQueue() {
    actionQueue.forEach((a) => store.dispatch(a)); // flush queue
    actionQueue = [];
  }

  function asyncDispatch(asyncAction) {
    actionQueue = actionQueue.concat([asyncAction]);

    if (syncActivityFinished) {
      flushQueue();
    }
  }

  const actionWithAsyncDispatch = Object.assign({}, action, { asyncDispatch });

  next(actionWithAsyncDispatch);
  syncActivityFinished = true;
  flushQueue();
};

export default asyncDispatchMiddleware;

when writing middleware `Store,` `next` state and `action` are your parameters

Then bind this middleware into your collection of middleware using applyMiddleware method provided by Redux

//store.js
import { createStore } from "redux";
import { applyMiddleware } from "redux";
import asyncDispatchMiddleware from './asyncDispatch';
import rootReducer from "./Reducer"; 
//Your reducers either root or combined version


const store = createStore(rootReducer,
    applyMiddleware(
    asyncDispatchMiddleware
    // your other middlewares ex thunkMiddleware orloggerMiddleware
)
  );

export default store;

Custom middlewares are very useful because of ease of extensibility

I have an even easier approach for you to implement it click here

Good luck

(This is an article posted to my blog at https://ibrahim-blog.iabushammah.now.sh/. You can read it online by clicking here.)

Dealing with files via MERN stack

Thu, 05 Mar 2020 22:12:03 GMT

This article meant to be written for everything you need to know about file upload MERN stack specifically.

if you want to escape this article for the code you can find here
Source Code

Let’s get started

1.Creating Server and Client instances

I assume you have already installed npm, NodeJS & MongoDB, we need to create a react app. NOTE: remember to put your repos on an organized folder structure. Open the terminal and use the following commands:

npx create-react-app file-upload-mern
cd ./file-upload-mern

Also, we want to use axios to send the file to the server instance, to install axios:

npm i axios

here we created the react client-side app, we end with a file structure like this:

file-upload-mern
├── .gitignore
├── public
├── package.json    
├── src
│   └── App.js
│   └── index.js
│   └── App.css
│   └── index.css
│   └── serverWorker.js
│   └── setupTests.js
├── README.md

Now, we need now to create the server-side app also, on the folder file-upload-mern write the following on the terminal:

mkdir server
cd ./server
npm init -y
touch server.js
touch model.js
mkdir public

server.js => is where the server instance will be
model.js => Where the file schema on mongoDB

To make sure we are on the same page this is the final file structure scheme:

file-upload-mern
├── .gitignore
├── public
├── package.json    
├── src
│   └── App.js
│   └── index.js
│   └── App.css
│   └── index.css
│   └── serverWorker.js
│   └── setupTests.js
├── server
│   └── package.json
│   └── public 
│   └── server.js
│   └── node_modules
│   └── model.js
├── README.md

To install the backend dependencies:

npm i express
npm i mongoose
npm i multer

To make things clear about the dependencies we installed:

Express is the API library for nodeJS.
Mongoose is a MongoDB object modeling tool aka nodeJS driver.
Multer is a node.js middleware for handling multipart/form-data

Now we created the server and the client sides so move to the next point.

2.Write the code

First, we will start with the client code by heading to /src/App.js to write the following:

// destination  /src/App.js

import React from 'react';
import './App.css';
import axios from 'axios';

class App extends React.Component {

  constructor(props) {
      super(props);
      this.state ={
          file: null
      };
      this.onFormSubmit = this.onFormSubmit.bind(this);
      this.onChange = this.onChange.bind(this);
  }
  onFormSubmit(e){
      e.preventDefault();
      const formData = new FormData();
      formData.append('myfile',this.state.file);
      const config = {
          headers: {
              'content-type': 'multipart/form-data'
          }
      };
      axios.post("http://localhost:5000/upload",formData,config)
          .then((response) => {
              alert("The file is successfully uploaded");
          }).catch((error) => {
      });
  }

  onChange(e) {
      this.setState({file:e.target.files});
  }

  render() {
      return (
          <form onSubmit={this.onFormSubmit}>
              <h1>File Upload</h1>
              <input type="file" className="custom-file-input" name="myImage" onChange= {this.onChange} />
              {console.log(this.state.file)}
              <button className="upload-button" type="submit">Upload to DB</button>
          </form>
      )
  }
}

export default App;

Here we created a form in which the user uploads the file and saves it in the app component state which after submitting will be transferred for the server-side.

Now let head into the side we start with the /server/model.js

var mongoose = require('mongoose');


const fileSchema = new mongoose.Schema({
    meta_data:{}
});

mongoose.model("file",fileSchema);

And this is how we built the user schema sounds easy right?

Now let’s build the server instance which will listen on port 5000 on /server/server.js

// destination /server/server.js
const express = require("express");
const path = require("path");
const multer = require("multer");
const mongoose  = require("mongoose");
const app = express();
const PORT = 5000;
require("./model")
const File = mongoose.model("file");
const router = express.Router();

const storage = multer.diskStorage({
   destination: "./public/",
   filename: function(req, file, cb){
      cb(null,"IMAGE-" + Date.now() + path.extname(file.originalname));
   }
});

const upload = multer({
   storage: storage,
   limits:{fileSize: 1000000},
}).single("myfile");

const obj =(req,res) => {
   upload(req, res, () => {
      console.log("Request ---", req.body);
      console.log("Request file ---", req.file);//Here you get file.
      const file = new File();
      file.meta_data = req.file;
      file.save().then(()=>{
      res.send({message:"uploaded successfully"})
      })
      /*Now do where ever you want to do*/
   });
}

router.post("/upload", obj);

app.use(router);

app.get("/",(req,res)=>{
   return res.send("<p>hello!</p>");
});

mongoose.connect("mongodb://localhost/file-upload",{
   useUnifiedTopology: true,
   useNewUrlParser: true,
   useCreateIndex: true,
}).then(()=>{console.log("DB is connected")})

app.listen(PORT,()=>{
   console.log("\u{1F525}\u{1F680} app listen on port",PORT,"\u{1F525}\u{1F680}")
});

Note: path library is a built in NodeJS library to deal with file systems paths operations and dealing with it is more recommended than using RegEx.

3.Running the code

First, make sure you are on the root directory of the project via terminal and open two instances of terminals one for the client and second for the server-side of the project: To run the server

node ./server/server.js

To run the client

npm start

4.Dealing with exporting files to the client side

you need to make the files Directory public just by exporting it as a static asset using Express

const path = require("path");
app.use(express.static(path.join(__dirname, "./public/")));

Conclusion

We discussed simple details in terms of MERN stack development note that you may get a CORS permission error and that happens because the client fetches data from different origin API and fixing it from your browser by allowing all origins of APIs and it has an extension on chrome to handle it properly. Happy coding.

(This is an article posted to my blog at https://ibrahim-blog.iabushammah.now.sh/. You can read it online by clicking here.)

Functional programming

Sun, 05 Jan 2020 22:12:03 GMT

In many ways, the concepts of functional programming (often abbreviated FP) predate programming itself. This paradigm is strongly based on the lambda-calculus invented by Alonzo Church in the 1930s.

Don’t let all the new buzzwords scare you away. It’s a lot easier than it sounds.

A programming paradigm is a way of thinking when constructing software, other examples of programming paradigms include object-oriented programming and procedural programming.

FP is the process of building software by composing pure functions, avoiding shared state, mutable data(changeable), and side-effects. Functional programming is declarative rather than imperative, and the application state flows through pure functions. Contrast with object-oriented programming, where the application state is usually shared and colocated with methods in objects or sometimes the state is being separated into its own object.

Sounds Nerdy? :nerd_face: we will explain every word said above :rose:

pure functions

This is when the same input that gives the same output always in some way it is similar to the stateless object(Has no side-effects).

Function composition

This is when the process of combining two or more functions in order to produce a new function or perform some computation. For example, composition f . g (the dot means “composed with”) is equivalent to f(g(x)) in JavaScript.This is really useful when applying the dependency inversion principle. Better check this article out! The dependency inversion principle

Shared State

Meanwhile, This is any variable, object, or memory space that exists in a shared scope, can be delivered to any function as a parameter as the property of an object being passed between scopes. A shared scope can include global scope or closure scopes. Often, in object-oriented programming, objects are shared between scopes by adding properties to other objects.

Immutation## This article meant to be written for everything you need to know about file upload MERN stack specifically. :rocket:

if you want to escape this article for the code you can find here :upsidedownface: {% github https://github.com/IbrahimShamma99/file-upload %}

Let’s get started :fire:

1.Creating Server and Client instances :building_construction:

I assume you have already installed npm, NodeJS & MongoDB, we need to create a react app. NOTE: remember to put your repos on an organized folder structure. Open the terminal and use the following commands:

npx create-react-app file-upload-mern cd ./file-upload-mern

Also, we want to use axios to send the file to the server instance, to install axios:

npm i axios

here we created the react client-side app, we end with a file structure like this:

file-upload-mern ├── .gitignore ├── public ├── package.json ├── src │ └── App.js │ └── index.js │ └── App.css │ └── index.css │ └── serverWorker.js │ └── setupTests.js ├── README.md

Now, we need now to create the server-side app also, on the folder file-upload-mern write the following on the terminal:

mkdir server cd ./server npm init -y touch server.js touch model.js mkdir public

server.js => is where the server instance will be

model.js => Where the file schema on mongoDB

To make sure we are on the same page this is the final file structure scheme:

file-upload-mern ├── .gitignore ├── public ├── package.json ├── src │ └── App.js │ └── index.js │ └── App.css │ └── index.css │ └── serverWorker.js │ └── setupTests.js ├── server │ └── package.json │ └── public │ └── server.js │ └── node_modules │ └── model.js ├── README.md

To install the backend dependencies:

npm i express npm i mongoose npm i multer

To make things clear about the dependencies we installed:

Express is the API library for nodeJS. :cowboyhatface:

Mongoose is a MongoDB object modeling tool aka nodeJS driver. :sunglasses:

Multer is a node.js middleware for handling multipart/form-data :scream:

Now we created the server and the client sides so move to the next point.

2.Write the code :computer:

First, we will start with the client :unicorn: :top: code by heading to /src/App.js to write the following:

// destination /src/App.js import React from 'react'; import './App.css'; import axios from 'axios'; class App extends React.Component { constructor(props) { super(props); this.state ={ file: null }; this.onFormSubmit = this.onFormSubmit.bind(this); this.onChange = this.onChange.bind(this); } onFormSubmit(e){ e.preventDefault(); const formData = new FormData(); formData.append('myfile',this.state.file); const config = { headers: { 'content-type': 'multipart/form-data' } }; axios.post("http://localhost:5000/upload",formData,config) .then((response) => { alert("The file is successfully uploaded"); }).catch((error) => { }); } onChange(e) { this.setState({file:e.target.files}); } render() { return ( <form onSubmit={this.onFormSubmit}> <h1>File Upload</h1> <input type="file" className="custom-file-input" name="myImage" onChange= {this.onChange} /> {console.log(this.state.file)} <button className="upload-button" type="submit">Upload to DB</button> </form> ) } } export default App;

Here we created a form in which the user uploads the file and saves it in the app component state which after submitting will be transferred for the server-side.

Now let head into the :back::end: side we start with the /server/model.js

var mongoose = require('mongoose'); const fileSchema = new mongoose.Schema({ meta_data:{} }); mongoose.model("file",fileSchema);

And this is how we built the user schema sounds easy right? :nerd_face:

Now let’s build the server instance which will listen on port 5000 on /server/server.js

// destination /server/server.js const express = require("express"); const path = require("path"); const multer = require("multer"); const mongoose = require("mongoose"); const app = express(); const PORT = 5000; require("./model") const File = mongoose.model("file"); const router = express.Router(); const storage = multer.diskStorage({ destination: "./public/", filename: function(req, file, cb){ cb(null,"IMAGE-" + Date.now() + path.extname(file.originalname)); } }); const upload = multer({ storage: storage, limits:{fileSize: 1000000}, }).single("myfile"); const obj =(req,res) => { upload(req, res, () => { console.log("Request ---", req.body); console.log("Request file ---", req.file);//Here you get file. const file = new File(); file.meta_data = req.file; file.save().then(()=>{ res.send({message:"uploaded successfully"}) }) /*Now do where ever you want to do*/ }); } router.post("/upload", obj); app.use(router); app.get("/",(req,res)=>{ return res.send("<p>hello!</p>"); }); mongoose.connect("mongodb://localhost/file-upload",{ useUnifiedTopology: true, useNewUrlParser: true, useCreateIndex: true, }).then(()=>{console.log("DB is connected")}) app.listen(PORT,()=>{ console.log("\u{1F525}\u{1F680} app listen on port",PORT,"\u{1F525}\u{1F680}") });

Note: path library is a built in NodeJS library to deal with file systems paths operations and dealing with it is more recommended than using RegEx.

3.Running the code :fire: :bug:

First, make sure you are on the root directory of the project via terminal and open two instances of terminals one for the client and second for the server-side of the project: To run the server

node ./server/server.js

To run the client

npm start

Conclusion

We discussed simple details in terms of MERN stack development note that you may get a CORS permission error and that happens because the client fetches data from different origin API and fixing it from your browser by allowing all origins of APIs and it has an extension on chrome to handle it properly. Happy coding.

s An immutable object is an object that can’t be modified(Changes) after it’s created. Conversely, a mutable object is any object which can be modified after it’s created. Immutability is the most important concept of functional programming because, without it, the data flow in your program is messed up, state history is abandoned, and strange bugs can creep into your software. I recommend you to check this medium article out it has some in-depth Immutations details

the-dao-of-immutability

(This is an article posted to my blog at https://ibrahim-blog.iabushammah.now.sh/. You can read it online by clicking here.)

The "SOLID" Principles in designing software

Mon, 12 Aug 2019 00:00:00 GMT

As with everything in life, using these principles mindlessly can cause more harm than good. The cost of applying these principles into a program’s architecture might be making it more complicated than it should be. there’s no successful software product in which all of these principles are applied at once. Striving for these principles is good, but always try to be pragmatic and don’t take everything written here as dogma.

These principles called the S.O.L.I.D principles is an acronym derived by Michael Feathers. S: Single Responsibility Principle O: Open-Closed Principle L: Liskov Substitution Principle I: Interface Segregation Principle D: Dependency Inversion Principle. So let’s start with them briefly:

1-Single Responsibility Principle

A class should have just one reason to change. Try to make every class responsible for a single part of the functionality provided by the software. Make that responsibility entirely encapsulated. One reason to change Notice The main goal of this principle is to reduce complexity. You don’t need to invent a sophisticated design for a program that only has about 200 lines of code. Make a dozen methods pretty, and you’ll be fine. The real problems emerge when your program constantly grows and changes.

2- Open/Closed Principle

Classes should be open for extension. But at the same time close for modification. The main idea of this principle is to keep existing code from breaking when you implement new features.

3- Liskov Substitution Principle

When extending a class, remember that you should be able to pass objects of the subclass in place of objects of the parent class without breaking the client code. This means that the subclass should remain compatible with the behavior of the superclass. When overriding a method, extend the base behavior rather than replacing it with something else entirely.

This concept is critical when developing libraries and frameworks because your classes are going to be used by other people whose code you can’t directly access and change.

Invariants are conditions in which an object makes sense. For example, invariants of a cat are having four legs, a tail, the ability to meow, etc.

4- Interface Segregation Principle (ISP)

Clients shouldn’t be forced to depend on methods they do not use. ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces. And notice Correct abstraction is the key to Interface Segregation Principle.

5- Dependency Inversion Principle (DIP)

High-level classes shouldn’t depend on low-level classes. Both should depend on abstractions. Abstractions shouldn’t depend on details. Details should depend on abstractions.

To make a distinction between low and high-level classes • Low-level classes implement basic operations such as working with a disk, transferring data over a network, connecting to a database, etc. • High-level classes contain complex business logic that directs low-level classes to do something.

In quick words how to implement DIP A-Build low-level classes B-Build its interface based on abstraction C-Build high-level classes

Conclusion

We discussed briefly the solid principles when designing software, although you would never implement them each project you wok with, In the other hand; it is good to put those principles on notice when coding or when design the software by the architect.

(This is an article posted to my blog at https://ibrahim-blog.iabushammah.now.sh/. You can read it online by clicking here.)

What is depedency inversion

Fri, 05 Jul 2019 22:12:03 GMT

Here we go 🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀 Imagine what software development was like before a safe and convenient mechanism for polymorphism was available, it was manually handled via pointers in C and other old languages.

Dependency Inversion

In the typical calling tree, main functions called high-level functions, which called mid-level functions, which called low-level functions. In that calling tree, however, source code dependencies inexorably followed the flow of control.

Sounds interesting?

But let’s take a look at how the process flows

Let’s say that the main function calls out high-level function, the middle-level function acts as an interface for F(), however, that the source code dependency (the inheritance relationship) between ML1 and the interface, I point in the opposite direction compared to the flow of control.

The fact that OO languages provide safe and convenient polymorphism means that any source code dependency, no matter where it is, can be inverted.

With this approach:nerd_face:, architects who working in systems written in OO languages have absolute control over the direction of all source code dependencies flow in the system. They are not constrained to align those dependencies with the flow of control they can add more dependencies as a sort of plugin thanks to polymorphism:heart:.

Also this principle makes your program functionality clear and agile.

No matter which module does the calling and which module is called, the software architect can point the source code dependency in either direction.

That is power! That is the power that OO provides. That’s what OO is really.

All about at least from the architect’s point of view. What can you do with that power? As an example, you can rearrange the source code dependencies of your system so that the database and the user interface (UI) depend on the business rules, rather than the other way around.

This means that the UI is the main function, the database and business logic can be plugins to the system’s rules. It means that the source code of the business rules never mentions the UI or the database. And this will help in software fast delivery. For further check out the book of architecture called clean architecture by Robert-C,-Martin.

(This is an article posted to my blog at https://ibrahim-blog.iabushammah.now.sh/. You can read it online by clicking here.)

the SRP principle

Mon, 04 Mar 2019 00:00:00 GMT

Of all the SOLID principles, the Single Responsibility Principle (SRP) would be the least well understood. That’s likely because it has a particularly inappropriate name. It is too easy for programmers to hear the name and then assume that it means that every module should do just one thing. I discussed all the SOLID principles here, you can check it out!
The-solid-principles-in-designing-software
After finding the suitable definition from the Design Patterns: Elements of Reusable Object-Oriented Software aka (The gang of four) which is:

A module should have one, and only one reason to change.

Let’s have an example

Suppose we are working on an imaging app that creates huge Geo images that would be 2GB of size or even more, we now stitch multiple satellite images to get one huge image then we need to save the image in the available hardware, the implementation would be: The first thought would be to store image we convert the image to the demanded format then we store it in the local machine. That would be like this:

class StoreGeoImage { function converttoTiff(){ //convert the image to tiff format } function FileStore(){ //Store the image in the local machine } }

Although this might work out this implementation violates the SRP, this class has more than one reason to change

What if we need to save the image in SVS format?

What if we don’t want to store the image on local machine but instead we want to stream the image to the cloud?

After looking at those assumptions we end up with an implementation like this:

class ConvertGeoImage { function converttoTiff(){ //convert the image to tiff format } function converttoSvs(){ //convert the image to svs format } } class Store(){ function localStore(){ //Store the image on the local machine } function cloudStore(){ //Store the image on the cloud } }

Conclusion: design improves with domain enlightenment

When we understand the domain, at an architectural level:

Conclusions

we’re able to identify the actors of change (convert & store)

we’re able to split out code into subdomains(two independent classes instead of one)

we’re able to implement package by module (module is just a file of code)

(This is an article posted to my blog at https://ibrahim-blog.iabushammah.now.sh/. You can read it online by clicking here.)

Making setInterval Declarative with React Hooks

Mon, 04 Feb 2019 00:00:00 GMT

If you played with React Hooks for more than a few hours, you probably ran into an intriguing problem: using setInterval just doesn’t work as you’d expect.

In the words of Ryan Florence:

I’ve had a lot of people point to setInterval with hooks as some sort of egg on React’s face

Honestly, I think these people have a point. It is confusing at first.

But I’ve also come to see it not as a flaw of Hooks but as a mismatch between the React programming model and setInterval. Hooks, being closer to the React programming model than classes, make that mismatch more prominent.

There is a way to get them working together very well but it’s a bit unintuitive.

In this post, we’ll look at how to make intervals and Hooks play well together, why this solution makes sense, and which new capabilities it can give you.

Disclaimer: this post focuses on a pathological case. Even if an API simplifies a hundred use cases, the discussion will always focus on the one that got harder.

If you’re new to Hooks and don’t understand what the fuss is about, check out this introduction and the documentation instead. This post assumes that you worked with Hooks for more than an hour.

Just Show Me the Code

Without further ado, here’s a counter that increments every second:

import React, { useState, useEffect, useRef } from 'react'; function Counter() { let [count, setCount] = useState(0); useInterval(() => { // Your custom logic here setCount(count + 1); }, 1000); return <h1>{count}</h1>; }

(Here’s a CodeSandbox demo.)

This useInterval isn’t a built-in React Hook; it’s a custom Hook that I wrote:

import React, { useState, useEffect, useRef } from 'react'; function useInterval(callback, delay) { const savedCallback = useRef(); // Remember the latest callback. useEffect(() => { savedCallback.current = callback; }, [callback]); // Set up the interval. useEffect(() => { function tick() { savedCallback.current(); } if (delay !== null) { let id = setInterval(tick, delay); return () => clearInterval(id); } }, [delay]); }

(Here’s a CodeSandbox demo in case you missed it earlier.)

My useInterval Hook sets up an interval and clears it after unmounting. It’s a combo of setInterval and clearInterval tied to the component lifecycle.

Feel free to copy paste it in your project or put it on npm.

If you don’t care how this works, you can stop reading now! The rest of the blog post is for folks who are ready to take a deep dive into React Hooks.

Wait What?! 🤔

I know what you’re thinking:

Dan, this code doesn’t make any sense. What happened to “Just JavaScript”? Admit that React has jumped the shark with Hooks!

I thought this too but I changed my mind, and I’m going to change yours. Before explaining why this code makes sense, I want to show off what it can do.

Why useInterval() Is a Better API

To remind you, my useInterval Hook accepts a function and a delay:

useInterval(() => { // ... }, 1000);

This looks a lot like setInterval:

setInterval(() => { // ... }, 1000);

So why not just use setInterval directly?

This may not be obvious at first, but the difference between the setInterval you know and my useInterval Hook is that its arguments are “dynamic”.

I’ll illustrate this point with a concrete example.

Let’s say we want the interval delay to be adjustable:

While you wouldn’t necessarily control the delay with an input, adjusting it dynamically can be useful — for example, to poll for some AJAX updates less often while the user has switched to a different tab.

So how would you do this with setInterval in a class? I ended up with this:

class Counter extends React.Component { state = { count: 0, delay: 1000, }; componentDidMount() { this.interval = setInterval(this.tick, this.state.delay); } componentDidUpdate(prevProps, prevState) { if (prevState.delay !== this.state.delay) { clearInterval(this.interval); this.interval = setInterval(this.tick, this.state.delay); } } componentWillUnmount() { clearInterval(this.interval); } tick = () => { this.setState({ count: this.state.count + 1 }); } handleDelayChange = (e) => { this.setState({ delay: Number(e.target.value) }); } render() { return ( <> <h1>{this.state.count}</h1> <input value={this.state.delay} onChange={this.handleDelayChange} /> </> ); } }

(Here’s a CodeSandbox demo.)

This is not too bad!

What’s the Hook version looking like?

🥁🥁🥁

function Counter() { let [count, setCount] = useState(0); let [delay, setDelay] = useState(1000); useInterval(() => { // Your custom logic here setCount(count + 1); }, delay); function handleDelayChange(e) { setDelay(Number(e.target.value)); } return ( <> <h1>{count}</h1> <input value={delay} onChange={handleDelayChange} /> </> ); }

(Here’s a CodeSandbox demo.)

Yeah, that’s all it takes.

Unlike the class version, there is no complexity gap for “upgrading” the useInterval Hook example to have a dynamically adjusted delay:

// Constant delay useInterval(() => { setCount(count + 1); }, 1000); // Adjustable delay useInterval(() => { setCount(count + 1); }, delay);

When useInterval Hook sees a different delay, it sets up the interval again.

Instead of writing code to set and clear the interval, I can declare an interval with a particular delay — and our useInterval Hook makes it happen.

What if I want to temporarily pause my interval? I can do this with state too:

const [delay, setDelay] = useState(1000); const [isRunning, setIsRunning] = useState(true); useInterval(() => { setCount(count + 1); }, isRunning ? delay : null);

(Here is a demo!)

This is what gets me excited about Hooks and React all over again. We can wrap the existing imperative APIs and create declarative APIs expressing our intent more closely. Just like with rendering, we can describe the process at all points in time simultaneously instead of carefully issuing commands to manipulate it.

I hope by this you’re sold on useInterval() Hook being a nicer API — at least when we’re doing it from a component.

But why is using setInterval() and clearInterval() annoying with Hooks? Let’s go back to our counter example and try to implement it manually.

First Attempt

I’ll start with a simple example that just renders the initial state:

function Counter() { const [count, setCount] = useState(0); return <h1>{count}</h1>; }

Now I want an interval that increments it every second. It’s a side effect that needs cleanup so I’m going to useEffect() and return the cleanup function:

function Counter() { let [count, setCount] = useState(0); useEffect(() => { let id = setInterval(() => { setCount(count + 1); }, 1000); return () => clearInterval(id); }); return <h1>{count}</h1>; }

(See the CodeSandbox demo.)

Seems easy enough? This kind of works.

However, this code has a strange behavior.

React by default re-applies effects after every render. This is intentional and helps avoid a whole class of bugs that are present in React class components.

This is usually good because many subscription APIs can happily remove the old and add a new listener at any time. However, setInterval isn’t one of them. When we run clearInterval and setInterval, their timing shifts. If we re-render and re-apply effects too often, the interval never gets a chance to fire!

We can see the bug by re-rendering our component within a smaller interval:

setInterval(() => { // Re-renders and re-applies Counter's effects // which in turn causes it to clearInterval() // and setInterval() before that interval fires. ReactDOM.render(<Counter />, rootElement); }, 100);

(See a demo of this bug.)

Second Attempt

You might know that useEffect() lets us opt out of re-applying effects. You can specify a dependency array as a second argument, and React will only re-run the effect if something in that array changes:

useEffect(() => { document.title = `You clicked ${count} times`; }, [count]);

When we want to only run the effect on mount and cleanup on unmount, we can pass an empty [] array of dependencies.

However, this is a common source of mistakes if you’re not very familiar with JavaScript closures. We’re going to make this mistake right now! (We’ve also built a lint rule to surface these bugs early.)

In the first attempt, our problem was that re-running the effects caused our timer to get cleared too early. We can try to fix it by never re-running them:

function Counter() { let [count, setCount] = useState(0); useEffect(() => { let id = setInterval(() => { setCount(count + 1); }, 1000); return () => clearInterval(id); }, []); return <h1>{count}</h1>; }

However, now our counter updates to 1 and stays there. (See the bug in action.)

What happened?!

The problem is that useEffect captures the count from the first render. It is equal to 0. We never re-apply the effect so the closure in setInterval always references the count from the first render, and count + 1 is always 1. Oops!

I can hear your teeth grinding. Hooks are so annoying, right?

One way to fix it is to replace setCount(count + 1) with the “updater” form like setCount(c => c + 1). It can always read fresh state for that variable. But this doesn’t help you read the fresh props, for example.

Another fix is to useReducer(). This approach gives you more flexibility. Inside the reducer, you have the access both to current state and fresh props. The dispatch function itself never changes so you can pump data into it from any closure. One limitation of useReducer() is that you can’t yet emit side effects in it. (However, you could return new state — triggering some effect.)

But why is it getting so convoluted?

The Impedance Mismatch

This term is sometimes thrown around, and Phil Haack explains it like this:

One might say Databases are from Mars and Objects are from Venus. Databases do not map naturally to object models. It’s a lot like trying to push the north poles of two magnets together.

Our “impedance mismatch” is not between Databases and Objects. It is between the React programming model and the imperative setInterval API.

A React component may be mounted for a while and go through many different states, but its render result describes all of them at once.

// Describes every render return <h1>{count}</h1>

Hooks let us apply the same declarative approach to effects:

// Describes every interval state useInterval(() => { setCount(count + 1); }, isRunning ? delay : null);

We don’t set the interval, but specify whether it is set and with what delay. Our Hook makes it happen. A continuous process is described in discrete terms.

By contrast, setInterval does not describe a process in time — once you set the interval, you can’t change anything about it except clearing it.

That’s the mismatch between the React model and the setInterval API.

Props and state of React components can change. React will re-render them and “forget” everything about the previous render result. It becomes irrelevant.

The useEffect() Hook “forgets” the previous render too. It cleans up the last effect and sets up the next effect. The next effect closes over fresh props and state. This is why our first attempt worked for simple cases.

But setInterval() does not “forget”. It will forever reference the old props and state until you replace it — which you can’t do without resetting the time.

Or wait, can you?

Refs to the Rescue!

The problem boils down to this:

We do setInterval(callback1, delay) with callback1 from first render.

We have callback2 from next render that closes over fresh props and state.

But we can’t replace an already existing interval without resetting the time!

So what if we didn’t replace the interval at all, and instead introduced a mutable savedCallback variable pointing to the latest interval callback?

Now we can see the solution:

We setInterval(fn, delay) where fn calls savedCallback.

Set savedCallback to callback1 after the first render.

Set savedCallback to callback2 after the next render.

???

PROFIT

This mutable savedCallback needs to “persist” across the re-renders. So it can’t be a regular variable. We want something more like an instance field.

As we can learn from the Hooks FAQ, useRef() gives us exactly that:

const savedCallback = useRef(); // { current: null }

(You might be familiar with DOM refs in React. Hooks use the same concept for holding any mutable values. A ref is like a “box” into which you can put anything.)

useRef() returns a plain object with a mutable current property that’s shared between renders. We can save the latest interval callback into it:

function callback() { // Can read fresh props, state, etc. setCount(count + 1); } // After every render, save the latest callback into our ref. useEffect(() => { savedCallback.current = callback; });

And then we can read and call it from inside our interval:

useEffect(() => { function tick() { savedCallback.current(); } let id = setInterval(tick, 1000); return () => clearInterval(id); }, []);

Thanks to [], our effect never re-executes, and the interval doesn’t get reset. However, thanks to the savedCallback ref, we can always read the callback that we set after the last render, and call it from the interval tick.

Here’s a complete working solution:

function Counter() { const [count, setCount] = useState(0); const savedCallback = useRef(); function callback() { setCount(count + 1); } useEffect(() => { savedCallback.current = callback; }); useEffect(() => { function tick() { savedCallback.current(); } let id = setInterval(tick, 1000); return () => clearInterval(id); }, []); return <h1>{count}</h1>; }

(See the CodeSandbox demo.)

Extracting a Hook

Admittedly, the above code can be disorienting. It’s mind-bending to mix the opposite paradigms. There’s also a potential to make a mess with mutable refs.

I think Hooks provide lower-level primitives than classes — but their beauty is that they enable us to compose and create better declarative abstractions.

Ideally, I just want to write this:

function Counter() { const [count, setCount] = useState(0); useInterval(() => { setCount(count + 1); }, 1000); return <h1>{count}</h1>; }

I’ll copy and paste the body of my ref mechanism into a custom Hook:

function useInterval(callback) { const savedCallback = useRef(); useEffect(() => { savedCallback.current = callback; }); useEffect(() => { function tick() { savedCallback.current(); } let id = setInterval(tick, 1000); return () => clearInterval(id); }, []); }

Currently, the 1000 delay is hardcoded. I want to make it an argument:

function useInterval(callback, delay) {

I will use it when I set up the interval:

let id = setInterval(tick, delay);

Now that the delay can change between renders, I need to declare it in the dependencies of my interval effect:

useEffect(() => { function tick() { savedCallback.current(); } let id = setInterval(tick, delay); return () => clearInterval(id); }, [delay]);

Wait, didn’t we want to avoid resetting the interval effect, and specifically passed [] to avoid it? Not quite. We only wanted to avoid resetting it when the callback changes. But when the delay changes, we want to restart the timer!

Let’s check if our code works:

function Counter() { const [count, setCount] = useState(0); useInterval(() => { setCount(count + 1); }, 1000); return <h1>{count}</h1>; } function useInterval(callback, delay) { const savedCallback = useRef(); useEffect(() => { savedCallback.current = callback; }); useEffect(() => { function tick() { savedCallback.current(); } let id = setInterval(tick, delay); return () => clearInterval(id); }, [delay]); }

(Try it on CodeSandbox.)

It does! We can now useInterval() in any component and not think too much about its implementation details.

Bonus: Pausing the Interval

Say we want to be able to pause our interval by passing null as the delay:

const [delay, setDelay] = useState(1000); const [isRunning, setIsRunning] = useState(true); useInterval(() => { setCount(count + 1); }, isRunning ? delay : null);

How do we implement this? The answer is: by not setting up an interval.

useEffect(() => { function tick() { savedCallback.current(); } if (delay !== null) { let id = setInterval(tick, delay); return () => clearInterval(id); } }, [delay]);

(See the CodeSandbox demo.)

That’s it. This code handles all possible transitions: a change of a delay, pausing, or resuming an interval. The useEffect() API asks us to spend more upfront effort to describe the setup and cleanup — but adding new cases is easy.

Bonus: Fun Demo

This useInterval() Hook is really fun to play with. When the side effects are declarative, it’s much easier to orchestrate complex behaviors together.

For example, we can have a delay of one interval be controlled by another:

function Counter() { const [delay, setDelay] = useState(1000); const [count, setCount] = useState(0); // Increment the counter. useInterval(() => { setCount(count + 1); }, delay); // Make it faster every second! useInterval(() => { if (delay > 10) { setDelay(delay / 2); } }, 1000); function handleReset() { setDelay(1000); } return ( <> <h1>Counter: {count}</h1> <h4>Delay: {delay}</h4> <button onClick={handleReset}> Reset delay </button> </> ); }

(See the CodeSandbox demo!)

Closing Thoughts

Hooks take some getting used to — and especially at the boundary of imperative and declarative code. You can create powerful declarative abstractions with them like React Spring but they can definitely get on your nerves sometimes.

This is an early time for Hooks, and there are definitely still patterns we need to work out and compare. Don’t rush to adopt Hooks if you’re used to following well-known “best practices”. There’s still a lot to try and discover.

I hope this post helps you understand the common pitfalls related to using APIs like setInterval() with Hooks, the patterns that can help you overcome them, and the sweet fruit of creating more expressive declarative APIs on top of them.

(This is an article posted to my blog at https://ibrahim-blog.iabushammah.now.sh/. You can read it online by clicking here.)

Ibrahim https://ibrahim-blog.iabushammah.now.sh/ Blog RSS Feed

Dealing with bad code

asynchronous dispatch is now on npm packages!

Table of contents

Install

Usage

To Do

License

Write your own custom asyncDispatch middleware

when writing middleware Store, next state and action are your parameters

Dealing with files via MERN stack

This article meant to be written for everything you need to know about file upload MERN stack specifically.

Let’s get started

1.Creating Server and Client instances

2.Write the code

3.Running the code

4.Dealing with exporting files to the client side

Conclusion

Functional programming

In many ways, the concepts of functional programming (often abbreviated FP) predate programming itself. This paradigm is strongly based on the lambda-calculus invented by Alonzo Church in the 1930s.

Don’t let all the new buzzwords scare you away. It’s a lot easier than it sounds.

Sounds Nerdy? :nerd_face: we will explain every word said above :rose:

pure functions

Function composition

Shared State

Immutation## This article meant to be written for everything you need to know about file upload MERN stack specifically. :rocket:

Let’s get started :fire:

1.Creating Server and Client instances :building_construction:

2.Write the code :computer:

3.Running the code :fire: :bug:

Conclusion

The "SOLID" Principles in designing software

What is depedency inversion

Dependency Inversion

Sounds interesting?

But let’s take a look at how the process flows

The fact that OO languages provide safe and convenient polymorphism means that any source code dependency, no matter where it is, can be inverted.

Also this principle makes your program functionality clear and agile.

That is power! That is the power that OO provides. That’s what OO is really.

the SRP principle

A module should have one, and only one reason to change.

Let’s have an example

What if we need to save the image in SVS format?

What if we don’t want to store the image on local machine but instead we want to stream the image to the cloud?

Conclusion: design improves with domain enlightenment

Making setInterval Declarative with React Hooks

Just Show Me the Code

Wait What?! 🤔

Why useInterval() Is a Better API

First Attempt

Second Attempt

The Impedance Mismatch

Refs to the Rescue!

Extracting a Hook

Bonus: Pausing the Interval

Bonus: Fun Demo

Closing Thoughts

when writing middleware `Store,` `next` state and `action` are your parameters

Why `useInterval()` Is a Better API