Migration difficulties with routes

[Iaotle]

Hi!

We've been using laravel-tables for our project, and the upgrade to v5 seems to require significant migration, specifically in the routes department. Whereas before you could specify routes using a routes variable, now you have to create actions and pass routes to them.

Could there be a backwards-compatible option in order to reduce the migration difficulties?

Also, it seems like the row actions aren't rendering properly and the icons are missing.

[Okipa]

Hi @Iaotle, I'm currently working on the upgrade guide in order to make the migration as smooth as possible but it will indeed demand a bit of work.

Regarding icons, this is because Fontawesome 6 is used by default, instead of Fontawesome 5.

I'll take account about your comment to add a part about routing in the migration guide.

I let you know when it is finished!

[Okipa]

Hi @Iaotle, I just finished the upgrade guide : https://github.com/Okipa/laravel-table/blob/v5/docs/upgrade-guides/from-v4-to-v5.md

Could you please follow it and tell me if everything is going well ?

This upgrade is a massive one and it is impossible to assure a backward compatibility with the routes method as actions are some new features based on Livewire and not based on a page-reloading behavior.

[Iaotle]

Hey @Okipa, I'm going to leave the issues I encounter piecemeal. Hope you don't mind.

1. You have livewire components starting with <x:livewire.table - shouldn't this be <livewire:table instead?
2. ->format(new Datetime('d/m/Y H:i', 'Europe/Paris')) doesn't actually work.
   

[Okipa]

Thanks @Iaotle, the wrong <x:livewire.table was a typo, I have fixed it.

Regarding the wrong DateTime formatter, it is also a typo, I changed some signatures during the implementation and I forgot the change some elements in the Readme, sorry for that => It is ->format(new DateFormatter('d/m/Y H:i', 'Europe/Paris')) instead, it has also been fixed in the doc.

[Iaotle]

How is configuration meant to be handled? I want to use the old font awesome icons, but the config file changes will reset every time I update the app from git. Is there a better way to do this?

[Okipa]

@Iaotle No the config file will not be overridden every time you update the app from git, you just have to rename your old published config file (laravel-table-ex for example) and to publish the new config file with php artisan vendor:publish --tag=laravel-table:config.

Once the new config file is published, you can report some configs from the old file to the new one if necessary, and set the FontAwesome V4 (or previous) icons.

But I strongly advise you to migrate to FontAwesome 5, the new version allows the V4 markup and still displays icons from the previous version, event if you should at least add new icons with the V5 markup.
I'm pretty sure this backward compatibility will not work for version under V4.

[Iaotle]

Templating is mentioned as completely changed but no info is provided as to how this is meant to be done in livewire.

[Okipa]

@Iaotle No info is given about that because it is impossible to do :)

In fact, a lot of time has been spent to design the table with the best ergonomics and accessibility as possible, so I'm considering that it is pretty OK as is.

But if you absolutely want to report your customizations, you can proceed the same way you did for the configuration file and check the published template in resources/views/vendor/laravel-table to see what customizations can be migrated.

You also should keep in mind before customizing the new templates that the V5 has many additional features (this is the main reason the package has been totally rewritten) that may cause conflicts with your previous custom implementation.

[Iaotle]

I think the row actions generator text is incorrect: 'You may need to create your own row actions. To do so, execute the following command: php artisan make:table:bulk:action MyNewRowAction.' bulk should be row.

Additionally, the generator for rowactions uses Eloquent model twice:

[Okipa]

@Iaotle thanks, just fixed that 👍

[Iaotle]

@Okipa I think formatters should support nulls, and output a blank result when no input is provided. For instance the DateFormatter will fail if no input is given for a column.

[Okipa]

@Iaotle Yes I agree, it has been updated 👍

[Okipa]

It seems that everything is OK here ? I mark this as answered.

[Iaotle]

Yep, migration is finished successfully.