Nittro – novinka pro váš frontend (původně NetteJS)

Vypadá to skvěle, ale je to pro mě stavbou dost cizí. Chtělo by to nějakou sample appku, abych věděl jak to používat a v čem mi to vlastně pomůže. Neplánuješ nějaký sandbox?

@jahudka: Díky za jasnou odpověď.

Co se druhého bodu týče (že i já jsem frontenďák), tak to je na trochu filosofickou diskuzi. To, že občas skládám i nějkaý design pomocí bootstrapu a občas používám snippety, js confirm, závislé selectboxy a js validaci formulářů (vše pomocí předpřipravených řešení), to ze mě nedělá frontendového programátora. Stejně, jako bych neuznal za php programátora někoho, kdo si metodou pokus omyl upraví pár šablon ve wordpressu. Mluvím teď o profesi, nikoli o tom, k čemu nás okolnosti občas donutí.
A když už filosofuji, tak přemýšlím i o tom, jestli se dá uživatelské rozhraní admin modulu považovat za frontend :)

Šaman napsal(a):

@jahudka: Díky za jasnou odpověď.

Co se druhého bodu týče (že i já jsem frontenďák), tak to je na trochu filosofickou diskuzi. To, že občas skládám i nějkaý design pomocí bootstrapu a občas používám snippety, js confirm, závislé selectboxy a js validaci formulářů (vše pomocí předpřipravených řešení), to ze mě nedělá frontendového programátora. Stejně, jako bych neuznal za php programátora někoho, kdo si metodou pokus omyl upraví pár šablon ve wordpressu. Mluvím teď o profesi, nikoli o tom, k čemu nás okolnosti občas donutí.
A když už filosofuji, tak přemýšlím i o tom, jestli se dá uživatelské rozhraní admin modulu považovat za frontend :)

Podle mě úplně není :-) myslím že je úplně putna jestli se člověk „cejtí“ bejt frontenďákem nebo ne, podstatný je to, že je nějaká aplikace, někdo ji vyvíjí, a pokud ty jsi jedinej kdo píše její „frontendovou část“, pak jsi pro tuhle aplikaci „frontenďák“ – myšleno tak, že výsledná podoba a chování fronendu nezávisí na nikom jiným než na tobě. Neznamená to, že frontend je tvoje profesní specializace; přesto je frontend tvoje osobní zodpovědnost nebo jak to líp říct..

Samozřejmě že i uživatelské rozhraní admin modulu je frontend :-) používá ho přece uživatel. Ne tisíce uživatelů, ale pořád to je nějakej uživatel. Já poslední dobou dělám vlastně spíš věci, který maj jenom „admin modul“ – různý interní nástroje který používaj jednotky, max malý desítky lidí, a přijde mi, že musím UX řešit naopak o to víc – protože tady mám narozdíl od „public“ frontendu velmi přímou a detailní zpětnou vazbu o tom, jak se co používá, co koho kde brzdí nebo co by mohlo bejt intuitivnější atd.. A lidi často neví, co vlastně chtěj – myšleno tak, že si na něco zvyknou, a nepřemejšlej moc o tom, že (potažmo jak) by to šlo jinak.. přijde mi, že bejt v tomhle nějak proaktivní je trochu základ, jinak přestávám bejt programátor a stává se ze mě automat na plnění mechanickejch úkolů..

jahudka napsal(a):

Šaman napsal(a):

@jahudka: Díky za jasnou odpověď.

Co se druhého bodu týče (že i já jsem frontenďák), tak to je na trochu filosofickou diskuzi. To, že občas skládám i nějkaý design pomocí bootstrapu a občas používám snippety, js confirm, závislé selectboxy a js validaci formulářů (vše pomocí předpřipravených řešení), to ze mě nedělá frontendového programátora. Stejně, jako bych neuznal za php programátora někoho, kdo si metodou pokus omyl upraví pár šablon ve wordpressu. Mluvím teď o profesi, nikoli o tom, k čemu nás okolnosti občas donutí.
A když už filosofuji, tak přemýšlím i o tom, jestli se dá uživatelské rozhraní admin modulu považovat za frontend :)

