Intro

I have been coding for a long time, and I have been using React for over five years. During this time, I have had several ideas on how React could be improved. About three years ago, I started working on implementing these ideas. First, I tested the concepts, and then decided to turn everything into a library. In this article, I would like to tell you about what came out of it.

What is good about React

Firstly, this is the approach of React in combining Javascript and HTML in one code. Other frameworks did not manage to do this as well. For example, some frameworks invented their own template programming languages, which duplicate the constructions of the JavaScript language, such as if, else, each...

In my opinion, this is an unnecessary cognitive load. Fortunately, some frameworks have since acquired support for JSX.

Another important but not so obvious feature of React is the one-way data flow and the corresponding mental model, which helps to structure the code while remaining flexible.

What is wrong with React

Component creation

In React, it is recommended to use functional components instead of class-based ones. This certainly makes the work easier.

Let’s consider the following example:

function CounterButton() {
  const [count, setCount] = useState(0);
  const handleClick = () => setCount(count + 1);
  return (
    <button onClick={handleClick}>
      You clicked {count} times
    </button>
  );
}

The CounterButton function is both a component constructor and a function that updates data. Such a mix of responsibilities is a bad practice, and it creates many problems, which we will talk about now.

Updating components

React calls the CounterButton function every time data is updated. All objects created inside this function will be recreated every time it is called.

In the example, the handleClick function is such an object. Resources could be saved if this function were created once in the constructor. But it does not exist in functional components.

Also, the CounterButton function returns a new virtual DOM object every time it is called.

New objects are created on the heap, and old objects are removed by the garbage collector. This process causes fragmentation and excessive memory usage. Periodic defragmentation is also required. All of these processes are resource-intensive.

It is worth noting that in our specific example, this aspect of React’s behavior does not matter. But for large applications with hundreds or thousands of components, it becomes noticeable.

That is why the React team, starting with version 17, began developing concurrent mode to allow updating the UI while React processes are running.

Hooks

One could argue that using hooks would partially solve the issue of creating unnecessary objects.

By the way, in one company where I worked, the policy was to always use hooks.

So here is an example:

const handleClick = useCallback(
  () => setCount(count + 1),
  [count]
);

On one hand, hooks allow you to forget about unnecessary updates of components located lower in the tree. But on the other hand, they do not solve the problem of creating “garbage” objects. For instance, the function () => setCount(count + 1) is created only to be discarded by the hook if count has not changed. Moreover, a new array object [count] is also created.

The same thing happens with other hooks as well. For example, compare constructor(){code();} and useEffect(() => {code();}, []). In the first case, the code will run only once in the constructor. In the second case, two extra objects will be created on each update.

Also, the hooks mechanism itself is additional logic that affects performance. But the biggest drawback of hooks, in my opinion, is their verbosity. It is incredibly boring to write wrappers for simple operations. And the readability of the code suffers as well.

In conclusion

• Many unnecessary objects are created and deleted on the heap, causing fragmentation, memory overconsumption, and defragmentation, which deteriorates performance.
• More logic is introduced for the concurrent mode, which also worsens performance.
• Additional logic of the use of hooks also worsens performance.
• Hooks make the code more verbose and harder to understand.

How to Improve

Next, I would like to propose solutions to the aforementioned problems.

So, in short, we need to:

• Improve performance.
• Reduce verbosity.
• Make the code more explicit and easy to understand.

Component Constructor

Let’s start with a hypothetical example:

function CounterButton() {
  let count = 0;
  const handleClick = () => {
    count++;
    btn.update();
  };
  const btn = button(
    { click$e: handleClick }, // props
    () => `You clicked ${count} times`, // child
  );
  return btn;
}

It looks very similar to a React example. For simplicity, let’s omit JSX for now.

The only unknown factor here is the button function, where all the "magic" happens. We can imagine how it might work based on our example.

The button function should perform the following actions:

• Create a DOM object HTMLButtonElement.
• Set a click event handler handleClick for the button.
• Set the text of the button using the value returned by the lambda function () => `You clicked ${count} times`.
• Allow updating the text of the button using the result of the lambda function.

It makes sense that the button function should create and return an object with two properties: element and update.

The class for this object could look like this:

class Component {
  get element() {}; // return DOM Element object
  update() {}; // update dynamic data
}

When the button is clicked, the counter is increased by one count++. Then the btn.update() method is called, which executes the lambda function and updates the button text.

Using the component

Now let’s attach this component to the DOM tree:

document.body.append(
  CounterButton().element,
);

First, we call the CounterButton function, which creates and returns the component, and then attach its element to the DOM tree.

