DEV Community: Paul Edward

Laravel Optional Helper

Paul Edward — Mon, 02 Dec 2024 10:50:31 +0000

Laravel Optional Helper

_# The “optional” function can accept any argument which will allow you to access properties or call methods on that object. If the given object is null, properties and methods will return null instead of causing an error
_
I saw a post on twitter by Taylor Otwell on how he use Laravel Optional helper

i said to myself, alot might not be aware of the helper method called Optional, so i decided to give it some voice on my blog today

The optional method started with laravel 5.5 and i am going to show you how i have been using it just to clear up with my views

First and foremost install laravel application starting from 5.5 upward and generate authentication scaffolding with

php artisan make:auth

Now head over to your command line and let’s make an Profile model with a one to one relationship with the User Model. For example a user with one profile, so i generating this along with the migration

$ php artisan make:model Profile -m

go over to the Profile Migration in the database folder and add the following details

*public function *up()
{
    Schema::create('profiles', *function *(Blueprint $table) {
        $table->bigIncrements('id');
        $table->unsignedInteger('user_id')->index();
        $table->string('address');
        $table->timestamps();
    });
}

once done, you can migrate using the php artisan migrate

Just for the purpose of the tutorial, i will have to manually fill in the address details in the Profile table, relating it to my Id in the user table

less i forget, it actually skipped me, we need to add the one to one relationship in the user model (User.php)

*public function *profile(){
    return $this->hasOne(Profile::*class*);
}

so over in my home.blade.php, i want to go ahead and output my address on the dashboard

outputting the user address using the auth helper function in relation to the profile actually works using this

{{ auth()->user()->profile->address }}

What if the user doesn’t have an address. to demonstrate this i delete the record i created in the profile table

I did and i refreshed my dashboard, as you rightly guess, there is going to be an error because we are trying to get a property of a non object, because the profile relationship is returning NULL and actually that is what i got

in solving this previously, what would have been done is to use an IF statement and definately that will fix the problem

*@if(*auth()->user()->profile*)
    *{{ auth()->user()->profile->address }}
*@endif*

The only issue with this is wrapping this within an IF statement and just for the purpose of this tutorial and to lay the foundation and usefulness of optional helper, so we will be changing the above code

so, we take what we are trying to access then wrap it inside the optional helper and that works

{{ optional(auth()->user()->profile)->address }}

the optional helper will introduce a dynamic getter on whatever we passed into it and that means if the property we are trying to access doesn’t exist, it will silently return null

and that works as well, so let go ahead and add an address back into the Profile table to be sure everything is fine

and yes it works

So if you are wrapping loads of IF then the optional helper is really going to help you out and of course you can use this absolutely anywhere and not just limited to views,

in conclusion you can use it to tidy up your code. we also have the Optional() callback. i will be writing about it soon in case you need it.

Happy Coding

Good Looking IF Statement

Paul Edward — Mon, 02 Dec 2024 10:18:07 +0000

Good Looking IF Statement

IF statement are very big part of development, the essence of the write up is to avoid deep nested if statements, although there are no fixed rules for every situation.

There are couples of advise i am going to give you and when you apply this you will find out your code looks a lot cleaner , Just to start with, Let's look at a basic example

*<?php



class *user
{
    *public function Location*(){
        *if*($this->longitude && $this->latitude){
            return $this->longitude . ' '.$this->latitude;
        }

        *return null*;
    }

}

now we want to check if they have the Longitude, Latitude or either then concatenate the longitude, a space and the latitude, to avoid us repeating codes in our application…

Generally what i found when i develop is always return what you are expecting last, do the checks you need first and then dont nest the return of the value you expect to see

what do i mean?

*<?php



class *user
{
   *public function *Location(){
        *if*(!$this->longitude || !$this->latitude){
            *return null*;
        }
        //Other checks can come here
        *return *$this->longitude . ' '.$this->latitude;
    }
}

The way i look at this is perhaps, we are doing other checks, if we are to do it the first way and we have to return another checks that means we may have to duplicate codes, so i add the expected return value last and i can do as many checks as i want returning NULL, throwing Exceptions or whatever you need it to do. I hope you get the idea?

Now Let's look at a slightly more complex examples and this involve using Nesting IF and also using IF ELSE, see what i meant below

*<?php

if *() {
    *if*(){
        *if *(){

        }
    }
} *else *{

}

