Forem: Sven Schannak

How to Use ImportAction in Laravel Filament with RelationManager

Sven Schannak — Sat, 27 Jan 2024 15:25:56 +0000

Laravel Filament, a powerful tool for building admin panels, offers a variety of features for managing data, including the ImportAction. This is particularly useful when dealing with bulk imports on related resource tables. However, a common challenge arises when you need to specify the ID of the record that the imported data belongs to.

Setting Up ImportAction

When using ImportAction on a RelationManager in Laravel Filament, you need to set the ID of the record that the imported data is related to. Here's how you can do this:

use Filament\Tables\Actions\ImportAction;

ImportAction::make()
    ->importer(MyImporter::class)
    ->options([
        'related_id' => $this->ownerRecord->id
    ]);

In this snippet:

ImportAction::make() initializes the import action. ->importer(MyImporter::class) sets the importer class.
Replace MyImporter with your custom importer class.
->options([...]) is used to pass additional options. Here, we are setting the related_id option to the ID of the owner record.

Accessing Options in Lifecycle Hooks

Once you have set the related_id in the options, you can access these values in all lifecycle hooks of the ImportAction. Here's an example of accessing related_id in a lifecycle hook:

->beforeSave() {
    $relatedId = $options['related_id'];
    // Additional logic using $relatedId
}

In this example, the beforeSave hook is used to retrieve the related_id from the options and perform some operations before the save process begins.

Conclusion

While the Laravel Filament documentation might not explicitly cover the usage of ImportAction with RelationManager, especially regarding setting and accessing the ID of the related record, the above method provides a clear and effective way to handle this scenario. By passing the related_id in the options and accessing it in lifecycle hooks and the resolveRecord() method, you can efficiently manage bulk imports on related resource tables in your Laravel Filament projects.

Composer - When to use install, update or require

Sven Schannak — Wed, 23 Nov 2022 16:18:03 +0000

Using composer and other package managers like npm can have a different meaning for their commands to install or update packages. Image the following content of your composer.json and composer.lock:

composer.json

"laravel/framework": "v8.*"

composer.lock

"name": "laravel/framework",
"version": "v8.83.17"

composer install laravel/framework

When you use the install command, composer will install the version from the composer.lock file. For the example this would be v8.83.25.

composer update laravel/framework

Using the update command would install the version as given in the composer.json file. For the example this would be v8.83.26, because it is the latest version for v8 (as today).

composer require laravel/framework

Require will "ignore" the versions from composer.json and composer.lock and will install the newest version available. As today this would be v9.41.0. Also composer.json and composer.lock will be updated.

install -> v8.83.17
update -> v8.83.26
require -> v9.41.0

Should you use JavaScript WeakMaps or WeakRef?

Sven Schannak — Tue, 30 Nov 2021 23:21:18 +0000

Developers are always searching for the new exciting stuff and so they are excited when they find something new. Finally a new hammer to put any kind of nail into all walls you can possibly find! But with time, you accept the harsh truth that new and exciting technology should be avoided to be used instantly when you discover them.

First you should try to understand them better. A good example are WeakMaps in JavaScript. And to be honest they are not really something new and exciting as their spec was already implemented in IE11, but most of of JS developers probably never really heard of them. And that is for a good reason, because most of us developers don't really need to use that in our daily coding business, because it is an advanced spec that you will probably only need if you want to write your own library or squeeze the last tiny bit of possible optimization out of your frontend app.

Still, you should learn about them and there is actually a great introduction to the topic on YouTube that i would definitely recommend you to watch:

However, i want to give you some quick introduction into this topic so you can understand better what is possible with this "weak" JavaScript stuff and why you should avoid using it for the most cases.

WeakMaps

What is the difference between a normal Map and a WeakMap? There are two key (pun intended) factors that differentiate them. For the start, only an object is allowed as a key for a WeakMap and you can't iterate over a WeakMap.

Imagine the object you define as a key as something like real key, that you can't copy. A string as the key for example would be easy to copy. Because two equal strings are the same. This is different for objects and that is really important for WeakMaps. Because WeakMaps don't hold a strong reference to an object. And this means if the object is nowhere else in the running code used anymore, the key on the WeakMap will also vanish. Because it is actually garbage collected. And this is where the problem with WeakMaps start. Because by the specification of garbage collection for JavaScript engines for the different browser you can't rely on the fact that they all handle their garbage collection the same way. You actually can never be sure how your code behaves for different browsers or even in different browser versions. If that sounds really dangerous to you, it probably should.

Nonetheless some developers still use a WeakMap for example to add metadata to objects, that they also want to be garbage collected when the object is garbage collected. Or just want to add that metadata in some part of the code and need the metadata only there. But ask yourself: Is it worth the risk to use something that can possibly behave different than you expect? And will your coworkers understand it, when they have to review or even change your code later? There is a good chance that they have never worked with WeakMaps and will therefore possibly introduce some bugs to your system that are hard to fix.

