Refine will be launching soon 🎉 Sign up for the early access list to stay up to date.
Refine for Laravel
A package by Hammerstone

Migrating IDs

Hammerstone Refine has not launched yet. Sign up for the early access list to stay up to date!

Every condition has an id that should never change, as we've discussed in other places in the docs.

Every time you create a condition, you're giving it an id:

1TextCondition::make('name');

These ids are important because it's how the frontend and backend communicate, but it's also the way that stabilized filters know where to apply their data. When the filter data is stored, it stores the condition ids alongside the data.

Despite your best efforts, there are just going to be times when you have to change a condition's id and you simply can't afford to invalidate all stored filters.

To allow for this, there is a conditionMigrationMap on the filter that you can use to accomplish this.

Let's take the name condition from above and assume that we need to change the id to employee_name for some reason. To make sure all the stored filters still work correctly, we would map name (the old id) to employee_name (the new id) in the conditionMigrationMap:

1class EmployeeFilter extends Filter
2{
3 public function initialQuery()
4 {
5 return Employee::query();
6 }
7 
8 public function conditions()
9 {
10 return [
11 TextCondition::make('employee_name')
12 ];
13 }
14 
15 protected function conditionMigrationMap()
16 {
17 return [
18 // There used to be a condition with an ID of
19 // "name", but now it's "employee_name".
20 'name' => 'employee_name'
21 ];
22 }
23}
Code highlighting powered by torchlight.dev, a Hammerstone product.

Now anytime data comes in attached to a condition id of name it will transparently be switched to employee_name.