import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      debugShowCheckedModeBanner: false,
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  final String title;

  const MyHomePage({
    Key? key,
    required this.title,
  }) : super(key: key);

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  int _counter = 0;

  void _incrementCounter() {   
    setState(() {
      _counter++;
    }); 
    var snackBar = SnackBar(
      content: Text('Yay! A Counter SnackBar! $_counter'),
    );
     ScaffoldMessenger.of(context).showSnackBar(snackBar);
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            const Text(
              'You have pushed the button this many times:',
            ),
            Text(
              '$_counter',
              style: Theme.of(context).textTheme.headlineMedium,
            ),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: 'Increment',
        child: const Icon(Icons.add),
      ),
    );
  }
}

If you look at the code, the code looks fine and seems to work fine as well. Now I want you to copy the code to dartpad and run it. After that click the floating action button a single time, and then press the button 5 time continuously. Did you find anything odd?

If you click the button 5 times continuously, you would see something like this.

We can see that the snack bar keeps on showing even after a long time that we clicked. The snack bar persists even if we change the screen. If we clicked continuously, showSnackbar is sent to the event loop and they are executed no matter what. It is working as intended but it leads to a bad user experience. We want to make it so that only the last snack bar is shown leading to a better user experience.

Here, I am giving the example of a snack bar but what if I was calling API, it would be called multiple times. We want to make it so that if an action is performed one after another in a short interval of time, in this case tapping a button and showing the snack bar, the previous action is canceled and only the latest action is executed. So how to do so?

Debouncing

Debouncing is a technique used to avoid unnecessary processing by setting a delay before executing a function, so that if the function is called again within the delay, the previous function is canceled and the timer is reset again. The function is only executed once the delay timer has been completed without any new events occurring.

Here are some of the important of Debouncing:

• It avoids unnecessary processing.

• It optimizes performance by reducing function invocations.

• It helps to enhance user experience.

• It helps to optimize network requests and traffic.

• It prevents race-around conditions.

So, let's implement debouncing in our Flutter app and see the result.

import 'package:flutter/material.dart';
import 'dart:async';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      debugShowCheckedModeBanner: false,
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  final String title;

  const MyHomePage({
    Key? key,
    required this.title,
  }) : super(key: key);

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  int _counter = 0;

  final _debouncer = Debouncer(milliseconds: 500);
  void _incrementCounter() {

    setState(() {
      _counter++;
    }); 
       var snackBar = SnackBar(
      content: Text('Yay! A Counter SnackBar! $_counter'),
    );
    _debouncer.run(() {
      ScaffoldMessenger.of(context).showSnackBar(snackBar);
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            const Text(
              'You have pushed the button this many times:',
            ),
            Text(
              '$_counter',
              style: Theme.of(context).textTheme.headlineMedium,
            ),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: 'Increment',
        child: const Icon(Icons.add),
      ),
    );
  }
}

class Debouncer {
  final int milliseconds;
  Timer? _timer;
  Debouncer({required this.milliseconds});
  void run(VoidCallback action) {
    if (_timer != null) {
      _timer!.cancel();
    }
    _timer = Timer(Duration(milliseconds: milliseconds), action);
  }
}

It’s much better. We can only see the last snack bar. It is much better and user-friendly.

Now, how did we implement debouncing in our code? Let’s dive in.

class Debouncer {
  final int milliseconds;
  Timer? _timer;
  Debouncer({required this.milliseconds});
  void run(VoidCallback action) {
    if (_timer != null) {
      _timer!.cancel();
    }
    _timer = Timer(Duration(milliseconds: milliseconds), action);
  }
}

Here we are defining a Debouncer class. The Debouncer class has two properties: milliseconds and _timer. The _timer property is an Timer object used to manage the delay.

_timer = Timer(Duration(milliseconds: milliseconds), action);

The timer takes two parameters. The first param is the duration and the second params void callback or the function that is executed once the countdown/duration is completed. We can cancel the execution of the function at any time with _timer!.cancel().

Now let's look at run function.

In this function, at first, we are checking if the _timer is null or not. At first, it is null as we haven’t initialized it. As the _timer is null,_timer!.cancel() doesn’t run for the first time. After that the timer function is initialized and the action function that we provided is set to run after the time we provide. Now let’s see what happens when we call the run function again. This time _timer isn’t null as it has been initialized before, so _timer!.cancel() gets executed canceling the previous function that was set to run. If our next call exceeds the delay we provided, the function gets called. After that the _timer value is set again, to run the function again after the delay we provided. This process is continued again and again resulting in debouncing.

