Forem: Michael Darko

Build Your Next SaaS with PHP — In Hours, Not Days

Michael Darko — Sun, 13 Apr 2025 00:57:26 +0000

We've been working on Leaf PHP, and building it into the perfect tool for makers and solo builders. If you’re looking to build fast and ship faster, Leaf might be the fastest way to launch your next SaaS — all with plain, elegant PHP that scales with you.

Here’s how 👇

🚀 Kickstart with a ready-to-go starter

Random and annoying tasks like setting up authentication end up taking away a ton of time which could go into building your application's actual features, so we built all of that so you don't have to. Create a new project using the CLI:

leaf create

You can choose to use the application starter together with your frontend tooling of choice

💸 One-time payments & subscriptions in minutes

Billing should not be a pain, that's why we built a billing module for you applications. It currently supports only Stripe, but will soon add PayStack and LemonSqueezy support. To get started with subscriptions, just use our scaffolding tool:

php leaf scaffold:subscriptions

Add your tiers and publish them to stripe using the config:billing command. That's it!

⏳ Quick Waitlist setup

Creating a waitlist/coming soon page is a great way to build anticipation for your product before it launches. It allows you to collect email addresses from interested users, which can be invaluable for marketing and user engagement once your product is live. You can scaffold a waitlist using:

php leaf scaffold:waitlist

🧪 Launch with a ready-made landing page

Another annoying starting point for most developers is the landing page. Leaf MVC's scaffolding tool allows you to scaffold a landing page with a single command:

php leaf scaffold:landing-page

You get:

A structured homepage layout
Sections like hero, features, and footers
Tailwind for styling + your preferred frontend setup

No design stress. Just tweak and go.

💡 Beginner-friendly. Lightning fast

On top of all this, the biggest thing about Leaf is how easy it is to get started.

Clean docs. Cleaner code.
If you’ve written PHP before, it’ll feel like home.
If you haven’t — it’s easy to learn in a weekend.

🌱 Why Leaf?

Because you don’t need 900 features to ship — you need speed, clarity, and the freedom to build.

That’s Leaf. No bloat. Just the essentials.

🛠️ Try it: https://leafphp.dev
📚 Docs: https://leafphp.dev/docs

Happy gardening! 👨‍🌾

Introducing Leaf PHP 3

Michael Darko — Thu, 23 Sep 2021 22:04:55 +0000

It's been a while since the release of Leaf v2 last year. v2 brought in a whole lot of improvement to the Leaf franchise and opened up doors for further development and the reform of Leaf API and Leaf MVC. Leaf 2 has without a doubt been very successful and we'll like to thank everyone who has checked Leaf out or built anything with it 🙏🏽

Why another major version?

Since Leaf 2 is doing really well, with v2.6 released a few days ago, why would we want to move on to a new major version? There are a bunch of reasons for this which I'll go over below.

Leaf's vision

This discussion above states some of Leaf 2's features and how easy it is to use them in your app. Leaf 2 provides a ton of features and unparalleled simplicity to match that, however...

Leaf 2 bloated without even realising it. Although Leaf 2 is still one of the most lightweight frameworks out there, it has a lot going on, and has features people don't use in everyday development so we decided to strip off those features and return Leaf to a clean simple state where other features will be served as installable plugins.

A fresh start

Considering all the goodies that would come out of this new version with the introduction of modules, source code of about 60kb, blazing speed, component rewrites and so much more, we decided to use this opportunity to refresh Leaf's identity and we did this thoroughly 🚀

Leaf comes in with a new logo which looks simpler (going back to our vision) and a dark theme showing usability. Leaf 3 takes usability and simplicity to a whole new level without sacrificing any of the powerful goodies you need 😇

What's new in Leaf 3?

We can sing about Leaf 3's features for a full day. I'll list some of them below.

Modules 🥞

This is the biggest change in Leaf since v2. Modules are basically wrapped up pieces of functionality which can be installed independently both in and outside Leaf apps. Modules are fast, small and easy to get started with. Modules also require zero configuration and can be used right after installation with zero setup.

Tiny Footprint 🦶🏾

