Nittro – error in Nextras/Datagrid

@jahudka Could you provide more intel what's the voodoo? Datagrid behavior is pretty standard.

I've tried Datagrid 3.0@rc with Nittro 2.0 and it seems to work pretty well, with only exception: forms are not send by ajax. I have no idea how to force nitro to do that.

The way I see it, what I'd need in order to be able to make a Nittro extension to fully support the Datagrid component is this:

• Make the <thead>, <tbody> and <tfoot> tags snippets
• Update the component's server-side code to only redraw them when needed (which means redraw the <thead> only when sorting changes and the <tfoot> only when the current page or filtering rules change)

Then I could make a JS extension / bridge that would add the proper data attributes to the <tbody> to make the dynamic snippets work (even with client-side sorting that would stay up to date with the current sorting mode), add transition effects, apply client-side dynamic snippet removals so that you don't need to redraw the whole table when a row is removed (this would also need server-side support, but that only means not rendering any snippets when rows are removed) and it should still be compatible with the current nette.ajax.js implementation, but also behave nicer with Nittro in the picture ;-)

hrach wrote:

Well, not really. You define a static snippet “rows” here – which means it's a wrapper for the whole table, but the dynamic snippets are the rows within <tbody>

Imo this is wrong assumption. Latte doesn't force you to put dynamic snippets as direct child. See this check which travers indefinitely, until it finds static snippet.

Yes, you're right about that – but if you take into account what dynamic snippets are usually used for (dynamic content which can also get added or deleted, apart from getting updated) then it's quite clear that the front end must be able to deal with that kind of use cases – and Nittro does that by requiring you to adhere to a specific DOM structure, in exchange for ease of use in that making dynamic snippets work is a matter of writing a single Latte macro (which itself translates to one data attribute and one class).

so there is absolutely no way any front-end library could possibly know how to deal with the dynamic snippets

The problem may be here a fact, that your library does something which it shouldn't – or better, dynamic snippets aren't desinged for. You should update only that elements of which html id and contents is returned from backend.

Yes, I'm doing that when you're just updating snippets (even for dynamic snippets), but if the backend returns a snippet which doesn't yet exist in the page then there's nothing to update – as is the case when the snippet is new. I don't know what dynamic snippets were designed for, but limiting their usage to updating existing content seems to be quite a drastic underestimation of what they could be used for ;-)

I was referring to as “voodoo” was the way the dynamic snippets are rendered

Well, there is some voodoo in the backend side, but not in the HTTP interface side.
Datagrid works with ajax quite openly:

If you send ajax requires (x-requsted-with) → it returns array of snippets – their ids and contents, which should be replaced. nothing more. Sometimes it returns ids of rows – so it updates only specific rows, sometimes it returns only one snippet – the general table.

Yeah, that's mostly true and you're quite right that I shouldn't care how it's done on the server side – and I mostly don't, except it made it harder for me to understand how it works, hence “voodoo” :-)

it's overkill to redraw the whole table each time

Please, double check the behavior. The whole datagrid is redrawn only when needed – e.g. pagination. There is no point to sned seprately each of td's instead of the whole table.

Okay, it might have been a misunderstanding on my end (might've been inspecting different requests in the DevTools).

wouldn't need to refresh event handlers

Sorry, but this is so 2010. Nowadays, we add one event handler and check for the source when the event happend, don't we? ;) I mean $('.grid').on('click', 'a', function() {}).

You don't have to explain event delegation to me, it's your end-users I'm worried about ;-)

Another thing is that the way dynamic snippets work means you shouldn't apply dynamic classes to the row snippets themselves,

Yes, this is wrong demo, this is just a little demonstration of some behaviour, which may make sence when do you don't need inline edit.

Ok

Aaaaah, it's solved! The magic is in async defer.

Glad it helped :-) some of the scripts probably need document.body which wouldn't be available if the script was executed synchronously in the <head> section. I'll get around to moving the DOM ready checking before that so that it works both ways..

Resolution: Datagrid 3.0 & Nittro 2.0 works generally ok! The only missing is some custom javascript, which would close previously inline-edit-open rows. Simply, the logic here: https://github.com/….datagrid.js I wonder if it's simple to extend Nittro to do similar job.