Podle mě úplně není :-) myslím že je úplně putna jestli se člověk „cejtí“ bejt frontenďákem nebo ne, podstatný je to, že je nějaká aplikace, někdo ji vyvíjí, a pokud ty jsi jedinej kdo píše její „frontendovou část“, pak jsi pro tuhle aplikaci „frontenďák“ – myšleno tak, že výsledná podoba a chování fronendu nezávisí na nikom jiným než na tobě. Neznamená to, že frontend je tvoje profesní specializace; přesto je frontend tvoje osobní zodpovědnost nebo jak to líp říct..

Samozřejmě že i uživatelské rozhraní admin modulu je frontend :-) používá ho přece uživatel. Ne tisíce uživatelů, ale pořád to je nějakej uživatel. Já poslední dobou dělám vlastně spíš věci, který maj jenom „admin modul“ – různý interní nástroje který používaj jednotky, max malý desítky lidí, a přijde mi, že musím UX řešit naopak o to víc – protože tady mám narozdíl od „public“ frontendu velmi přímou a detailní zpětnou vazbu o tom, jak se co používá, co koho kde brzdí nebo co by mohlo bejt intuitivnější atd.. A lidi často neví, co vlastně chtěj – myšleno tak, že si na něco zvyknou, a nepřemejšlej moc o tom, že (potažmo jak) by to šlo jinak.. přijde mi, že bejt v tomhle nějak proaktivní je trochu základ, jinak přestávám bejt programátor a stává se ze mě automat na plnění mechanickejch úkolů..

Defakto píši stejný typ aplikací, různé správní aplikace. Využívám hodně modalová okna, tabulky, stránkování a vše funguje přes ajax anižby se uživatel ztratil nebo se nějaká data „ztratila z pohledu“ (někdy si uživatel stěžuje, že se mu po vykonání akce přescrolluje stránka). Je to hlavně z toho důvodu, že každá aplikace ať už jakkoliv velká, funguje na telefonu a uživatel nemusí zbytečně čekat nebo se bát „bílého přechodu“. Prostě zobrazím spinner a člověk má pocit, že s ním aplikace komunikuje. User Experience je velice důležitý.

Editoval GEpic (15. 2. 2016 5:07)

flamengo napsal(a):

@jahudka @chemix Ahoj, byl by doporučen plugin DropZone, ale nikde jsem nenašel demo ani žádnou informaci, jak vůbec použít, co to dělá, prostě vůbec nic. Nejdu toto někde? Díky za info.

Ahoj, promiň, jak připravuju dvojku, tak mi dokumentace lehce pokulhává. Jedna věc je použít build Nittra kterej dropzone obsahuje; pokud ještě nepoužíváš nittro#master, dropzone je v buildu bower balíčku nittro obsaženej automaticky, pokud už jedeš na masteru, musíš si nittro zbuildovat ručně. To jde pomocí gulp nebo grunt pluginu, readme na githubu by tě mělo postrčit správným směrem.

Co se samotnýho dropzone týče: dropzone je plugin pro usnadnění drag&drop file uploadů. Jednoduchý použití s klasickým nette/forms upload control vypadá tak, že vykreslíš formulář s normálním upload políčkem, a pak inicializuješ dropzónu z toho políčka; dropzóna si to políčko „hijackne“, což má několik efektů:

• dropzóna přebere validační pravidla políčka (validuje se normálně přes netteForms.js, takže umí všechno, co by uměl samotnej input)
• dropzóna přebere název POST parametru políčka
• dropzóna „vysává“ soubory vybraný pomocí původního políčka – když uživatel místo drag&drop vybere soubor(y) normálně z Choose…, dropzóna spustí stejný události jako kdyby uživatel soubory dropnul na příslušný místo ve stránce, včetně validace etc., a resetuje políčko – tím můžeš sjednotit chování interface nezávisle na metodě, kterou uživatel vybere soubory
• validační pravidla na původním políčku plus případně atribut „required“ dropzóna zruší, protože je zpracovává sama a kdyby tam zůstaly, nefungovalo by to správně (například právě required by selhávalo, protože dropzóna soubory z políčka hned po výběru „vysaje“)
• jeden z vedlejších efektů je, že není potřeba dělat žádné úpravy v backendu, protože z pohledu backendu se dropzóna chová stejně jako původní HTML input