_debouncer.run(() {
      ScaffoldMessenger.of(context).showSnackBar(snackBar);
    });

In our code, we are passing the function to show the snack bar so that even if the user starts button mashing, the function gets executed a single time within the specified duration or time frame.

If you are still struggling to find a place to use debouncing. Use it in search.

Curiosity ignites, satisfaction revives. Keep exploring, keep thriving. As the saying goes,“ Curiosity killed the cat, but satisfaction brought it back.”

As a flutter developer how we should utilize those lifecycle methods is the primary intent of this article so let’s move to the fun part.

createState()

When we create a stateful widget in Flutter, the createState method is immediately called to return a state instance of the associated class.

This is essential because, in Flutter, everything is immutable (including stateful widgets). It is important to separate the mutability task and delegate it to the state class. This way, Flutter can make immutable classes look and work like mutable ones, and we can see all the changes in the UI.

This also has a performance benefit, as it is easier for Flutter to change a state variable and reflect the change in an optimized manner than to recreate the entire widget tree due to small changes.

class HomePage extends StatefulWidget {
  @override
  _HomePageState createState() => new _HomePageState();
}

initState()

This is the first method called after-state creation. And it is called **only once.
**This method can be used to:

1. Initilaize late variables

2. Subscribe to stream etc

@override
initState() {
  super.initState();
  _controller=TextEditingController();
  myStream.listen((data) {});
}

didChangeDependencies

This method is called immediately after the initState() for the first time and later on when its dependency changes.

So what exactly is its dependency?
Let's say we use MediaQuery.of in a widget then we can say our widget depends on MediaQuery. So whenever MediaQuery updates this method gets triggered.

So we can say if our widget depends on Inherited Widget (media query, theme, providers, etc) and whenever those inherited widget push updates it will trigger this method.

After this build() method will be triggered so as a developer there are not many scenarios where we may have to use custom logic here but as per official documentation, it says

to do some expensive work (e.g., network fetches) when their dependencies change and that work would be too expensive to do for every build.

For eg: From your Inherited Widget you may receive some value and need to do some expensive operation based on that value and show it in UI. You may not want to do this in the build method sodidChangeDependencies will be the perfect spot for this.

didUpdateWidget

Let's take an example to understand this. You have a Container which is of Red color and with a button tap you change it to Blue.

Here both the old and new object instances are of the same type runtimeType but the data is different so in this case this method gets triggered. It receives old widgets too didUpdateWidget(Widget oldWidget) .

@override
void didUpdateWidget(Widget oldWidget) {
  if (oldWidget.color != widget.color) {
  /// Your logic
  }
}

How can we utilize it?

• One possible scenario could be used in animation to transition between values.

• Another could be a specific use case based on your app requirement, based on new widget value do some different tasks for eg: subscribe to a new stream and un-subscribe to an earlier stream.

Since build() method will be called after this method so it's redundant to call setState((){}) in this method.

build()

This is the important method where, as a programmer, we need to return the widget that we want to show to the user.

Also, this method can get triggered multiple times so it’s not a good practice to perform expensive tasks inside this method.

This method can potentially be called in every frame and should not have any side effects beyond building a widget.

setState((){})

setState((){}) is a method that takes a method as a parameter and internally calls markNeedsBuild() method to trigger a new build.

/// Implementation of setState() in flutter 
@protected
void setState(VoidCallback fn) {
  final Object? result = fn() as dynamic;
  _element!.markNeedsBuild();
}

Here we can see the internal implementation of setState. It first runs the method that we passed and triggers markNeedsBuild() . We can derive another thing from this implementation code that

• we should not pass an async function to setState as internally it won’t wait for the future to resolve so we won’t see the desired UI reflection.

So as a developer, we can use this method to notify Flutter that something has changed and please update the UI.

setState(() {
  /// New State values
  color=Colors.red;
});

dispose()

dispose() method is called when the state object is removed. This is the last method to get triggered in the lifecycle.

So as a developer, we can:

1. Unsubscribe to streams

2. Dispose of the controllers

3. Stop animations etc

So these are the most common and must-know lifecycle methods in Flutter.

Since stateless widget doesn’t have its own mutable state (obvious from name) some lifecycle methods eg initState , dispose etc are missing here.

Sources:
https://www.youtube.com/watch?v=_gIbneld-bw
https://api.flutter.dev/index.html