It most definitely should be – just tell me exactly what the original script is intended to do :-) I can read JavaScript, but as I've never really used nette.ajax.js I don't have the faintest idea how it's supposed to work :-)

EDIT: ohh, just found out – you probably mean that the DataGrid can only have one row open in inline edit mode and without AJAX that happens automatically, but with AJAX if you edit one row and then another without saving or cancelling the first edit, you'll have two rows active at the same time.. And if I understand it correctly, the current script is solving that by changing all the “edit” buttons' hrefs? Oh boy..

Okay, try this after the datagrid render:

<script type="application/javascript">
	(window._stack = window._stack || []).push([function (di, DOM) {
		DOM.getByClassName('grid').forEach(function (grid) {
			DOM.addListener(grid, 'click', function (evt) {
				var link = DOM.closest(evt.target, 'a'),
					frm = grid.getElementsByTagName('form').item(0);

				if (link && link.hasAttribute('data-datagrid-edit')) {
					evt.preventDefault();

					var btns = frm.elements.namedItem('edit[cancel]') || [],
						data = {};

					if (btns.tagName) {
						btns = [btns];
					}

					data[DOM.getData(grid, 'grid-name') + '-cancelEditPrimaryValue'] = btns
						.map(function (btn) {
							return DOM.getByClassName('grid-primary-value', DOM.closest(btn, 'tr'))[0].value;
						})
						.join(',');

					di.getService('page').open(link.href, 'get', data);
				}
			});
		});
	}, {
		DOM: 'Utils.DOM'
	}]);
</script>

If it works for you same as it does for me, I'll write it into an actual Nittro extension and add it to DataGrid via PR :-)

Last edited by jahudka (2017-03-03 22:15)

You don't have to explain event delegation to me

Yeah, I know, I was just trolling :-D

I don't know what dynamic snippets were designed for, but limiting their usage to updating existing content seems to be quite a drastic underestimation of what they could be used for ;-)

I'm getting to understand what your lib also can do! +1 Still, some doc would be needed :) For now, fortunatelly, Nextras Datagrid does need this behavior, it doesn't do that (“the backend returns a snippet which doesn't yet exist in the page”).

just tell me exactly what the original script is intended to do

• filtering form:
  • pressing enter in input “sends” the filtering form
  • choosing value in select “sends” the filtering form
• clicking td with ctrl “clicks” the inline edit button
• pressing enter in inline-edit input “savs” the inline-edit form
• after each ajax change of the form it:
  • collects the ids of opened inline edit (should be just one)
  • updates inline-edit links to contain and id of row, which should be closed.
  • why: after clicking inline edit button, XHR sends a request to the backend with the id of the row. Backend recognize it wants only one row inline edit, therefore it renders only one row – dynamic snippets and send it only that to the frontend; however, because it's rendering only one row, the previously “inline-edited” tr stays “open”; that's wrong at least for now, because the whole grid is one html form and backend doesn't duplicate the inline-edit inputs for each row, so data would be rewritten with the last inline-edit row… I hope it's clear what is the desired behavior.

so you probably could just apply the nittro-snippet-container class and data-dynamic-mask attribute to the <tbody>

Hey, I've read the docs and I'm starting to get this. :-)

jahudka wrote:

hrach wrote:

Well, not really. You define a static snippet “rows” here – which means it's a wrapper for the whole table, but the dynamic snippets are the rows within <tbody>

Imo this is wrong assumption. Latte doesn't force you to put dynamic snippets as direct child. See this check which travers indefinitely, until it finds static snippet.

Yes, you're right about that – but if you take into account what dynamic snippets are usually used for (dynamic content which can also get added or deleted, apart from getting updated) then it's quite clear that the front end must be able to deal with that kind of use cases – and Nittro does that by requiring you to adhere to a specific DOM structure, in exchange for ease of use in that making dynamic snippets work is a matter of writing a single Latte macro (which itself translates to one data attribute and one class).

so there is absolutely no way any front-end library could possibly know how to deal with the dynamic snippets

