Best practices – fragment nebo komponenta, helper nebo metoda nebo…?

Pokud je komponenta stejná a mění se jen ten zdroj dat, tak na to používám občas „vnitřní stav“ té komponenty. A ona si doplní, co potřebuje a „card“ mívám v komponentně přes multiplier.

class CardList
{
	pf __constructor(private string $type)
	{
	}

	pf createComponentCard()
	{
		return new Multiplier(function () {...
	}


	pf beforeRender()
	{
		$this->template->data = $database->where('type', $this->type)->order($this-> === 'byUser' ? 'user_ranking' : 'views');
	}

	pf handleChangeStatus(int $id): void
	{
	}
}

//latte komponenty
{foreach $data as $row}
	{control card-$row->id}
	<a n:href=changeStatus id: $row->id>chycená karta pokémona</a>
{/foreach}

//presenter
pf createComponentCardByUser()
{
	return $this->CardListFactory->create('byUser');
}

Pokud je komponenta stejná a jen se mění zdroj dat (jinak seřazené/vyfiltrované atp.), tak data komponentě předám při vytváření:

//presenter
pf createComponentCardList()
{
	return $this->cardListFactory->create($this->cards);
}

$this->cards se pak plní čím je potřeba :)

Co se týče bodu 2, tak tam je to podle potřeby – pokud jde o „hloupý“ výpis, tak tam multiplier a „subkomponenta“ není nutná. Pokud je tam např. „vložit do košíku“ nebo „přidat do oblíbených“, tak tam se to už hodí a dává to smysl.

ad B) Vůbec si nedokážu představit k čemu by to mělo sloužit a nenapadá mi, jestli jsem to někde použil. Drtivá většina dat jde do šablony rovnou připravená pro použití. Případně to řeším dědičností šablon ať už latte nebo twig.

Gappa napsal(a):

Ještě k B – občas 1, občas 2, zatím nikdy 3 :)

Nejsprávnější bude asi 1?

:-) jasný, jen jsem chtěl vědět, jestli jsem něco neopomněl.

Kcko napsal(a):

Gappa napsal(a):

Pokud je komponenta stejná a jen se mění zdroj dat (jinak seřazené/vyfiltrované atp.), tak data komponentě předám při vytváření:

//presenter
pf createComponentCardList()
{
	return $this->cardListFactory->create($this->cards);
}

$this->cards se pak plní čím je potřeba :)

Co se týče bodu 2, tak tam je to podle potřeby – pokud jde o „hloupý“ výpis, tak tam multiplier a „subkomponenta“ není nutná. Pokud je tam např. „vložit do košíku“ nebo „přidat do oblíbených“, tak tam se to už hodí a dává to smysl.

Ahoj,
rozumím, někdy to tak dělám. Nicméně, chci aby se komponenta stara o svoje záležitosti sama, takže předat ji takhle data u mě v mnoha případech není vhodné.

Jedna komponenta má filtry a stránkuje (tady by jí asi šlo předat selection, ale i tak se mi to nelíbí moc), další vypisuje data přes X dalších tabulek a proto se jmenuje jinak, má jiný model, ale renderuje to samé co první (kartu / karty).

S bodem 2 ano, pokud to dává smysl (třeba přidat do oblíbených, to jsem zrovna psal, tak tam taky použiji Multiplier).

Ahoj,

pokud chápu správně, tak svým způsobem se jedná principově o datagrid? V tom případě by se mohlo jít cestou, že by jsi vždy definoval callback pro zdroj dat.

Něco jako:
https://nextras.org/…docs/master/#…

Kcko napsal(a):

Pavel Kravčík napsal(a):

ad B) Vůbec si nedokážu představit k čemu by to mělo sloužit a nenapadá mi, jestli jsem to někde použil. Drtivá většina dat jde do šablony rovnou připravená pro použití. Případně to řeším dědičností šablon ať už latte nebo twig.

