What is the right way in Strapi Admin UI to have a single View for a collection type that allows to fill out an entry and create other relational entries (for other collections) for this type?
For example, I have a Course collection type. A Course has many Chapters (and a Chapter is another collection type). Each Chapter has many Lessons (and a Lesson is yet another collection type).
If I want to click “add new Course” and have a view that allows to create a chapter and create and add lessons to it. How do I do this?
I am going to post an answer here to my own question.
TL;DR: There is no such way and there is no plan to have it in near future.
You can get somewhat close experience with using components but they have many limits that you don’t really want to bring in. Also, you can’t have Dynamic Zones inside components.
So there are two options (not really but it is complicated).
a) Just use relations between collection types, like:
Course has categories
Category has lessons.
Lesson has a dynamic zone with a choice of components that would represent different types of lessons, e.g. Video lesson, text lesson, quiz, etc.
This I call “proper relations” because from the DB design and data modelling perspective this is correct approach.
But this way of modelling the course will not deliver the UX: there will be no way to have one editor to fill in the entire course. Lessons will be created separately, then Chapters will be created separately and lessons linked to them.
Course will be created separately and chapters linked to it. Not a beautiful world with unicorns and rainbows for someone who wants to create a course using this UX.
b) use Components with Dynamic Zones to design all the repeatable parts like chapters and lessons.
Potentially this could work for UX (but doesn’t because Components can’t have Dynamic Zones in them) but relations between lessons and chapters will be all pain. So querying data will be tough work.
So, I went with the proper relations with poor UX (because I have requirement on data querying that I can’t meet with components).
Fundamentally, this is correct approach as I can have proper queries to my data at the frontend.
And the gaps in editing UX I can address later by investing my effort in building custom content Editor.
Unless of course, Strapi team will do something about it on their end (which is not very likely).