Dropzóna jen obaluje události a provazuje data s formulářem – uživatelské rozhraní je zcela na tobě – dropzóně jen řekneš, na jakém elementu má sledovat drag&drop události, a pak posloucháš události z dropzóny a reaguješ – takže například když uživatel nad cílovej HTML element najede s dragovaným souborem, můžeš cílovej element nějak zvýraznit atd. Pro každej dropnutej soubor kterej splní validační pravidla pak dropzóna spustí událost „file“, v níž máš přístup k File objektu a můžeš s jeho pomocí například přidat soubor do nějaký viditelný fronty (platný soubory si dropzóna jinak ve frontě udržuje sama, opět jde jen o GUI).

Kompletní příklad použití dropzóny bude časem v distribuci; prozatím aspoň tady: https://gist.github.com/…80b9a7cb3b54

Editoval jahudka (4. 8. 2016 19:07)

@jiri.pudil: Ahoj, validation scope momentálně nittro ještě nepodporuje, dík za připomenutí! Do dvojky určitě poladíme. Co se týče přidávání do historie, máš v zásadě dvě možnosti: buď dál používat službu Page, která je by design dělaná na to, aby věci dávala do historie (a upravit trošku backend aby se to chovalo tak jak chceš), nebo jít víc low-level a použít službu Ajax.

Příklad pomocí Page service:

page.open({link addItem!}, 'GET', { id: 123 });
// udělá GET request na "/aktuální/url?do=add-item&id=123"

V backendu se pak chováš stejně, jako by ses měl chovat při zpracování podobného typu požadavku bez ajaxu – tj. provedeš co potřebuješ a uděláš redirect. Narozdíl od neajaxového zpracování ale nemusíš nutně dělat reálnej redirect, protože tady jde jen o to uložit do historie až tu finální adresu – což můžeš udělat takhle:

// řekni nittru, že si má vzít URL pro položku historie z payloadu
// místo původní adresy requestu
$presenter->payload->postGet = true;

// .. a samozřejmě dodej tu správnou adresu
$presenter->payload->url = $presenter->link('this');

// Tohle chování by se ještě mělo dělat jen pokud je request
// opravdu AJAXový, jinak by se měl udělat normální redirect
// pomocí `$presenter->redirect(...)`. Pokud používáš
// `nittro/nette-bridges` a `PresenterUtils` trait, můžeš si
// celou tuhle logiku zjednodušit na jeden řádek:
$presenter->postGet('this');

Metoda postGet() se chová pro tebe zvenku dost podobně jako metoda redirect() – uživatel je na konci na správné adrese ať už šel request AJAXem nebo ne – ale zásadní rozdíl je, že pokud request AJAXem šel, metoda postGet neodešle odpověď a místo toho pokračuje normální renderování snippetů, jen do payloadu už jsou přidané právě ty položky postGet a url. Takže ideální podoba backendu pokud tohle používáš je něco jako:

public function handleAddItem($id) {
    // .. proveď potřebné operace ..

    // .. zavolej postGet ..
    $this->postGet('this');

    // .. a tenhle kód už se zpracuje jen pokud
    // odpovídáš na AJAXový request - takže invaliduješ
    // příslušné snippety a nastavíš šablonu a zbytek
    // za tebe udělá nette + nittro :-)
    $this->redrawControl('items');
    $this->template->items = [...];
}

Pokud bys na to chtěl jít pomocí služby Ajax, můžeš použít něco jako:

di.getService('ajax')
    .get({link addItem!}, {id: 123})
    .then(
        function(response) { /* response je instance Nittro.Ajax.Response */ },
        function(err) { /* server nevrátil 2XX nebo jsi offline etc. */ }
    );

Editoval jahudka (23. 8. 2016 0:56)

@jahudka, bylo by prosím možné umístit někam veřejně zdrojáky na to demo, které bylo prezentováni na poslední poslední sobotě?

Zkouším Nitto, a když chci definovat prostor pro výpis flash zpráv <div n:flashes></div>, tam mi tento řádek vyhodí chybovou hlášku „Unknown attribute n:flashes“.