Jak to, že ne? Ty připravíš všechna data rovnou v modelu? Vždyť to je už na úrovni šablony a výpisu řádků a jednotlivých sloupců / hodnot (= na tohle se to většinou aplikuje), to by sis z modelu do šablony musel ty data takhle už připravit (nějaké pole objektů, pole polí …) nebo to máš jinak?

Nenapadá mě jak dědičností šablony aplikovat něco jako

<?php
// vypis v komponente
{foreach $rows as $row}
 {$control->formatColumn($row->heading)} {* tady bude lepší asi helper, ale někdy se k tomu uchylím, protože ta metoda může dělat víc věcí najednou a většinou je to jednorázové pro danou komponentu *}
{/foreach}
?>

To bych asi řešil další komponentou nebo filtrem, ale asi jsem jen nikdy nepoužil nějaké složitější řešení. Na většinu výpisů v šabloně stačí dobře připravený pohled. Možná si jen nedokážu představit, co ta funkce reálně dělá.

@PavelKravčík , @Kcko

ad B) Vůbec si nedokážu představit k čemu by to mělo sloužit a nenapadá mi, jestli jsem to někde použil.

Nějak jsem narazil prave na jecas.cz a přemýšlel jsem, v čem by mi ta komponenta, která dostane parametry přímo do renderu a slouží vyloženě jako renderovací věc, pomohla.

2. jsem nějak úplně nepochopil, ale parametry předané vyloženě pro řízení vykreslování používám při vykreslování částí webové stránky v responzivním designu. Zde se komponenta vykreslující tentýž navigační prvek vykresluje dvakrát, ato ve dnou případech a) pomocí css breakpointů se zobrazí vždy jen jedna, b) např. navigační menu vykresluji na začátku a na konci stránky a html se mírně liší.

V obou případech a) i b) vykresluje komponenta stejná data z modelu, ale modifikuje se html/css třídy. Takže rovnou do šablony předávám parametr kterým řídím to vykreslování, presenter tím nezatěžuji a šablona je daleko přehlednější.

@Kcko

Když jsme na mobilu, tak je vhodné mít navigaci úplně tu stejnou na začátku i na konci – protože v okamžiku dorolování na konec potřebuje uživatel nabídku kam dál, ne aby musel někam zdlouhavě rolovat. No a data obou navigací jsou identická, grafika a html je skoro stejné, takže jedna společná šablona, ale drobné rozdíly tam jsou – navigace nahoře je na mobilu zabalená a má tlačítko na rozbalení, navigace dole je naopak rozbalená a to bez možnosti zabalení. Takže tady je ideální rozlišit typ vykreslení až v šabloně.

Jiný případ je boční sloupec, kde mám třeba box s kontaktními údaji a telefonem. Na desktopu je boční sloupec nahoře a tak to chci – aby byl kontakt hned na začátku vidět. Na mobilu se celý boční sloupec hodí dolů, kontaktní box tam třeba může zůstat, ale potřebuji ho i někde nahoře, ale ne úplně nahoře. Tak si kontaktní box vykreslím podruhé do sloupce article a na desktopu je skrytý. Zobrazí se na mobilu. Tady je to úplně stejný případ – jedna šablona, jedna komponenta a mírná modifikace html (css třídy) při dvojím vykreslování.

Responzivitu je ideální řešit css a vůbec do toho netahat server. On totiž klient může mít mobil/tablet naležato a pak ho otočit svisle a když to řešíš na serveru tak jseš v háji. CSS fungují vždy.

Parametrem předaným do vykreslování komponenty můžeš i přepínat jaká šablona komponenty se použije. Velkou výhodou když to předáš v šabloně je to, že je to přehledné. V šabloně řešíš grafický vzhled a když se rozhodneš změnit šablonu komponenty, uděláš to v Latte a presenter tím nezatěžuješ.

Editoval m.brecher (22. 3. 2023 21:39)