What are keys?

Flutter describes Keys as an identifier for Widget, Element, and SemanticNodes. But what does that mean? This simply means that keys are unique labels assigned to widgets so that they can be distinguished from other widgets. For cases when widgets change positions in the widget tree, keys essentially help preserve their states. This also means that keys mostly come in handy for stateful widgets rather than stateless ones.

When to use them?

Keys can go almost everywhere in our code and they do not cause any harm. But placing keys when it isn't required only means that it is unnecessarily hogging up memory spaces. Therefore, one must be clear on when to use them as well.

Most cases do not require the need to work with keys. They are useful while adding, removing, or reordering a collection of widgets of the same type that hold some state and are at the same level in the widget tree. In the absence of keys, updating such a collection of widgets may not give the expected kind of results. We tend to use keys with children of widgets like ListViews or Stateful widgets whose data is constantly changing.

To further clarify, why we need keys when modifying a collection of widgets here is a simple example illustration. The example described below shows two color tiles that swap places at the click of a button.

The example is represented in two ways.

Firstly, the color tiles widgets are stateless with the color property stored in the widget itself. When the FloatingActionButton is tapped the tiles properly swap their position as expected.

import 'package:flutter/material.dart';
import 'package:keys_example/value_key_example.dart';
import 'package:random_color/random_color.dart';

void main() {
  runApp(const MyApp());
}
class MyApp extends StatelessWidget {
  const MyApp({super.key});
  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home:const PositionTiles(),
    );
  }
}
class PositionTiles extends StatefulWidget {
  const PositionTiles({Key? key}) : super(key: key);
  @override
  State<PositionTiles> createState() => _PositionTilesState();
}
class _PositionTilesState extends State<PositionTiles> {
  List<Widget> tiles = [];
  @override
  void initState() {
    super.initState();
    tiles = [ 
       StatelessColorTiles(),
        StatelessColorTiles(),
    ];
  }
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(child: Row(mainAxisAlignment:MainAxisAlignment.center,children: tiles,),),
      floatingActionButton: FloatingActionButton(child: Icon(Icons.sentiment_very_satisfied, ),onPressed: swapTiles,),
    );
  }
  void swapTiles() {
    setState(() {
      tiles.insert(1, tiles.removeAt(0));
    });
  }
}
class StatelessColorTiles extends StatelessWidget {

 Color myColor = RandomColor().randomColor();
  @override
  Widget build(BuildContext context) {
    return  Container(
      height: 100,
      width: 100,
      color: myColor,
    );
  }
}

Secondly, we make the color tile widgets stateful and store the color property in the state. This time, when pressing the floating action button nothing seems to happen. For the tiles to swap places correctly we need to add a key parameter to the stateful widgets.

import 'package:flutter/material.dart';
import 'package:keys_example/value_key_example.dart';
import 'package:random_color/random_color.dart';

void main() {
  runApp(const MyApp());
}
class MyApp extends StatelessWidget {
  const MyApp({super.key});
  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home:const PositionTiles(),
    );
  }
}
class PositionTiles extends StatefulWidget {
  const PositionTiles({Key? key}) : super(key: key);
  @override
  State<PositionTiles> createState() => _PositionTilesState();
}
class _PositionTilesState extends State<PositionTiles> {
  List<Widget> tiles = [];
  @override
  void initState() {
    super.initState();
    tiles = [ 
        StatefulColorTiles(key: UniqueKey(),),
        StatefulColorTiles(key: UniqueKey(),),

    ];
  }
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(child: Row(mainAxisAlignment:MainAxisAlignment.center,children: tiles,),),
      floatingActionButton: FloatingActionButton(child: Icon(Icons.sentiment_very_satisfied, ),onPressed: swapTiles,),
    );
  }
  void swapTiles() {
    setState(() {
      tiles.insert(1, tiles.removeAt(0));
    });
  }
}
class StatefulColorTiles extends StatefulWidget {
  const StatefulColorTiles({Key? key}) : super(key: key);
  @override
  State<StatefulColorTiles> createState() => _StatefulColorTilesState();
}
class _StatefulColorTilesState extends State<StatefulColorTiles> {
  late Color myColor;
  @override
  void initState() {
    super.initState();
    RandomColor _randomColor = RandomColor();
    myColor = _randomColor.randomColor();
  }
  @override
  Widget build(BuildContext context) {
    return Container(
        height: 100,
        width: 100,
        color: myColor,
     );
  }
}