Right now you probably ask yourself why stuff like WeakMaps do exist in the first place? To understand this better, let's talk about WeakRef.

WeakRefs

A WeakRef holds a weak reference to an object. So like the WeakMap, the object can be garbage collected even if there still exists a WeakRef that contains an object.

Why do we need WeakRefs actually? One of the most popular reasons has something to do with the FinalizationRegistry and WebAssembly. Because FinalizationRegistry will give you a way to create a callback to also clean up your objects in WebAssembly if a related object is garbage collected in the actual JavaScript Code of your WebAssembly project.

Otherwise it would be really hard to recognize if an object was garbage collected and you probably have to use much more memory than you would need. And this is especially interesting for WebAssembly. Because most of the WebAssembly projects are created with performance and speed at the heart of the project. So this part becomes really important.

Avoid where possible

As you have probably already realized it is not only hard to use WeakMap or WeakRef, but it can also lead to some bugs that are even harder to debug. And with modern state management libraries there are better ways to add meta data to objects. So, as the official specs will tell you: Try to avoid using them.

MySQL calculate percentages

Sven Schannak — Sat, 27 Nov 2021 23:31:56 +0000

Information is only useful, if you view it in a context. In data analysis you should avoid to only look at absolute numbers. For example you could just get the number of all users that have signed up in the previous month:

SELECT COUNT(*) as has_orderd
FROM users
WHERE users.has_ordered = true
AND YEAR(date_created) = YEAR(CURRENT_DATE - INTERVAL 1 MONTH)
AND MONTH(date_created) = MONTH(CURRENT_DATE - INTERVAL 1 MONTH)

Result:

has_ordered
450

But this number only gives you a certain amount of useful information. So you should look at that data, compared to all users that signed up the previous month:

SELECT COUNT(*) as total
FROM users
WHERE YEAR(date_created) = YEAR(CURRENT_DATE - INTERVAL 1 MONTH)
AND MONTH(date_created) = MONTH(CURRENT_DATE - INTERVAL 1 MONTH)

Result:

total
1100

If you want both data points next to each other, you can do the following:

SELECT 
    SUM(users.has_ordered = true) as user_with_orders, 
    COUNT(*) as total
FROM users
WHERE YEAR(date_created) = YEAR(CURRENT_DATE - INTERVAL 1 MONTH)
AND MONTH(date_created) = MONTH(CURRENT_DATE - INTERVAL 1 MONTH)

Result:

user_with_orders    total
450                 1100

And to calculate the percentage of all users that have signed up the last month, you can just do:

SELECT 
    SUM(users.has_ordered = true) as user_with_orders, 
    COUNT(*) as total,
    ((SUM(users.has_ordered = true)/COUNT(*)) * 100) as percentage
FROM users
WHERE YEAR(date_created) = YEAR(CURRENT_DATE - INTERVAL 1 MONTH)
AND MONTH(date_created) = MONTH(CURRENT_DATE - INTERVAL 1 MONTH)

Result:

user_with_orders    total   percentage
450                 1100    40.9

Taking advantage of React context und useContext in a function only React App with Hooks

Sven Schannak — Wed, 31 Jul 2019 08:57:48 +0000

What problem does Context in React solve?

The typical use case for Context in React is passing down user data or the number of current items in a checkout, because you don't really need to load that kind of data every time you rerender a component.

In a common scenario you would pass down the value from the main root, where you have saved the data. This leads to a problem, where you are using some child components just as a proxy to pass down the values. In this case, you would add extra props and dependencies to a component, even if you don't really need them.

import React from 'react';

function UserData({ userName }) {
    return (
        <div>{userName}</div>
    )
}

function Header({ userName }) {
    return (
        <div>
            <h2>Header</h2>
            <UserData userName={userName} />
        </div>
    )
}

export default function MainFn() {
    const [userName, setUserName] = React.useState("Sven");
    React.useEffect(() => {
        // load user data and set username
    }, []);

    return (
        <Header userName={userName} />
    )
}

A better way with React Context

Hooks and React Context to the rescue! With Context we can just set some data from the MainFn and with useContext we can just get the context data into any child elements.

import React from 'react';

const UserContext = React.createContext(
    { username: "", email: "" }
);

function UserData() {
    const context = React.useContext(UserContext);

    return (
        <div>
            {context.username}
        </div>
    )
}

function Header() {
    return (
        <UserData />
    )
}

export default function MainFn() {
    const [username, setUsername] = React.useState("Sven");
    const context = React.useContext(UserContext);

    // copy the origin context to override only necessary objects and not the whole object
    const contextValue = { ...context }
    contextValue["username"] = username;

    return (
        <UserContext.Provider value={contextValue}>
            <Header />
        </UserContext.Provider>
    )
};

Disclaimer

Always think about if you really want to use Context. As you can see, the function for the UserData does not specify any parameter. So you never know what data is needed and where it comes from. By design it is difficult to see which dependencies are needed in a component that uses Context.