@Kcko

https://www.kniharstvi-honsnejman.cz/

Navigační menu je nahoře i dole ale chování je mírně modifikované.

@front-layout.latte:

{block 'mainMenuTop'}
	{control 'mainMenu', location: 'top', toggle: true}
{/block}

{block 'mainMenuBottom'}
	{control 'mainMenu', location: 'bottom', toggle: false}
{/block}

@layout.latte

<!DOCTYPE html>

<html n:attr="lang: $lang? 'cs'">

<head>

	<meta charset="utf-8">

	<meta name='viewport' content='width=device-width, initial-scale=1.0'>

	{block 'robots'}{/block}

	<link rel='icon' type='image/png'  sizes='32x32' href='{$basePath}/css/images/favicon-32.png'>

	<link rel='icon' type='image/png'  sizes='192x192' href='{$basePath}/css/images/favicon-192.png'>

	{block 'head'}{/block}

	{block 'headTitle'}{/block}

	{ifset 'description'}<meta name='description' content='{include description|stripHtml}'>{/ifset}

	{block 'analytics'}{/block}

</head>

<body class="body body-image">

{*	{block flashes}{/block}*}

	{block 'siteHeader'}{/block}

	<div class="site-container">

		{block 'mainMenuTop'}{/block}  {* tady je první varianta *}

	<main class="main">

		{block 'aside'}{/block}

		{block 'content'}{/block}

		{block 'asideMobile'}{/block}

	</main>

		{block 'mainMenuBottom'}{/block}    {* tady je druhá varianta *}

	{block 'footer'}{/block}

	</div>

	{block 'scripts'}{/block}

</body>

</html>

control MainMenu.php

class MainMenu extends Control
{
    public function __construct(private MenuModel $menuModel, private string $slug)
    {}

    public function render(string $location, bool $toggle)
    {
        $this->template->menuModel = $this->menuModel;
        $this->template->nodeRows = $this->menuModel->getNodeRows();
        $this->template->buttonItemRows = $this->menuModel->getButtonItemRows();
        $this->template->slug = $this->slug;
        $this->template->location = $location;
        $this->template->toggle = $toggle;
        $this->template->render(__DIR__.'/templates/main-menu.latte');
    }

}

main-menu.latte:

{var
    $menuClasses = $toggle ? ['toggle-menu', 'menu-mobile-view'] : [],
    $containerClass = match($location){
        'top' => 'top-menu-container',
        'bottom' => 'bottom-menu-container'
    },
    $linkClass = match($location){
        'top' => 'scrolldown-button',
        'bottom' => 'scrollup-button'
    }
}
<div n:class="main-menu-container, $containerClass">
        {if $toggle}
            {include toggleButton}
        {/if}
        <nav n:class="'main-menu', ...$menuClasses">
            {foreach $nodeRows as $row}
                {var
                    $item = $menuModel->langRow($row),
                    $fragment = $row->slug_cs === '@homepage' && $menuModel->lang === 'cs' ? '#stay' : '',
                    $selected = $menuModel->slug === $item->slug ? 'selected' : null
                }
                <a n:class="'button', $selected" href="{plink 'Article:article'.$fragment, slug: $item->slug}">{$item->caption}</a>
            {/foreach}

            {foreach $buttonItemRows as $itemRow}
                {var
                    $button = $menuModel->langRow($itemRow->button),
                    $buttonItem = $menuModel->langButtonRow($itemRow),
                    $view = $buttonItem->{$location.'_view'},
                    $renderButton = $view !== 'none',
                    $viewClass = match($view){
                        'default' => '',
                        'desktop' => 'desktop-view',
                        'mobile' => 'mobile-view',
                        default => null,
                    }
                }
                <a n:if="$renderButton" n:class="'button', $linkClass, $viewClass" href="{plink 'Article:article#'.$button->fragment, slug: $slug}">
                    <span class="icon-right">{$button->caption}</span>
                </a>
            {/foreach}
    </nav>