The example thus, shows that keys are required for modifying widgets only if they are stateful. Stateless widgets don't require them.

Behind the scenes:

We just looked at an example where using keys allowed us to achieve the expected behavior from our code. But why did keys make this possible? Let's find out.

When rendering widgets, flutter not only builds a widget tree but side by side its corresponding element tree as well. The element tree holds information about the widgets present in the widget tree and references to its children’s widgets. In the process of modifying and re-rendering, flutter looks up the element tree to see whether or not the element tree has changed, so that if in case the element hasn't been changed it can reuse the old one itself.

For the stateless example, each of the tile widgets has its corresponding tile element. Because the color property was saved in the widget itself, when swapping the tiles in the widget tree, the references in the element tree weren't affected as they were the tile element itself. This thereby accurately swapped the color tiles.

For the stateful example, each tile widget had its corresponding tile element along with an extra state property in the element tree. When swapping the tiles, the corresponding elements do not match because they hold the state property and the desired behavior isn't achieved. After adding the key parameter to the tiles, the element tree and the widget tree get updated with the key values. Now when we swap the tiles, the tile elements with the help of their key can find out their corresponding widgets in the widget tree and update their reference correctly resulting in the widgets correctly swapping places and updating their color when the button is pressed.

Hence, this is how keys work under the hood and are useful for modifying stateful widgets in a collection.

Types of Keys:

Keys are broadly classified into two types:

1. Local Keys

2. Global Keys

Local Keys :

These must be unique amongst the elements with the same parent. Local keys can further be classified as follows:

Value Key:

Value key takes alphanumeric values. They are commonly used in a list of children where the value of each child is unique and constant.

Object Key:

Same as the value key with the only difference being that it takes in a class object that holds data.

Unique Key:

A unique key is used to identify a widget’s child in cases where they do not have unique values or don't have values at all.

Page Storage Key:

This key is used to preserve the scroll location of a user in scrolling views so that it can be saved for later.

That is all for this article. Stay tuned to learn about global keys in my next blog.

Till then, Happy reading!!

First, let’s look at what is XML file.

XML stands for eXtensible Markup Language, and it is a markup language used to store and transport data. An XML file is a text file that contains structured data in the form of tags and attributes. It is designed to be both human-readable and machine-readable, making it a popular choice for data exchange and storage. It doesn’t contain any code.

Remember XML File Does Not DO Anything

If an XML file doesn’t do anything, why are we even discussing it?

Yes, XML alone doesn’t do anything in itself but it contains essential information about our app to the Android build tools, Android OS, and Google Play. It acts as the container of information for our build tools to use. It acts like a notebook which is used by the system to build and give information about our app.

As the information is used to build our app, it is crucial to be able to read, write and manipulate this information to step up our app development journey.

AndroidManifest.xml is a required file in the android application at the root of the project source set. Every app project must have an AndroidManifest.xml file at the root of the project source set.

The manifest file can be used to do a ton of things. Some of the basic and most important things the manifest file does are:

1. Describes the components of the application

Every app component that we create must be declared in the manifest file otherwise our app won’t recognize that app component and we will be unable to use those app components. App components include Activity, Service, BroadcastReceiver, and ContentProvider. Each app component has a specific tag assigned to it. <activity>, <service>,<receiver> and <provider> tags are assigned for Activity, Service, BroadcastReceiver, and ContentProvider respectively.

2. Declares the Permissions

The app requires permission from the system for some of its features. For example, if the app requires internet access to work properly, it must be declared in the manifest file. Android system has a unique label for each feature for the app to ask permission for.

3. Device Compatibility

In the app manifest, the feature required by the app to function properly is declared and thus only the system having those features available may install the app, thus describing if the app is compatible with the android system or not.

Structure of the manifest

<?xml version="1.0" encoding="utf-8"?>
<manifest >
    <uses-sdk/>
    <uses-permission />
    <application>
       <activity>
          <intent-filter>
            <action />
            <category />
            <data />
          </intent-filter>
          <meta-data />
        </activity>
        <service>
            <intent-filter> . . . </intent-filter>
            <meta-data/>
        </service>
        <receiver>
            <intent-filter> . . . </intent-filter>
            <meta-data />
        </receiver>
        <provider>
            <grant-uri-permission />
            <meta-data />
            <path-permission />
        </provider>
    </application>
</manifest>