The problem may be here a fact, that your library does something which it shouldn't – or better, dynamic snippets aren't desinged for. You should update only that elements of which html id and contents is returned from backend.

Yes, I'm doing that when you're just updating snippets (even for dynamic snippets), but if the backend returns a snippet which doesn't yet exist in the page then there's nothing to update – as is the case when the snippet is new. I don't know what dynamic snippets were designed for, but limiting their usage to updating existing content seems to be quite a drastic underestimation of what they could be used for ;-)

I was referring to as “voodoo” was the way the dynamic snippets are rendered

Well, there is some voodoo in the backend side, but not in the HTTP interface side.
Datagrid works with ajax quite openly:

If you send ajax requires (x-requsted-with) → it returns array of snippets – their ids and contents, which should be replaced. nothing more. Sometimes it returns ids of rows – so it updates only specific rows, sometimes it returns only one snippet – the general table.

Yeah, that's mostly true and you're quite right that I shouldn't care how it's done on the server side – and I mostly don't, except it made it harder for me to understand how it works, hence “voodoo” :-)

it's overkill to redraw the whole table each time

Please, double check the behavior. The whole datagrid is redrawn only when needed – e.g. pagination. There is no point to sned seprately each of td's instead of the whole table.

Okay, it might have been a misunderstanding on my end (might've been inspecting different requests in the DevTools).

wouldn't need to refresh event handlers

Sorry, but this is so 2010. Nowadays, we add one event handler and check for the source when the event happend, don't we? ;) I mean $('.grid').on('click', 'a', function() {}).

You don't have to explain event delegation to me, it's your end-users I'm worried about ;-)

Another thing is that the way dynamic snippets work means you shouldn't apply dynamic classes to the row snippets themselves,

Yes, this is wrong demo, this is just a little demonstration of some behaviour, which may make sence when do you don't need inline edit.

Ok

Aaaaah, it's solved! The magic is in async defer.

Glad it helped :-) some of the scripts probably need document.body which wouldn't be available if the script was executed synchronously in the <head> section. I'll get around to moving the DOM ready checking before that so that it works both ways..

Resolution: Datagrid 3.0 & Nittro 2.0 works generally ok! The only missing is some custom java, which would close previously inline-edit-open rows. Simply, the logic here: https://github.com/….datagrid.js I wonder if it's simple to extend Nittro to do similar job.

It most definitely should be – just tell me exactly what the original script is intended to do :-) I can read JavaScript, but as I've never really used nette.ajax.js I don't have the faintest idea how it's supposed to work :-)

EDIT: ohh, just found out – you probably mean that the DataGrid can only have one row open in inline edit mode and without AJAX that happens automatically, but with AJAX if you edit one row and then another without saving or cancelling the first edit, you'll have two rows active at the same time.. And if I understand it correctly, the current script is solving that by changing all the “edit” buttons' hrefs? Oh boy..

Okay, try this after the datagrid render:

<script type="application/javascript">
	(window._stack = window._stack || []).push([function (di, DOM) {
		DOM.getByClassName('grid').forEach(function (grid) {
			DOM.addListener(grid, 'click', function (evt) {
				var link = DOM.closest(evt.target, 'a'),
					frm = grid.getElementsByTagName('form').item(0);

				if (link && link.hasAttribute('data-datagrid-edit')) {
					evt.preventDefault();

					var btns = frm.elements.namedItem('edit[cancel]') || [],
						data = {};

					if (btns.tagName) {
						btns = [btns];
					}

					data[DOM.getData(grid, 'grid-name') + '-cancelEditPrimaryValue'] = btns
						.map(function (btn) {
							return DOM.getByClassName('grid-primary-value', DOM.closest(btn, 'tr'))[0].value;
						})
						.join(',');

					di.getService('page').open(link.href, 'get', data);
				}
			});
		});
	}, {
		DOM: 'Utils.DOM'
	}]);
</script>

If it works for you same as it does for me, I'll write it into an actual Nittro extension and add it to DataGrid via PR :-)

I was getting the same issue earlier but it resolved after go through this thread conversation.