Ještě mám jednu otázku, řeším závislé položky formuláře. Na základě výběru položky v select boxu se zobrazí textová pole a nebo zatržítka. Šlo by to řešit také přes Nittro?

@jahudka v configu jsem to měl, pomohla mi aktualizace nittro/nette-bridges. Díky za opravu a za celé Nittro.

Ahoj, zkouším Nittro (2.0.5) a nelíbí se mi, že po ajaxovém odeslání formuláře se mu nastaví výchozí hodnoty (i když není ve snippetu). Zkoušel jsem tomu zabránit podle https://github.com/…o/wiki/Forms přidáním no-reset class na dotyčný element ve formu, ale nepomohlo to. Nepomohlo ani její přidání na form.

Dá se s tím něco dělat?

Jinak hodně těchhle základních / nejčastějších věcí je tady: https://github.com/…ck-reference

.. pravda, zrovna to zakazování resetu formulářů tam nebylo, mea culpa :-) doplněno.

Editoval jahudka (28. 3. 2017 21:36)

Ahoj, narazil jsem na menší problém. Pokud mám přes nittro otevřený dialog s formulářem, potvrdím ho, znovu otevřu a chci znovu potvrdit (odeslat) tak mi vyhodí chybu chrome do konzole: Uncaught (in promise) TypeError: Cannot use 'in' operator to search for 'frm-postForm' in undefined. Nejprve jsem myslel že je chyba někde u mě ale stejná se objevuje i v demu na githubu.

Když bych poté dialog otevřel znovu, zavřel přes btn s data-action="close", otevřel znovu a pokusil se odeslat tak se vše provede bez problémů.

Našel jsem další chybku, teď je tedy o dost menší a spíš taková kosměťárna, jde o to že při zavolání upravené prompt nittrem jsou tlačítka na potvrzení nebo zavření s data atributy napsána špatně. data-action=""confirm"" v data action jsou dvakrát úvozovky, koukal jsem na to v chromu i ve firefoxu a v obou případech jsou uvozovky dvě.

Imho: Jde nějak přepsat text který bude v tlačítkách v propmtě, pokud možno přes data attr.

v dnešní době bych řekl že vývoj webových aplikací prochází slušnou polarizací a širokým rozštěpem fronendového přístupu k vývoji (angular, react, …) a backendového (v případě php symphony, nette, apod…) … ten spor je celý vlastně o tom kdo opanuje statky a pozemky pod dnešními presentery a latte šablonami pokud se nemýlímm, zatímco pro backendový vývoj je browser jen displej kterému se obvykle dodávají celé obrazovky k vykreslení aniž by si klientská část musela řešit otázky stránkování, filtrování tabulek, obsluhy menu, zvýrazňování vybraných položek, pak fronendový dělá pravý opak, toto všechno přebírá a snaží se trivializovat backend jen na nějaké jednoduché restové api nebo webovou servisu nad základním modelem aplikace. De fakto tím zcela převzít úlohu dnešních nette presenterů a latte šablon a přesunout ji do klientské aplikační části. Zajímalo by mne zda lze považovat NETTE+NITTRO za nějaký počátek systematické snahy tento přerod skutečně dotáhnout do konce a zcela nahradit klientskou částí úlohu presenterů a latte šablon, nebo takto důsledné cíle a zásahy do architektury NETTE+NITTRO zatím nemá ?

Editoval zacatecnik27 (28. 4. 2017 8:52)

@zacatecnik27 nittro rozhodně nemá ambici dělat z nette jen „restovou servisu“ a nahradit presentery a latte na frontendu. Naopak integrace Nittra s Nette funguje jenom díky Nette presenterům a Latte. Takže ani dlouhodobě takovou ambici rozhodně nemám. U některýho typu webů je a vždycky bude naprosto adekvátní psát je jako single-page aplikace které jen komunikují s nějakým API a všechno se renderuje na klientu, ale u jiných typů webů naopak vždycky bude adekvátní renderovat je na serveru. Ty první jsou doménou Reactu, Angularu, Vue.js a podobných; ty druhé jsou záležitostí pro Nette, Symfony, Django a spol. A pro tu část té druhé skupiny která je postavená na Nette je tu Nittro.