Sample

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.myapp">
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.VIBRATE" />
    <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
    <application
        android:name=".App"
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name">
        <activity
            android:name=".MainActivity"
            android:exported="true"
            android:label="@string/app_name"
            android:theme="@style/Theme.MyVpnApp">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
          <service android:name=".service.MyFirebaseMessagingService"
            android:exported="false">
            <intent-filter>
                <action android:name="com.google.firebase.MESSAGING_EVENT" />
            </intent-filter>
        </service>
        <receiver android:name=".ConnectionReceiver" >
             <intent-filter>
                 <action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
               </intent-filter>
        </receiver>
    </application>
</manifest>

Let’s look at some of the tags and attributes of the manifest file:

1 . <manifest>

It is the root element of the manifest file. It must contain <application> tag element and specify xmlns:android and package attributes.

Attributes

• xmlns:android : This attribute should always be set to “http://schemas.android.com/apk/res/android". When using prefixes in XML, a namespace for the prefix must be defined. Instead of calling android:id , the xml will use ‘http://schemas.android.com/apk/res/android:id ’( it’s a URI Uniform Resource Identifier ) to be unique.

• package : It is the unique name for the app. It has to be formatted as a full Java-language-style package name.

• android:installLocation : It is used to define the default install location for the app. It can have three values, “internal only”, “auto” and “preferExternal”.

1. <application>

It is used to define the properties and components of an Android application. It declares the application. The components of the app are declared in it.

Attributes

• android:label : It is a user-readable label/name for the app as a whole.

• android:icon : It defines the icon for the app as a whole.

• android:name : It points to the subclass of the Application class that we created. The subclass is optional, most applications won’t need one. When an application starts, this class is instantiated before any other application component.

1. <uses-permission>

It specifies the system permission that the user must grant for the app to function correctly.

Attributes

• android:name : It is the name of the permission being requested. For example “android.permission.INTERNET” to use the internet.

1. <activity>

It is used to define the activity that we have created. Activity can’t be recognized by the system if it is not defined under this tag. It can contain <intent-filter> ,<meta-data> and <layout>

Attributes

• android:name : It points to the subclass of the Activity class that we created.

• android:exported : It contains a boolean value. If “true”, the activity is accessible to any app and is launchable by its exact class name. If “false”, it can only be launched by components of the same application.

• android:theme : It is a reference to the style resources for the activity to use.

• android:configChanges : It contains a list of configuration changes that the activity will handle. It prevents the activity from restarting when the defined config change takes place as the activity is restarted by default on configuration changes.

• android:launchMode : It instructs how the activity should be launched. It has 5 modes. They are:“standard","singleTop", "singleTask", "singleInstance", and "singleInstancePerTask".

1. <service>

It is used to declare a Service subclass. All services must be declared by this tag. It can contain \<intent-filter> and \<meta-data>. Service run on background independent of any user interface.

Attributes

• android:name : It points to the subclass of the Service class that we created.

1. <receiver>

It declares the BroadcastReceiver subclass. Broadcast receivers enable applications to receive intents that are broadcast by the system or by other applications, even when other components of the application are not running.

• android:name : It points to the subclass of BroadcastReceiver class that we created.

1. <provider>

It contains a reference to the subclass of ContentProvider subclass. ContentProvider is necessary if we require to share data between multiple apps.

Attributes

• android:authorities : It is the list of the URI that can be used to share data across the application. Multiple authorities are listed by separating their names with a semicolon.

• android:name : It points to the subclass of ContentProvider class that we created.

• android:permission : It is the permission that the app must have to use it.

1. <intent-filter>