if you look at the above, this could be much pain to bear when you trying to debug or trying to go back to change things and tend to get really messy too quickly, i have been there in the pass and i guess you too.

Now let's look at an example

*<?php*

*if*(*ISSET*($_POST['file'])) {
    *if*(*in_array*($fileExtension, $allowExtention)) {
        *//Upload Files
    *} *else *{
     //Another Set Of Errors

    }
} *else *{
    *//display errrors
    return*;
}

now am going to tell you, you can do all of the thing you have done above without using else and without nesting.. now lets tidy this up

Firstly Think About Things That Are Negative

*<?php*

*if*(!*isset*($_POST['file'])){
    *return*;
    *//Error here
*}
*//At This Point You are breaking the flow of the application here and you might be redirecting the user here

if*(*in_array*($fileExtension, $allowExtention)){
    *return *;
    *//Checking for Faulty Value
*}

*//Upload The file, and write other codes*

If you think about it this way, you will end up with a much leaner and cleaner code. Easy to read, Easy to Maintain

Lastly, Improving code readability is an art, not a science. Sometimes it’s best to avoid negations in if statements, and sometimes it’s best to handle the most common case first and deal with errors later. But it’s always best to avoid nesting logic too deeply.

Taming the Beast of Intermittent Failures: A Laravel Circuit Breaker Tale

Paul Edward — Mon, 02 Dec 2024 10:13:09 +0000

Taming the Beast of Intermittent Failures: A Laravel Circuit Breaker Tale

Ring, ring! The alarm bells are going off again. The once reliable third-party service, our good old friend (Trading Service), has started acting out like a rebellious teenager. Sigh. Any seasoned developer would get a few more grey hairs from inconsistent answers and sporadic failures.

Well, let’s not give up, ladies and gentlemen. This is not my first time at the game, and I’m here to share a small Laravel magic trick that has more than once kept me sane. Let’s talk about implementing a Circuit Breaker when everyone is together.

A Circuit Breaker? you ask. Are we going to dabble in some electrical engineering? Laughs in code. Not quite! A circuit breaker is a design pattern that stops a system from continually attempting to carry out an operation that is likely to fail.

Now, let’s get our hands dirty with some code.

Here is some Laravel code that illustrates how to remain resilient in the face of resistance from others:

public function handle(CompleteKyc $event)
{
    try {
        $delay = $this->applyCircuitBreaker();
        if ($delay !== null) {
            $this->release($delay);
        }
        $result = $this->createZanibalAccount($event);

        Cache::forget('failures');
        Cache::forget('circuit:open');
    } catch (Exception $exception) {
        if($exception->getCode() >= 500){
          $this->handleException($exception);
          $this->release(600);
        }

    }
}

You’ll see that this Laravel job/listener has a fair dosage of self-preservation ingrained in them.

The major performance is provided by the handle method. Using our helpful neighbor $this->applyCircuitBreaker(), it determines whether a circuit is open (signifying a recent failure). If the circuit is indeed open, it hibernates like a well-fed bear, delaying any future demands until the situation is under control and the coast is clear.

protected function applyCircuitBreaker()
{
    $lastFailureTimestamp = Cache::get('circuit:open');
    if (is_int($lastFailureTimestamp) && time() - $lastFailureTimestamp < 8 * 60) {
        return $lastFailureTimestamp + 600 + rand(1, 120);
    } else {
        $this->halfOpen = true;
        return null;
    }
}

In the applyCircuitBreaker method, the magic happens. It obtains the date of the most recent failure and, if it is older than eight minutes, requires a delay before the following request. For a touch of unpredictability, a random additional delay (between 1 and 120 seconds) is introduced. Variety is the flavor of life, after all, and even code needs to be jazzed up occasionally!

protected function handleException(Exception $exception)
{
    if ($this->halfOpen) {
        Cache::put('circuit:open', time(), 600);
        return $this->release(600);
    }
    if (!$failures = Cache::get('failures')) {
        Cache::put('failures', 1, 60);
    } else {
        Cache::increment('failures');
    }

    if (Cache::get('failures') > 10) {
        Cache::put('circuit:open', time(), 600);
    }
}

Should an exception occur (and let’s face it, exceptions happen to the best of us), the handleException method swoops into action like a superhero in a cape. It increments a failure count in our cache, but after ten failures, it drops the big bomb and opens the circuit, preventing further heartache (or in this case, request-ache) for a cooling-off period.