Well, I doubt there's any other feature rich PHP framework with a source code size of 60kb with modules less than 5kb in size. This goes a long way to improve the performance of your applications.

Zero Configuration ⚙️

Another big deal leaf has been pushing is zero config. We believe that if you need to configure anything in your app, it should be external (like database connections and env). Leaf just works and Leaf 3 makes sure that no extra configuration is needed to make your app work, no matter what environment you're in or the modules/external libraries you pull in.
We believe that if it works on localhost, it must work in production (let's burn docker down😂)

Speed to production 🚀

Leaf 3 and it's modules come with a ton of regularly used features which have been simplified for use, this means that the time spent building these features is greatly reduced. How fast you go from development to production will depend on how fast you can type🤭

Overpowered Efficiency ⏰

Leaf 3 helps you write clean and more modular code, with the basic Leaf setup having only 6 lines of code. This can be reduced further to 5 lines in "functional mode". Read below for more information🥰

Super easy to learn 👨🏾‍🏫

Leaf 3 compared to leaf 2 is a lot easier to learn. This is because Leaf 3 has less at the core and anything else can be learned as a plugin. Because of this you can focus on learning what you need one thing at a time beginning with only what you need to develop your application.

Global Shortcut functions 🌍

Global functions is an idea taken from Leaf MVC and Leaf API. These functions create global initialisers for your app which makes sure that you don't go round repeating functions and long class namespaces.

Instead of Leaf\Http\Response::json($something), you can do json($something), response($something) or response()->json($something)

??? ☃️

Adding global functions paved way for new features like what we call "functional mode". Look at this example below:

With functional mode, you don't even need to initialise leaf yourself, just install leaf and build your app without any worries. To top it all, installing modules like session opens up the door to more functions like session(), flash(), auth()...

Why modules?

This is a question a couple of people have asked me. I thought I would just answer this in case others were wondering.

Decluttering leaf core 🗃

As mentioned above leaf blew up without realising. This lead to people having code and dependencies they would never use in their projects. The sad part is that some of this code would be executed without their knowledge eventually slowing down their app (leaf 2 is still blazing fast though🚀). For this reason, we decided to serve Leaf's base and provide modules that could be used to extend Leaf's power on demand.

The community asked for it 🚴🏽‍♂️

Other users have been asking for this as far back as January this year. Last month, we made a twitter poll and the results we obvious.

Most of the people who contributed in this poll agreed that modules are the way forward.

Easy to version 🔖

Modules are independent libraries and so have their own versions, bugs and fixes. This means that you can build your app with Leaf and not have to worry about future changes throughout the whole framework. If you need a patch just install the latest version of that particular module instead of the full framework.

Easy to learn 📚

Most modules (especially the newer ones) focus on providing a familiar and very friendly interface similar to other popular libraries and frameworks. For instance leaf cors is modelled after the express js cors middleware which is really popular. This means that if you've used express before jumping on this module would take less than a minute.

Modules can be used outside leaf 🌐

This is another ground shaking addition to the Leaf community. You can now take any piece of Leaf and use it in a totally unrelated framework or simply in a raw PHP project. Leaf modules are framework agnostic and will work anywhere there's PHP to run them.

The fun part is that all modules are plug-n-play, requiring zero configuration. You install, you use.

Release Info

Leaf 3 is now under active development under the v3.x-dev branch. A release data for v3 alpha has not yet been confirmed, but the progress on development is looking great with 21 modules already published on composer.

Updates during development will be posted on our twitter page

To keep up with our development, you can install leaf from the v3.x or v3.x-dev branches. Since all dev and pull requests are made to the v3.x-dev branch, this branch will receive more updates with early testing for features even after the alpha release.

To test v3 right now, you can set it up with composer

composer require leafs/leaf dev-v3.x-dev

This will quickly setup leaf 3 with the default modules. From there, create your index.php file and add this quickstart.

<?php

require __DIR__ . "/vendor/autoload.php";

app()->get("/", function () {
  response(["name" => "Mychi"]);
});

app()->run();

You can run this with the built in php server

php -S localhost:5500

What of Leaf v2?

Leaf v2 will continue to maintained and will receive updates and security patches. You can still continue to use Leaf 2 in your existing projects since it will still receive security patches with no breaking changes. However, after the official release, we recommend going in for version 3

React Tips & Patterns

Michael Darko — Wed, 24 Mar 2021 12:33:28 +0000

React is pretty easy to learn if you know JavaScript, however, it's pretty easy to lose track of your project or just mess things up as it scales or gets ready for a refactor or re-write. I'll share some tips which have literally saved my life...and a whole lot of time😇. Let's get into it!

Tip 1: (Using Containers)

It's very easy to bloat your components with a lot of code: API calls, form logic and a whole lot more logic. To add to all this, the UI code is shoved into these already bloated components. How do we solve this? Containerizing! Containers allow us to isolate our logic and UI code into different components which helps us avoid bloating that particular component just like MVC does. Let's look at an example:

This component fetches news items and displays a UI for the fetched new items

const Dashboard = () => {
  const [news, newsError] = useCustomFetch("/news");
  const [user, userError] = useCustomFetch("/user");
  const [trends, trendsError] = useCustomFetch("/trends");
  const [notifications] = useCustomFetch("/notifications");

  if (news) {
    // sort news for tags
    // sort news for "sort options"
    // perform some custom operations on news
    // do something else like caching?
  }

  if (trends) {
    // sort trends for tags
    // sort trends for "sort options"
    // perform some custom operations on trends
    // do something else like caching?
  }

  if (notifications) {
    // sort notifications for tags
    // sort notifications for "sort options"
    // perform some custom operations on notifications
    // do something else like caching?
  }

  return (
    <div>
      <h2>user</h2>
      loading handler
      map cards
      display available tags
      display sort options

      <h2>notifications</h2>
      loading handler
      map cards
      display available tags
      display sort options

      <h2>Latest News</h2>
      loading handler
      map cards
      display available tags
      display sort options

      <h2>Trends</h2>
      loading handler
      map cards
      display available tags
      display sort options
    </div>
  );
};

We're skipping a whole lot of logic and UI code here, but you can pretty much see how huge our component can get if left to grow on its own terms. Now let's look at this same example containerized.

Instead of having our entire code as just Dashboard, we can split it into DashboardContainer and Dashboard. It's NOT compulsory to name your containers with Container, however, it's a good naming convention as done with Controllers in MVC eg: UsersController.

DashboardContainer.jsx

const DashboardContainer = () => {
  const [news, newsError] = useCustomFetch("/news");
  const [user, userError] = useCustomFetch("/user");
  const [trends, trendsError] = useCustomFetch("/trends");
  const [notifications] = useCustomFetch("/notifications");

  if (news) {
    // sort news for tags
    // sort news for "sort options"
    // perform some custom operations on news
    // do something else like caching?
  }

  if (trends) {
    // sort trends for tags
    // sort trends for "sort options"
    // perform some custom operations on trends
    // do something else like caching?
  }

  if (notifications) {
    // sort notifications for tags
    // sort notifications for "sort options"
    // perform some custom operations on notifications
    // do something else like caching?
  }

  return (
    <Dashboard
      notifications={notifications}
      trends={trends}
      news={news}
      user={user}
      {/* all your other props */}
    />
  );
};

Now, your dashboard component will look like this:

const Dashboard = ({ user, notifications, ... }) => {
  return (
    <div>
      <h2>user</h2>
      loading handler
      map cards
      display available tags
      display sort options

      <h2>notifications</h2>
      loading handler
      map cards
      display available tags
      display sort options

      <h2>Latest News</h2>
      loading handler
      map cards
      display available tags
      display sort options

      <h2>Trends</h2>
      loading handler
      map cards
      display available tags
      display sort options
    </div>
  );
};

This way, you can have all your logic in one component and pass all data needed in the UI through props.

Tip 2: (Tidy man's props😂)

I gave this tip a such a ridiculous name because I actually discovered this while I was trying to beautify my code and cut down a bunch of lines. What does this whole thing involve? Let's take a look. In the above tip, we passed our props like this:

<Dashboard
  notifications={notifications}
  trends={trends}
  news={news}
  user={user}
/>

This is fine, but sometimes, you just need something a bit straightforward and easier to grasp. We can replace the above code with this:

const props = { notifications, trends, news, user };

<Dashboard {...props} />

Clean, simple and very readable😊

Tip 3: (Error Boundaries)

According to the react docs, Error boundaries are React components that catch JavaScript errors anywhere in their child component tree, log those errors, and display a fallback UI instead of the component tree that crashed. Error boundaries catch errors during rendering, in lifecycle methods, and in constructors of the whole tree below them.

Basically, a part of your app crashing won't drag the whole app down with it, and on top of that, you get to display a custom fallback UI and log/report the errors associated with your app crash. All you need to do is to create your error boundary and pass your components as props. I usually wrap my whole app with the error boundary.

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    // Update state so the next render will show the fallback UI.
    return { hasError: true };
  }

  componentDidCatch(error, errorInfo) {
    // You can also log the error to an error reporting service
    logErrorToMyService(error, errorInfo);
  }

  render() {
    if (this.state.hasError) {
      // You can render any custom fallback UI
      return <h1>Something went wrong.</h1>;
    }

    return this.props.children; 
  }
}