It informs the system about the intent that the app components can respond to. It opens the component receiving intent. It must contain \<action>and may contain [\<category>](https://developer.android.com/guide/topics/manifest/category-element)and[\<data>](https://developer.android.com/guide/topics/manifest/data-element)and\).

An Intent is a message or a request for the app component to perform some action. An app can have multiple intent filters.

1. <action>

It is the action that the app components can perform and is contained inside \<intent-filter> . For example,<action android:name=”android.intent.action.SEND” /> to send data to another application.

Attribute

• android:name : It is the name of the action to be performed.

1. <category>

It provides additional information on which the app components can perform an action. For example, the <category android:name=”android.intent.category.LAUNCHER” /> indicates that an activity should be listed in the launcher as an entry point for the application while first opening the app.

Attribute

• android:name : It is the name of the category.

There are many other amazing tags and attributes for your need. I only explore the surface. For more detail and to find the tag that you need head over to the android official site .

Thanks for reading

Here is the demo link.

Challenge

Creating a bar is easy unless there are no segments. But since we are creating a segmented bar, we need to take care of segments beforehand.

For this, we need a variable to store the number of segments. Let's say

const BAR_COUNT = 7;

We are assuming there will be 7 segments of the bar but you can make more segments. The only constraint here is the color of each segment because for now, the 7 colors are hard-coded.

Initialization

So a full bar is 100%. But since we have segments we also have to know how much percent will a segment hold. To determine this we can divide 100% by the total number of segments.

const quartilePercentage = 100 / BAR_COUNT;

Since we have 7 segments, the percentage each bar will hold is 14.28%

100 / 7 = 14.28

This percentage will be handy when filling the bar with color later.

And since we need an actual percentage to show on the bar, we will pass them as props.

<GradientPercentBar percent={40} />

We will use this percentage and assign it to a variable inside the component which will restrict the percentage to be maximum of 100.

const truePercent = percent > 100 ? 100 : percent < 0 ? 0 : percent;

We will also want to know where the percentage will fall and based on that we will assign a color. To figure out whether the label will be low, medium or high, we will divide the truePercent with the quartilePercentage we initialize earlier.

If truePercent = 40, the barIndicator will be 40/14.28 = 2.80 ~ 3.

Thus the potentialLabel is medium. So the bar will fall on 3rd segment

const barIndicator = Math.round(truePercent / quartilePercentage);

const potentialLabel = barIndicator < 3 ? 'low' : barIndicator <= 5 ? 'medium' : 'high';

Indicator

We will create a simple indicator that will render the true percentage and the class will depend on the potentialLabel. We will get back to this function in a while.

  const renderTooltip = useCallback(
    (potential: string) => {
      return (
        <div className={`indicator ${potential}`}>
          <span>{truePercent}</span>
        </div>
      );
    },
    [truePercent]
  );

Magic Function

This function will be responsible for creating the bar hence the magic function.

Some variables initialization that we will be needing later.

let elementArr = [];
let root = document.documentElement;
let percent;
let quartileValue;

We will now loop through BAR_COUNT with starting index of 1 and with each iteration, we will assign the range of each bar.

 const currentPoint = Math.round(quartilePercentage * i);

This will provide us with the value each bar will have. For example

In 1st iteration, i = 1 and (1 * 14.28) ~= 14

In 2nd iteration, i =2 and (2* 14.28) ~= 29

..

..

In 7th iteration, i = 7 and (7 * 14.28) ~= 100

In this example, we have our truePercent value of 40, so all the bars below 40 should be filled. This will be done by pushing the element elementArr array.

elementArr.push(<div className='item filled' key={i} />);

But all the points above will have further calculations to determine what elements to push in elementArr.

Now we calculate the percentage that will be used to fill the bar with gradient color. If you are not familiar with CSS, we can use background-image to generate a linear effect to show half filled and half-empty.

 const previousPoint = Math.round(quartilePercentage * (i - 1));

 const difference = currentPoint - previousPoint;

 percent = `${Math.round(((truePercent - previousPoint) / difference) * 100)}%`;

We know that the truePercent lies in 3rd segment. But it will not fill to 3rd segment. Some of them will be half empty. Thus the above calculation comes in handy.

The above percentage will be

((40- 29)/14) * 100 = 78.57 ~= 79

This means the color will be filled up to 79% of 3rd segment and the rest will be white.

Now we have all the values required to implement the bar, we just need to push it into elementArr.

 elementArr.push(
        <div className={`item ${i === quartileValue ? 'current filled'               : ''}`} key={i}>
            {i === quartileValue && renderTooltip(potentialLabel)}
          </div>
 );

After all the iterations, the elements will be pushed into elementArr.

Some code looks like this.

root.style.setProperty(`--block-${i}`, percent);
root.style.setProperty(`--left-value`, percent);

These are used to set CSS variables that will be used CSS.

The --block-${i} is used in linear gradient while the --left-value is used to indicate how far the indicator is from the block.

Final Structure

The return function for the bar component is simple. It will call rangeArray function which will be responsible for generating the bar.

    <div className='App'>
      <div className='potential__range'>
        <div className='range'>{rangeArray}</div>
      </div>
    </div>

There is further CSS required to color the bar but the major functionality for the bar is done.

Hope this tutorial will be useful for some of you.