Now, the button with a counter should be displayed and correctly count the number of clicks.

Okay, let’s suppose that:

• In addition to button, there is a full set of HTML functions: h1, div, span, and so on...
• Components created by these functions can contain child components, and so on to infinity.
• When the parent component is updated, its child components will be updated as well.

That’s it! 🤗

This approach solves all the aforementioned problems and preserves the good features of React.

Result

I bet you expected something bigger.

Do not worry that component updates are made explicitly. Mostly, updates are triggered by higher-order components. However, it is also possible to update any part selectively.

By the way, in React, explicit updates also need to be called. The setState function and useState hook serve this purpose. However, it is less flexible and more resource-intensive. For example, calling setCount(count + 1) will set the variable through the state mechanism, and then add the need for an update to the queue through the update mechanism. As you can see, there is again a mixing of responsibilities.

Thus, the aforementioned concept helps to solve problems in the following way:

• Firstly, the component creation function serves as its constructor and is called only once. Accordingly, objects created inside the function are also created only once and do not require such hacks as hooks.
• There are no hooks. There is no additional logic. Everything happens explicitly and readably.
• Concurrent mode is not necessary, as firstly, the amount of logic has significantly decreased, and secondly, we have complete control over the processes of creation and update, and can easily insert interface rendering where needed.

Fusor

What it is

Fusor is a simple library that helps declaratively create and update DOM elements.

In Fusor, there are no additional mechanisms for:

• Props
• State
• Context
• Lifecycle

Fusor is a minimalistic and transparent approach that uses the constructs of the Javascript language and DOM functions “almost without a library”.

Nevertheless, Fusor can fully replace React! How is that possible? Let’s take a closer look.

Economy

Fusor is an economical library.

Fusor does not create a heap of unnecessary objects on the heap.

For example, let’s consider the following code:

import { div, p } from '@fusorjs/dom/html';
const wrapper = div(
  p('I am the static text')
);

The variable wrapper will contain an HTMLDivElement object, not a Component as in the example with the counter button, since there are no dynamic parts here.

If we take the example with the button and modify it slightly:

import { button } from '@fusorjs/dom/html';
function CounterButton() {
  let count = 0;
  const handleClick = () => {
    count++;
    btn.update();
  };
  const btn = button(
    // props:
    { click$e: handleClick }, 

    // child text nodes:
    'You clicked ', // static
    () => count, // dynamic 
    ' times', // static
  );
  return btn;
}

So you can see that now only one of the three child elements of the button is dynamic. And the btn variable will be an object of the Component class.

When updating, only the value of one text node, to which the lambda function () => count is bound, will be changed if the value is different from what is already there.

Thus, an additional component object is only created if it contains dynamic data.

Dynamic data can also be in properties. For example, {class: () => selected ? 'selected' : 'unselected'}.

Lifecycle

Component lifecycle is the only mechanism that Fusor lacks to be able to replace React.

Since Fusor does one thing and does it well, it does not have a component lifecycle logic. However, such logic exists in native custom elements.

Fusor fully supports all web standards, including web components. Therefore, they can be used to connect lifecycle events.

Nevertheless, for convenience, Fusor has a custom element called fusor-life and its wrapper component Life:

import { Life } from '@fusorjs/dom/life';
const wrapper = Life(
  {
    connected$e: () => {},
    disconnected$e: () => {},
    // ... other props
  },
  // ... children
);

Compare this to the React component lifecycle mechanism and the O(n) traversal of the component tree.

Customization

It is not necessary to use functions located in html, svg, or life. They exist to avoid having to create them manually and to demonstrate how it is done.

For example, if you need to create a specific set of HTML tags, you can easily do so.

If you need to use a single function for all elements, you can use the h function for HTML or the s function for SVG. For example: h('div', props, children). Or you can make other variations.

There is also a more flexible function create(element, props, children). Using this function, you can configure the use of JSX with Fusor.

About JSX

JSX support will also be available.

Functional notation is also good because:

• It is pure JavaScript with regular comments.
• No conversion, build, or compilation is required.
• You can use any number of props and children in any order.

Links

Full-fledged applications and other resources:

• A counter button — an interactive example of an application.
• A tutorial with recipes (code) — an interactive application with the main usage scenarios of Fusor: lifecycle, request, routing, etc.
• Implementation of TodoMVC (code) — an application through which Fusor was developed. Therefore, it turned out not to be the easiest and most beautiful, but ideologically correct. Also, no lifecycle events are needed in this application.
• Fusor repository and documentation.