</div>

{define toggleButton}
    <div class='button transition toggle-menu-button'>
        <span class='closed-caption'>Menu</span>
        <span class='opened-caption'>Zavřít menu</span><span class='toggle-icon'></span>
    </div>
{/define}

MenuModel.php

class MenuModel extends LangModel
{
    private Selection $menuList;

    public readonly string $slug;

    public function __construct(private Explorer $database)
    {}

    public function setSlug(string $slug)
    {
        $this->slug = $slug;
    }

    public function getNodeRows(): Selection
    {
        if(isset($this->menuList)){
            return $this->menuList;
        }
        return  $this->menuList?
                $this->menuList = $this->database->table('node')
                    ->where($this->langCol('published'), true)
                    ->order($this->langCol('sort'));
    }

    public function getButtonItemRows(): Selection
    {
        return $this->database->table('button_item')
            ->where('node.'.$this->langCol('slug'), $this->slug)
            ->order('sort');
    }

    public function langButtonRow(ActiveRow $activeRow): LangButtonRow
    {
        $tableName = $activeRow->getTable()->getName();
        $langRow =  $this->langRows[$tableName]?
            $this->langRows[$tableName] = $this->createLangButtonRow($tableName);
        $langRow->loadActiveRow($activeRow);
        return $langRow;
    }

    private function createLangButtonRow(string $tableName): LangButtonRow
    {
        return  new LangButtonRow($this->lang, parent::Columns[$tableName]);
    }


}

Kcko napsal(a):

Jedna komponenta má filtry a stránkuje (tady by jí asi šlo předat selection, ale i tak se mi to nelíbí moc), další vypisuje data přes X dalších tabulek a proto se jmenuje jinak, má jiný model, ale renderuje to samé co první (kartu / karty).

Můžeš mít komponentu pro takový výpis a k ní jednu latte šablonu. Z té komponenty pak můžeš dědit potomky, kterým přepíšeš jen nějakou metodu pro získání dat, ale render necháš z předka.

Kamil Valenta napsal(a):

Kcko napsal(a):

Jedna komponenta má filtry a stránkuje (tady by jí asi šlo předat selection, ale i tak se mi to nelíbí moc), další vypisuje data přes X dalších tabulek a proto se jmenuje jinak, má jiný model, ale renderuje to samé co první (kartu / karty).

Můžeš mít komponentu pro takový výpis a k ní jednu latte šablonu. Z té komponenty pak můžeš dědit potomky, kterým přepíšeš jen nějakou metodu pro získání dat, ale render necháš z předka.

Ahoj, chápu, ale tak dědit od složitější komponenty, plné konfigů atd. abych v poděděné třeba část složitého konfigu přepisoval nebo to takhle dělal jen kvůli sdílenému renderu mi nepřijde zcela dobré.

Nicméně jsem rád, že jsem si tady utvrdil myšlenky a dozvěděl se různé postupy.

Kamil Valenta napsal(a):

Kcko napsal(a):

Ahoj, chápu, ale tak dědit od složitější komponenty, plné konfigů atd. abych v poděděné třeba část složitého konfigu přepisoval nebo to takhle dělal jen kvůli sdílenému renderu mi nepřijde zcela dobré.

V úvodním dotazu je uvedeno, že se jen mění datasource. Pokud se mění i config, závislosti a kdo ví co ještě, tak bych si udělal komponentu v komponentě. Ta vnitřní dostane připravená data a udělá společný render, ta vnější se bude měnit a data připraví podle svého configu a dalších „střev“…

Ano, napsal jsem toho hodně, ale taky jsem psal, že řeším hlavně renderování, tj. jednotnou cestu k zobrazení (includovaný fragment, komponenta s parametrem v renderu, pak se k tomu přidala komponenta v komponentně atd ..). A to co ty popisuješ už tu padlo a já se o to nepřu ;-)