Samozřejmě nevím, jestli se Nette jednou touhle cestou nevydá, ale Nittro s tím nepočítá a pokud se tak stane, Nittro přestane mít důvod existovat (protože React, Angular, Vue, …).

Editoval jahudka (28. 4. 2017 14:12)

@Blujacker zdravím, jsem rád, že vám to funguje :-) jestli jsem ten problém správně pochopil, je to úplně typickej adept na řešení pomocí životního cyklu snippetu.

Mějme ve stránce nějakej „hlavní“ snippet (třeba „content“) a v něm další kterej se jmenuje třeba „refreshme“ (to je ten, kterej budeme obnovovat). Zároveň předpokládejme, že jsou nainstalované nittro/nette-bridges a zaregistrovaná Nittro Latte macra. Nakonec ještě předpokládáme, že používáte build Nittra obsahující _stack knihovnu. V šabloně pak bude něco takovéhohle:

<div n:snippet="content">

	<div n:snippet="refreshme"></div>

	<script type="application/json">
	// následující dva řádky se díky _stack knihovně
	// postarají o spuštění JS kódu až po načtení Nittra
	window._stack || (window._stack = []);
	window._stack.push(function(di) {

		// definujeme si proměnnou pro uložení timeru
		// vně setup a teardown callbacků, abychom k ní
		// měli přístup z obou
		var tmr = null;

		// macro snippetId vpodstatě vrací
		// $template->escape($control->getSnippetId($arg)),
		// takže tady bude jeho výstup "snippet--content"
		di.getService('page').getSnippet({snippetId content})
			.setup(function(elem) {
				// elem === document.getElementById('snippet--content')
				// tenhle kód se spustí hned potom, co se hlavní
				// snippet objeví ve stránce a naplní HTML kódem

				// ...

				tmr = window.setTimeout(function() {
					// volej něco co překreslí snippet refreshme
				}, 123);
			})
			.teardown(function(elem) {
				// tenhle kód se spustí těsně před tím, než hlavní
				// snippet Nittro překreslí nebo odstraní ze stránky

				// takže tady po sobě můžeme uklidit :-)
				if (tmr) {
					window.clearTimeout(tmr);
				}
			});

	});
	</script>

</div> <!-- /#snippet--content -->

Je důležitý, že ten JS blok je vně snippetu „refreshme“, ale uvnitř snippetu „content“ – můžeme se na to koukat tak, že ten JS blok inicializuje snippet „content“, jehož je součástí – tudíž se spustí pokaždý, když se snippet „content“ překreslí touhle šablonou. setup() a teardown() callbacky se po zavolání zahazují, takže je to přesně to chování, které chceme (jinak by se snippet v této podobě inicializoval jen poprvé když se objeví ve stránce a příště už ne).

Editoval jahudka (27. 6. 2017 2:12)

Ahoj:

function nittroOpenLinkWorkaround(di, Url, url, params, transition)
{
        // ...
        // nezapomínej na "var" před lokální proměnnou!
        var finalUrl = Url.from(url);

        // tohle:
        for (var key in params) {
                finalUrl.setParam(key, params[key]);
        }

        // jde zjednodušit na:
        finalUrl.addParams(params);

        // ale hlavně, smaž / zakomentuj tohle:
        a.setAttribute('data-history', 'false');
        // ...
}

Editoval jahudka (29. 6. 2017 12:01)

@Blujacker s trochou zpoždení oproti původnímu plánu jsem teď releasnul aktualizovanou verzi nittro-page, ve který by mělo jít do parametru context.transition uvést selektor pro elementy, které se mají animovat – takže ten workaround výše by neměl být potřeba. Snad to bude fungovat :-) neměl jsem úplně čas to otestovat..

V SecuredPresenteru overuji identitu a pri selhani, provadim redirect na sign-in nicmene tento klasicky redirect se neprovede a misto toho v consoli dotanu

nittro.min.js:4 Uncaught (in promise) TypeError: Cannot read property 'trigger' of undefined
    at tmp._doDispatch (nittro.min.js:4)
    at <anonymous>

kleinpetr napsal(a):

V SecuredPresenteru overuji identitu a pri selhani, provadim redirect na sign-in nicmene tento klasicky redirect se neprovede a misto toho v consoli dotanu