And wrap the component you want to "protect"

<ErrorBoundary>
  <App />
</ErrorBoundary>

That's all. You can check out the docs demo here.

Tip 4: (Picking your libraries)

Like it or not, libraries determine how you write and organize your code. You might have a way of doing something, but a library will ultimately determine what input it takes in and how it works.

One problem I've always had with react is how other libraries usually don't fit into your react app, require a lot of boilerplate code, or how they just have these weird operations😓 Redux meets all these criteria btw😓

There's some good news though, there's usually always an easier/smaller option if you look hard enough. For example, most projects don't need all of redux's features, just a global state, maybe reducers, a setter and a getter😅 You can try libraries like Zustand, Reactn and the multipurpose React Query.

If you want a simpler routing experience, you can also try out Glass Router which takes a friendlier approach to the whole routing business.

Just remember, the community always has simpler, smaller and usually faster alternatives.

Tip 5: (Relative imports)

This applies to CRA users

We usually have different directories for assets, views and all those in our app. This usually leads to uncomfortable imports with ../../... There are a bunch of solutions for this, however, the most used, which I also prefer is to reconfigure webpack to use relative paths: Instead of ../../assets, we can have @/assets

setup

We basically want to edit our CRA setup without having to eject first. There are some nice libraries for this, which we'll install in our project:

yarn add react-app-rewired customize-cra

From there, we create a config-overrides.js file and dump this code in:

const { override, addWebpackAlias } = require("customize-cra");
const path = require("path");

module.exports = override(
    addWebpackAlias({
        ["@"]: path.resolve(__dirname, "src"),
    })
);

From there, we head over to our package.json scripts section and replace react-scripts with react-app-rewired like so:

"scripts": {
  "start": "react-app-rewired start",
  "build": "react-app-rewired build",
  "test": "react-app-rewired test",
  "eject": "react-scripts eject"
}

That's it for the CRA + JS users!

If you're using TypeScript with CRA, you need to add the following so the compiler doesn't shout at you for using @ in your imports.

Create a new file like tsconfig.base.json in your project root (at the same level as your package.json) and add the following:

{
    "compilerOptions": {
        "paths": {
            "@/*": [
                "src/*"
            ]
        }
    },
}

We're not adding this in the main tsconfig.json because TypeScript will rewrite the tsconfig.json and throw this error:

The following changes are being made to your tsconfig.json file:
  - compilerOptions.paths must not be set (aliased imports are not supported)

Now to get this to work, you simply need to extend this in your main tsconfig.json file:

{
  "extends": "./tsconfig.base.json",

You may need to restart your editor for this to take effect (TypeScript users only). From there, you can start replacing all your uncomfortable imports😇

Thanks for reading

These are a few tips and tricks which have helped me speed up my workflow, keep my code neat and basically help on my quest for laziness😇

If you have anything you'll like to share, a new tip, a faster way to do something I mentioned, something you don't agree with, just reach out to me. Thanks!

PHP Tips and Tricks

Michael Darko — Tue, 16 Mar 2021 22:08:12 +0000

Working with PHP has been one of the most fun experiences for me, working on both major and minor projects and learning something new on every journey.

I'll be sharing some little tricks that have helped me cut down a couple of lines of code and others that totally flipped my workflow like this:

Hit me up if you have any ideas, questions, comments... Without further ado, let's get into it.

Tip 1: (if and else)

You may have seen this before on tutorials or some other articles, but this is something really important I should mention, a bit in-depth. It's not wrong to use else and else if blocks in your code, in fact, they were made for use, however, in some cases, these blocks become redundant. Let's look at an example:



function output_gender(bool $user_is_male) {
    if ($user_is_male) {
        return "User is male";
    } else {
        return "User is female";
    }
}

In this case the output_gender function returns a set output based on $user_is_male is true or false. When return is used in a function, any code below the return statement is totally ignored, so, if $user_is_male is true, then the else block will be ignored since a value is returned. With this concept, we can get rid of the else block like this:



function output_gender(bool $user_is_male) {
    if ($user_is_male) {
        return "User is male";
    }

    return "User is female";
}

We know that the if statement won't run if the condition passed in is false. This means it will skip straight to the "User is female" part.

Tip 2: (if blocks: less vs more)

Tip 2 builds upon the tip we just looked at above but goes in a bit deeper. In an if/else or even using an example like tip 1, you might have conditions where one block, either the if or else, has less code than the other. It's better in such situations to handle the block with less code first. Let's look at a real example.



public function categoryWithPosts($category)
{
    $category = Category::find($category);

    if ($category) {
        $category->posts = $category->posts()->published()->get();
        return response(['data' => $category], 200);
    } else {
        return response(['error' => 'Category not found'], 404);
    }
}

This code above checks for a post category and runs a condition based on whether the category is found or not. If we're to go with ONLY tip 1, we'll have code looking like this:



public function categoryWithPosts($category)
{
    $category = Category::find($category);

    if ($category) {
        $category->posts = $category->posts()->published()->get();
        // having any more code here would
        // bloat this part of the function
        return response(['data' => $category], 200);
    }

    return response(['error' => 'Category not found'], 404);
}

This code is correct, however, you can clearly see that our major code is wrapped with {}, and pushed in further. If this code were significantly longer, it would be a pain to keep it all within the if block. Following tip 2, we can have this instead:



public function categoryWithPosts($category)
{
    $category = Category::find($category);

    if (!$category) {
        return response(['error' => 'Category not found'], 404);
    }

    $category->posts = $category->posts()->published()->get();
    // we can freely have more code here
    // without worrying about the code looking weird
    return response(['data' => $category], 200);
}

Since the else block has less code, we use a negative statement with ! to make that code run first. So our if rather contains if not category, run code.... This gives us more room to handle our major code freely.

Tip 3: (verifying multiple strings)

Let's just say we want to find if a certain variable is or isn't one of many strings, we'd obviously have to write a bunch of conditional statements to verify this:



$item = "candy";

switch ($item) {
    case 'candy':
        return true;
    case 'toy':
        return true;
    default:
        return false;
}
// we're not adding break because we're using return

// or
if ($item == 'candy' || $item == 'toy') {
    return true;
}

return false;

This code returns false if the item variable is neither candy nor toy. This is perfectly correct, however, this is very repetitive. Instead, we can check an array for the string we want to find:



if (in_array($item, ["candy", "toy"])) {
    return true;
}

return false;

Even this can be shortened further because in_array returns a boolean.



return in_array($item, ["candy", "toy"]);

We just shortened these lines to just a single line, clean right? How does this work? We have an array containing the strings we want to check for. Then we pass that into in_array. This creates a simple condition like:



if $item is inside the array holding "candy" and "toy", return true, else false

You might be wondering, why not just return whether $item is candy or toy directly since that too is just one line, like this:



return ($item == 'candy' || $item == 'toy');

This will give us the same result, however let's say we were checking 10 strings:



return ($letter == 'a' || $letter == 'b' || $letter == 'c' || $letter == 'd' ...);

You can clearly see that this easily gets out of hand, compared to this:



return in_array($letter, ["a", "b", "c", "d", ...]);

Note that the first parameter of in_array is the string we're actually checking

Tip 4: (??)

?? is probably the easiest way to create inline conditions without 2 parts. What do I mean? Let's look at an example, that would do all the explaining for me.



$data = [
    "a" => 1,
    "b" => 2,
    "c" => null,
];

return $data["c"] ? $data["c"] : "No data";

The last line here checks if the key c in $data is truthy, if not it returns "No data".

We can rewrite the last line with ?? to look like this:



// ...
return $data["c"] ?? "No data";

In this case ?? behaves like the || logical operator in other languages. A real-world example of this would look like this:



$user = getUserFromDb($user_id) ?? trigger_error("User id is invalid");

echo $user;

getUserFromDb is to return a user from a database somewhere, however, if the user isn't found, instead of setting the user variable, we break the application with trigger_error. Without ?? we'd have to write this instead:



$user = getUserFromDb($user_id);

if (!$user) {
    trigger_error("User id is invalid");
}

echo $user;

Tip 5: (Recursiveness over repetition)

I think this tip is pretty straightforward, try to use recursiveness rather than repeating yourself a lot. There are situations that'll make you repeat some code, that's fine, but if you find you're repeating the same code, just make it a method. Where does recursiveness come in? Let's look at an example: This is a method I wrote for my Leaf framework's request object, to return a particular field passed into the request.



/**
 * Returns request data
 *
 * This methods returns data passed into the request (request or form data).
 * This method returns get, post, put patch, delete or raw faw form data or NULL
 * if the data isn't found.
 *
 * @param string|array $params The parameter(s) to return
 * @param bool $safeData Sanitize output
 */

This means that this method can take in either an array or string and based on the input, it would return a string or an array. The solution would be to check if the input was an array, loop over it to get the strings in the array then perform the data fetch on those strings, which would look like this.



public function get($params, bool $safeData = true)
{
    if (is_string($params)) return $this->body($safeData)[$params] ?? null;

    $data = [];
    foreach ($params as $param) {
        $data[$param] = $this->body($safeData)[$params] ?? null;
    }
    return $data;
}

Here, you notice $this->body($safeData)[$params] ?? null is being repeated, not just that, but what if an array holding another array is passed in instead. Since this is a library, there's no telling what sorts of things users would pass in there, so I did this instead.



public function get($params, bool $safeData = true)
{
    if (is_string($params)) return $this->body($safeData)[$params] ?? null;

    $data = [];
    foreach ($params as $param) {
        $data[$param] = $this->get($param, $safeData); // I called the function again
    }
    return $data;
}

This makes sure that until the looped value is a string, it won't attempt to fetch its data. A small trick compared to those above, but definitely useful. Note that this function is class scoped, hence the use of $this

Tip 6: (PHP + HTML)

This is for when you want to write PHP in your HTML or HTML in your PHP😅. We'd usually do something like:



<?php
foreach ($items as $item) {
    echo '
        <div class="product__card">
            <h3>{$item->name}</h3>
        </div>
    ';
}
?>

Although this is fine, you can clearly see, we're outputting the HTML as a string. The bulkier the HTML, the more stressful it becomes to match tags and keep track of exactly what part of the HTML we're writing is. There's a neat solution for this.



<?php foreach ($items as $item): ?>
    <div class="product__card">
        <h3><?php echo $item->name; ?></h3>
    </div>
<?php endforeach; ?>

You can clearly see how we're maintaining our HTML formatting and code alignment...and no, this is not a templating engine, this is just PHP making things simple for us. One major thing about PHP is how it allows the same thing to be done in many different ways. In this example above, we're using:



foreach (...):
// code
endforeach;

// also works with if
if (...):
// code
endif;

// also
if (...) #one line code

while():
// ...
endwhile;

Tip 7: (Writing functional blocks)

Functional blocks can range from a large feature to a single lined wrapper, around a default PHP function, the point is just to create that functional block. This isn't just to avoid repetition, but also to speed up your workflow and make your code more readable.

You can write a simple method to create a redirect like this:



function redirectTo($route) {
    header("location: $route", true, 302);
}

So instead of writing header("location: /home", true, 302) everytime, it makes more sense to write redirectTo("/home"). The same applies to 3rd party libraries, and long processes, writing a reusable block of code in an open way eg:



UserNotification::send($user_id, $notification);

is obviously better than writing a bunch of lines every time you have to send a notification to a user. Another very small but very useful tip.

Tip 8: (Using Types)

Another straightforward one. This is one of the least used, but very powerful features available in PHP. This is a feature that can save you and other developers a whole lot of stress (if you work with a team).

Of course, you can write function descriptions like the example in tip 5 above, but it becomes quite a daunting task to write function descriptions for all your functions and variables in a large project.

Let's take a look at how types can save our lives later:



function getItem($item) {
    // $item is expected to be an array
    // for whatever reason
    return allItems()[$item[0]];
}

If a different developer works on the project or even yourself after a few weeks, seeing the getItem method, the $item variable there is obviously expected to be a string, but the function was written to handle an array.

The dangerous thing here is that passing in a string won't break the app, it would still run perfectly. Why?

If "chair" is passed into the function, it will be evaluated to allItems()["c"], which will end up causing errors that will keep you up at 12am😅. This can easily be avoided like this:



function getItem(array $item) {
    return allItems()[$item[0]];
}

This will make sure that whatever is passed in here is the type needed. You can read more from php.net

You can also use methods like is_string and is_array which we saw above like this:



function getItem($item) {
    if (!is_array($item)) throwErr("item should be array");

    return allItems()[$item[0]];
}

Tip 9: (Frameworks/Libraries aren't evil)

I'll be real over here, open-source libraries cause problems! Sometimes the libraries we bring in cause more problems for us instead of helping us. This might sound like I'm totally trashing open source packages, I'm not, I also write open-source packages myself, so obviously not!

My point is that you should read more on packages you bring in, read their documentation, check their issues on GitHub, don't take unnecessary risks. One thing I'll advise, and that goes back to Tip 7, write wrappers for features around the packages you bring in. This will give you a bit more control and also make your code cleaner.

In regards to frameworks, you might have heard this before, but you should familiarize yourself with PHP first. PHP frameworks, no matter the language they were written in still use PHP's principles and style, so the first step is to obviously familiarize yourself with PHP.

Next would be to pick something you're comfortable with and stick to it. There are many choices out there:

Laravel: if you love magic, laravel does literally everything for you (unless you decide otherwise)
Slim: A rest API framework, has a sort of "bring your own" vibe
Leaf: That's what I wrote, inspired by Slim and Laravel, it gives you the magic you can control.

I only mentioned frameworks I actually use to avoid bias.

Tip 10: (Don't just code!)

Alright, this one is a bonus tip. It applies to not just PHP, but technically almost every language/framework you work with. What I mean by don't just code is relatively straightforward.

Let's say you want to write a method that sort of requests a payment from a user's account, jumping straight into coding out this feature may (or may not) end up getting you confused at some point, where you'll have to stop, scroll back up, check something from a file somewhere, or something similar.

What am I proposing? Here:



// in class scope
public function requestPayout()
{
    // parse token to get user id

    // fetch user from DB with id

    // check if the user is eligible for payouts

    // get user balance with user helper

    // check and throwErr for insufficient funds

    // ...
}

The above just allows you to do all the required thinking before actually jumping in to write any features. It also in a way helps you cross-check what you're building since you'll end up listing out all your processes out first.

Thanks for reading

These are a few tips and tricks I've discovered on my PHP journey, some of these might work for you and others may not, feel free to choose whichever you're comfortable with and stick to those.

It's quite wrong to say these are good ways of doing stuff so use these only, as I mentioned before, PHP is the type of language that provides many different ways of doing the same thing, so if you have anything you'll like to share, a new tip, a faster way to do something I mentioned, something you don't agree with, just reach out to me.