Conclusion

There are applications. Examples of basic usage scenarios are available. Test coverage is also available.

The API has been stable for quite some time. Fusor can be used in production.

npm install @fusorjs/dom

PS: Thank you to everyone who made it to the end! 🤗 ❤️

How I wanted to improve React was originally published in Webtips on Medium, where people are continuing the conversation by highlighting and responding to this story.

Most of us, Front-End/React Developers, are not aware of Environment Variable usages in our Client-Side projects. You say “I don’t even know what the heck are they?”, so let’s begin this to be more of a developer :)

In this article you may read:

- What is an Environment Variable

- How it can solve a big problem in scaled front-end projects

- Custom Environment Variables in create-react-app and their most important usage there

What is an Environment Variable?

Environment Variable, as it’s clearly obvious, is a variable that can have a value, but its value is stored outside our project, in the environment the project is running. This environment can be an OS, Server or any Micro Service.

Usages

• Configuration of the application (HTTP Port and address which the project is being served through)
• location of static files
• Endpoints of other external services
• storage connection information (Database name, …)

The most common problem in scaled Front-End projects

As we’re working on a scaled project in a scaled company, it is kind of weird to have every single API call containing the server Endpoint!
If you don’t follow any architecture in your project, Environment Variables may help you here.

Now imagine there are two different servers to connect. A Staging Server for development and test purposes, and a Production Server which is the server that real users are connected to it. Oops… It’s hard to handle? Don’t worry!

Environment Variables in create-react-app

Most React Developers are using create-react-app for their projects these days. Create-react-app itself has some default environment variables for some configuration of the React project.
The most known environment variable in create-react-app is NODE_ENV.

NODE_ENV has three different values in order to separate Production, Development and Test environments.

• on npm start, the value of NODE_ENV is “development”
• on npm test, this value is “test”
• and finally on npm run build, this value is “production”

Remember that the value of an Environment Variable is always string.

NODE_ENV is not overridable manually. This is to prevent any changes of the Production and Development environments by mistake.

So as we read above, we can enable/disable some parts of our project based on the environment we’re running it.

But this is not completely what we need. Consider we need to run npm start in production environment. Or we need to publish the staging build of our project. Here we can try some custom Environment Variables within create-react-app.

Custom Environment Variables in create-react-app

We can have some custom environment variables to config our application the way we want (defining different Staging and Production Endpoints and …).

We need a .env file to write our Environment Variables in it. We put it next to the package.json in project’s root folder.

├── README.md
├── node_modules
├── package.json
├── .env
├── .gitignore
├── public
│   ├── favicon.ico
│   ├── index.html
│   └── manifest.json
└── src
    ├── App.css
    ├── App.js
    ├── App.test.js
    ├── index.css
    ├── index.js
    ├── logo.svg
    └── serviceWorker.js

Now inside this .env file, we can write custom Environment Variables.

Please note that custom Environment Variables Must have REACT_APP_ as their prefix. Any other environment variables without this prefix, may be ignored in create-react-app.

REACT_APP_API_ENDPOINT = https://api.test.com

Also note that values (which are strings) don’t require quotation marks, unless there’s a space in the string.

How to use these Environment Variables inside React

Variables inside this .env file, are accessible via process.env Object in JS, which is a global object provided by the environment you are working on, through NodeJs.

Remember that, as long as there’s no NodeJs in the browser, here comes the WebPack or other Js Bundlers to handle this.

Now let’s see how we can access an Environment Variable in our React project. Consider that we use axios for sending HTTP requests:

let serverURL = process.env.REACT_APP_API_ENDPOINT;
axios.get(serverURL)
  .then(function (response) {
    // handle success
  })
  .catch(function (error) {
    // handle error
  });

And after building the project, the bundler will replace the first line with the following line:

let serverURL = "https://api.test.com";

So we’re halfway through separating staging and production endpoints in the project. Cause now the API Call is not dependent on a specific URL.

Separating Staging and Production Endpoints without separating the code base

Now that we’ve learnt how to use Environment Variables in React, let’s see how we can have different endpoints/configs in different environments like staging and production.

To do this, we need another .env file for new configs. So let’s have proper names for our .env files:

• .env.production for production configs
• .env.staging for staging configs

#This is .env.production file

REACT_APP_ENVIRONMENT = production
REACT_APP_REST_ENDPOINT = https://api-production.test.com
REACT_APP_SOCKET_ENDPOINT = https://socket-production.test.com

Comments are followed by a # in .env files.

#This is .env.staging file