nittro.min.js:4 Uncaught (in promise) TypeError: Cannot read property 'trigger' of undefined
    at tmp._doDispatch (nittro.min.js:4)
    at <anonymous>

Ahoj, a co ti přijde v odpovědi na ten první AJAX požadavek na SecuredPresenter? Dostaneš normálně JSON s „redirect“: „nějaká URL“?

@kleinpetr aha, už to asi mám, byl tam bug – zkus si updatnout Nittro, jestli si buildíš sám, tak npm update nittro-page (nebo npm update nittro, podle toho co máš v package.json), jinak si stáhni aktuální build z https://nittro.org/download

@DominikDvorak94 ahoj, to první je warning Nittra – nedávno jsem udělal takovej upgrade dialogů, jehož smyslem bylo řešit otevírání a zavírání dialogů trochu komplexnějc než to bylo doteď. Dialogy teď musí, podobně jako komponenty v Nette, mít jméno; zároveň existuje několik různejch typů dialogu který se používají na různý věci – základní typ funguje na všechny situace kdy uvnitř dialogu je normální DOM, ale třeba FormDialog má navíc API pro práci s formulářem uvnitř dialogu, dělá autofocus atd. IframeDialog pak umí v dialogu zobrazit iframe a řeší nějaké přechodné stavy a tak. A nakonec občas vznikne situace, kdy se o případném zavření dialogu rozhoduje až na backendu – např. když v dialogu zobrazíš formulář, chceš ho většinou zavřít až tehdy, kdy projdou i server-side validace, jinak ho chceš nechat zobrazenej a vyrenderovat v něm nějaký chybový hlášky atd. Proto se stávající konvence zavřít aktivní dialog při prvním dalším ajax requestu rozšířila o pár nových feature.

Typické workflow je takové, že otevřu dialog pomocí data-dialog, a uvnitř dialogu pak všechny odkazy / formuláře které mohou způsobit že dialog zůstane otevřený mají data-dialog="self"; v obsluze příslušných signálů pak kromě obvyklých redrawControl(...) a případne postGet(...) ještě volám metodu closeDialog(<nazev>) (ComponentUtils trait z nittro/nette-bridges), která se postará o to, že dialog na client side se zavře a zahodí. Zároveň existuje v ComponentUtils ještě metoda openInDialog(<nazev>, <snippet nebo url>[, <typ>]), která umí otevření dialogu vyvolat ze serveru – tím by třeba šlo řešit nějaký bezpečný confirm dialogy (bezpečný ve smyslu že fungujou i bez JS – jen by se nezobrazily v dialogu).

Pokud chceš nějakej celej funkční example, mrkni se na Nittro Demo, konkrétně na PostPresenter a jeho šablony default.latte a form.latte, kde se to používá.

To druhý ale nevím – Nittro myslím s data URI moc nepracuje (jestli vůbec), nemáš k tomu nějakej trace kterej by pomohl odhalit kde to vzniká?

Ages napsal(a):

Ahoj, nasadil jsem Nittro na svůj projekt a můsím říct že je to vážně supr :) jen jsem narazil na menší zádrhel a to že se mi přepisuje $title na původní hodnotu
Struktura šablon je:

<!-- @layout.latte -->
<html>
<head>
<title n:snippet="title">{ifset $title}{$title|stripHtml} | {/ifset}Super Web</title>
</head>
...

<!-- test.latte -->
{extends '../@layout.latte'}
{var $title = 'Test'}
{block content}
...

Takto mám postavenou celou aplikaci a před nasazením Nittro se mi normálně generovaly správně nadpisy, ale nyní když přejdu jinam se mi nejprve změní title na správnou v tomto případě na Test | Super Web a pak se přepíše zpět na původní hodnotu.
Změna je téměř nepostřehnutelná a ano snippet title mám nasteven pro defaultní překreslování.

Má někdo nápad co by to mohlo způsobovat?

Ahoj, taky se mi to chovalo zvláštně, tak title upravuju tímto způsobem:

public function renderDefault()
{
	if($this->isAjax()){
		$this->payload->title = 'Super titulek';
	}
}

a funguje to korektně.