Repeatable/flexible fields

[bernhardh]

It would be great, if we could have a repeatable field type, basically the same what https://whitecube.github.io/nova-flexible-content/ does for nova. I already saw #185 but thats not what I mean.

Must have's:

• Define your own subfields for the repeatable and group it as fieldsets/layouts
• Allow to format (grid) the repeatable and also its subfields

Nice to have's:

• Limit number of rows (min, max)
• Allow nestesting of the repeatable
• Controll how everything is stored. Allow to store it inside a json field or a separate database table or whatever. (Whitecube solve this with custom resolver classes for storing/retrieving data)

What do you think about this? Sounds like a lot of work to do, right?

[ryangjchandler]

@bernhardh This is on our roadmap and we'll be working on it soon.

I can't see us adding support for saving to separate database tables in the initial release. That would add a level of complexity to the field type that doesn't really make sense in Filament's context.

[bernhardh]

Thanks for feedback!

Oh great. I really love filement so far and would love to see the missing last pieces.

I understand your point, that you don't wanna add too much complexity to such fields. Maybe I am wrong, but why not just add a way to control (aka overwrite) data fetch and storing logic for each field (not only this specific one)? Then the user could implement such a feature himself. Such a mechanismn would not only help in this case, but also in a lot of other situations, where he has to manipulate the fetched data from the database or before writing to database.

Something like:

Field::make($name)
   ->fetchCallback(function(Model $model, string $fieldName) {
        return $model->$fieldName;
   })
   ->storeCallback(function(Model $model, string $fieldName, $request) {
        $model->$fieldName = $request->post($fieldName);
        
        return $model;
   });

where you can already see the default behaviour.

With this, someone could easily implement logic by using these callbacks and fetch/save the data from another table by themself. And of course this would be a good additional option for other situations as well, when you have to transform userinput for the database (=storeCallback) or data for fields (=fetchCallback).

Or do I oversee something?

[ryangjchandler]

You can actually already do this using hooks, like beforeCreate.

[bernhardh]

Oh. Stupid me. I was (coming from nova) expecting this on field level. But you are right. It makes sense, to put this on resource level.

[ryangjchandler]

Yeah, finding a good and generic API for something like that can be difficult.

[danharrin]

Hey! 👋

I'm pleased to announce that this is now a feature of Filament Form Builder v2. When Filament Admin Panel v2 is released in Winter 2021, it will be available there. For more information, please see #495.

In the meantime, feel free to try out the feature in the Form Builder and let me know if it fits your needs! It only takes a minute to install.

If you have any questions, let me know in a reply!

Dan

[bernhardh]

So is this ment to be used/usable in the meantime in custom jetstream projects? Because i need to start a admin panel project right now and can't wait for winter time 🤣

[danharrin]

Yup! All docs are on our website :)

[danharrin]

I think I will release specific videos about the repeater and builder soon as well.