REACT_APP_ENVIRONMENT = staging
REACT_APP_REST_ENDPOINT = https://api-staging.test.com
REACT_APP_SOCKET_ENDPOINT = https://socket-staging.test.com

As we see, variable names are the same in both files. And only the values of the same variable is different. So this may help our React app be free of if statements while sending the HTTP Request.

Now we have to tell our node server, to read one of these two files while it wants to start the project.

Run npm start based on the Environment

For this purpose, we need a npm package called env-cmd which tells our react scripts to start the project with the staging or the production config.

After installing env-cmd, we need to change the react scripts in the package.json file:

"scripts": {
  "start:staging": "env-cmd .env.staging react-scripts start",
  "start:production": "env-cmd .env.production react-scripts start",
  "build:staging": "env-cmd .env.staging react-scripts build",
  "build:production": "env-cmd .env.production react-scripts build",
  "test": "react-scripts test",
  "eject": "react-scripts eject"
}

And for starting the project, we should run npm run start:staging and npm run start:production instead of the old command npm start .

Dos and Don’ts

• It’s better not to store .env files in source controls cause it may cause your configs/endpoints being leaked in open source projects.
  But to avoid misunderstandings, you may publish a .env.sample file including variable names with a description of what it is used for:

#This is .env.sample file

REACT_APP_ENVIRONMENT = "staging or production"
REACT_APP_REST_ENDPOINT = "Your Rest Endpoint will come here"
REACT_APP_SOCKET_ENDPOINT = "Your Socket Endpoint will come here"

#You should have 2 different files, .env.production and .env.staging
#with the same variables and different values

• Always remember to check the Environment Variable and its value, cause if the React application can’t find the true Environment Variable, it won’t affect the application’s starting process and you may face a run-time error.
• Also changing any Environment Variable needs the node server to being restarted in order to consider the new value.
• Please note that while create-react-app is bundling your application, there are no Environment Variables in the build folder.
  This is because all of them are replaced with their values. So it is NOT safe to store secret values in Environment Variables with Front-End Web Development. (Although this is common for Back-End developers to store API Keys there).
  If you want to do so, you may have SSR with your React Application, so that Environment Variables are being replaced real-time while application is running. More info here.
• As it’s referenced, it’s a good idea to ignore some part of your application that is not needed in a specific environment. For example you can ignore Analytics Methods in the staging Environment:

if (process.env.REACT_APP_ENVIRONMENT !== 'production') {
  analytics.disable();
}

This may lead to smaller bundle size after building your application.

So as we saw earlier, using Environment Variables could be useful in order to prevent endpoints being exposed, run the entire application in different Environments (e.g Staging and Production) without the pain of switching between different branches and also build the project based on an environment.

Hope you start using them asap. Let me know of any questions or further information in the comments.

Happy Enving :D

Environment Variables in Client-Side was originally published in Webtips on Medium, where people are continuing the conversation by highlighting and responding to this story.

To start, Next.js creates static HTML files for each of your routes automatically. This implies that each page’s content can be simply read and indexed by a search engine when it crawls your website. This can significantly increase how visible your website is in search results.

Next.js also makes it easy to add metadata to your pages, such as the page title and description. This metadata is used by search engines to understand the content of your pages and to display them in the search results. You can set this metadata either globally for your entire site or on a per-page basis.

Another SEO benefit of Next.js is its support for client-side rendering. When a user clicks on a link to one of your pages, the browser can pre-fetch the data for that page in the background. This can make the page load faster, which is important for SEO because Google takes page load speed into account when ranking sites.

Finally, Next.js makes it easy to implement server-side rendering, which can further improve the performance of your site. With server-side rendering, the HTML for a page is generated on the server and sent to the client, rather than being generated on the client using JavaScript. This can make your pages load faster, especially on low-powered devices or for users with slow internet connections.

How to get the optimal SEO performance

First and foremost, make sure you’re generating static HTML files for each of your routes. This will allow search engines to easily crawl and index the content on your site, improving its visibility in search results. To enable this feature in Next.js, you’ll need to add the target: 'serverless' option to your next.config.js file.

Next, you’ll want to set up metadata for your pages. This includes the page title and description, as well as any relevant keywords. You can set this metadata either globally for your entire site or on a per-page basis. To do this in Next.js, you can use the Head component from the next/head module. Here's an example of how you might use it:

import Head from 'next/head';

function MyPage() {
  return (
    <>
      <Head>
        <title>My Page Title</title>
        <meta name="description" content="A description of my page." />
        <meta name="keywords" content="keyword1, keyword2, keyword3" />
      </Head>
      {/* page content goes here */}
    </>
  );
}