Like any good drama, there’s a plot twist. If the circuit is in a ‘half-open’ state — meaning it’s testing the waters after a previous failure — and an exception occurs, it immediately halts the operation and reopens the circuit.

protected function createZanibalAccount(CompleteKyc $event){
    //Your third party API
}

In the end, this code does more than just carry out duties; it also tells a story about overcoming difficulty, rising above failure, and making sure that our system can withstand the unpredictability of using third-party services. It recognizes that sometimes you have to take a step back, gather your breath, and only then go back into the fight, much like a stubborn boxer in the ring.

So the next time your third-party service decides to throw a tantrum, don’t panic! Just pull out your reliable circuit breaker, and let it do the heavy lifting. Just remember, as I always say, “Keep calm, code on!”

That’s it for now. Until next time, may your code be bug-free and your coffee strong.

Happy coding, my fellow Laravel enthusiasts!

PHP and Multithreading: A Lighthearted Look at Concurrency

Paul Edward — Mon, 02 Dec 2024 10:12:19 +0000

PHP and Multithreading: A Lighthearted Look at Concurrency

Have you ever found yourself daydreaming about PHP and multithreading? Well, maybe not. But if you’re curious about how PHP handles concurrency, you’re in for a treat!

Multithreading is when you have parts in the same program or task doing things in parallel. PHP and multithreading go together like, well, oil and water. While PHP does have a PTHREAD extension (though it’s currently not maintained and it’s advised to use the parallel extension instead), it only supports multithreading at the command line level. But don’t worry my friend; we won’t dive into the depths of PTHREAD today.

You see, people often crave multithreading because they want to squeeze every ounce of power from their machine’s cores. But, PHP already does a fantastic job of keeping your cores busy by handling concurrent requests through web servers like PHP-FPM and there is no issue of not making use of all the cores in a machine like a standalone daemon or a CLI. So, you might say, PHP is already a multitasking powerhouse!

When it comes to PHP running on your frontend web server, you should treat long-running tasks like a hot potato. Toss them to a different set of servers using a message queue or job worker setup. That way, you can asynchronously manage jobs without clogging up your front-end server. Keep those frontend servers free for, well, serving the front end!

Think of it like a well-orchestrated ballet — your frontend server should dance gracefully with incoming requests and swiftly send responses back. But those long-running tasks? They belong in the background, like stagehands pulling the ropes.

Just as you wouldn’t run your database on your frontend web service (I’m looking at you, daredevils), you should have a dedicated database server. This way, you can optimize hardware for specific tasks, such as providing a database server with ample memory.

Consider this tale of an e-commerce platform: a seemingly unified web application, but in reality, a modular masterpiece. Each aspect — product listings, cart management, and order checking — was hosted on separate server clusters. This modular approach allowed for optimal performance and scalability.

Now, I know what you’re thinking. “If PHP had multithreading, we could run everything on the frontend server, right?” Hold your horses, partner! That kind of setup just wouldn’t scale. PHP’s stateless, sandboxed design makes it a horizontally scalable champion. Threading would only encourage running background tasks on front-end servers, leading to chaos and anarchy in the world of web applications.

In recent years, PHP has seen significant advancements with tools like React PHP and Swoole, which allow for asynchronous, non-blocking I/O operations in PHP. While these solutions provide new ways to handle concurrency in PHP, they are not a replacement for proper architecture when building web applications

With the arrival of PHP 8, we’ve got some new kids on the block: PHP Parallel and Fibers. PHP Parallel provides a new way to achieve concurrency using parallelism, while Fibers introduce cooperative multitasking, allowing you to write asynchronous code in a more straightforward, synchronous-looking way. Although these features are exciting and open up new possibilities, they should not encourage poor architectural choices or promote running heavy background tasks on front-end web servers.

While these tools can offer improved performance and concurrency, it’s essential not to lose sight of PHP’s core strengths and the importance of proper architecture in web applications. Remember to keep things modular and scalable, and your web application will sing like a well-orchestrated symphony.

In summary, multithreading in PHP isn’t the holy grail of performance. Instead, focus on building modular web applications that take advantage of PHP’s concurrency capabilities. With the right architecture, PHP can be the superhero of scalability that it was always meant to be.

So, the next time you find yourself pondering PHP and multithreading, remember this lighthearted tale and embrace the beauty of PHP’s concurrency capabilities. Happy coding!

The Solid Design Principle — Single Responsibility

