I’m trying to figure out the best use-case for modular pages.
From what I get from the documentation, modular pages are meant to build complex UI splitting the page in several modules (each module have it’s own template under modular directory and, eventually, a specific blueprint).
Now, for my purpose I’ve to create several pages, let’s say homepage, contacts, about us and so on. Each page has unique UI and does not share any reusable component (let’s say module).
In this case, is recommended to create 1 unique twig template for each page or go with several modular blocks (each prefixed with page name e.g. homepage has homepage_heading.html.twig and so on…) ?
I think the primary benefits of modular pages being easy reuse layouts and a bit easier to maintain content in the admin panel. It sounds like modular pages would be unnecessary in your case. If you ever need to add in some universal content like a call to action button or headers/footers you can do that easily enough using a partial.
I do agree with you.
I think that modules in modular pages are designed to be self-contained reusable chunk of code with specific blueprint that let users handle theirs data from admin panel.
Looking at my scenario I found that partials pattern (I’m used to Ruby on Rails) more suitable since each page does not share any component (like Features in the Antimatter starter) except for header and footer.
By attaching a blueprint to my homepage.html.twig I can handle data from admin panel, am I right?
Yes that is correct. Also, the blueprint is not exclusive so you can put say 90% of the page content hard coded into the twig file and only have a few modifiable fields in the blueprint or vice versa. You might find uploading new twig files far easier than messing around with admin panel fields.
Yeah that’s exactly what I’m doing since my client need to edit few fields, the others are hardcoded in the twig template Thank you for your support!