You can also improve the performance of your site by using client-side rendering. This allows the browser to pre-fetch data for a page in the background when a user clicks on a link, making the page load faster. To enable this feature in Next.js, you’ll need to set the optimizeDynamicImport option to true in your next.config.js file.

Finally, consider implementing server-side rendering for even faster performance. With server-side rendering, the HTML for a page is generated on the server and sent to the client, rather than being generated on the client using JavaScript. To enable this feature in Next.js, you’ll need to set the target: 'server' option in your next.config.js file.

By following these steps, you can set up your Next.js project for optimal SEO performance. This will help your site rank higher in search results and provide a better experience for your users.

Optimal SEO Performance for NextJS was originally published in Webtips on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. What are decorators in typescript?
2. What are circuit breakers in software systems?

Let's first read a bit about decorators

Decorators are a way to decorate functions, members of a class, or a class itself, with extra functionality.

When you apply a decorator to a function, a class, or a class member, you are actually calling a function that is going to receive details of what is being decorated, and the decorator implementation will then be able to transform the code dynamically, adding extra functionality, and reducing boilerplate code.

They are a way to have metaprogramming in TypeScript, which is a programming technique that enables the programmer to create code that uses other code from the application itself as data.

class Greeter {
  @format("Hello, %s")
  greeting: string;
  constructor(message: string) {
    this.greeting = message;
  }
  greet() {
    let formatString = getFormat(this, "greeting");
    return formatString.replace("%s", this.greeting);
  }
}

Read more about Typescript Decorators.

Let’s now see what are circuit breakers

A circuit breaker is an electrical safety device designed to protect an electrical circuit from damage caused by an overcurrent or short circuit. Its basic function is to interrupt current flow to protect equipment and to prevent the risk of fire. Unlike a fuse, which operates once and then must be replaced, a circuit breaker can be reset (either manually or automatically) to resume normal operation.

It’s common for software systems to make remote calls to software running in different processes, probably on different machines across a network. One of the big differences between in-memory calls and remote calls is that remote calls can fail, or hang without a response until some timeout limit is reached. What’s worse if you have many callers on an unresponsive supplier, then you can run out of critical resources leading to cascading failures across multiple systems.

The basic idea behind the circuit breaker is very simple. You wrap a protected function call in a circuit breaker object, which monitors for failures. Once the failures reach a certain threshold, the circuit breaker trips, and all further calls to the circuit breaker return with an error, without the protected call being made at all. Usually, you’ll also want some kind of monitor alert if the circuit breaker trips.

This above example is taken from CircuitBreaker.

Enabling Circuit Breaker (or other) Decorators Support in TypeScript

To enable decorators' support when using the TypeScript Compiler CLI (tsc) the only extra step needed is to pass an additional flag --experimentalDecorators:

tsc --experimentalDecorators

tsconfig.json

When working on a project that has a tsconfig.json file, to enable experimental decorators you must add the experimentalDecorators property to the compilerOptions object:

{
  "compilerOptions": {
    "experimentalDecorators": true
  }
}

Since we are focusing on creating circuit breaker decorators particularly, we will not go into detail about creating all approaches or creating different decorators, hence we will create only Method Decator for this blog and skip other decorators, but you can read more about other decorators from the official documentation of decorators

Dependency

Since we are using CircuitBrekaer from opossum.

npm i opossum

CircuitBreakable — Custom Decorator using CircuitBreaker

Example how we created Custom Decorator using CircuitBreaker from opposum.

And How we used it as a Method Decorator in class with the method.

Further enhancement of custom CircuitBreakable

We were able to customize CircuitBreakable further on

1. Passing the default result as what method will return as a response — different methods might need different timeouts, let’s say.
2. Passing custom configs from the different methods — different methods might need different timeouts, let's say.

Let's see the updated code for CircuitBreakable and its example below

Often they (circuit breakers) will protect against a range of errors that protected calls could raise, such as network connection failures. Not all errors should trip the circuit, some should reflect normal failures and be dealt with as part of regular logic.

Also, to be notified about my new articles and stories:

Subscribe to my YouTube Channel for educational content on similar topics

Follow me on Medium, Github, and Twitter for connecting quickly

You can find me on LinkedIn as it's a professional network for people like me and you.

I am quite active on Dev Community as well and write small topics over there.

Cheers !!!!!

Circuit Breaker Pattern in Typescript/Javascript Microservices: A Guide with code example was originally published in Webtips on Medium, where people are continuing the conversation by highlighting and responding to this story.