Paul Edward — Mon, 02 Dec 2024 10:07:04 +0000

The Solid Design Principle — Single Responsibility

In this series, we’re going to discuss the five Solid Principle, this is actually applied to all Object-Oriented Programming, not just PHP

The five solid designs are listed below

S — Single Responsibility

O — Open/Close

L — Liskov Substitution

I — Interface Segregation

D — Dependency Inversion

So in this write up I will be writing about the S

S — Single Responsibility

This state that a class should have only one reason to change, in simpler terms, a class should only have one task or one responsibility so if there are any other methods in a class that deals with something completely different, that method should be extracted and put somewhere else and your class should have one task/job/responsibilities

Why The Need For Single Responsibility

if we keep our classes just with one responsibility, it does the following

Makes the class easier to maintain.
Potentially make class reusable ( depending on whatever your class is dealing with)
Easier to test

The point of the User Class above is to save a record to the database and if something goes wrong, an error message is been logged to the file and here are the methods Create, Edit and logError

Now the above class breaks the single responsibility principle because it has more than one responsibility or task, and the reason for this is because of the method logError. Create and Edit Method has perfect reasons to stay in the User Class, it actually performs actions upon the User but the logError does otherwise

So how do we fix this?

We can extract the logError method and keep it in its own class,

*<?php

class *Logger {
    *public function *writeToFile($message){
        *//Write To File
    *}
}

we can also have flexible and expandable enough for it to save to file or save to external resource so if we still need the LogError method then use dependency injection to inject it into the User Class

Thanks for reading, I hope this clears any questions on responsibility principle, if you have any question, simply drop a comment below

Laravel Query Builder Security

Paul Edward — Mon, 02 Dec 2024 10:05:21 +0000

Laravel Query Builder Security

“Never Trust A User Input” as it is widely said

Most people ain’t aware that PDO which is what most modern PHP application use to talk to databases, don’t have a built in mechanism for escaping column names like they do the values.

for instance when you write the code below

User::*where*('firstname', 'infinitypaul')->first();

the ‘infinitypaul’ value is properly escaped and you safely pass user input into that of course, but the column name “firstname” there is no built in mechanism to escape the column name in PDO,so you never let your user dictate the column of your query without you verifying/sanitizing it first otherwise it is possible to have a SQL injection vulnerability in your application

*public function *welcome(Request $request){
    User::*where*($request->firstname, 'infinitypaul')->orderBy($request->col)->first();
}

if a user enters something like this 1*+ORDER+BY+10 **or *->”%27))%23injectedSQL , or **someone with ill intentions can add any malicious code they want there. the input might not make sense to you but Laravel will convert the input to an SQL query which might return an output that might give an hint to something on your database..

i guess you now asking what if i need the user to dictate the column name, wait, am almost there, the best practice as at the time of writing is whitelist on the server of allowed column check just to make sure what the user is sending across matches your whitelisted set of column names, that way you know you can only pass those values

*public function *welcome(Request $request){
    $column_name = *array*('firstname', 'lastname', 'username');
    *if *(!*in_array*($request->firstname, $column_name, true)){
        *//you can add whatever result here if not found
       return*;
    }
    User::*where*($request->firstname, 'infinitypaul')->first();

}

the inarray keyword checks if what the user sent is in your whitelisted value in the array. and the true makes sure it is case sensitive

As short as the above will solve and prevent the database from being compromise, there are several ways in which you can prevent that, it depends on your use case.. easy as that right.. the most important factor is bringing this info to your knowledge

One of the thing i love about php/laravel is the up and running community .Laravel Stated it in red in their documentation just to make you are aint ignorant of the above info

On a final note, you should either not allow your user control the column name at all or if you need to allow that, then you need to use a whitelist, cause if you fall vulnerable of that. it could be very disastrous,

Check your apps if you know you allowed user to control the column name and correct where necessary

Laravel Optional Helper

Paul Edward — Mon, 02 Dec 2024 10:03:36 +0000

Laravel Optional Helper

The “optional” function can accept any argument which will allow you to access properties or call methods on that object. If the given object is null, properties and methods will return null instead of causing an error

I saw a post on twitter by Taylor Otwell on how he use Laravel Optional helper

i said to myself, alot might not be aware of the helper method called Optional, so i decided to give it some voice on my blog today

The optional method started with laravel 5.5 and i am going to show you how i have been using it just to clear up with my views

