[v5][Summary] Not all fields work as subfields inside relationship

Right now, we do NOT have a clear map:

• what field types works as subfields inside repeatable?
• what field types work as subfields inside relationship?
• is there any difference between the two?

And we should. We MUST. It’s just a matter of time before somebody tries a combination we haven’t - and they will get a horrible experience. If we do not tell them “X does not work as subfield”, they will expect everything to work as subfields. So we need to TEST EVERYTHING, KNOW what works and what doesn’t and DOCUMENT what works and what doesn’t. Then, one by one, we can make them work (if it’s reasonable to do so). Here’s my first attempt to test EVERYTHING.

What is left untested?

• all subfields inside repeatable field - we have them inside the Dummies CRUD ✅
• all subfields inside relationship field
  • (A) work on the 1-1 interface (attributes on hasOne/morphOne) 🟨
  • (B) work on the 1-n interface (attributes on hasMany/morphMany) 🟨
  • © work on the n-n interface (attributes on belongsToMany/morphToMany pivot table) 🟨

So what we need to add to the Demo, to have all bases covered, are examples that use all field types as subfields, inside the yellow scenarios above. The new interfaces we just added for the relationship field. Fortunately, we already have a model with ALL field types. And they’re already configured inside MonsterCrudController, we can just re-use their definition like we did in Dummies CRUD.

How do we test the untested?

We can add three new entities, Cave, Story and Hero, with the following db tables:

This means that:

• Cave hasOne Monster (there’s a cave_id on the monsters table) - treats use case (A)
• Story hasMany Monster (there’s a story_id on the monsters table) - treats use case (B)
• Hero hasMany Monster (there’s a hero_id on the monsters` table, which also means:
  • Hero belongsToMany Story (through the monsters pivot table) - treats use case ©
  • Story belongsToMany Hero (through the monsters pivot table)- treats use case ©

So we can build three new CRUDs, to have ALL subfields tested in these 3 new use cases. I’ll submit a PR to the demo with these three new CRUDs:

Update: PR here - https://github.com/Laravel-Backpack/demo/pull/346

[pxpm]

Hello @kee0624 . It migth display on page, but surelly it’s not working.

Subfields inside subfields are not supported. Some will display, some will not display and throw errors. Use at will, we do not recommend and we do not support them (for now).

thanks

[pxpm]

Hello @guleswine it’s indeed strange but I guess that it might be some corner case while using default values or something like that. As far as I am aware select2_from_array was working properly as a subfield.

If you remove the default does the problem still happen ?

If so, please open a separate issue so we can have a look at and don’t forget about it in the middle of this thread.

Thanks