First and foremost install laravel application starting from 5.5 upward and generate authentication scaffolding with

php artisan make:auth

$ php artisan make:model Profile -m

go over to the Profile Migration in the database folder and add the following details

*public function *up()
{
    Schema::create('profiles', *function *(Blueprint $table) {
        $table->bigIncrements('id');
        $table->unsignedInteger('user_id')->index();
        $table->string('address');
        $table->timestamps();
    });
}

once done, you can migrate using the php artisan migrate

Just for the purpose of the tutorial, i will have to manually fill in the address details in the Profile table, relating it to my Id in the user table

less i forget, it actually skipped me, we need to add the one to one relationship in the user model (User.php)

*public function *profile(){
    return $this->hasOne(Profile::*class*);
}

so over in my home.blade.php, i want to go ahead and output my address on the dashboard

outputting the user address using the auth helper function in relation to the profile actually works using this

{{ auth()->user()->profile->address }}

What if the user doesn’t have an address. to demonstrate this i delete the record i created in the profile table

in solving this previously, what would have been done is to use an IF statement and definately that will fix the problem

*@if(*auth()->user()->profile*)
    *{{ auth()->user()->profile->address }}
*@endif*

so, we take what we are trying to access then wrap it inside the optional helper and that works

{{ optional(auth()->user()->profile)->address }}

the optional helper will introduce a dynamic getter on whatever we passed into it and that means if the property we are trying to access doesn’t exist, it will silently return null

and that works as well, so let go ahead and add an address back into the Profile table to be sure everything is fine

and yes it works

So if you are wrapping loads of IF then the optional helper is really going to help you out and of course you can use this absolutely anywhere and not just limited to views,

in conclusion you can use it to tidy up your code. we also have the Optional() callback. i will be writing about it soon in case you need it.

Happy Coding

inder — HTML Link Download Attribute

Paul Edward — Mon, 02 Dec 2024 10:02:26 +0000

Reminder — HTML Link Download Attribute

“download” is a thing on tags, download the file when clicking on a link instead of navigating to the file

You could even name the file to be downloaded by giving the download attribute a value.

The download attribute is actually new for HTML 5

There are no limit to the value you can allow, you can try it with the following extensions — .img .pdf .txt and so on

Although naming the file only works if it’s being downloaded from the same domain as the current page. Otherwise it uses the actual filename or a browser default if no name can be determined that is If the value is omitted, the original filename is used.

On a final note, I actually wish more browsers supports the download attributes , but you you can give it a short on the following browser version

Chrome: 14.0

Internet Explorer; 13.0

Mozilla: 20.0

Safari: 10.0

Opera: 15.0

This are the ones I know for now if there is an update or you have tried it on other version of indicate in the comment section

Enjoy!

Dependency Injection in PHP

Paul Edward — Mon, 02 Dec 2024 10:01:32 +0000

Dependency Injection in PHP

The main advantages of using dependency injection is that it encourages modular programming (The process of subdividing a computer program into separate sub-programs)

The first thing we need to talk about is what dependencies are. So in dependency injection, dependencies are objects that you need to use in your class and injection simply means passing those dependencies into your class, simply put, a dependency is just another object that your class needs to function

There are different ways of injecting dependencies into your classes but the most common way is through the constructor of your class.

*class *UserRepository
{
    *private *$db;
    *private *$config;
    *private *$user;

    *public function *__construct(Database $db, Config $config, User $user)
    {

        $this->db = $db;
        $this->config = $config;
        $this->user = $user;
    }
}

Above is my constructor method, which will bring the dependencies into UserRepository as class properties, so I can use them throughout the class. Rather than instantiating them within my class, I’ll inject them when UserRepository is itself instantiated.

In conjunction with interfaces — you can treat classes as “black boxes” where you can change the dependencies and know that nothing will break!

This seems great right? your code will start to feel more like Lego and less like spaghetti. There are many other benefits too.

Testing becomes easier,

Refactoring becomes easier and

Reusing code is easier.

Life for a coder who uses dependency injection is far easier.

For me, personally, dependency injection has improved my code quality and it is certainly worth implementing.

Enjoy!!

Is PHP Dead On Windows? Rate Of Impact?

Paul Edward — Mon, 02 Dec 2024 09:58:31 +0000

Is PHP Dead On Windows? Rate Of Impact?

We know that the current cadence is 2 years from release for bug fixes, and 1 year after that for security fixes. This means that PHP 7.2 will be going out of support in November. PHP 7.3 will be going into security fix mode only in November. PHP 7.4 will continue to have another year of bug fix and then one year of security fixes. We are committed to maintaining development and building of PHP on Windows for 7.2, 7.3 and 7.4 as long as they are officially supported. We are not, however, going to be supporting PHP for Windows in any capacity for version 8.0 and beyond.

Microsoft recently announced PHP wouldn’t be supported on Windows, so should I be concerned if I’m a PHP developer? Does this mean the end of PHP?

If you are an experienced PHP developer, I know you ain’t bothered or concerned of the recent announcement, because 99% of the time, if you are deploying your PHP application, you are going to be implementing it on a Linux environment and not on a Microsoft server. I’m pretty sure most PHP developers are not even aware of that fact that Microsoft support PHP, so I believe the announcement is a non-issue.

All I can deduce from the announcement is there are probably not too many people using PHP on Windows in the first place.

You have to understand Microsoft has a very open dispositional vis-a-vis programming language. In the old days, Microsoft was very centric towards Microsoft technologies and products, but these days they’ve opened up and realized that they can embrace different frameworks, languages and operating systems. So currently you can install a Linux operating system on windows pretty quickly, and that is because Microsoft is making that happen.

If you need to run PHP, you are likely going to be developing a PHP application in the environment of deployment, which in most cases is on a Linux server

On a windows environment, you can install Linux and then run your PHP application on that Linux environment all within your Windows operating system and voila, problem solved or probably just run PHP on a Docker environment

If you look at the latest PHP usage statistics depending on which one you are looking at, PHP is typically in the top 5 or 6 most popular widely-used programming language in the world. 30 to 35 per cent of websites run PHP in some form or another, so just because Microsoft won’t support PHP anymore doesn’t mean some other company won’t step up to do it, having in mind that PHP is open-sourced.

Lastly, if there is going be a severe need for PHP on windows, you can be sure someone is going to do it, and that could be you, but I don’t think there is, because you can run Linux on Windows pretty efficiently or probably in your docker containers. I don’t see why you should be very bothered about running PHP directly on windows

ReactJS — useEffect() & useCallback()

Paul Edward — Mon, 02 Dec 2024 09:36:37 +0000

ReactJS — useEffect() & useCallback()

In case you never heard about useCallback() and useEffect(), I strongly recommend that you check the official docs listed below

React in general: https://reactjs.org/docs/getting-started.html
useEffect(): https://reactjs.org/docs/hooks-reference.html#useeffect
useCallback(): https://reactjs.org/docs/hooks-reference.html#usecallback

In Summary:

useEffect()

useEffect() is a React Hook which allows you to handle side effects in your functional React components.

You can use it to do anything that doesn’t directly impact your UI/ JSX code (it might eventually affect it, for example, if you’re fetching data from some server, but for the current render cycle, it will not).

useEffect() allows you to register a function which executes AFTER the current render cycle.

useEffect() runs after every render cycle (i.e. whenever your functional component re-runs/ re-renders), unless you pass a second argument to an array of dependencies of the effect.

With such a dependency array provided, useEffect() will only re-run the function you passed as a first argument, whenever one of the dependencies changed.

useCallback()

useCallback() often is used in conjunction with useEffect() because it allows you to prevent the re-creation of a function. For this, it's important to understand that functions are just objects in JavaScript.

Therefore, if you have a function (A) inside of a function (B), the inner function (=A) will be recreated (i.e. a brand-new object is created) whenever the outer function (B) runs.

That means that in a functional component, any function you define inside of it is re-created whenever the component rebuilds

Example:

Typically, it’s not a problem, that innerFunction is re-created for every render cycle.

But it becomes a problem if innerFunction is a dependency of useEffect():

Why is the above code problematic?

The effect re-runs whenever innerFunction changes. As stated, it is re-created whenever MyComponent re-builds

Because functions are objects and objects are reference types, that means that the effect will re-run for every render cycle

That might still not be a huge problem, but it is, if innerFunction does something that causes MyComponent to re-build (i.e. if it either does something that changes the props or the state).

Now, you would have an infinite loop!

useCallback() helps you prevent this.

By wrapping it around a function declaration and defining the dependencies of the function, it ensures that the function is only re-created if its dependencies changed.

Hence the function is NOT re-built on every render cycle anymore => You break out of the infinite loop!